Heating Manager - PID and more

[Dgille]

 

Winter is coming !

 

Cela fait un moment que jalouse les thermostats connectés NetAtmo et Nest, mais le coté connecté me gène. Les beaux thermostats MCO ne gèrent la régulation que par hystérisis, bref, il fallait une solution pour nos box préférées.

 

En y réfléchissant, l'excellent Heating Manager de @OJC fourni déjà presque tout le nécessaire, voici donc une version 3.2 qui intègre une gestion de la régulation par PID, en plus des autres modes déjà présents.

 

Le fonctionnement de l'ensemble reste le même, donc si vous êtes nouveaux sur le sujet, commencez par :

 

Citation

 

 

J'en ai profité pour intégrer quelques corrections remontées par les autres membres du forum et d'autres que j'ai découverte.

 

Pour activer le mode PID, il suffit de remplacer les directives setHysteresisMode ou   setProportionalMode par  setPIDMode(default_Kp, default_Ki, default_Kpd, cycle, minCycle).

 

La partie la plus difficile est de fixer les coefficients. Il y a pléthore d'articles sur le sujet, donc interrogez Google !

 

Je vous en propose par défaut, mais pour faire simple :

      - la partie proportionnelle peut être fixée autour de 50 à 60 %

      - la partie intégrale peut être fixée à 20 % de la partie proportionnelle

      - la partie dérivée aux 2/3 de la partie intégrale.

 

Tout cela est à ajuster à votre installation et dépend des caractéristiques de celle-ci, de votre isolation, du type de chauffage et de son inertie, etc....

 

Ayez à l'esprit que le mode PID n'est pas adapté à de brusques variations de consigne, donc si vos règles font de votre thermostat un yoyo, oubliez le PID et utilisez les autres modes !

 

La régulation PID peut générer des temps d'activation très court quand le système est stable, j'ai donc introduit un nouveau paramètre global minP (fixé à 2%), pour ne pas activer chaudières et convecteurs sur de très courtes durées, ce qui est inutile voire néfaste pour l'installation.

 

Amusez vous bien !

 

 

Voici le code de la scène :

 

Heating-manager-scene with PID-3.2.lua

 

Anticipation de chauffe :

Un peu de théorie:

 

