Gestion du chauffage native

Feature description

Suite a mon achat de tête connectée, je constate que Gladys ne supporte pas encore la gestion native du chauffage :

Votez tous dès aujourd’hui pour que ça soit le cas avant la fin de l’hiver :sweat_smile:

De ce que j’ai compris, les votes n’y changeront rien tant qu’il n’y aura soit personne de dispo soit aucun dev équipé et ce malgré le nombre de votants

Cf :
https://community.gladysassistant.com/t/ajout-enceinte-sonos/5504/5?u=spenceur

On peut peut-être en parler à un autre endroit, mais si les votes ont un énorme intérêt: cela donne à la communauté une indication de ce qui est demandé/pas demandé.

Perso, quand je développe une nouvelle fonctionnalité, je prend la liste de fonctionnalités lié au core, j’ordonne par vote, et je développe la plus demandée. C’est pas une règle d’or, biensûr parfois je développe aussi des fonctionnalités peu demandée que j’estime importante selon mon jugement.

En tout cas historiquement sur la dernière année, j’ai développé les 30 fonctionnalités qui étaient les plus demandées (cf archive: [Archive] Demande de fonctionnalités - Gladys Assistant Community)

Dans le cas des intégrations, je t’ai déjà répondu @spenceur sur un autre sujet.

1 « J'aime »

D’ailleurs peut-être que la ligne est fine entre développement core et développement intégration, mais cette issue (gestion du chauffage native) est clairement un développement lié au core, ce n’est pas une intégration!

Il n’y a pas besoin de matériel pour cette feature request.

Sinon @lmilcent si tu veux que cette issue avance, 90% du travail ici est de la spécification fonctionnelle.

Je crois que t’as l’habitude, je le fais sur chaque demande de fonctionnalité, mais il va falloir faire:

  • Etude des différentes solutions de chauffage (on va faire une développement qui sera le même quel que soit les intégrations, pas juste Zigbee)
  • Les spécifications fonctionnelles: qu’est ce qu’on veut?
  • Les maquettes: A quoi ça va ressembler ?
  • Enfin, le développement

Bref, écrire du code ça sera le dernier 10%.

Si tu te sens pas de faire tout ça, à moins que quelqu’un d’autre s’y penche, personnellement il y a des dizaines d’autres demandes plus votées que celle-ci du coup ça risque de prendre du temps avant que j’arrive sur cette feature :slight_smile: (Plusieurs années? :joy: :joy: )

Edit: Exemple de spec/maquettes: Multi-utilisateurs - #6 by pierre-gilles

1 « J'aime »

Ayant acheté 2 têtes thermostatique enocean y a genre 2 ans et que l’une dort dans un tiroir, et l’autre est montée mais utilisée en mode déconnectée, j’ai toujours en tete d’avoir un système de gestion du chauffage complet sous Gladys.

Ça ne me dérangerait pas de me pencher dessus pour le dev, mais les specs que j’ai en tête sont assez complètes/complexes.Sachant que j’ai de grosse difficultés à dégager (beaucoup) de temps actuellement. J’ai bien peur de passer un nouvel hiver avec mon ancien système ^^

Je suis déjà comme le dis @pierre-gilles dispo pour discuter de ces specs.

Pour ma part, grosse maille, je voyais déjà un système de “Déclaration de son chauffage”.

  • C’est à dire un lien entre les équipements thermostatiques, les vannes du radiateur ou la vanne centrale (je pense à mon cas) avec des capteurs de température.

  • Chaque vanne est couplée avec son/ses capteurs.

  • Un système de consignes pour chaque couple vanne/capteur.

  • Un dépassement du seuil sur un capteur relié à une vanne enclencherait la demande sur la vanne ou l’arreterait.

  • Enfin bien sur, la gestion visuelle d’un planning.

  • Sans oublier un éventuelle couplage des vannes avec les capteurs de fenetres, si l’on ouvre une porte / fenêtre dans la pièce ou il y a une vanne, on l’arrête pour ne pas chauffer à tord.

  • De la même manière, si la maison est vide, on peut décider d’éteindre le chauffage, avec un retard … … à voir … ou bien démarrer à distance quand un utilisateur arrive ou le décide…

Merci pour vos réponses. Comme @Jean-Philippe j’ai toujours du mal à dégager du temps de cerveau en ce moment, mais cela ne m’empêche pas de commencer quelque chose, à plusieurs on arrivera à faire un rendu complet pour faciliter le développement.

C’est vrai que j’avais pas identifié qu’il s’agissait surtout de spec, mais ça permet ensuite dérouler le développement facilement !

