Thermostat with Zigbee2MQTT

[AlexTrovato]

Hello, following the integration of the thermostat into Gladys, I created this thread to validate the integration of this feature with Zigbee2MQTT.

@lmilcent we pick up here

Gestion du chauffage native

De mon côté j’ai des têtes connectées Moes BRT-100-TRV control via MQTT | Zigbee2MQTT.

---

I’ve already had a quick look, and I can already provide a test image: atrovato/gladys:z2m-thermostat.
As a reminder, it’s preferable to back up your database or start from a fresh installation before testing a « beta » image.

Thanks in advance for your feedback.

[lmilcent]

Thanks for what you started, sorry for getting back to you only now — I hadn’t seen your message.

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

I see that the HomeKit service is present, I conclude that this image is based on the latest version with @pierre-gilles’s fixes. But as you can see on the screenshot, the thermostats are cut off on the dashboard (FullHD screen and Chrome 107).

Other feedback :

• The « Temperature » feature is added by your changes, great! =\u003e It is the temperature sensor embedded in the connected head
• There’s still « switch » without knowing what it is in the interface =\u003e It’s the [EDIT] « ECO MODE » « lock » child lock and window opening detection

[lmilcent]

I should add that the temperature control in the interface works well and this is reflected in the Z2M interface.

[AlexTrovato]

@lmilcent

I see that there is the HomeKit service, so I conclude that this image is based on the latest version with @pierre-gilles’s fixes. But as you can see in the screenshot, the thermostats are cut off on the dashboard (FullHD screen and Chrome 107).

So yes, I based it on a version that includes HomeKit, not sure it’s the latest.

@lmilcent

The « Temperature » feature is added by your changes, great! =\u003e It is the temperature sensor built into the connected head

Great!

[quote=« lmilcent, post:2, topic:7634 »]
There is still

[lmilcent]

Indeed, it’s more related to the connected head model than to the thermostat, but it affects its control, because the « eco » mode causes the setpoint temperature to no longer be used, but the « eco » temperature.
Example: 16°C as eco temperature and 21°C as setpoint temperature => the radiator will heat to 16°C/

As for the thermostat, it’s all good for me apart from the raised point:

• Reporting of the local temperature
• Sending a heating value

[pierre-gilles]

@lmilcent

Indeed, it’s more related to the connected valve head model than to the thermostat, but it influences its control

Are these so-called modes standard? Do all thermostats that handle « eco » modes, etc., have more or less the same modes?

You need to create a new type in the thermostat category for this control; in this case, it really doesn’t have much to do with the Zigbee part.

[AlexTrovato]

For your information, the eco_mode (binary) is only available on a single Zigbee device:

Moes BRT-100-TRV control via MQTT | Zigbee2MQTT

Otherwise we also talk about:

• system_mode (enum) : 'off', 'heat', 'cool', 'auto', 'dry', 'fan_only', 'sleep', 'emergency_heating'
• away_mode (binary) : what happens when I’m away?
• regulator_mode (binary) : regulator vs thermostat

I’m only talking about what I found in the zigbee2mqtt documentation.

But I think we’ll quickly get stuck if we don’t add the concept of ‹ available value › to the features, because not all system_mode options are available on every device, and if we want to manage this from the dashboard, we need to know only the modes available on the actuators.

[lmilcent]

Otherwise, shall we start with an eco / normal mode and then add to it as we go?

[pierre-gilles]

@AlexTrovato

But I think we’ll quickly be blocked if we don’t add the notion of ‹ available value › on features, because system_mode values are not all available on all devices, and if we want to manage that from the dashboard, we need to know only the modes available on the actuators.

I agree, we need to work on this in the core!

[AlexTrovato]

In the meantime, @pierre-gilles, what do you think of this proposal?

@lmilcent

Otherwise, shall we go with an eco / normal mode and then add more as we go?

Note that I haven’t found any other devices with this feature (having only searched in the list of z2m devices).

[pierre-gilles]

@AlexTrovato

In the meantime, @pierre-gilles, what do you think of this proposal?

I don’t see how it’s more complicated to add everything than to just add eco/normal?

@AlexTrovato

Knowing that I haven’t found any other devices with this feature (having only searched in the list of z2m devices).

ah! So it’s really 100% custom development then, there’s nothing generic about this behavior?

[AlexTrovato]

@pierre-gilles

I don’t see how it’s more complicated to set everything than to just set eco/normal?

In the case of eco/normal, it’s just a custom binary.
In other cases, it’s an evolution of the feature model to determine the available values, knowing

[pierre-gilles]

@AlexTrovato

In other cases, it’s an update to the features model to know the available values, knowing that this change could include the custom binary.

Is this change that complicated? I find it’s a fairly recurring request, and it would solve quite a few issues. I have the impression that even the « click button » stuff with translations could benefit from

[AlexTrovato]

Not complicated, no — just a bit heavy. As soon as it touches the core, the model, and the DB, we introduce risks. But we’re here for that.
I’m not committing to taking

[pierre-gilles]

[quote="AlexTrovato, post:15

[AlexTrovato]

Created!

Fonctionnalités avec liste de valeurs

Nous avons de plus en plus de features qui peuvent avoir des valeurs différentes, toutes ne sont pas disponibles sur tous les devices. Afin de pouvoir fournir une information plus précise sur les valeurs possibles pour une features en particulier, nous devons donc être capable de connaître et de stocker ces valeurs. Sujet source : Ici nous discuterons des solutions possibles pour réaliser ce chantier.

We can start listing our ideas over there

[Romuald_Pochet]

Hello,

Regarding the operating modes of the heaters, it should be based on the pilot wire (fil pilote):

• 4-order pilot wire (fil pilote): Comfort, Eco, Frost protection, Off
• 6-order pilot wire (fil pilote): Comfort, Comfort -1°C, Comfort -2°C, Eco, Frost protection, Off

In Z-Wave, there are devices of the 4-order pilot wire (fil pilote) type.

For the list, couldn’t we put

[pierre-gilles]

@Romuald_Pochet

For the list, couldn’t we put this one in the params field of Gladys devices and only offer that one?

I’m rather in favor of moving toward something static if it’s a behavior we can factorize

[pierre-gilles]

For your information I just merged @AlexTrovato’s PR

Thanks to everyone who ran tests!

z2m thermostat mangement

It will be included in the next Gladys release