En fouillant sur internet, je n'ai pas trouvé beaucoup de littérature sur l'anticipation de chauffe, je n'ai pas beaucoup cherché non plus...
L'algo imaginé consiste à effectuer une approximation linéaire de la montée en température de la pièce à chauffer lors des cycles de chauffe de Heating Manager. Pour ce faire, une fonction d'apprentissage alimente une matrice creuse dont les couples {température de départ, température d'arrivée) donnent une durée pour y parvenir, généralement, la durée du cycle.

 

Pour déterminer la durée d'anticipation, une fonction récursive va chercher un chemin dans cette matrice pour déterminer la durée nécessaire pour aller de la température actuelle à la température de la consigne.

La courbe résultant de la régulation PID ou UBat de Heating manager est en fait découpée en petits morceaux de droite si on en faisant une représentation géométrique.

 

On compare ensuite la durée nécessaire pour arriver à la consigne cible à l'heure H à l'heure actuelle.

 

Passons à la pratique:

 

Cette version de Heating Manager, réalise un apprentissage basé sur les cycles de chauffe, en permanence, même lorsque la fonctionnalité est désactivée (par défaut). Pour avoir une anticipation fiable, il est conseillé de laisser tourner ainsi quelques jours pour constituer la matrice, stockée dans une table Lua, sauvegardée dans la VG HeatingManagerAA.

 

L'apprentissage moyenne les températures de fin de cycle, pour compenser les périodes de chauffe rapide en demi saison et les périodes de chauffe lente en hiver. En cas de brusque changement des conditions climatiques, l'anticipation pourra ne pas être optimale pendant quelques jours, le temps que la matrice s'adapte. Il faut prévoir dans ce cas une marge de sécurité sur vos panneaux, j'intègrerai peut être celle-ci dans une prochaine version.

Pour activer la fonctionnalité, il suffit d'activer la ligne

 self:setAutoAdapt(true)

dans la section configuration de la scène.

Par contre, pour anticiper les cycles, il faut un planning, vous devez donc vous appuyer, soit sur le Heating Provider, soit sur les panneaux de chauffage de la HC2.

Les horaires indiquée deviennent ceux ou la température doit être atteinte.

 

Si vous utilisez les panneaux de chauffage et si une température de vacance ou une dérogation de consigne est en cours, la scène en tient compte et désactive l'anticipation de chauffe.

 

La scène vérifie que le temps d'anticipation ne dépasse pas 3h par défaut. Si vous devez chauffer 6h à l'avance pour obtenir votre consigne, c'est que vous avez un problème de chauffage ou de porte ouverte....

 

J'ai ajouté également une version du VD Heating Provider intègrant la fonctionnalité AutoAdapt.

 

Il aura besoin, en plus du planning, de connaitre la sonde de température de la zone et de l'ID déclaré dans la scène pour identifier le dispositif de chauffe. Deux fonctions pour cela :

 

HeatingManager:addheater("lblZoneJour", "id du qubino ou du FGS" )
HeatingManager:addprobe("lblZoneJour", {id de la sonde,"value"} )

 

Je pense que l'algo peut encore être amélioré, mais je partage cette première version avant de passer à la HC3...

 

Amusez vous bien....

 

 

 

 

Heating_Provider with AutoAdapt 3.4.vfib

heating-manager-scene with PID and AutoAdapt.lua-3.5.lua

Heating Manager V4.0 HC3 BETA with PID and AutoAdapt.lua

Modifié le 29 novembre 2020 par Dgille

[Nico]

Bah dis donc, sacré boulot, bravo !!

[Dgille]

Merci, nos box méritent le meilleur (algo) !

[Dgille]

Et voila, publication de la version 3.4 avec anticipation des cycles de chauffage...

[Dgille]

Bonjour, une nouvelle version 3.5 pour HC2, dans le premier post, qui gère mieux l'anticipation de chauffe lorsque l'horaire de démarrage se situe le jour précédent.

 

En bonus, une première version 4.0 BETA de la scène pour HC3. La version sous forme de QA est en préparation !

 

Bonnes fêtes de fin d'année !

 

 

 

Modifié le 29 novembre 2020 par Dgille

[XSRomano]

merci je vais suivre ce post en attendant la QA

[Felig]

Bonjour @Dgille et merci pour ce gros travail. Un thermostat sans PID on est d'accord ça ne vaut rien! J'avais de mon côté aussi amélioré le programme de Olivier Meyer pour l'adapter à mon environnement, et le rendre plus convivial (je suis un maniaque des messages dans la console qui expliquent ce que fait le programme). Du coup j'ai passé pas mal de temps à fusionner ma version avec la tienne, ce qui m'a permis de trouver quelques bugs supplémentaires:

 

1) dans addHeater() j'ai remplacé

 if (self.HMCF.kP.start)

par

if isnil(self.HMCF.kP.data[tostring(idHeater[1)])

 

2) Toujours dans addHeater, j'ai remplacé

properSonde       = isnil(idSonde),

par

properSonde       = isnotnil(idSonde),

 

3) dans setIndoorSonde(), il y a une typo: j.TemperatureSonde doit être remplacé par j.temperatureSonde

 

4) dans checkConfiguration / checkRoomArray(), j'ai remplacé

checkRoom(room)

par

     err = checkRoom(room); if isnotnil(err) then return err end

(err est bien mis à jour dans la fonction checkRoom, mais ce n'est pas renvoyé dans la fonction checkConfiguration)

 

5) de même, dans checkConfiguration / checkCondition() j'ai remplacé

      checkVariable(condition[1])

par

