Gestion thermostat

Cette fois-ci un article sur un plugin que j’utilise le plugin Gestion thermostat. L’idée de ce plugin est arrivée suite à la généralisation du télétravail (forcé). Avant le télétravail le thermostat de la maison était toujours sur 20,5°C la journée et 19°C la nuit. Avec le travail à la maison, on a installé nos bureaux dans des pièces plus froides. En effet, le thermostat est central dans le salon, une pièce au sud et avec de grandes ouvertures, a contrario des pièces qui nous servent de bureaux qui sont soit au nord soit au sous-sol… Autant vous dire, qu’il ne faisait pas très chaud surtout en restant statique…

Au début j’ai essayé simplement d’augmenter la température du thermostat principal. Cela marche mais dans le salon il faisait très chaud (surtout que c’est une pièce qui n’a quasiment pas besoin de chauffage pour atteindre 20,5°C voir plus la journée). Vu que c’est un chauffage à eau, j’ai donc mis des vannes Zigbee pilotées (Danfoss pour ne pas les citer) sur les radiateurs de la pièce principale et des 2 bureaux. L’idée étant de limiter la chauffe aux deux pièces bureaux lorsque la température de la pièce principale est bonne.

Autre point, je voulais aussi éviter de chauffer les bureaux s’il n’y a personne ou qu’il n’y en a pas besoin.

Gestion température bureau

Ici il y a deux trucs importants :

• « Ne rien faire automatiquement si » : si jamais la maison est en mode été* ou si jamais la maison est en mode absent (donc personne de présent) ou encore si on est hors des heures de travail alors aucun contrôle de la part du plugin (vu que le bureau sert aussi de chambre c’est plus confortable la nuit)
• « Reprendre la main après (min), ne rien mettre pour jamais » : indique au plugin de reprendre le contrôle du thermostat de la pièce au bout de 30min si quelqu’un y a touché

*Il est conseillé l’été d’ouvrir à fond toutes les vannes des radiateurs (consigne à 28°C). J’ai donc ajouté la condition « maison en mode été » pour éviter que le plugin les referme.

Pour commencer, rien de bien particulier, je définis juste ma commande de contrôle de la vanne et celle qui remonte la valeur de consigne de la vanne. La consigne permet au plugin de savoir si quelqu’un a touché au thermostat ; si oui alors il ne fait plus rien pendant 30 min puis reprend la main et remet à la consigne voulue.

Ensuite c’est plus intéressant : c’est là qu’on va définir la notion de présence dans une pièce. Cela se fait à l’aide d’un simple capteur de présence mais je voulais éviter les montées de consignes si on ne fait que passer dans la pièce. Donc on a des paramètres pour spécifier ce qu’est une présence, la température de consigne à mettre et le délai avant de revenir à la valeur précédente. Donc ici, j’ai « si sur les 5 dernières minutes il y a eu une présence plus de 70% du temps alors je mets la consigne à 20,5°C, et suite à ça si pendant 10 min je ne vois plus personne alors je remets la consigne à la valeur précédente ».

Evidemment on indique le ou les capteur(s) de présence :

Le plugin gère aussi les ouvertures de fenêtre (quitte à faire autant en tenir compte pour éviter de chauffer dehors). Là c’est très simple, je dis au plugin « si la fenêtre s’ouvre attend 2min, si elle est toujours ouverte passe la consigne à 10°C ; une fois refermée attend 2min et revient à la consigne précédente ».

Idem, vous indiquez un ou plusieurs capteur(s) d’ouverture :

Enfin, un peu comme pour le plugin gestion de volets vous pouvez créer des modes (seules commandes que vous pouvez ajouter) avec la consigne pour chaque mode.

Attention : les modes sont les valeurs courantes (ici jour/nuit) et absolument pas les valeurs de présence dans une pièce ou d’ouverture de fenêtres qui sont spécifiques et « au-dessus » des modes.

Gestion du thermostat central

