Change in Honeywell Thermostat Display - Time in cooling mode not shown

[CaptTom (Tom)]

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.

This seems sort of useless:

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?

[nickrout]

You don’t give us even the barest of information about your system, like home assistant version. However you are on 0.96 you should read the release notes on changes to the climate system.

[CaptTom (Tom)]

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.

There’s a great write-up on the dev blog, which was (helpfully) linked from the Relase Notes page.

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.

[123 (Taras)]

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:

Explanation of climate history chart?

I’ve been experimenting with the climate component for the MQTT platform (MQTT HVAC) and I have a question about the climate history chart. Here is its appearance in the UI widget: [HASS%20Thermostat] Here is its appearance in the History menu: [HASS%20Temperature%20History%20Chart] What does the green-shaded area represent? My guess is it represents the component’s current operation mode. In the example above it is set to heating mode. If operation mode is ‘off’ then the shaded area is w…

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!

That little bug was corrected in 0.96.1. There was also another bug corrected, specific to the Honeywell integration in 0.96.2. You should upgrade to the latest available release which is currently 0.96.2.

[CaptTom (Tom)]

@123

That little bug was corrected in 0.96.1. There was also another bug corrected, specific to the Honeywell integration in 0.96.2. You should upgrade to the latest available release which is currently 0.96.2.

Thank you for the quick response!!!

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.

[123 (Taras)]

@CaptTom

Prior to 0.96.0, there was a filled-in vertical bar representing when the thermostat was actually calling for heating or cooling

I believe what you are referring to is the shaded area that represented when the HVAC system was actively heating/cooling (i.e. doing actual work as opposed to being idle).

Here’s a screenshot of my thermostat which is running my custom version of MQTT HVAC (in 0.89). The green shaded area indicates when the AC ran this morning.

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.

[CaptTom (Tom)]

@123

Here’s a screenshot of my thermostat which is running my custom version of MQTT HVAC (in 0.89). The green shaded area indicates when the AC ran this morning.

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:

[123 (Taras)]

@CaptTom

On my system, the “state” currently shows “cool” even though the thermostat is idle (not calling for heating or cooling.)

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.

@CaptTom

I’ve never reported an issue before. Where would I go for this?

Create a GitHub account and then go here to create a New Issue.

[benquan (Ben)]

I posted the issue: https://github.com/home-assistant/home-assistant/issues/25578

[CaptTom (Tom)]

Thanks!! Good write-up!

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.

[123 (Taras)]

@CaptTom

I see it’s been closed already, with a note to post it somewhere else

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

[Erwin_Nieuwenhuis]

This same issue also appears at my Generic Thermostat.

Prior to 0.96 I had the green shade in the graph. After upgrading to 0.96 there is no green shade anymore.

I commented to the closed issue, no idea if someone reads it over there.

Maybe we need to open a new issue, because I think it is something in the Home Assistant Climate component, and not depending on the platform.

My code:

climate:
  - platform: generic_thermostat
    name: Ventilatie Receptie thermostaat
    heater: switch.ventilatie_receptie
    target_sensor: sensor.ventilatie_receptie_temperatuur_min
    ac_mode: true
    target_temp: 22
    initial_hvac_mode: "off"

[HypnoToad]

Maybe we need to open a new issue, because I think it is something in the Home Assistant Climate component, and not depending on the platform.

It would be best to open a new issue imo

[CaptTom (Tom)]

@HypnoToad

It would be best to open a new issue imo

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.

[ltjessem]

Still not working in 0.97.0, did anyone open an issue?

[makai]

There is one here:

Generic Thermostat - graph not showing green fill after 0.96

But it has been opened in HA backend repository. I think that it’s a frontend issue.

[CaptTom (Tom)]

Just to close the loop… I had to run the heat the other day (ug!!) and it’s fixed!

The issue (linked above) now shows others reporting that it’s fixed with version 0.99.2. I’m at 0.99.3, but haven’t needed heat or air conditioning for a while, so I didn’t notice.

[CaptTom (Tom)]

@123

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.

Now it’s fall, and the problem is back. But only on two of my three thermostats. The other one looks like it is working. Here is the working one, and one non-working one:

Note the green vertical bars on the “1st Floor” graph. Those appear when the thermostat is calling for heat. It’s not that cold out yet, so it doesn’t stay on for long. On the far right is the widest bar, when the thermostat went from 62F to 68F, so the heat had to run for a while to recover.

Note the lack of any green bars for “Guest Room.” I know that the heat came on several times, and there should be a wide bar at 8PM when the thermostat called for heat to raise the temp from 64F to 65F, and again just now when I cranked it up to 66F.

I also confirmed that the hvac_action attribute does change to “heating” at the appropriate times for both thermostats.

The only difference I can see in the way the two thermostats appear in Developer Tools / States is that the 1st Floor controls the air conditioning, too, so it has the following attributes:

Could it be that the shaded area in the graph isn’t based on the hvac_action?

For example, there is also a fan_action attribute. That attribute is null for the the thermostat which only supports heating (hydronic baseboards; no fan) but it does (incorrectly) show up as “running” on the one which also can control the air conditioner in summer.

If this was the attribute chosen to draw the shading, I’d call that flat-out wrong.

The fan is not an indication of the action of the heating or cooling system. Some systems, like my heating system, have no fan. It’s also possible to run the fan continuously, whether the system is cooling, heating or just circulating air. And even if the fan mode is set to “auto,” most systems run the fan for a while after the heating or cooling has stopped.

Is there any way to check which attribute the shaded area is showing?