local err = checkVariable(condition[1]); if isnotnil(err) then return err end

et

  checkDevice(condition, 5, true)

par

local err = checkDevice(condition, 5, true); if isnotnil(err) then return err end

 

6) Enfin, dans startHeater() j'ai remplacé

 _f:call(item.heater, "pressButton", item.actions[1])

par

 _f:call(item.idHeater, "pressButton", item.actions[1])

 

Voilà, rien de grave, vu que dans la majorité des configs ces lignes de code ne seront pas utilisées, mais si ça peut être utile pour le développement de la QA

 

 

[Felig]

Autre sujet plus intéressant:

 

Sur la régulation PID (j'ai mis du temps à comprendre le fonctionnement), j'ai testé une modification que je trouve assez efficace: au lieu de calculer l'erreur cumulée (CumError) comme étant la somme des [10] dernières erreurs*, je la calcule comme la somme cumulée de toutes les erreurs. Ça simplifie le programme (pas la peine de mémoriser les 10 dernières erreurs, on mémorise juste la somme, et on ajoute la dernière erreur*). Mais surtout ça évite d'avoir des données faussées par la sortie de l'erreur la plus ancienne de l'échantillon à chaque cycle, qui peut compenser l'impact que devrait avoir la dernière erreur. Bref, je trouve que ça donne un meilleur résultat. A tester.

 

(*) pour les non spécialistes en langage PID, erreur = différence entre la température actuelle et la consigne du thermostat

[Dgille]

Merci, je corrigerai dès que possible , je suis hospitalisé pour le moment.

[Felig]

@Dgille Désolé de l'apprendre, j'espère que ce n'est pas grave, et tous mes vœux de rétablissement rapide.

 

J'en profite pour partager ma version de Heating Manager, développée en parallèle de la tienne, mais incluant ton ajout sur la régulation PID notamment. Je n'ai pas intégré la partie Anticipation de Chauffe. Mes modifications sont résumées dans les notes de version, mais en gros j'ai ajouté la possibilité de piloter HM avec un virtual device dans chaque pièce (soit pour récupérer la consigne du thermostat, soit pour afficher des infos sur le taux d'activité des radiateurs, soit les deux) (possibilité qui était dans la version originale de O Meyer mais dans un format différent). J'ai beaucoup travaillé sur la robustesse et la simplification du code (je l'utilise pour mon chauffage, et Madame ne plaisante pas avec ça!) et pour ceux qui aiment comprendre ce que fait le programme, il y a la possibilité d'activer une option "debug" qui donne beaucoup (trop) d'infos. Le troisième axe d'amélioration est la régulation PID, avec notamment un cycle propre à chaque radiateur, ce qui permet une synchronisation sur les temps de réveil de la sonde de température de la pièce. Il y a aussi des petits ajouts de confort comme la possibilité de déclencher des événements en fonction de l'heure, ou la possibilité de configurer les pièces en utilisant leur nom plutôt que leur ID.

 

Je ne connaissais rien à PID avant, mais honnêtement le résultat est impressionnant: la température dans la chambre parentale reste constante au dixième de degré près. Je suis sûr que c'est mieux que le STR321 qu'on ne peut pas vraiment adapter à chaque pièce. L'autre grand avantage de HM par rapport au STR est qu'en cas d'ouverture de fenêtre par exemple, le temps de réaction est immédiat, pas la peine d'attendre le réveil du thermostat pour transmettre une nouvelle consigne. Et le retour d'infos donnés par le programme est intéressant et très utile pour optimiser la consommation: quand il fait froid dehors, on se rend compte que baisser la consigne de 0.5° a un gros impact sur le taux d'activité des radiateurs.

 

PS: Si vous souhaitez tester le programme sans perturber votre système de chauffage actuel, il y a une option "simulation". Pour l'utiliser vous devez quand même paramétrer au moins un radiateur existant (si le radiateur n'est pas valide le programme vous avertira et n'ira pas plus loin). Dans ce mode le programme ne touchera pas aux radiateurs, mais ça permet de tester si votre configuration est valide, y compris pour les événements.

 

