Frontend: Climate 1.0: Restore Missing UI functionality

[OnFreund]

Context

(I'm not sure this is the right place for this, but I couldn't find a better one. Let me know if I'm missing anything).

Since Climate 1.0 came out, the UI has lost functionality, some of which was missing in the backend and since then restored, and some that I'm not sure why it was dropped.
Specifically, I would like to restore the following functionality:

1. The ability to turn a climate device on (both in the lovelace card and in the thermostat dialog)
2. The highlight over periods in the graph when the device was not off.

Proposal

Restore those two missing pieces of functionality, along with anything else that I might have missed.

Consequences

This functionality existed in the past and is supported by the backend, so there shouldn't be any consequences.

[zxdavb]

This issue - climate graph not showing green fill - affects:

• evohome (tested today by me)
• generic thermostat, honeywell, and Ecobee via HomeKit Controller (as reported above, https://github.com/home-assistant/home-assistant/issues/25722)
• mqtt - https://github.com/home-assistant/home-assistant/issues/25917

And also with some custom_components (yes, I know, but anyway): https://github.com/home-assistant/home-assistant/issues/25578

Duplicate issue here: #3423 (MQTT)

[zxdavb]

This is an evohome system:

[OnFreund]

@zxdavb it also affects CoolMasteNet.
Based on the discussion in other issues, it seems that there are two separate causes. First, a bug, but once it's fixed, some platforms are still not going to work, since the green fill is based on hvac_action.
I can understand that decision, but since hvac_action is an optional attribute, I would suggest falling back on hvac_mode when hvac_action isn't implemented.

[tdejneka]

I'll add this to the list which raises the same issue concerning the lack of shading in the chart to indicate when the HVAC system is operating (for MQTT HVAC):
https://github.com/home-assistant/home-assistant/issues/25917

the green fill is based on hvac_action

Yes, but even when the integration does support hvac_action it would appear there's still the potential for failure. Case in point is MQTT HVAC. In 0.96, it lacked hvac_action. In 0.97, it was added but even the author of that modification reported the chart still fails to show the shaded area (see PR 3423).

This was supposed to have been fixed by PR 3380: Fix shade for HVAC action on graph. The code is clearly looking for hvac_action to be either heating or cooling in order for it produce the shaded chart area. However, something still isn't quite right because it fails to do that.

[benquan]

I would also second @OnFreund suggestion: "I can understand that decision, but since hvac_action is an optional attribute, I would suggest falling back on hvac_mode when hvac_action isn't implemented."

[tdejneka]

but since hvac_action is an optional attribute

It's _not_ an optional attribute. hvac_action is part of the Climate 1.0 architecture. Every climate platform is supposed to implement it (assuming the platform can support it). If the platform you are using doesn't have hvac_action, then it probably just means it hasn't been updated yet. This was the case with MQTT HVAC in version 0.96 (when Climate 1.0 was introduced). It didn't get an hvac_action attribute until it was updated in 0.97.

A 'fallback' is unlikely since hvac_mode was implemented inconsistently pre-Climate 1.0. For a few platforms it represented its operation mode (heat or cool, worthless for graphing) and for others it was its operating state (heating or cooling, which is the purpose of hvac_action).

[OnFreund]

@tdejneka like you said - assuming the platform can support it (meaning it's optional). The platform I'm using was actually written by me, so it's not a matter of updating.
As of Climate 1.0, hvac_mode is consistent (that was the main driver of Climate 1.0), so there's no reason not to fallback on it.

[tdejneka]

assuming the platform can support it (meaning it's optional)

No, it doesn't mean it's 'optional'. It's mandatory for reporting its operating state which is what gets graphed.

If it can only support hvac_mode that property does _not_ represent when it is actively heating or cooling. hvac_mode represents which mode is in effect (like heat or cool) which is _not_ graphed by the Climate 1.0 architecture and for good reason because it's virtually worthless to graph (the HVAC system is either ready to heat, or to cool, or is off; being 'ready to do something' isn't very graph-worthy). That's why a 'fallback' is unlikely to be implemented because the effort to achieve it isn't worth the result.

The onus is on each platform's developer to update their code to meet the requirements of Climate 1.0 and that means implementing hvac_action. If the device cannot report its current state (heating or cooling) then hvac_action cannot be implemented and its graph will lack the shaded area.

---

EDIT

BTW, there's no need to request a 'fallback' for the charting code. If you are the author of the custom component (and the device really can't report its actual operating state) simply modify the component so that hvac_action duplicates hvac_mode. That will allow it to be graphed (although, as I mentioned earlier, graphing the operation mode isn't particularly useful).

[ltjessem]

If this is the case then why doesn't generic_thermostat show a shaded area? It reports hvac_action but is not graphed.

[OnFreund]

@tdejneka we can split hairs on the definition of optional, but the point is that there are platforms where you can't implement hvac_action yet it makes total sense to fallback on hvac_mode.
Take A/Cs for example (already the biggest victims of Climate 1.0):

• Many, if not most, of them do not report back their current action.
• Many, if not most, of them support an automatic heat/cool mode.
• Many, if not most, of them (especially VRF systems), always "do something" when they're on.

The intersection of all 3 is a pretty large group that can't have hvac_action implemented (because you don't know if it's cooling or heating, for example), yet can have a trivial implementation of the green fill, which doesn't care if the device is heating or cooling, since it's green either way.

I've implemented my platform according to the Climate 1.0 specification, which has already resulted in a loss of important functionality. There's no reason to lose more functionality, especially when the implementation is trivial and accurate.

[OnFreund]

More succinctly:
hvac_action requires a distinction between heating and cooling, the green fill does not, therefore there's no reason to mandate one for the other.

Additionally, there's already a fallback if the device is not a climate device (e.g. water heater), all that needs to be done is extend it to climates w/o hvac_action.

[tdejneka]

The principal change in Climate 1.0 is the _distinction_ between an HVAC system's mode (hvac_mode) and its activity (hvac_action).

Previously there was no such distinction. As a result the "green fill", as you've described it, represented the HVAC system's operation mode (i.e. the entity's state). Effectively, it indicates when the HVAC system 'might be operating but most of the time is not' ... not very useful information.

A few component developers worked around the issue by changing the entity's state from representing its mode to its activity. This resulted in the "green fill" indicating when the HVAC system was actively heating/cooling (this is useful information; expenditure of energy over time). HOWEVER, this solution broke the rule that the entity's state must represent its operation mode. (a practice discouraged by balloob).

Climate 1.0 addresses the need to distinguish between operation mode and activity. In addition, it changes the "green fill" to represent the system's activity, not its mode.

Requesting a fallback to the old way of charting would make the meaning of the 'green fill' _inconsistent from one platform to another_. Instead of the "green fill" consistently representing when the HVAC system is _active_ (heating/cooling), for some platforms it would mean the system is just _enabled_. That's a step backwards; it re-establishes the inconsistency of pre-Climate 1.0.

[OnFreund]

Climate 1.0 was all about the state representing the mode vs the activity. It does not mean that other clients should rely specifically on one of them.

The green fill (name used by others in the related issues, I'm just using it for consistency) can rely on whatever it wants, without it being a regression or going against Climate 1.0. If anything, forcing platform developers to implement hvac_action just for the green fill would be a regression.

While I understand the reasoning for Climate 1.0, its pro-heating-systems bias has already resulted in degradation of A/C systems support. While the other degradations could potentially be justified, this one cannot. Even if there was some consistency concern here (which there isn't, as I showed above), user experience seems like a more important concern.

[OnFreund]

Also, if consistency is what you care about, Climate entities do not show their past state in their history chart, whereas other entity types do. Let's fix this inconsistency.

[balloob]

• I'm fine with hvac_mode being used if hvac_action is absent
• ~hvac_mode~ hvac_action is optional for climate integrations
• I don't know why my fix didn't work. It's tagged for the frontend project so we are planning on fixing this. There are just many things to do, and not many frontend devs.

[OnFreund]

Thanks @balloob.

I'm assuming you meant that hvac_action is optional, not hvac_mode in the second bullet point, right?

[balloob]

Yes, my bad.

[tdejneka]

• I'm fine with hvac_mode being used if hvac_action is absent
• hvac_action is optional for climate integrations

Over one year of deliberation and development for Climate 1.0 and in the end, climate platforms will remain as inconsistent as they ever were?!?

¯_(ツ)_/¯

[balloob]

Not really. We split out hvac action and mode as 2 properties, instead of 1. That clarified a lot.

Each abstraction will allow for optional fields as not every platform can provide things, that's just the way it is. We should try have the UI adapt to each situation as good as possible.

[tdejneka]

Splitting out hvac action and mode isn't the issue. The issue is allowing either one to render the history chart's "green fill". This repeats the inconsistent way the history chart was rendered in pre-Climate 1.0.

In pre-climate 1.0, the history chart's "green fill" for many platforms was mode vs time. My furnace is in heat mode for ~ 4 months so the chart shows "green fill" 24 hours x 7 days x 4 months. That's not a useful chart (an opaque blend of when the furnace is _waiting_ to heat and when it actually _does_ heat). On the other hand, the history chart for some other platforms was activity vs time. This produces useful "green fill" indicating actual activity (i.e. energy expenditure) vs time.

However, to achieve it, the climate entity's _state_ was used to represent its activity, not its mode. This was allowed ... until it wasn't.

Last October you vetoed definitio's PR to fix MQTT HVAC's history chart (in fact, I believe it was his second attempt; the first was also rejected). Your reason was that the entity's _state_ shouldn't be used that way (despite the fact other platforms were already doing it). You indicated the climate component was undergoing a major re-design that would address this requirement.

Fast forward 9 months to the present and, yes indeed, we have a new hvac_action property to serve as the history chart's y-axis (support for hvac_action was implemented by definitio in 0.97) . Wonderful, except for the fact that the entity's state (a.k.a. hvac_mode) has also been grandfathered in so we've retained the inconsistency of the "green fill" meaning one thing for some climate platforms and something entirely different for others. Two steps forward, one step back.

My opinion is that if a climate platform is incapable of reporting its activity, and there's no way to infer its activity, then it gets _no_ 'green fill' on its chart. This green-shaded area should only have one interpretation for all climate platforms and that's indicating when the HVAC system is _active_ (i.e. expending energy). The green fill's meaning shouldn't depend on which climate platform is in use.

[ltjessem]

Still broken in 0.98.0

[bramkragten]

Have looked into it, but it seems like the history only contains a small subset of the attributes, and doesn't include hvac_action.

history:

attributes:
current_temperature: 22
target_temp_high: null
target_temp_low: null
temperature: 24

State:

attributes:
hvac_modes: off,heat,cool,auto,dry,fan_only
current_temperature: 22
min_temp: 7
max_temp: 35
temperature: 24
target_temp_high: null
target_temp_low: null
current_humidity: 54
humidity: 67
min_humidity: 30
max_humidity: 99
fan_mode: On High
fan_modes: On Low,On High,Auto Low,Auto High,Off
hvac_action: heating
swing_mode: Off
swing_modes: Auto,1,2,3,Off
aux_heat: off
friendly_name: Hvac
supported_features: 111

[OnFreund]

@balloob
https://github.com/home-assistant/home-assistant-polymer/pull/3570/ only addresses half of this. The other half is:

The ability to turn a climate device on (both in the lovelace card and in the thermostat dialog)

Can we reopen this?

[bramkragten]

@OnFreund What do you mean with turn on? You can set the operation from Off to Heat or Cool or whatever your climate device supports?

[OnFreund]

@bramkragten that requires deciding the mode. The climate platform already has a climate.turn_on that platforms can override.

[balloob]

Please open a new issue for this.