Climate 1.0: Restore on/off functionality

[OnFreund]

Context

Now that home-assistant/core#23899 is merged, we've lost important functionality in the shape of simple on/off functionality (detached from hvac_mode) for climate platforms. This was requested by several people in the original arch topic, and in the PR, but was eventually left out.
The reasons I think this is a good idea:

1. Critical functions are currently not available. Some example use cases:

• An automation that turns the unit on and relies on it being preset to the correct values. Such an automation would now have to figure out the operating mode as well.
• An automation that sets the presets according to some criteria, so that a human can simply turn the device on when they want.
• Making sure a 2 pipe system has all units set to the same mode.

2. This is inline with the way many HVAC systems operate - they have separate on/off and mode switches.
3. This seems to be pretty standard in automation software - OpenHAB has on/off for Daikin and Coolmaster (for example), google assistant recommends the on/off trait for types of HVAC systems, etc...
4. This can be implemented in a way that does not require modifications to platforms that don't support it (see below).

Proposal

I propose re-adding SUPPORT_ON_OFF to climate, and using the following logic in clients of the component:
If the platform has the SUPPORT_ON_OFF flag set, it will call upon turn_on, turn_off, and is_on. Otherwise, to turn off it will call set_hvac_mode with HVAC_MODE_OFF to turn off, and in case there's only one more available mode, it will set that in order to turn on. This will preserve the current functionality for all platforms, and allow gradual migration of platforms that want/need distinct on/off.

Consequences

All current functionality will be preserved. Platforms with distinct on/off support will be easier to work with and support more functionality.

[andrewsayre]

I agree with this. I think the key thing I want to highlight is the loss of functionality. This isn't a complaint about having to adapt to the new schema, it's a gap in our model.

[pvizeli]

From 48 climate platform, there are currently 5 platforms they support also ON as recovery the latest state from off -> This seems to be pretty standard

Because most of the platforms they support off have no on support, we should add following to cover every case:
would say, we add a turn_on and turn_off and the climate component fake this like media_player. the turn_off send a set_hvac_mode('off') per default and turn_on select the best choise. The platform integration can overwrite what they real support on there API and can handle it better

The biggest mistake on old climate was that the on/off as state because a climate is bounded to HVAC states and don't represent only 2 (binary) states. on/off is not the primary function of a climate.

[OnFreund]

@pvizeli I agree with most of what you said except for the last sentence. For A/C systems, being on or off is the primary state as the mode rarely changes (if at all).
I would propose that default state is hvac_mode but that platforms can overwrite. For example, I have a lovelace card showing all A/C units that are on, which is really hard to do when the state is the static mode.

[pvizeli]

@OnFreund well, you can filter for things they are not in off state. If we go back that every platform can self select what should be the state, we end up in the same issue as before.

[OnFreund]

Once we restore on/off functionality, the mode would no longer be off - it would be the actual mode.
What we can do, however, is to preserve current functionality for state - i.e. off if device is off, and hvac_mode otherwise.
Example:

• Device is off, hvac_mode is cool, state is off
• Device is on, hvac_mode is cool, state is cool

[pvizeli]

We need cover external interfaces like alexa/google and follow the way that we need have a very static and fix model they don't try to implement all the functions from hardware, instead of the platform implement and call the function on their API they are needed.

That mean, if the device is on cool, they is on and you need to implement that. There was so many possible states with old model, that you end up in wired things like a device was off but in heating.

[OnFreund]

Google assistant does suggest implementing the on/off trait for some types of HVACs.
In any case, google assistant doesn't care about hvac_mode but rather about state. My suggestion above preserves states, but lets hvac_mode be controlled independently, which is the way these systems work.

[pvizeli]

we can reintegrate on/off function but never as state like before. If the user select heating, you device going on and into heating modus. To turn it first and as second call into heating is wired for an application. At the end we need a model they work for most hardware.

Your view is that HA should integrate and cover your device and not the platform should represent simplify the model they need to work for so many hardware.