C'est une version pour HC2 (je n'ai pas encore de HC3).

 

 

 

 

Heating Manager PID 4.01.lua

Modifié le 21 février 2021 par Felig

[Felig]

PID POUR LES NULS

 

Si vous êtes comme moi, vous ne connaissez rien aux théories de régulation, et vous voulez avant tout un thermostat clé en main qui ne demande pas d'expertise, comme le SRT321. La bonne nouvelle c'est qu'un thermostat PID marche plutôt bien même avec des paramètres "au pif". Mais après plusieurs semaines d'utilisation, j'ai acquis un peu d'expérience pratique qui pourra vous être utile si vous recherchez une régulation (et une consommation) optimisées. Ce n'est que de la pratique, donc par avance mes excuses aux experts (l y a plein de littérature et d’équations complexes sur Wikipedia).

Le fonctionnement de Heating Manager (développé initalement par Olivier Meyer) est le suivant : toutes les 15 minutes (délai réglable), le programme va allumer le chauffage pendant une durée comprise entre 0% et 100% du cycle (50% = radiateur allumé pendant 7m30s, etc.). Ce paramètre qu’on appellera POWER est la somme de trois « moteurs » : P, I et D (Proportionnel, Intégrale et Dérivée).

 

Pour comprendre comment fonctionnent ces 3 moteurs, il faut imaginer que votre radiateur est un véhicule sans freins, qui grimpe une route de montagne, qui doit atteindre le plus rapidement possible un point précis, et ensuite s’y maintenir sans bouger. Tant que le véhicule est loin du point d’arrivée, il roulera à sa vitesse maximum (POWER 100%). Mais en approchant, il devra ralentir progressivement (souvenez-vous, il n’a pas de freins). A partir de quelle distance du point devra-t-il ralentir ? C’est ce qui est déterminé par le moteur P : P = Kp x distance. Vous pouvez modifier le paramètre Kp pour chaque radiateur.

 

Quelle est la valeur optimale pour Kp ?

 

Exemple : Supposons Kp = 50. Si la température est de 18.1° et la consigne est de 20°, on aura P = Kp x distance = 50 x 1.9° = 95%. Le radiateur sera donc allumé 14m15s sur un cycle de 15m. Si on avait fixé Kp à 100, la "vitesse" ne se réduirait qu'au-delà de 19°.

 

Conclusion: Avec une valeur de Kp à 50, la décélération commence dès que la distance est inférieure à 2°. Si Kp =100, la décélération commence quand l'écart entre la consigne et la température < 1°.

La valeur Kp idéale dépend de l’inertie de votre radiateur. Si votre radiateur est un camion (radiateur moderne), Kp doit être plus faible. Si votre radiateur est un scooter (radiateur électrique « grille pains ») Kp doit avoir une valeur élevée. La surface à chauffer entre aussi en compte: dans une grande pièce un radiateur aura moins d'efficacité, et il vaut mieux un Kp élevé. Dans une petite pièce avec un radiateur moderne j'ai mis Kp à 50. Dans la suite parentale, je trouvais les temps d'ajustements un peu longs, et j'ai augmenté à 100. Plus Kp est élevé, plus le radiateur sera réactif. Je vous conseille de commencer avec 100 et de baisser si le radiateur a tendance à dépasser la consigne au lieu de converger. Si le radiateur est peu puissant, une valeur supérieure à 100 sera sans doute plus adaptée. N'ayez pas peur de faire des erreurs  : un Kp trop faible va faire que le radiateur mettra plus de temps à atteindre l’objectif (rien de grave), un Kp trop élevé va le conduire à le dépasser un peu (rien de grave non plus). Note: Le paramètre Kp est surtout important en cas de changement fréquent de consigne: si la consigne est stable, le paramètre Kp aura peu d'impact.

 

