Some time in the past few days, the way my Honeywell thermostat displays on the front end has changed.
It used to show green, filled in under the temperature bar, whenever the thermostat called for cooling. Likewise, in the winter it was filled in red. In other words, alternating bands of green and white would show as the cooling cycled on and off to maintain the temperature.
Now, as soon as I switch on cooling mode at the thermostat, the green fill is displayed, but that no longer changes when the cooling cycles off. It appears that it’s just showing that the system is in cooling MODE, not that it’s actively cooling.
I notice some other changes with this climate entity. I think there used to be only one “target_temp.” Now there’s one for “_high” and “_low.” I’m not clear on whether it was the Honeywell server which changed, the entity in HA, or something else.
Any ideas how to get back an indication as to when the cooling (and heating) are actually active?
Thank you! I missed that in the Release Notes because I was scanning for breaking changes. Admittedly, nothing really “broke,” so I guess that’s on me. There’s only so many hours in a day, and I just didn’t have time to read everything.
Yes, I recently updated to 0.96, sorry I left that out. Again, rushed for time.
The change was pretty significant. Overall, it’s a real positive, kudos to all who worked on it! This will bring the Climate integration into much better shape to support all kinds of hardware going forward.
One welcome change was this: (Quoting Paulus in the blog post linked above):
The biggest mistake we made is that we conflated operating and operation mode. Operation mode is what you want your thermostat to do, for example, heat the house to 19 °C. The operating mode is what the thermostat is currently doing. Is it heating because the house is too cold? Or did it already reach the target temperature and is it currently idle?
My problem, however, is that the climate card in Lovelace is now using that “Operating mode” (now called hvac_mode) to paint the shading under the line in the chart.
That’s not really helpful. Knowing what the thermostat is currently doing is what’s important.
The biggest mistake we made is that we conflated operating and operation mode.
Last October, when I was a Home Assistant neophyte (but not a home automation neophyte) I raised this very issue in this thread:
I used MQTT HVAC and was perplexed by the History Chart’s insistence to graph the operation mode (heat/cool/off) as opposed to the operating state (heating/cooling/idle). That’s not very useful and, as a Home Assistant newbie, I felt I must’ve configured something incorrectly. But no, it was a long-standing issue with the underlying climate component.
I looked at the source code of other climate platforms and learned it was left to the component’s author to decide which one of the two (the mode the thermostat is set to use versus what it’s currently doing) would represent the component’s state property. The History Chart graphs the component’s state property (keep this in mind, it will be important in a moment).
Anyway, this arrangement did not meet my concept of a proper History Chart so I created a custom version of MQTT HVAC and have upgraded it several times since October 2018 (to keep up with Home Assistant’s changes).
Fast forward to the present, and the ‘Climate 1.0’ initiative has addressed this issue. The climate component now has a clear separation of ‘church and state’ operation mode and operating state. The climate component’s state property represents the operation mode (auto/heat/cool/off, etc) whereas a separate attribute represents the operating state (heating/cooling).
HOWEVER, there was one little oversight in 0.96.0. Remember when I said the History Chart graphs the climate component’s state property? Well, it continues to do so in 0.96.0. That means it’s graphing the operation mode, not the operating state. Ooops!
I did the update to 0.96.2. That fixed half the problem. The operation mode is no longer flood-filling the entire space under the line in the history-graph card in Lovelace. Yeah!!
But… Now there’s NO indication of the operating state. Prior to 0.96.0, there was a filled-in vertical bar representing when the thermostat was actually calling for heating or cooling. The width of the bar indicated the duration; in other words, it started filling under the temperature line when the thermostat clicked “on” and stopped when it clicked “off.” I wish I had a picture, it’s hard to explain. But it worked perfectly before 0.96.0, so maybe Honeywell’s implementation played well with the old way, but not the new, improved way.
Here’s what it looks like now. Earlier this morning I’d turned the cooling setting down for some testing I was doing, and you can see on the graph how the “target temperature” (green) went below the “current temperature” (red.)
But there’s no indication when the operating state changed to call for cooling, which it’s done many times during the time shown on this graph.
If you’re not seeing this shaded area in 0.96.2 then I can only assume that there is still a bug somewhere because ‘Climate 1.0’ was supposed to sort this out. You may need to report this an Issue (in GitHub).
My guess is that the previous version of the Honeywell climate component, stored its operating state (that’s when it’s actively heating or cooling) in the climate entity’s state property. The History Chart’s code was designed to graph the entity’s state (it looked for heat or cool). Therefore the chart’s shaded area represented when the HVAC system was actively heating/cooling.
Like I said earlier, before the advent of Climate 1.0, not all climate platforms worked this way. For example, the MQTT HVAC platform stored its operation mode (heat/cool/auto/off) in the state property. Therefore the shaded area in its History Chart showed when the HVAC system was in heat or cool mode (which is not particularly useful).
There were several attempts last fall to change MQTT HVAC’s behavior and have it save its operating state, not its mode, in its state property. All the PRs were rejected because there was a desire to re-design the entire climate component and the long-term vision was to have the state property hold the operation mode. I think it should’ve been the other way around but as long as the two parameters are understood to be different, and stored separately, the rest is just semantics.
So here we are in the summer of 2019 and Climate 1.0 has been released. The operation mode is stored in the state property and the operating state is stored in a separate attribute. The History Chart graphs this attribute. If the Honeywell climate component isn’t behaving this way then there must a bug.
Yes! That’s exactly what I meant, thank you for posting the graphic.
I think you’re right about the cause, too. On my system, the “state” currently shows “cool” even though the thermostat is idle (not calling for heating or cooling.) And since it’s Honeywell, I should add that it’s been that way for at least 15 minutes, so it’s not just because the Honeywell server is only checked every six minutes or whatever.
I’ve never reported an issue before. Where would I go for this?
Here’s what I see under Developer Tools / State for this thermostat:
Yeah, that’s what I meant when I said “I think it should’ve been the other way around”. The state should indicate the HVAC’s system’s current operating state (What is the device doing at this very moment?) and the operation mode should’ve been relegated to an attribute. It allows me to have the thermostat what I want to see at a glance (is it heating/cooling/idle).
FWIW, it’s possible it was done this way (state = operation mode) because of other needs, perhaps for a more seamless integration with voice assistants.
Create a GitHub account and then go here to create a New Issue.
I see it’s been closed already, with a note to post it somewhere else. Good thing I didn’t try, I’d never have been as complete and succinct as you were, and I would never have been able to guess the right location to post it.
I hadn’t been running the heat or cooling until the past few days, when I noticed the shading is still missing, although all the other problems introduced in 0.96 seem to be resolved.
For good reason because the Issue was for a custom climate platform called SmartIR.
- platform: smartir
Issues posted to the repo are meant to refer to Home Assistant’s main source code, not someone else’s source code.
Although Honeywell and SmartIR climate components may share a common symptom (history chart graphs the wrong parameter) they may not share the same root cause. Even if they do, the correction may need to be applied to each one’s code (by different developers).
Anybody comfortable doing that? I’ve never done one before. After seeing the other one get closed so quickly because it was in the wrong place, I’m quite sure I’d screw up something and get the same result.
I was hoping someone who’s done it before and knows how would be willing to give it a shot.