[OnFreund]

My view is that HA should support HVAC systems, and many of them have independent on/off functionality. It seems to me that the opposite view is the one that's trying to adapt to a specific kind of device rather than support many of them. Also, counting platforms and counting devices is very different - CoolMasterNet by itself supports about a dozen different vendors and supports on/off for all.

Re-iterating - my proposal preserves state, but lets hvac_mode have a value even when the device is off. Clients should rely on state, not hvac_mode, and there's no reason to make them identical.

Once again, and as @andrewsayre mentioned, this is important functionality that existed before climate 1.0, and can be implemented while preserving backwards compatibility with 1.0.

[balloob]

There are lights out there that allow to change the brightness and color without turning on the light. We don't support those either.

I don't see an issue with a device returning HVAC_MODE_OFF when the device is turned off. That seems appropriate. The hvac mode should reflect what the device is currently up to, not what it would be up to if it was turned on if it is not.

The only gap I see with the new model is the turn_on method not being there, allowing an easy way to turn a device back on with the old HVAC mode restored. Leaving SUPPORT_ON_OFF was a good decision.

[OnFreund]

Small correction: I do propose that specifically lovelace does display hvac_mode so that you can see the mode your device is set to even when it's off. Selecting one of the modes in lovelace would set hvac_mode as well, and platforms that have SUPPORT_ON_OFF can then keep the device off.

[OnFreund]

@balloob as mentioned in the PR, I don't think the comparison to light is a good one. Additionally, the brightness is similar to temperature, which we do allow to change while the device is off, not to its hvac_mode.

Your suggestion covers the first use case I mentioned, but not the other two.

[pvizeli]

I add a draft to show what I mean and what I think is the best for every exists integration/platform: home-assistant/core#25026

[OnFreund]

@balloob @pvizeli
Another approach: literally every A/C panel/thermostat I've seen in my life had at least 3 distinct controls:

• on/off
• mode (usually heat/cool/auto/fan)
• some form of "intensity" or fan speed.

Most modern systems also support temperature, and some have additional controls (e.g. fan direction), but all of them have those basic 3. Given the insistence for climate to not support this mode of operation, I propose A/C becomes a new component. Climate will mostly support heating systems, and could potentially be simplified as a result.

[pvizeli]

home-assistant/core#25026

=

The only gap I see with the new model is the turn_on method not being there, allowing an easy way to turn a device back on with the old HVAC mode restored.

!

Yes, the benefit of new model is that we protect the climate to go in such weird state. Everthing is on what is not explicit off. So if you have a nest/homematic/ecobee -> all looks same on HA (well, presets are different). So you turn you device off if they go to off state and if they go to cool state, you turn it on. My PR above only allow to use the native restore functionality they are offer by less as a handfull hvac devices and allow that every climate can handle on/off thraits like google described.

[OnFreund]

"Yes, the benefit of new model is that we protect the climate to go in such weird state"
That "weird state" is what every A/C thermostat in the world is in when you set it to cool and turn it off.
I think you're also confusing state and hvac_mode which don't have to be identical. I'm ok with state being off, but there needs to be an attribute that represent what the device will do once turned on - that's how A/C controls work.

Once again, if this is not what you want for climate, I propose a new A/C component.

[balloob]

You want a new AC component because you can't change the mode when a device is off. We're not doing that.

This issue has been resolved with home-assistant/core#25026

[OnFreund]

@balloob I don't want an A/C component - I'm proposing one because central heating and A/C work fundamentally differently and there seems to be no appetite to have climate support the latter. I'm also not the only one proposing it (for example, #260 (comment)).

This issue has not been resolved. I've listed 3 use cases that are critical to A/C systems, and only one of them was addressed. I'm also not sure what the big harm is in a property that gets/sets the desired mode of operation detached from on/off. How is that fundamentally different from temperature, or preset, or fan mode, or fan speed, that we do allow to get/set when off?