J’ai déjà regardé, rapidement, et je peux déjà fournir une image de test : atrovato/gladys:z2m-thermostat.
Pour rappel, il est préférable de faire un backup de sa base de données ou de partir d’une installation neuve avant de tester une image « bêta ».
Je vois qu’il y a le service Homekit, j’en conclue que cette image est basée sur la dernière version avec les fix de @pierre-gilles . Mais on le voit sur la capture d’écran, les thermostats sont coupés sur le dashboard (écran FullHD et Chrome 107).
Autre retour :
La fonctionnalité « Température » est ajoutée par tes modifications, top ! => Il s’agit de la sonde de température embarquée dans la tête connectée
Il y a toujours « commutateur » sans que l’on sache ce que c’est dans l’interface => C’est le [EDIT] « ECO MODE » « lock » enfant et détection de l’ouverture des fenêtres
Alors oui, je me suis basé sur une version intégrant HomeKit, pas sûr que ce soit la dernière.
Top !
Je suppose que c’est hors sujet du thermostat ? Si c’est lié au thermostat, je vais voir ce que je peux faire, sinon je veux bien d’avantages d’explication dans un topic dédié.
En effet, c’est plus lié au modèle de tête connecté que de thermostat, mais ça influe sur son contrôle, car le mode « eco » fait que la température de consigne n’est plus utilisée, mais la température « eco ».
Exemple : 16°C en température éco et 21°C en température de consigne => le radiateur chauffera à 16°C/
Pour ce qui concerne le thermostat, c’est tout bon pour moi à part le point soulevé :
away_mode (binary) : que se passe-t-il lorsque je suis absent ?
regulator_mode (binary) : régulateur vs thermostat
Je parle uniquement de ce que j’ai trouvé dans les documentations zigbee2mqtt.
Mais je pense qu’on va vite être bloqué si on n’ajoute pas la notion de ‹ available value › sur les features, car les system_mode ne sont pas tous disponibles sur tous les devices, et si on veut gérer ça depuis la dashboard, il faut connaître uniquement les modes disponibles sur les actionneurs.
Dans le cas du eco/normal, c’est juste un « binary » custom.
Dans les autres cas, c’est une evolution sur le model des features pour connaitre les valeurs disponibles, sachant que cette évolution peut inclure le binary custom.
J’en ai bien peur… du moins pour le binary custom.
Est-ce que cette évolution est si compliqué que ça? C’est une demande assez récurrente je trouve, et qui résoudrait pas mal de soucis. J’ai l’impression que même les histoires de « click bouton » avec des translations pourrait bénéficier de ce changement.
Le binary custom c’est un peu un hack, je pense ça vaut le coup de le faire propre
Compliquée non, lourde un peu. Dès que ça touche au core, au modele, et à la DB, on inclus des risques. Mais on est la pour ça.
Je ne m’engage pas sur la prise en main du dev, je suis pas sûr d’avoir du temps dans les jours qui viennent.