En attendant @Jean-Philippe il y a node-red je pense, qui peut permettre de bidouiller le temps que ça soit supporté. J’ai pas encore essayé, je saurais pas dire si ça fonctionne :wink:

Affaire à suivre donc, je commence une version de travail dès que je peux. N’hésitez pas tous à proposer aussi des infos, compléter, relire, donner vos scénarios, etc.

1 « J'aime »

Spécification fonctionnelle

En tant qu’utilisateur de Gladys, je veux pouvoir contrôler mon chauffage. Pour cela j’y vois quelques possibilités :

  1. Via un calendrier, ou programmation statique
  2. Via un calendrier avec priorité aux capteurs
  3. Manuellement, via une sorte de thermostat ou de commande centrale
  4. Automatiquement, à l’aide d’autres capteurs

1. Via un calendrier

Une interface type « calendrier » sur une semaine, permet de choisir de quelle heure à quelle heure le chauffage est allumé ou éteint, avec en supplément une consigne de chauffe.
Exemple :

  • Lundi : 21°C de 7h à 9h, off de 9h à 17h, 19°C de 17h à 21h, 17°C de 21h à 7h.
  • Mardi: etc. jusqu’à dimanche

2. Via un calendrier avec priorité aux capteurs

L’interface calendrier est toujours active, mais si une scène modifie les températures de consigne, alors c’est elle qui aura la priorité. Dès que cette température de consigne est retirée ou que le chauffage est éteint, c’est à nouveau le calendrier qui prend la main.
Exemple :

  • Le calendrier chauffe tous les jours entre 6h et 9h puis entre 16h et 21h. La journée, le chauffage est éteint.
  • Une scène détecte ma présence à 9h (#télétravail) et active le chauffage en augmentant la température de consigne. Malgré la désactivation prévue dans le calendrier, c’est bien la scène qui garde la main sur le chauffage.
  • A 17h, la scène désactive le chauffage et envoie un signal à Gladys pour « rendre la main » et laisser le calendrier suivre son cours.

3. Manuellement

Un thermostat sur le dashboard permet de contrôler la température de chauffe par pièce. Aucune automatisation n’est présente ici, c’est l’utilisateur qui choisi via Gladys comment il veut chauffer ses différentes pièces.
Si un thermostat physique est ajouté à Gladys, il peut être utilisé lié ou à la place de celui affiché sur le dashboard. Ce sera toujours la priorité au thermostat physique.

Si le calendrier de gestion du chauffage est en cours d’utilisation, mais que l’utilisateur modifie le thermostat via le dashboard, alors c’est lui qui a la main à la place. Un petit message d’avertissement (en mode info) pourra rappeler que le calendrier (ou une scène) était en cours de gestion de la température de consigne.

4. Automatiquement (WIP)

Quelle est la meilleure solution pour utiliser des capteurs extérieur de manière pratique et pas au travers de 25 000 scènes, un peu de calendrier, etc. ?
TODO

  • Un lien entre les équipements thermostatiques, les vannes du radiateur ou la vanne centrale (je pense à mon cas) avec des capteurs de température.

  • Chaque vanne est couplée avec son/ses capteurs.

  • Un système de consignes pour chaque couple vanne/capteur.

  • Un dépassement du seuil sur un capteur relié à une vanne enclencherait la demande sur la vanne ou l’arreterait.

  • Enfin bien sur, la gestion visuelle d’un planning.

  • Sans oublier un éventuelle couplage des vannes avec les capteurs de fenetres, si l’on ouvre une porte / fenêtre dans la pièce ou il y a une vanne, on l’arrête pour ne pas chauffer à tord.

  • De la même manière, si la maison est vide, on peut décider d’éteindre le chauffage, avec un retard … … à voir … ou bien démarrer à distance quand un utilisateur arrive ou le décide…

2 « J'aime »

Excellente description !
Si je puis me permettre, j’aimerais y voir en plus une possibilité de suspendre l’utilisation de la programmation sur du plus long terme (ne pas chauffer pendant l’été même si on a un ‘coup de froid’) et une réactivation programmée (je suis en déplacement/vacances toute la semaine mais réactive la programmation du chauffage vendredi 15h).
… Et une fonctionnalité pratique aussi est “chauffer pendant X heures en plus” et inversement “ne pas chauffer pendant X heures” car “j’ai des invités qui vont rester mais je risque d’oublier d’arrêter le chauffage en allant me coucher” ( ou de ne plus savoir comment on fait) et “après-midi shopping, pas besoin de chauffer pendant 2 heures” (réelles, ressenties 8h).

2 « J'aime »

Salut @lmilcent,
C’est très intéressant mais, comme le dit @pierre-gilles, il faut que cela fonctionne quelle que soit l’intégration.
Pour la part, j’ai des modules Z-wave Qubino ZMNHJD1 pour les chauffages électriques au sol, le sèche-serviettes, et d’autres, pas encore installés, pour des convecteurs. J’ai aussi des radiateurs à inertie, programmables, qui seront intégrés dans Gladys si le Z-wave devient fonctionnel.
Tout ce qui est utilisé fonctionne avec Domoticz depuis plusieurs années.
Le fait que je ne puisse gérer le chauffage est LA raison pour laquelle je ne passe pas à Gladys Plus…

Merci pour ton retour @gaetanb76, en effet il reste encore du travail à faire pour compléter cette description et prendre la plupart des cas d’usage en compte.

Pour ma part, entre temps j’ai acheté des têtes connectés Zigbee, que je contrôle avec Zigbee2MQTT et Node-Red. J’ai rencontré pleins de difficultés et j’y ai passé pas mal de temps, je mettrais à jour mon message principal pour le modifier en fonction de mon retour d’expérience ensuite :slight_smile:

Je viens de commencer à intégrer mes vannes https://ubiwizz.com/l-offre-produits-ubiwizz/9636-vanne-thermostatique-enocean.html dans mon intégration enOcean (pas mergée sur Gladys pour l’heure).

Et dans mon cas, elles peuvent s’interfacer nativement avec des capteurs d’ouverture de fenêtre et un capteur de température externe si on ne veut pas utiliser le capteur interne.

Globalement une gestion natives du chauffage qui gère tous les cas sans erreurs comme l’indique @gaetanb76 peut s’avérer bien complexe à écrire, mais je pense en effet que ce serait un facteur d’adoption de Gladys, le chauffage dans une maison, c’est un des leviers majeures pour la domotique.

Je pense qu’une fois que je pourrais gérer mes vannes, je ferais du statique et laisserais mon boitier gérer les consignes, le temps que je le domotise aussi, mais pas d’urgence du coup :smiley:

2 « J'aime »

Génial, je souhaitais regarder côté EnOcean pour ma domotique, surtout pour leurs boutons sans pile !
Mais vu le mastodonte Zigbee, j’étais parti sur le plus supporté un peu partout.

Vivement ta v1 dans Gladys :+1:

Hello, je me permet de revenir à la charge du coup parce que effectivement ça serait super comme intégration. Donc c’est partir pour définir de la spécification fonctionnelle.

Pour moi déjà la notion de chauffage doit être propre à une pièce.
Il y a deux types de chauffage :

  • Les On/Off tout bête
  • Les têtes thermostatiques

Tête thermostatique

Ainsi dans le cas des têtes thermostatiques, elles ont un capteur de température et s’occupe elle même d’atteindre cette température de pièce. Il suffit juste de pouvoir lui transmettre cette valeure.
Je pense que c’est le cas d’usage le plus simple et un qui couvre déjà 80% des besoins de tout les utilisateurs je pense.
L’intégration depuis un calendrier peut se faire avec des scènes depuis la 4.8
On peut gérer en fonction des personnes présente à la maison etc… Bref il y a déjà moyen de faire beaucoup de chose.
Pour les têtes termostatiques il reste à pouvoir modifier la valeure de la température depuis le Dashboard. Pour ce faire je voyais bien un design ressemblant à ça :
Screenshot from 2022-03-22 20-02-25

Chauffage On/Off

La question du chauffage On/Off est plus complexe.
Idéalement il faudrait pouvoir creer un lien entre un capteur de température et l’intérupteur avec allumage automatique et extinction automatique autour de la valeure cible.
Je pense que juste le fait d’avoir une valeure cible rejoint la demande de fonctionnalitée dans Gladys d’avoir des variables fictives. Car clairement ça serait le cas pour cette valeure.

Cela permettrait de transformer ainsi n’importe quel chauffage On/Off en une tête thermostatique et donc d’être controller de la même manière.

Aller plus loin

  • Introduire une notion de priorité dans les modifications,
  • switch on/off général pour toute la maisons, pour certaines pièces etc… (l’utilisation de varialbe virtuelle quoi, avec laquelle on intéragit dans les scènes).
  • Pouvoir dire dans une scène coupe le chauffage de cette pièce plutot que de déclarer un a un les chauffages (pareil encore une variable virtuelle)

Voilà est ce que j’ai bien résumé les fonctionnalitées souhaitées ?
Cela ne me semble pas être un travail énorme pour l’intégration Core des têtes thermostatiques, il y aura un peu de travaille côté Zigbee2Mqtt et les autres intégrations je pense.
Par contre l’intégration des On/Off me semble plus compliqué en particulier si à un moment on arrive pas à remonter l’information du capteur de température et que la pièce surchauffe du coup…

Hésitez pas si vous avez des remarques, ou réflexion.

1 « J'aime »

Merci, c’est très bien résumé. Après mon expérience de cet hiver, je confirme ta réflexion sur les têtes thermostatiques et la possibilité de la coupler avec un capteur de température externe a la tête. C’était une des idées que j’ai abandonné avec NodeRed.
Il faut penser à pouvoir régler la valeur de rafraichissement (ou de check de la température), car c’est pas à faire toutes les 10 sec mais plutôt toutes les 10 min, vue l’inertie.

Autre point, la possibilité d’une consigne manuelle sur la tête ou sur Gladys qui prenne la priorité sur la programmation.
C’est le fonctionnement de nos têtes Moes, appelé “temporary manual”. Ça prend ta nouvelle condition de température jusqu’au prochain cycle de programmation.
Exemple : 18°C programmé entre 20h et 6h. Si à 21h je demande a la tête connecté ou Gladys via le dashboard (ou telegram) de passer à 21°C, ça sera appliqué jusqu’à 6h.

Oui, je vois après je pense que faire une liste des fonctionnalités de la plus importante à la moins importante et on sera déjà content si on peux faire les trucs basiques de dans mais allons y pour les fonctionnalité plus avancée.

Donc il y a la fonctionnalitée que tu viens de décrire, il y aussi le fait de pouvoir faire on/off sur le chauffage facilement parce que je pensais à un cas.
Si j’ouvre la fenetre alors coupe le chauffage. Dans ses cas là on est intéressé par ne pas modifier la valeure de température souhaitée pour pouvoir revenir au mode normal facilement.

1 « J'aime »

Okay donc let’s go avancer vu qu’il me semble qu’il y a pas trop de réticence.

Premier Besoin : les têtes thermostatiques

Intégrations :

  • sur Zigbee2Mqtt cela correspond aux topics : occupied_heating_setpoint ou current_heating_setpoint des appareils
  • Est ce que quelqu’un a une tête thermostatique Zwave pour qu’on puisse comprendre comment l’intégrer ?

Après:

  • Chaque pièce peut avoir un état chauffage On ou chauffage Off pour éviter de changer la température et de perdre la température qui a pu être décidé dans une des scènes.
    (ex: Tout les matins de 8h à 10h chauffe à 20 degrés Si une fenetre est s’ouvre coupe le chauffage. Quand elle se ferme met l’ancienne température (donc rallume le chauffage)).

Ce qui se traduit par dans les scènes :

  • Une action pour définir la température de chauffage d’une pièce et ça se répercute sur les différents chauffages de la pièces
  • Une action pour allumer/Eteindre le chauffage d’une pièce
  • Une condition: Si le chauffage d’une pièce n’est pas allumé

Sur le dashboard :

  • Un interrupteur pour le chauffage de la pièce
  • Un compteur pour définir la température voulue dans la pièce.

Je pense que c’est les 5 besoins les plus fondamentales et à partir de ça on puet commencer à construire quelque chose de plus en plus intéressant. Des avis ?

@lmilcent petite question, le cas ou tu rajoutes un degré ou deux manuellement sur ton radiateur ça t’es arrivé souvent ?
Dans gladys je pense que ça serait naturellement géré par met la température à 18 degrés, un utilisateur modifie directement sur la vanne, la prochaine fois qu’il y a une température définie dans les scènes hop ça remet la valeure définie dans la scène. ça conviendrais comme mode de fonctionnement ?

1 « J'aime »

Oui, dans presque toutes mes pièces !

Pour le moment je n’ai rien a redire !

@pierre-gilles est ce que ce niveau de détails pour les spécification fonctionnelle te suffit ? est ce que tu souhaite plus de détails ?

@jgcb00 ton dernier message est très bien, par contre du coup je pense qu’une fois que vous êtes d’accord sur tout, ce serait cool d’avoir un message “récapitulatif” avec la spec totale en un message de taille raisonnable, avec la même organisation que tu as faites c’est très bien :

Dashbaord

Scènes

Intégrations

Merci de vous pencher sur ça, c’est tout bête mais ce que vous faites c’est la majeure partie du développement :slight_smile: Coder c’est que le dernier mètre, c’est de la technique c’est tout simple.

1 « J'aime »