Grâce au plugin, j’ai maintenant un système de gestion correcte des températures dans les bureaux. Il ne me reste plus qu’à gérer le thermostat principal. J’ai souhaité faire simple. L’idée est : si une vanne d’un des 2 bureaux à besoin de chauffage alors j’augmente la consigne du thermostat principal (jusqu’à un certain point bien-sûr) et je reviens à la valeur d’origine une fois qu’il n’y a plus besoin de chauffage. Pour rappel, j’ai aussi mis des vannes pilotées dans la pièce principale pour limiter la chauffe dans celle-ci lors d’une augmentation de consigne du thermostat principal. En gros, je redirige la chaleur que là où j’en ai besoin.

J’ai fait ça avec un scénario :

Il est déclenché toutes les heures ou par un changement de % de puissance que demande la vanne (c’est le truc vraiment bien sur les vannes Danfoss Zigbee : leur remontée de puissance voulue/pourcentage d’ouverture).

Un peu plus compliqué :

• 1er bloc : si la maison est en mode été on fait rien (simple et efficace)
• 2ème bloc :
  • (#[Bureau][Vanne][Puissance]# > 70 && #[Bureau][Vanne][Consigne]# > 20) || (#[Chambre 3][Vanne][Puissance]# > 70 && #[Chambre 3][Vanne][Consigne]# > 20) && variable(disable_heating_window) == 0 : si la vanne a besoin de plus de 70% de chauffage (le chiffre a été trouvé après plusieurs semaines de tests entre confort et économie d’énergie) et si on veut plus de 20°C dans la pièce (en dessous de 20°C c’est qu’il n’y a personne ou qu’on est en mode nuit donc pas besoin de déclencher la chaudière). Dernier point, je regarde la variable disable_heating_window qui m’indique si le chauffage a été coupé suite à l’ouverture de fenêtre pour aérer la maison (c’est géré dans un autre scénario)
  • Je mets à jour l’état du thermostat principal de la maison (c’est un Migo chez moi)
  • [Maison][Thermostat][Température]# + 1 > 25 && #[Maison][Thermostat][Etat Chauffage]# == 0 : si quand j’ajoute 1°C à la température de la maison (sonde thermostat principal) je reste bien en-dessous de 25°C (c’est pour éviter de surchauffer, idem ce chiffre a été trouvé après de nombreux jours de tests)
    • Là une action particulière : « remise à zéro des SI ». Si vous regardez bien le scénario, j’ai coché la case pour la non répétition des SI, cela indique à Jeedom de ne faire qu’une seule fois les actions tant que la condition ne change pas. Cela permet ici d’augmenter qu’une seule fois la température du thermostat. Sans ça, à chaque changement de puissance des vannes au-dessus de 70%, Jeedom augmenterait la température de 1°C, on se retrouverait vite à plus de 30°C. Par contre si je n’augmente pas la température du thermostat principal alors il faudra absolument la prochaine fois repasser dans les actions du SI (d’où cette action « remise à zéro des SI »)
    • Vous avez ensuite juste l’action Stop car on est dans le cas où il fait déjà trop chaud dans la maison
  • S’il ne fait pas trop chaud dans la maison alors j’augmente la consigne du thermostat principal de 1°C et je passe la variable heating_boost à 1 (elle me permet de savoir qu’on est bien en mode boost et donc que c’est bien le scénario boost qui a augmenté la consigne)
• 3ème bloc :
  • (#[Bureau][Vanne][Puissance]# < 55 || #[Bureau][Vanne][Consigne]# <= 20) && (#[Chambre 3][Vanne][Puissance]# < 55 || #[Chambre 3][Vanne][Consigne]# <= 20) && variable(heating_boost) == 1 && variable(disable_heating_window) == 0 : si la vanne a besoin de moins de 55% de puissance (chiffre trouvé après des semaines de tests également vous remarquerez qu’ici j’utilise le principe d’un cycle d’hystérésis pour éviter de nombreux arrêts/relances) ou si la consigne est en-dessous de 20°C et qu’on est bien en mode boost (variable de tout à l’heure) et pas en désactivation de chauffage dû à une aération de la maison
  • Si c’est le cas, alors je retourne sur le planning normal du thermostat principal et je remets la variable heating_boost à 0 pour indiquer qu’on est plus en mode boost de chauffage

• 4ème bloc : un peu particulier lui aussi, il remet à zero les SI toutes les heures (la condition vérifie que le scénario a bien été déclenché par la programmation horaire du scénario). Cela permet 2 choses :
  • si jamais j’ai augmenté la consigne de 1°C (20,5->21,5 par exemple) mais que cela n’a pas suffit pour chauffer le bureau (car on a atteint 21,5°C dans la pièce principale) alors le scénario s’autorise à en remettre une couche (21,5->22,5), et il fera ça toutes les heures jusqu’à un maximum de 24,5°C dans mon exemple (impossible de monter au-dessus de 25°C)
  • si jamais quelqu’un a touché le thermostat principal alors le scénario va s’autoriser à l’augmenter à nouveau car on n’a pas encore correctement chauffé le(s) bureau(x)

Bonus : gestion des fenêtres ouvertes

En bonus je vous mets mon scénario qui gère l’aération de la maison :

Le scénario est déclenché par l’ouverture d’une fenêtre de la maison sauf les bureaux où c’est géré de manière individuelle (par le plugin gestion de thermostat qui ne coupe le chauffage que dans la pièce en question)

• 1er bloc : comme souvent si on est en mode été le scénario ne fait rien (le mode été/hiver est mis manuellement quand il commence à faire froid)
• Calcul du nombre de fenêtres ouvertes (en ne prenant bien-sûr que celles qui m’intéressent et pas celles des pièces ayant une gestion individualisée du chauffage) et je stocke ce nombre dans la variable nb_windows_open_without_valve
• S’il y a une fenêtre ouverte j’attends 5min (afin d’être sûr qu’on a pas juste ouvert/fermé une fenêtre) et je regarde à nouveau s’il y a plus d’une fenêtre ouverte, si c’est le cas alors je désactive le chauffage et j’indique dans la variable disable_heating_window qu’il est coupé car il y a une fenêtre ouverte. Certains remarqueront sûrement que je ne refais pas le calcul sur nb_windows_open_without_valve après l’attente des 5min. C’est normal le scénario se lançant à chaque changement d’état des fenêtres, la variable est forcément toujours à jour
• Lors de la fermeture d’une fenêtre qui était ouverte (et donc chauffage désactivé), cela rebascule sur le planning du thermostat.

A noter qu’il peut y avoir un conflit avec le scénario précédant. Je m’explique :
Le scénario précédant a augmenté la consigne à 21,5°C car un bureau en a besoin. On décide alors d’aérer pendant 10min, le scénario va donc passer la valeur la consigne à 18°C puis revenir sur le planning au bout de 10min à 20,5°C (mode jour). La consigne ne sera donc plus à 21,5°C, et le bureau ne va pas chauffer. Sauf que dans le scénario précédant, le dernier bloc remet à 0 les SI toutes les heures, cela va donc remettre la consigne à 21,5°C au bout d’une heure maximum.

Conclusion

Ce n’est pas forcément l’article le plus simple du fait de la non répétition des SI. Cette notion peut être compliquée à comprendre. Pour simplifier cela, cette option ne fera qu’une seule fois les actions tant que le résultat de la condition ne change pas.
Exemple : j’ai un scénario qui se lance toutes les heures qui m’envoie un message si « il fait beau » ou si « il ne fait pas beau ». En temps normal toutes les heures je vais recevoir un message, avec la non répétition il ne me l’enverra qu’une fois quand il fait beau par exemple et plus rien jusqu’à ce qu’il ne fasse plus beau et ainsi de suite.

Pour revenir au sujet, vous avez pu voir un exemple de gestion de chauffage. Je pourrais encore l’améliorer en diminuant les consignes des vannes de la pièce principale lors d’un boost pour être sûr de bien rediriger toute la chaleur vers le(s) bureau(x). En effet, même avec des vannes pilotées réglées à 20,5°C, elles peuvent autoriser le radiateur à chauffer s’il fait 22°C (sûrement une histoire de calcul de déperdition) ou des fois l’inverse à 18°C elles ferment tout. Je pourrais donc passer dans un mode tout ou rien en fonction juste du Migo (thermostat principal).