Heating & Cooling Manager (PID HC3)

[Felig]

HEATING & COOLING MANAGER - THERMOSTAT PID POUR LA HC3 (QUICKAPP)

 

 

Je démarre un nouveau sujet pour que la dernière version soit plus facile à trouver. Le Heating Manager original a été développé par @OJC pour la HC2, et adapté ensuite par @Dgille pour la HC3. J'ai réécrit une grande partie du code pour essayer de le fiabiliser et le simplifier mais les ajouts les plus visibles sont l'interface QuickApp (utilisation mono pièce) et la possibilité de piloter des climatiseurs (demande spéciale de @jojo). J'ai enlevé les modes de régulation non PID et ajouté quelques fonctions de sécurité (recherche d'un autre capteur de température si le capteur par défaut n'est plus valide, test intensif de la configuration au démarrage, etc.). Il y aussi beaucoup de messages dans les logs pour suivre ce qui se passe (pour ceux que ça intéresse).

 

Ce QA est dédié à @Dgille qui a continué à le développer sur son lit d'hôpital pour nous alors qu'il se savait condamné. Remerciements à @jojo d'avoir pris le temps de le tester et pour toutes ses suggestions très utiles.

 

HCM peut être commandé facilement par GEA, mais il est aussi possible de configurer des événements spéciaux qui imposent une consigne prioritaire dans certaines conditions (par exemple consigne fixée à 5° tant qu'une fenêtre est ouverte). Une fois l'événement terminé, la consigne précédente est rétablie et l'utilisateur peut reprendre la main. Il est aussi possible de le piloter par une zone de climat (ex. panneau de chauffage). Un mode "simulation" est disponible si vous voulez le tester sans perturber votre installation actuelle.

 

Voici la dernière version pour une première installation:

HCM.fqa

 

Pour mettre à jour votre version actuelle sans modifier votre configuration, remplacez le contenu du fichier 'main' par:

HCM v520.14.lua

 

Attention, le fichier config a été modifié à partir de la 5.20.13 (remplacement de la fonction HM:setIndoorSensor par HM:setRoomSensor).

Si vous upgradez d'une version antérieure, il est conseillé de mettre à jour votre configuration en utilisant ce modèle:

config new.lua

 

Voici le mode d'emploi complet (inclus dans le fqa, dans le fichier 'help'):

mode emploi.lua

 

Et enfin le guide de démarrage rapide (première partie du mode d'emploi):

=====================================================
HEATING & COOLING MANAGER - GUIDE DE DEMARRAGE RAPIDE
=====================================================

Ce QuickApp est un thermostat PID dédié à une seule pièce. Par défaut, le QA utilisera le
capteur de température de la pièce. Ce capteur doit avoir un temps de réveil de 15 min max.

1) CHAUFFAGE OU CLIMATISATION ?
Par défaut ce QA gère des radiateurs. Pour gérer des climatiseurs, vous devez utiliser le
paramètre suivant dans les USER SETTINGS du fichier 'config':
  HMCF.coolingDevice  = true      -- false : chauffage, true : climatisation 

2) PERSONNALISATION DES MODES
4 modes à consigne fixe sont disponibles par défaut: Confort, Eco, Vacances, et Manuel.
Vous pouvez fixer les valeurs minimum et maximum pour chaque mode dans USER SETTINGS.
Vous pouvez aussi ajuster la durée du mode Manuel (par défaut: 2 heures):
  HMCF.range.Confort  = {19, 22}  -- Valeurs {min, max} pour le mode Confort 
  HMCF.range.Eco      = {10, 21}  -- Valeurs {min, max} pour le mode Eco
  HMCF.range.Vacation = { 5,  5}  -- Valeurs {min, max} pour le mode Vacances
  HMCF.range.Manuel   = { 5, 23}  -- Valeurs {min, max} pour le mode Manuel   
  HMCF.manualTimer    = 2*60      -- Durée maximum (en minutes) du mode Manuel

