My takeaway from the thread is that it is understood that operating mode and state are different things (if mode is currently heat then state can be heating or idle). However, in practice, platforms for the climate component can conflate state with mode (and that makes for a less useful chart).
There was a recent attempt to distinguish state from mode for the MQTT HVAC platform but the PR was closed. I pity the developer because the guidance offered was simply a link back to the lengthy architectural thread. I may be wrong, but it appears the developer gave up … and so the release version of MQTT HVAC continues to conflate state with mode.
I just fixed this for the radiotherm component and ran into a similar “suggestion” to read the 10 page design thread. The correct fix for now is to implement the is_on property and return True or False. That gets combined with the operation mode to determine if it’s heating or cooling. Of course this doesn’t really work - if the operating mode is AUTO then you can’t tell what’s active. But, I was told that that I couldn’t fix that - it will have to wait until climate is rewritten.
Thanks! I read Paulus’ suggestion to infer the state from the operation mode and current/target temperature. Like you said, if it’s AUTO mode, it gets more complicated to determine if the state is heating or cooling. I have some experience with this; I created a driver for a HAI Omnistat/2 thermostat (not for Home Assistant but for Premise).
The situation may be simpler for MQTT HVAC because it wouldn’t infer the state but simply acquire it from an MQTT topic. That’s what I did for the customized version I created for my own use (with version 0.80). However, as of version 0.86, it no longer works because of changes made deeper in the MQTT component.
I’m currently creating a revised version but will have to figure out a different way to handle the state. The way I originally did it is the way it was done in the PR that Paulus cancelled. I now want to do it a way that would pass muster in the event I ever wish to submit it as a PR.
Sorry - I’m confused. Any individual climate component doesn’t need to infer anything - they always have the state which is usually heating, cooling, or idle - it doesn’t matter whether it came from an mqtt payload or anything else. I don’t think you need to change anything about the internals of the mqtt climate component - the climate module is being redesigned. Once the design is finalized, all the climate components will need to be changed to meet that design. The point is to make the plot work, just add the is_on property to the current component which basically says “return True if the current state isn’t idle” and the plot will work properly.
123, I didn’t give up, just waiting for architectural changes. I update my component for every new release.
TD22057, It’s not actual state but mode and it never will be idle if you don’t set it manually or by thermostat (but it’s bad workaround because in this case, when mode is idle, there is not possible to determine actual operation mode), so chart is useless.
One more attempt to fix charts. It uses is_on property now. TD22057, thanks for suggestion.
Check out the long thread. Paulus introduced the idea that the operating state can be derived from the operating mode and other data like current temperature and target temperature. Personally, I disagree with this concept because many thermostats are able to report their operating state. To infer the operating state would only be required for thermostats that do not report it.
I’ll try that. EDIT
Doesn’t the is_on property refer to the whether the HVAC system is powered or de-powered (i.e. master switch is on/off)? That’s different from whether the HVAC system is active or inactive (i.e. heating/cooling). In other words, does is_on refer to the system’s operating mode or to its state?
I feel it refers to its operating mode. I’m basing that on how it’s handled here in init.py. It’s self.current_operation that correctly reports the current operating state and is_on reports if the HVAC system is powered up or not .
Regarding this statement in the PR:
* No support for ‘idle’ state - show ‘off’ instead
Does this only apply for the operating mode? auto, cool, heat, off (no idle)
Or does it also apply to the operating state? cooling, heating, off (no idle)
For the operating state, I believe there is a distinction between idle and off.
If mode=off and state=off then the HVAC system is de-powered and inactive.
If mode=cool and state=cooling then the HVAC system is powered and active.
If mode=cool and state=idle then the HVAC system is powered and on standby.
When it comes to operating state, off and idle are not exactly synonyms because they also reflect the operating mode.
If the proposed architectural change has chosen to conflate the two terms, then it has discarded a useful distinction.
I think is_on property refer to mode too, but I doubt that adding new properties will be merged before architectural review. ‘current_operation’ is current mode not state.
There is no way to display ‘idle’ without changing state property that isn’t allowed. However if you have idle mode it will be shown as any other mode. You are right about distinction between idle and off, but we should wait until architectural changes will be completed before trying to implement it.
def state(self):
"""Return the current state."""
if self.is_on is False:
return STATE_OFF
if self.current_operation:
return self.current_operation
if self.is_on:
return STATE_ON
return None
This is workaround that I mentioned early. It doesn’t require code changes but wil cause showing idle not only as state but as mode too instead of heat, cool, etc. That is serious problem if you have more than 1 modes.
I see; so current_operation refers to the operating mode, not the operating state. In that case, like you said, my suggestion could produce an undesirable result. I certainly wouldn’t want to see idle reported as an operating mode!
def current_operation(self):
"""Return the current state of the thermostat."""
state = self._pdp.hvac_state
if state in (1, 2):
return STATE_IDLE
if state == 3:
return STATE_HEAT
if state == 6:
return STATE_COOL
Just out of curiosity, how does Simple Thermostat render your new MQTT HVAC platform?
I tried the 0.86.4 version of MQTT HVAC and, as expected, the operating state is equal to the operating mode. In this screenshot, State and Mode indicate Heat but, in reality, the furnace is not running (it’s idle).
Naturally, this completely screws up a History Statistics Sensor I have that reports total daily heating hours. Given that state=mode, it reports the furnace is heating all day long. Just one of a few reasons I haven’t upgraded from 0.80 yet!
You can use my old component or new until new PR is merged. Both works with 0.87.
This is Lovelace’s thermostat card with new PR:
Simple Thermostat should work same, i.e show ‘off’ or current operation mode.
Thank you. However, my custom MQTT HVAC continues to work well for 0.80. It incorporates some of your code in the PR that was cancelled (to manage operating state) plus three additional COMMAND templates:
CONF_MODE_COMMAND_TEMPLATE
CONF_FAN_MODE_COMMAND_TEMPLATE
CONF_HOLD_COMMAND_TEMPLATE
It produces this with Simple Thermostat (idle state):
I’ve revised my custom version of MQTT HVAC (for 0.86.4) and now have it reporting operating state independently of operating mode. The following image shows three versions of Lovelace thermostat card all showing the correct operating state (Idle, furnace is enabled but not actively heating).
As a result, the temperature history chart, and my history statistics sensor, now correctly report active heating hours.
To achieve this, I had to directly act on self._state and use the state() method. In other words, I did what Paulus advised against … so my modification would never survive a PR review.
So is this heating chart already fixed? I am asking because I see few incosistencies and am not sure is it in system not ready or there is something wrong with my settings.
I have a Template Sensor that displays the thermostat’s hvac_action attribute. Then there are two History Stats sensors, one for heating and the other for cooling, that report how long hvac_action was heating, or cooling.
