The zwave_js climate entities clear the temperature (set-point) attribute when turned off. Is there is a fundamental reason for it (e.g., Zwave protocol), or is it an implementation ‘feature’? It is rather inconvenient: in order to know what the set-point temperature is I have to turn the thermostat on. It is not like that in other climate entities (e.g., the generic thermostat, or some Mill heaters).
Any thoughts?
I believe that is a choice in the integration. At least it is in the integration I wrote for Lennox hvac.
That said, I believe it also to be the correct behavior and consistent with the way most mainstream thermostat panels work (Nest, Honeywell, Lennox)
Remember the setpoint is dependent on the mode. If it is in heat mode the setpoint is different than cool mode; or if it’s in heat-cool mode there are 2 setpoints. So, if the thermostat supports more than one mode which of the possible 3 setpoints should it show when turned off? IMO The best and most consistent answer is not to show any setpoint.
Thanks @PeteRage , that makes sens of course. Although it’s probably a matter of taste also. If a thermostat has only one state (cool, or heat), then it’s clear which value should be displayed. So this choice is sacrificing functionality for possible generality and consistency, which are not really there: some other thermostat, as the mentioned generic thermostat, behave differently and leave the set-point intact.
But even if the thermostat has more states, you are likely using either cooling, or heating at any given period of time. So IMO it could be ‘correct’ (as in - intuitive) to leave this value untouched at what it was at the time of turning the thermostat off.
As said, your argument is also a good one, but it would be good at least to have a consistent behavior across HA.
FWIW, I am using the MQTT HVAC integration and when my climate entity is off it continues to display a temperature attribute with the value that was last used.
The HA developer docs don’t give strict guidance for things like this, and integrations are written by entirely different people, who have different opinions or ideas, so it’s natural there’s some inconsistency. Not to mention, the device or the integration’s support libraries may make it more difficult to support this behavior compared with others.
The actual names and definitions of these attributes are target temperatures:
To be pedantic, what is the current target temperature if a thermostat is off? It makes sense to me that there isn’t any target temperature, it’s not doing anything.
If you want to track the setpoints yourself, you can create template sensor entities by using the zwave_js.value_updated event as a trigger for the template. The device diagnostic file can guide you to determine which event parameters to use.
Since we’re keeping score, my Homekit thermostat (Sensi) does not support a temperature attribute when it is off.
What Generic Thermostat and MQTT HVAC have in common is that they don’t represent a specific manufacturer’s device; they represent a general-purpose climate-control device (with no specific pedigree or perhaps one that has no native integration other than via MQTT). That may account for some of the differences in how they handle certain things (i.e. more generically) compared to integrations that represent actual, branded thermostats.
As for what is the ‘current’ target temperature when off, I would have to agree that it’s ‘none’ because it’s not in an operational mode.
That’s where Generic Thermostat and MQTT HVAC may be somewhat misleading by displaying a target temperature even when off. That value is for whatever mode the climate entity was in prior to being turned off. In other words, when off, they continue to report a target temperature for a previous, and now unknown, operating mode; it’s incomplete information and not a good basis for use in, say, an automation/script/etc.
I agree with the suggestion that if you need to know the previous operating mode and target temperature(s) then you should devise a means to track it (like with a Trigger-based Template Sensor).
Thanks all for the clarification. I will do exactly that - track the set-point state in my component.
FWIW, I rarely turn thermostats off instead I have automations that turn the setpoints down. If my HASS box fails (it will eventually), i prefer my heating system to keep working.
@PeteRage That’s also a very good point. I have now re-written my code to use temperature_off, temperature_boost, and temperature_setpoint. Thanks for the suggestions!