Le mode Auto peut être associé à une consigne externe comme une zone de climat, une
variable globale, ou un même un autre thermostat. Des exemples sont disponibles dans la
section UTILISATION AVANCEE ci-dessous. Si vous ne configurez pas le mode Auto, il sera
par défaut équivalent au mode Confort.

3) AJOUT DES RADIATEURS / CLIMATISEURS
Chaque appareil (si il y en a plus d'un dans la pièce) doit être ajouté dans la section
HEATERS CONFIGURATION du fichier config avec la fonction HM:addHeater(). Dans la plupart
des cas, le seul paramètre nécessaire est son id:

=> Ex: HM:addHeater({id=145})  -- ATTENTION: un seul appareil par commande HM:addheater()

Par défaut, chaque appareil est commandé avec les commandes "turnOn"/"turnOff" et son 
retour d'état est vérifié avec la propriété "value". Si votre appareil n'est pas 
standard, des paramètres optionnels sont disponibles (cf. UTILISATION AVANCEE).

Voilà! Votre Thermostat PID est configuré et prêt à être utilisé.

 

Modifié le 6 mars 2023 par Felig

[Nico]

Bravo Man ! Une pensée émue à celui qui nous regarde de la haut.

Et maintenant si tu peux me faire la version HC2 à jour...

[mprinfo]

@nico je pense que le plus simple serait que tu passes doucement sur hc3

Envoyé de mon BLA-L29 en utilisant Tapatalk

[Nico]

Si un jour j'ai le temps oui, juste impossible là...

[jojo]

sinon @mprinfo peut le faire pour toi, il est expert maintenant

[Nico]

Merci Jojo

[jojo]

@Felig

je ne comprends plus rien ...

Le graphe ci-dessous montre une brusque variation de la régul, et promis juré, je n'ai modifié aucun paramètres.

Ah oui, peut-être, j'ai mis le dernier code. Je remets la version précédente et te dis qyoi

 

une idée ?

[Felig]

Tu as les logs correspondant à ces variations ?

[jojo]

très pauvres en logs ;-(,

mais si tu as le courage

 

Modifié le 8 février 2023 par jojo
remove logs

[Felig]

Ça ce sont les logs avec la précédente version du code non ? Je crois que j'ai trouvé quelque chose de mon côté, je posterai la version corrigée ce soir.

[jojo]

en effet, oui je suis revenu à une version précédente, pour voir ce que ça dit après une nuit.

Cool que tu ais trouvé qqch. A ta dispo pour tester

[Felig]

J'avais fait une modif sur la fonction d'arrêt des radiateurs sans la tester. Ça devrait être corrigé, j'ai mis à jour les fichiers dans le premier post.

[jojo]

cool, bonne nouvelle, car si tout f'un coup, sans explication ça ne fonctionne plus, ce sera difficile à trouvé.

En tout cas, avec la version précédente c'était ok :

Je mets en place ta version corrigée et te dis quoi

[jojo]

cette dernière version (cadre blru) et quand même moins bien que celle que nous avions testée ensemble sur l'autre post

 

Je te joint également un log bien plus complet (car je laisse ma fenêtre de debug ouvert h23)

log_Regul.txt

[Felig]

Merci Jojo. C'est intéressant mais très bizarre. On dirait que la clim. ne répond pas bien aux commandes de mise en marche.

 

Sur ce cycle de climatisation de 3 minutes (donc au maximum), on ne voit aucun effet sur la température, qui continue à monter:

[31.01.2023] [14:04:47] [DEBUG] [QUICKAPP846]: [REGUL] Cave Vins|Cave_AirCo : C 13°C | T 13.7°C | Début clim. 2m 58s
[31.01.2023] [14:07:17] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.7°C => 13.8°C
[31.01.2023] [14:07:47] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.8°C => 13.9°C

Alors que sur d'autres cycles le fonctionnement semble beaucoup plus normal:

[31.01.2023] [19:13:47] [DEBUG] [QUICKAPP846]: [REGUL] Cave Vins|Cave_AirCo : C 13°C | T 13.4°C | Début clim. 2m 36s
[31.01.2023] [19:13:57] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.4°C => 13.6°C
[31.01.2023] [19:14:47] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.6°C => 13.4°C
[31.01.2023] [19:15:17] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.4°C => 13.1°C
[31.01.2023] [19:15:47] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.1°C => 12.9°C
[31.01.2023] [19:16:17] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 12.9°C => 12.6°C
[31.01.2023] [19:16:24] [DEBUG] [QUICKAPP846]: [REGUL] Cave Vins|Cave_AirCo : Arrêt climatisation

J'aurais tendance à penser que c'est lié au fonctionnement de ta clim, mais ça n'explique pas pourquoi on n'a pas ce problème avec l'ancienne version. Tu peux la réinstaller et vérifier que ça se stabilise? Si c'est le cas je veux bien un log et le fqa de l'ancienne version pour comparer le code.

[jojo]

Merci BEAUCOUP pour cette analyse détaillée (je serais incapable d'en faire autant !)

J'ai remis l'ancienne version ce matin à 9h00 et le graphe ne montre aucune différence :

Ton code ne semble donc pas en cause 

 

Cette nuit j'ai pensé à un truc (qui serait  peut-être applicable ici).

Il y a des cas où le PID n'est peut-être pas la solution appropriée (expl : ma salle de bain : avant de prendre ma douche, je faits aller le chauffage "plein" pôt, histoire que le sèche serviette soit chaud, peut importe la température de la pièce)

Comme je trouve l'UI de ce QA super, je me disais qu'il pourrait remplir les 2 fonctions : régulation PID ou régulation par hystérésis.

On ajouterait 2 paramètre à la config :

HMCF.PID = true      -- false for hyterisis regulation, true for PID regulation (= default value)
HMCF.Hydtereis = 0,5      -- delta to setpoint for ON/OFF

Comme j'imagine que le système actuel appelle une fonction ON ou OFF en fonction de ses calculs, on aurait une nouvelle "méthode" de calcul qui appelerait les mêmes fonctions ON & OFF. Et dans l'UI, dans la 3° ligne qui a été libérée on préciserait la méthode de calcul.

Qu'en penses-tu ?

[Felig]

Il y avait cette possibilité dans le programme d'origine, mais je l'ai supprimée par simplification. En théorie PID n'est pas le mieux quand on a des changements importants de consigne, mais il fait très bien le boulot quand même. Et tu peux obtenir quelque chose qui ressemble à de l'hysteresis en mettant Ki et Kd à zéro (j'ai bloqué la possibilité de mettre Ki à zéro pour l'instant mais c'est facile à changer):

 

Si Kp = 50 (Ki=0, Kd=0) et la consigne est 20°, le thermostat aura le comportement suivant:

• Température <= 18° : chauffage à 100%
• Température 18.5° : chauffage à 75%
• Température 19° : chauffage à 50%
• Température 19.5° : chauffage à 25%
• Température >= 20° : pas de chauffage

Si Kp = 100 (Ki=0, Kd=0) et la consigne est 20°, le thermostat aura le comportement suivant:

• Température <= 19° : chauffage à 100%
• Température 19.5° : chauffage à 50%
• Température >= 20° : pas de chauffage

Si Kp = 200 (Ki=0, Kd=0) et la consigne est 20°, le thermostat aura le comportement suivant:

• Température <= 19.5° : chauffage à 100%
• Température >= 20° : pas de chauffage

Donc pour ta salle de bain, si tu met un Kp élevé le thermostat va rapidement dépasser la consigne avec l'inertie, mais comme tu ne cherches pas une température précise, pourquoi pas.

 

Pour revenir sur ta cave à vins, ça m'intrigue le comportement de ta clim. Est-ce que c'est du au fait qu'il lui faut plus de délai entre une commande on et off pour la laisser reposer ? Il n'y a pas moyen de la commander par fil pilote (moins brutal que on/off)? Il faut peut-être tester des cycles un peu plus long genre 4 minutes, même si on aura le pb de la température qui remonte très vite quand elle est off. Et qu'est-ce qui a changé par rapport à la période ou on n'avait pas de grosses oscillations ?

 

J'ai une nouvelle version que j'aurais bien aimé que tu testes, mais ça serait mieux si c'était avec un radiateur plus facile à contrôler.

[jojo]

en effet, je trouvais également que le PID était particulièrement adapté pour les longues périodes à la même consigne

mais ,maintenant, si on joue sur le kp pour faire de l'hystérésis c'est impeccable. Aurais-tu une formule pour calculer le delta entre la consigne et le démarrage du chauffage (si ki & kd =0). Comme ça si on le documente, c'est tout bon pour tout le monde.

Comme ki=0 n'est pas encore possible, quelle est sa valeur minimale (0,00001) ?

Je me posais la question depuis longtemps : expl d'une pièce rarement occupée : quand personne, consigne à 12°C (température qui ne sera jamais atteinte ou TRES TRES lentement); quand quelqu'un présent, consigne à 20°C (qui est une température atteignable). Quel sera l'impact si la consigne précédent a mis énormément de temp pour être atteinte) ou alors le programme détruit son historique à chaque changement de consigne ?

 

Pour ma cave à vins, j'ai mis la commande domotique en // avec le régulateur que l'installateur à mis (quand il vient faire l'entretient, je mes ma consigne à 30 °C  (donc jamais d'enclenchement de l'airco) et son régulateur à 13°C. Et inversement quand je travail avec ma box (qui lui fait peur ..). Je ne suis donc pas méga connaisseur de cette machine, mais je sais que son régulateur commande l'airco avec un contact sec. Donc j'ai juste fait mettre un FGS-224.

Ce que j'ai observé pour le On/Off : le Off est immédiat. Le On, non = peut aller jusqu'à 1 min après la commande...

 

Il y a 17 heures, Felig a dit :

J'ai une nouvelle version que j'aurais bien aimé que tu testes, mais ça serait mieux si c'était avec un radiateur plus facile à contrôler.

quand tu veux, je la mettrai sur le radiateur de mon bureau. Cela me permettra. de faire des tests avec mes Google Calendar. J'ai vu dans la doc qu'il y avait moyen de commander la consigne par GEA/ Mais pourquoi le dernier paramètre à passer est GEA. En fait mon script Google appelle un QA lua qui dit au bon thermostat à quelle consigne il doit être. Ici je lui dirais passe le thermostat du bureau sur confort ou sur Eco (c'est déjà prévu dans le programme pour GEA; mais pourquoi ce param!tre "GEA" ?)

[Felig]

La valeur minimum de Ki c'est 1 pour l'instant, mais en réfléchissant le mettre à zéro ça sert pas à grand chose, Ki ne ralentira pas le chauffage. Si Kp est très élevé, le rôle de Ki et Kd deviendra négligeable. Si Kp = 200, le chauffage sera à 100% jusqu'à 0.5° sous la consigne. Si Kp = 100 => 1°.

 

Le programme n'apprend que lorsqu'il est autour de la consigne, i.e. quand l'activité de chauffage est supérieure à 0 et inférieure à 100%. Dans ton exemple, si le système est à 20° et que tu met une consigne qui ne sera jamais atteinte, ça n'affectera pas son apprentissage. Et si il atteint les 12° il ajustera son apprentissage pour stabiliser les 12°.

 

Le "GEA" à la fin ne sert qu'à indiquer d'où vient la consigne. C'est un texte qui sera repris sur l'UI et dans les logs pour que l’utilisateur comprenne pourquoi la consigne a changé, et quel programme en est à l'origine (cf. exemple). C'est un paramètre facultatif, si il est manquant il sera remplacé par "System".

 

 

Voici une version bêta à tester. J'ai fait beaucoup de changements donc il y a surement des trucs à corriger. Principaux changements: système de régulation PID plus robuste (source: ici). système d'arrêt des radiateurs revu, et le mode Off (thermostat et radiateurs éteints) est maintenant préservé après un reboot.

 

Pour bien tester, ne met pas Kd à zéro stp, la nouvelle régulation modifie le mode de calcul de D.

 

HCM v520.lua

 

Merci!

 

Modifié le 2 février 2023 par Felig

[jojo]

J'ai installé ta dernière version du code sur le radiateur de mon bureau.

Du coup, je suis parti du dernier fichier fqa que tu avais publié. Dans les fichiers, le fichier tools avait disparu. Normal ? il n'est plus utilisé ?

Je peux donc le supprimer du QA pour l'airco de ma cave à vins ?

 

J'aime bien l'UI, car lorsqu'on agit sur les paramètres "standards" cela agit directement sur les labels.

Pour l'instant pas encore d'autres retours, car température > consigne.

Au niveau de l'UI, lorsque le thermostat passe sur OFF

j'aurais aimé garder les infos suivantes en ligne 2

Modifié le 5 février 2023 par jojo
parti trop vite

[Felig]

Oui je n'utilise plus le fichier tools depuis la 5.19, tu peux le supprimer.

En fait quand le thermostat est off, le QA est stoppé, et donc il ne fait plus les routines de vérification des températures. Mais je vais voir si je peux faire autrement.

 

EDIT: Voilà, essaie cette version stp.

 

(pièce jointe supprimée, la dernière version est disponible en téléchargement sur la première page)

 

Modifié le 27 février 2023 par Felig

[jojo]

je viens de voir ta dernière version, je la mets en place. Donc mon retour concerne la version précédente.

 

ma config :Config.txt

log  : log_Regul.txt

graphique température

j'ai été un peu surpris en voyant ceci : Consigne = 18 °C et température mesurée = 18°C. J'aurais pensé que le chauffage aurait fonctionné de manière préventive pour respecter la consigne, mais non ?

 

Je viens d'implémenter ton code adapté, et c'est ce que je proposais !

 

Modifié le 6 février 2023 par jojo
parti trop vite, comme d'hab ...

[Felig]

Oui c'est un point que j'ai identifié aussi entre-temps. Par défaut quand le programme n'a pas d'historique PID (nouvelle installation), il démarre avec une valeur de 0 pour I (qui détermine le ratio de chauffage quand on est à la consigne). Ensuite il va l'augmenter avec l'apprentissage, et la bonne valeur sera conservée en cas de reboot bien sûr. Dans les prochaines versions il démarrera à 20%, ce qui est une valeur arbitraire, mais probablement plus réaliste en moyenne, et qui accélérera un peu l'apprentissage.

Modifié le 6 février 2023 par Felig
typo

[jojo]

merci pour ces explications. en fait, si je détruis la variable <PID_Data>, ce sera alors comme si nouvelle installation ?

Le 02/02/2023 à 21:12, Felig a dit :

quand l'activité de chauffage est supérieure à 0 et inférieure à 100%.

tu parles ici de > 0 et < 100, pas >= 0 et <= 100 ?

[Felig]

Le 06/02/2023 à 14:56, jojo a dit :

merci pour ces explications. en fait, si je détruis la variable <PID_Data>, ce sera alors comme si nouvelle installation ? 

tu parles ici de > 0 et < 100, pas >= 0 et <= 100 ?

Première question: Oui. Et si l'id du radiateur change, il repartira de zéro aussi (l'apprentissage est lié à l'id du radiateur).

Deuxième question: Oui aussi. Il faut que ce soit strictement > 0 et < 100.

 

EDIT: Grâce à tes logs j'ai identifié un pb dans le calcul de D. Peux-tu remplacer par cette version stp:

(pièce jointe supprimée, la dernière version est disponible en téléchargement sur la première page)

Modifié le 27 février 2023 par Felig