Ok il reste un arbitrage technique à faire encore et c’est bon.
Alors on souhaite un interrupteur On-Off en plus du fait que c’est thermostatique sauf que la tête n’a pas d’interrupteur donc il faut que ce soit un faux interrupteur qui mettent une valeur par défaut (5 degrés par exemple) et que quand on réactive l’interupteur on remettent l’ancienne valeur que possédait la tête ou potentiellement une nouvelle qui a été poussé pour les scènes.
Ce qui oblige a avoir une sorte de mémoire c’est pas fou.
Sinon je propose le fonctionnement suivant :
variable numérique de la température souhaitez
Si modification de cette variable, on vérifie que le chauffage est on pour la publier
Si chauffage est off, on change seulement la valeur au sein de gladys
Si le chauffage devient on, on pousse la valeure qui est dans gladys
Si on éteint le chauffage on pousse une valeur qui a été définie par défaut.
Je pense avoir gérer tout les cas je sais pas si c’est très clair !
Je veux bien un avis d’expérimenté (@pierre-gilles ?) sur comment techniquement tu résoudrais ce problème ?
Est-ce qu’on veut vraiment ce fonctionnement ? Je trouve ça compliqué, et surtout ça fait un “faux comportement” que l’utilisateur ne va pas comprendre.
Je pense que Gladys doit juste mimer ce qu’il se passe dans la vraie vie, pour que ce soit clair pour l’utilisateur.
Si la tête thermostatique ne gère pas de On/Off, on ne met pas de On/Off dans Gladys à mon avis.
Si l’utilisateur veut mettre 5°C pour “éteindre” sa tête, il peut le faire dans Gladys, mais je pense que ce n’est pas à Gladys de faire des comportements magique avec des valeurs fixes comme ça non ?
Perso quand c’est pas fait à l’extrême, j’aime bien avoir des boutons (on / off dans notre cas) “désactivés” avec un message (genre tooltip) qui explique que c’est pas pris en charge par ma tete connectée.
Dans ce cas est-ce que ce n’est pas faisable simplement par l’utilisateur lui même avec un device factice et une scène ? Ce serait plus proche de la réalité… bon pour ca il faut que l’injection de valeur arrive dans les scènes dans le même temps. Et dans la doc on peut donner des exemples concrets de mise en oeuvre (la demande pour le classement des scènes dans des dossiers serait idéale également ^^)
Tout a fait @VonOx ^^
Mais de ce que je comprenais de la conversation, c’etait ici pour demarrer le projet avec le plus simple et d’ajouter la regulation dans une future PR, non ?
Alors en théorie oui je suis d’accord pour dire que c’est pas idéal, ça fait un peu redondant etc…
En pratique, il y a beaucoup de scenario ou c’est indispensable. Tout ce qui est interruption du chauffage / reprise du chauffage , il faut pouvoir retrouver l’ancien régime qui a ne valeure très certainement différente en fonction des cas…
Alors oui comme le dis @Terdious l’idée serait de faire dans un deuxième lot mais si il y a des devs motivés pour tout faire directement alors pourquoi pas l’intégrer directement ! @VonOx tu tiens à cette fonctionnalités dès le premier lot de feature ?
Je n’ai pas encore intégré mon chauffage dans Gladys, pour l’instant je débute avec Gladys et je n’ai pas encore tous les éléments que j’aurais besoin pour intégrer toute ma domotique, et en même temps pas facile de casser un système existant qui fonctionne pour une autre solution mais j’avance tout doucement.
En attendant je peux vous montrer comment j’ai fait dans mon système actuelle Domoticz, si cela peut donner des idées.
Dans un premier temps j’ai un interrupteur virtuel (fake device) pour le mode de chauffage (HIVER / ETE)
Si mode ETE, alors le chauffage est coupé
Si mode HIVER alors j’active le chauffage
Ensuite j’ai un thermostat NetAtmo, ou son relais est connecté directement sur mon Poêle à granulés.
Dans Domoticz je récupère 4 infos:
mode de fonctionnement => permet de gérer le fonctionnement du chauffage de toute ma maison (poêle à granulé et radiateur électrique) suivant un mode planning, un mode absent et un mode hors gel
Etat du relais => permet de savoir si le relais du thermostat est actif ou pas (on peut exécuté des scènes éventuellement en fonction de l’état)
Température lu par le thermostat
Température de consigne
J’ai écrit un script python qui permet d’interroger l’API NetAtrmo et afficher les données dans Gladys si cela peut intéressé quelqu’un. Il me manque juste l’affichage du mode car il n’y a pas de fake device mqtt qui peut afficher du texte, ou alors j’ai pas trouvé comment faire.
Le chauffage de mon poêle est donc gérer directement par le Thermostat NetAtmo et je fait que lire les données dans Domoticz.
Ensuite dans chaque pièce j’ai un chauffage électrique avec fil pilote (piloté avec un module QUBINO en ZWAVE)
Pour chaque pièce j’ai créer plusieurs fake device:
Mode de fonctionnement => manuel ou automatique
En mode manuel, il y a un autre fake device qui permet de contrôler le radiateur
En mode automatique, j’ai une scène qui vérifie l’état de mon thermostat général, si par exemple je suis en mode planning et que la température de consigne est au dessus d’une certaine valeur alors j’autorise le chauffage individuel de chaque pièce
Type de régulation => hystérésis ou PID Hystérésis => c’est une régulation tout ou rien avec 1 valeur de mise en marche et une autre pour l’arrêt. Par exemple je démarre le chauffage à 18°C et j’arrête à 20°C PID => c’est une régulation un peu plus complexe (proportionnel, intégral, dérivé), pour résumé c’est un système d’asservissement en boucle fermé qui a pour but de lisser la température (ou de ce qu’on veut contrôlé)
Commande manuel => si le mode est réglé en manuel alors je peux sélectionner le mode de fonctionnement du radiateur de la pièce (OFF, hors gel, eco, confort…)
Thermostat => qui permet de définir la température de consigne de la pièce
Capteur de température
Ici j’utilise un capteur xiaomi aqara zigbee pour lire la température de la pièce et comparer avec la valeur du thermostat virtuel.
Donc si la valeur de consigne est supérieur à la température actuelle, et aussi en fonction du thermostat général et du mode de fonctionnement manuel ou automatique, je pilote le radiateur en confort sinon en Eco.
Pour ma part ce qu’il manque à Gladys pour réaliser une fonction de chauffage, c’est un fake device thermostat, un fake device type switch multi position, pas uniquement ON/OFF, avec la possibilité de définir un texte pour chaque position de l’interrupteur.
Après pour moi tout le restant peut se gérer pas des scènes sauf la régulation par PID qui est assez complexe.
Pour le thermostat général, j’utilise un thermostat NetAtmo car je peux le contrôler à distance et si mon système domotique tombe en panne je peux toujours le contrôler physiquement, mais pour l’intégration dans Gladys on pourrait imaginer un fake device thermostat qui permet de régler une valeur de consigne. Ensuite avec le calendrier et une scène venir piloter le thermostat automatiquement en fonction de ce que l’on aura défini.
Hello everyone,
so I’m coming back to the topic following the release of Gladys 4.9
From what I understand from all our discussions, there’s for the moment only one thing left to agree on: how we want to present this in the dashboard?
Do we want a slider like the brightness control?
Or a thermostat somewhat like this, increasing in 0.5-degree increments?
On the development side to support devices
For Zigbee2MQTT we need to support the device topics: occupied_heating_setpoint or current_heating_setpoint
Still no idea for Z-Wave (and relates to the Z-Wave migration topic)
To enable/disable winter/summer heating -\u003e activating/deactivating scenes or setting the temperature to 5 degrees
To enable/disable all heaters in a room -\u003e fake scene switch that pushes a fixed value to the room’s radiators (We could potentially improve this in the future with a general thermostat for the room)
Controlling heating by schedule -\u003e doable with scenes
Control of an on-off heater with a room temperature -\u003e already doable with scenes, a fake device, and a temperature sensor in the room
@jgcb00 Could you make a design proposal on Whimsical ( https://whimsical.com/ ) to recap everything that needs to be developed? (Both the dashboard and the scenes)
Put together a proposal, and then we can iterate on it
That said, do we want to do « device by device » (which could be a good start at first), or do we want to offer controls rather by room? (which could come in a separate box later on)
In any case, I’m in favor of keeping things simple to start, and what you’re proposing is really pretty good!
Yes I had the same thought, but for me object groups are another topic, no? You might want to create an object group with the lamp plug and the ceiling lamp to always turn them on together, so do we want to restrict that to heating only?
I think the best trade-off on this point would be to be able to create an object group in a scene very easily like this:
or every change in the value of a type can be propagated to another object of the same type.
What do you think? And this is a big core feature of Gladys
It could be a custom box in Gladys, or we could select a list of heating-type devices to control those devices in a single box, without it necessarily being an object group management.
Anyway, in any case, the first step is the two components you propose @jgcb00. This kind of component is a layer on top to provide a UX that’s as practical to use on a daily basis
