Aller au contenu
Dgille

Heating Manager - PID and more

Recommended Posts

 

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....:2:

 

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é par Dgille
  • Like 4

Partager ce message


Lien à poster
Partager sur d’autres sites

Bah dis donc, sacré boulot, bravo !!

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

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

  • Like 2

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par Dgille
  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

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, 5true)

par

local err = checkDevice(condition, 5true); 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 :)

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

@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).

 

image.png

 

 

 

Heating Manager PID 4.01.lua

Modifié par Felig
  • Thanks 1

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par Felig
  • Like 2
  • Thanks 1

Partager ce message


Lien à poster
Partager sur d’autres sites

×