Thermostat avec Zigbee2MQTT

Bonjour, suite à l’intégration du thermostat dans Gladys, je créé ce topic afin de valider l’intégration de cette fonctionnalité avec Zigbee2MQTT.

@lmilcent on reprend ici :slight_smile:


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 ».

Merci d’avance pour vos retours.

Merci pour ce que tu as commencé, désolé de te faire un retour que maintenant je n’avais pas vu ton message.

Conteneur lancé, device radiateur mis à jour dans l’intégration Z2M :

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

Je rajoute que le contrôle des températures dans l’interface fonctionne bien et c’est répercuté dans l’interface Z2M.

1 « J'aime »

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é.

Merci d’avoir pris le temps :smiley:

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é :

  • :white_check_mark: Remontée de la température locale
  • :white_check_mark: Envoie d’une valeur de chauffe

Un message a été scindé en un nouveau sujet : Appareil Zigbee pour gestion chauffage électrique + poêle à bois :wood:

Est ce que ces fameux modes c’est standard ? Tous les thermostats qui gèrent des modes « eco » etc… ont les mêmes modes plus ou moins?

Il faut créer un nouveau type dans la catégorie thermostat pour ce contrôle, pour le coup effectivement ça a pas trop à voir avec la partie Zigbee

Pour ton information, le eco_mode (binary) n’est disponible que sur un seul device zigbee :

Sinon on parle également de :

  • system_mode (enum) : 'off', 'heat', 'cool', 'auto', 'dry', 'fan_only', 'sleep', 'emergency_heating'
  • 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.

Sinon partons sur un mode eco / normal puis on en rajoute au fil de l’eau ?

Je suis d’accord, il faut travailler sur ce sujet côté core!

En attendant, @pierre-gilles, tu penses quoi de cette proposition ?

Sachant que je n’ai pas trouvé d’autres devices avec cette feature (n’ayant cherché que dans la liste des devices z2m).

Je vois pas en quoi c’est plus compliqué de tout mettre que de juste mettre eco/normal ?

ah! Du coup c’est vraiment du dev 100% custom quoi, il y a rien de générique dans ce comportement?

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 :slight_smile:

1 « J'aime »

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.

C’est sûr! Il y a surtout toute une réflexion de comment on le fait ^^

Pas de soucis! Tu peux peut-être créer un sujet sur le forum pour juste avoir une trace et peut-être lancer une première spec d’implémentation?

Créé !

On peut commencer à lister nos idées de l’autre côté :slight_smile:

1 « J'aime »

Bonjour,

Concernant les modes de fonctionnement des chauffages, ca doit être basé sur le fil pilot:

  • Fil pilote 4 ordres : Confort, éco, hors gel, arrêt
  • Fil pilote 6 ordres: Confort, confort -1°C, confort -2°C, éco, hors gel, arrêt

En Zwave, il y a des devices de type fil pilot à 4 ordres.

Pour la liste, ne pourrais-ton pas mettre celle-ci dans le champ params des devices Gladys et ne proposer que celle-là ?

2 « J'aime »

Je suis plutôt d’accord pour aller vers du statique si c’est un comportement qu’on arrive à factoriser :slight_smile:

Pour information je viens de merge la PR de @AlexTrovato :pray:

Merci à tous ceux qui ont fait des tests !

Ca partira dans la prochaine release de Gladys

1 « J'aime »