Supposons maintenant que la température est parfaitement alignée avec la consigne à 20°. On aura une distance égale à 0 et donc P = 0. Et pourtant, si le radiateur ne chauffe pas, la température va baisser, et on va s’éloigner de l’objectif. Rappelez-vous, le véhicule est sur une route de montagne : s’il n’accélère plus, il va reculer. C’est là qu’intervient le deuxième moteur : I = Ki x cumError. Ce moteur est intelligent car il doit s’ajuster en fonction de la pente de la route. S’il fait très froid dehors il faudra un moteur puissant pour maintenir la température. La température extérieure étant variable, ce paramètre doit s’auto ajuster en permanence. Cet auto ajustement se fait tout seul par le paramètre cumError (somme des erreurs) : à chaque cycle, le programme va regarder à quelle distance il est de l’objectif (erreur = distance) et ajuster sa valeur en conséquence.

 

Quelle est la valeur optimale pour Ki ?

 

Exemple : Supposons Ki = 5 et cumError = 5. On a donc I = 5x5 = 25%. A la fin du cycle, supposons que la température soit 0.5° en-dessous de l’objectif, on ajoute cette erreur à la somme des erreurs précédentes, ce qui donne cumError = cumError + 0.5 = 5.5 ; le programme va donc chauffer un peu plus (I = 5 x 5.5 = 27.5% au lieu de 25% au cycle précédent).

 

Le paramètre I s’ajustant tout seul, la seule chose que vous pouvez déterminer c’est la vitesse à laquelle il va s’ajuster, avec le paramètre Ki. Si Ki est trop faible les ajustements vont être progressifs, et il faudra plus de cycles avant d’atteindre la température parfaite. Si Ki est trop élevé, les ajustements vont être brusques et vous risquez de dépasser l’objectif. Là aussi, le plus simple est l’expérience : regardez comment votre thermostat se comporte quand il est proche de l’objectif, et s’il met trop de temps à converger, augmentez Ki. Chez moi (radiateurs électriques modernes) je trouve que ça fonctionne bien avec 6. N'ayez pas peur de faire des erreurs, de gros ajustements ont un impact limité et Madame ne verra sans doute pas de différence.

 

Le troisième moteur D est moins important : il réagit en fonction de la variation des erreurs (c’est une sorte de dérivée) et en pratique son impact est minime chez moi. J’utilise un coefficient Kd de 3 (probablement trop faible), mais j’avoue que pour l’instant pas trop vu l’intérêt de ce facteur. Il est peut être plus important pour des chauffages avec une énorme inertie.

 

En résumé, deux messages importants :

1) Ne soyez pas inquiets. A moins de valeurs extrêmes, il n’y a pas de mauvaise valeur pour vos coefficients Kp, Ki et Kd. N’ayez pas peur de garder les valeurs par défaut ou de faire au pif, et vous verrez que le résultat sera quand même très bon. L’optimisation c’est bon pour les geeks comme moi qui râlent quand le thermostat reste pendant 2 heures à 19.9° alors que la consigne est 20°! Le thermostat SRT321 que nous utilisons tous a des coefficients en dur qui ne sont pas optimisés pour votre pièce, et ça ne l’empêche pas d’être efficace.

2) Have fun. Si vous êtes un peu geek, c’est intéressant de voir comment les cycles de chauffe s’ajustent en fonction de la température extérieure. On mesure mieux les problèmes d’isolation, via le % d'activité des radiateurs (qui peut être affiché sur un virtual device). Et c’est satisfaisant de battre les (rares) thermostats PID du commerce avec juste quelques lignes de code (la régulation PID tient sur moins de 10 lignes).

 

Modifié le 17 février 2021 par Felig

[Buddabye]

Bonjour a vous, je suis tres interessé pour la gestion du chauffage avec mes modile qubino qui ne sont pas reconus par climat de ma HC3. je cherche la solution a mon probleme et ce topic a l'air super interessant. Je n'ai jamais géré de LUA pour l'instant. Quelqu'un peut il m'aider a mettre ca en place svp ?

La QA est en cours de création mais pas de nouvelle depuis que @Dgille a été hospitalisé. J'espere que tu vas mieux au passage mon cher. As tu pu avancer depuis ?

Merci à vous tous pour vos réponses

[Dgille]

Bonjour, je suis toujours très malade, mais je vais publier le QA ds ma version stable dans quelques jours.

je vous laisse le faire évoluer ensuite, il n’y aura pas de nouvelles versions de mon côté.

 

merci

[Buddabye]

il y a 1 minute, Dgille a dit :

Bonjour, je suis toujours très malade, mais je vais publier le QA ds ma version stable dans quelques jours.

je vous laisse le faire évoluer ensuite, il n’y aura pas de nouvelles versions de mon côté.

 

merci

Oh je suis désolé de ce qui t'arrive mon cher. Ca n'a pas l'air sympa vu le temps à l'hôpital. C'est vraiment sympa de ta part de publier quand même la QA alors que tu as certainement d'autres choses à faire comme prendre soin de toi.
Quoi qu'il arrive je te souhaite le meilleur pour ta santé et espère te revoir sur pied rapidement.

[Dgille]

Bonjour, merci.

Comme convenu, voici le QA dasn la version en production chez moi, version 4.1, je n'ai pas pu intégrer les modifications de @Felig vu mon état, je vous laisse donc maintenant le faire évoluer à votre convenance.

 

Je n'assurerai aucun support de ce QA pour les mêmes raisons, désolé.

 

Bonne continuation à tous.

QA_Heating_Manager_4.1_sans_conf.fqa

[BertrandD]

Bonsoir à tous,

 

J'ai le regret de vous annoncer le décès de David, survenu ce dimanche 22 aout, après de longs mois de lutte contre la maladie. Ses funérailles ont eu lieu ce matin. Il est parti serein et apaisé.

J'ai travaillé 24 ans avec lui, et il m'avait initié à la domotique il y a quelques années. C'était un sujet de conversation récurent lors de nos pauses déjeuner.

Il va nous manquer....

 

Bertrand

Faire part deces David - 20210823091217.pdf

[fredokl]

Salut camarade.

[Lazer]

 

Repose en paix.

[TonyC]

Très attristé par cette terrible nouvelle. Sincère pensée pour sa petite famille. RIP David.

[Nico]

Terrible... Paix à lui et courage à toute sa famille !

[Felig]

Désolé, je n'ai pas consulté le forum pendant plusieurs mois, et là je me prends une grosse baffe avec cette nouvelle si triste, que David a visiblement vu venir et à laquelle il a su se préparer avec beaucoup de simplicité et de dignité de ce que je peux percevoir dans ses messages. On ne se connaissait pas, mais j'ai beaucoup travaillé sur son programme, et c'est comme construire quelque chose ensemble, ça crée des liens, d'autant que je viens de réaliser que nous avons pratiquement le même âge. Je n'ai pas encore osé passer à la HC3, car j'ai une config compliquée et plein de programmes à réécrire (y compris un GEA avec plusieurs fonctions personnalisées) mais c'est prévu dès que j'aurai quelques semaines de vacances, et je compte bien travailler sur son QA. Notre collaboration n'est pas finie!

David, repose en paix, et merci pour tout ce que tu as partagé.

@BertrandD Merci d'avoir partagé cette nouvelle avec nous.

Modifié le 30 novembre 2021 par Felig

[sweet38000]

Bonjour à tous

 

je tiens tout d'abord a remercier tous les intervenants du forum qui permettent de faire avancer les applications domotiques

 

l'enjeu me semble important au regard des couts de l'énergie qui explose : réguler (avec un PID)  la température de son logement à distance selon les besoins réels 

 

situation actuelle:

j'ai un plancher chauffant à eau sur 1 zone qui est actuellement régulé par une vanne 3 voies proportionnelle et un thermostat d'ambiance déporté (onde radio). ca marche très bien mais pas moyen d'intégrer ce système à ma HC2.

il y a 4 boucles 

 

solutions envisagées:

1/ piloter une vanne 3 voies avec un arduino par exemple et l'asservir en PID grâce à un capteur de température fibaro. (je n'ai pas trouvé de solution simple que je puisse mettre en œuvre)

2/piloter les vannettes des 4 boucles à l'aide de vannes motorisées (vu que je n'ai qu'une zone à contrôler cela me semple inutile)

3/commander la marche et l'arrêt du circulateur via un module actionneur FGS-214 et une température remontée par un motion sensor.

 

la solution 3 me semble adaptée mais reste le mode de régulation:

j'aimerais utiliser un thermostat virtuel avec une régulation de type PID (l'idéal pour réguler une température correctement)  

j'ai trouvé ce post et cela semble tout à fait correspondre à mon besoin mais à part installer le VD j'avoue ne pas savoir quoi faire des codes en lua proposés. 

 

pourriez-vous clarifier svp la procédure d'installation de la régulation PID svp? 

quel VD installer au juste? où déclarer son capteur et son actionneur qui vont être utilisé par le VD? a priori ca devrait suffire?

 

 merci de vos lumières 

[Felig]

Bonjour,

 

J'ai développé une nouvelle version du QA, avec une régulation PID. La principale différence avec les versions précédentes est qu'il faut utiliser un QA par pièce. Je ne l'ai pas posté plus tôt car j'attendais d'avoir quelques mois d'utilisation chez moi pour détecter d'éventuels problèmes. Je gère 4 pièces avec ce QA depuis le début de l'hiver et ça fonctionne très bien.

 

Il y a plusieurs onglets: main, config et tools. Il faut modifier uniquement l'onglet "config" (même logique que GEA). Il faut que tu indiques l'id de ton radiateur (en l’occurrence ta vanne). Il y a un paramètre optionnel Kp qui varie inversement en fonction de l'inertie du radiateur: pour un plancher chauffant, tu peux le mettre à 20 je pense. Ensuite il faut que tu indiques l'id de ton thermomètre, et c'est tout. Tu peux configurer des événements également. N'oublie pas de remplacer ma config par la tienne (effacer ce que tu n'utilises pas dans le fichier config).

 

En ce qui concerne le thermomètre il faut que son temps de réveil soit de 15 minutes max. La régulation PID a besoin de savoir la température à la fin de chaque cycle de 15 minutes pour ajuster les paramètres pour le cycle suivant. Si le temps de réveil est inférieur à 15 minutes, le programme le détectera et s'adaptera. J'utilise un SRT321 comme thermomètre (sans la fonction thermostat) car je le trouve plus fiable que les motion sensor, mais je suis un peu maniaque. Si tu n'es pas à 0.2 degrés près ça devrait être bon.

 

Surveille les logs au lancement, et à ta disposition en cas de besoin.

HM_PID_V5.fqa

Modifié le 3 janvier 2023 par Felig
Désolé je me suis trompé de sens: le facteur Kp doit être plus faible pour un chauffage avec grosse inertie comme un plancher chauffant. Cf. mon post PID pour les Nuls ci-dessus que j'aurais du relire plus tôt!

[sweet38000]

Hello Felig 

 

ca semble tout a fait correspondre à mon besoin  

 

je vais tester cela cette semaine et je te fais un retour 

 

merci mille fois du partage !

 

les économies d’énergies passent par une gestion intelligente du chauffage  

 

[jojo]

ta mise à jour arrive à point nommé : j'allais m'y attaque cette semaine ou WE prochain ...

 

Dans cette régulation, ne tient-t-on pas compte de la température extérieure ?

Autre (stupide) question : pourquoi devoir modifier le fichier config (je n'ai pas encore regardé), et pas simplement les variables du QA ?