Remove setting hvac_mode from ClimateEntity.set_temperature service

[gjohansson-ST]

Background

Currently in ClimateEntity there is a possibility to set hvac_mode as part of using the set_temperature service.

This provides some challenges that becomes very integration specific for validation of a temperature as the min and max temperature can be different depending on hvac_mode. As example see issue: home-assistant/core#128118
All logic to handle temperature in combination with changing the mode needs to be in the integration and can't be managed by the ClimateEntity itself which limits what we can do in a validation method.

The other service calls in ClimateEntity does not have this problem as they are single-purpose only.

Couldn't track each PR but it seems it was there somehow from the beginning, then removed and in version 0.30 it came back with home-assistant/core#3646 but the logic for adding it seems fuzzy to say the least.

Proposal

Remove hvac_mode from the set_temperature call so that it's purely used for setting temperature.
Users would have to use two action calls for the same procedure e.g. one for changing hvac_mode and another for setting the appropriate temperature(s).

During the deprecation period we would have to skip validation when hvac_mode is used as parameter to the set_temperature service.

Benefits

• Clean action calls. Single-purpose
• Full validation of user input

Alternatives to consider

• Allow integrations to skip validation by setting some skip_validation_for_set_temperature_action attribute.
• Use the validation method to separate the set_hvac_mode call and set_temperature call so that hvac_mode is set first and then secondly we call the set_temperature method. This way we would not have issues with the min/max property to be different depending on hvac_mode. See comment

[elupus]

I dont have any major opinion here, but i do know people do use it. Say having some automatic target heating temperature automation update the heating target, yet when climate is in cooling mode since its currently warm out.

In practice we are overloading one attribute with multiple states. So maybe the correct change would be to deprecate the non high/low temperature attribute and only keep the two distinct values.

So one always meaning setpoint for cooling and one for heating independent of mode, and... Importantly, supported even if only one hvac mode exist.

[gjohansson-ST]

When I think about this I typically think how I would operate a heat pump (or other climate devices) using a remote, control panel etc. and I can not imagine any device where it's possible to operate a temperature and an operational mode using a single command.
Therefore the proposal as it's made even though I'm sure this is extensively used (probably more as a shortcut to have a single action call rather than two in an automation or similar).

[elupus]

If i wanted i remote, id use a remote.

My heat pump support cooling temperature setting, even if its currently only allowed to heat.

[gjohansson-ST]

The documentation says "HVAC mode to set the climate device to. This defaults to current HVAC mode if not set, or set incorrectly." so it's for changing the current mode to something else (or same as current), not for modifying the property for a mode it's not using at the moment.

[elupus]

Let me refrase, my proposal would be.

• deprecate mode (and temperature?)
• always allow high, low values
• during deprecation period (or perhaps indefinitely), convert mode+temperature to temperature_high/low depending on passed mode or current mode.

This allow backend always assume high/low is present and map to expected set point.

[PeteRager]

It seems to work fine as is and provides an easy mechanism to change the hvac mode and provide a new temperature. We create work for existing implementations whenever we change something that works that people use.

For thermostats my preference would be for user definable limits - that can be used to override the defaults - and we can make these mode specific (e.g. heat hi limit, heat low limit, cool high limit, etc.). Just because a thermostat allow you to set 44-99 degrees as the heat setpoint; doesn't mean that I as a user of home assistant want the ability to set it that high or low Myself I would like to set the range to 59 - 71. I'd like to have the UI use those limits and the service to enforce those limits.

But for the thermostat in the garage I'd set the heat range to 40-45 - as I never want it to be warmer. If I had a commercial freezer the limits would be -20 to 0.

Historically customize has been used to change max and min and these are picked to by the UI. So we could use customize to do this or provide the ability to define new attributes on entities and store these in the entity registry.

[elupus]

Consider the follwing case.

1. Climate entity with heat or cool, not auto or combined.
2. Automation switching heat/cool based on outside temperatur or time of day
3. Automation changing target temperature based on house occupancy to keep cost down.

2: will set mode of climate, it does not modify set points and only need to trigger based on temp changes and/or time of day
3: will set the temperatures for heat and cool, currently as two separate calls. One for heat one for cool. It does not want to change the mode, it only need to trigger when occupancy changes.

If the set_temperature changes modes, the above scenerio is harder to realize. Since the automations cant control the heat and cool points without needing to know if we want to cool or heat at this exact moment. Meaning you have to create some combined automation. Not impossible, but harder.

[gjohansson-ST]

Yes, but also today that needs to be some custom service given that the hvac_mode in set_temperature method is meant to change the hvac_mode, not set a temp for a mode which it's not going to run.
My meaning for this proposal was not to consider all possible scenarios but to clean up the processing of this particular method as today it's quite different between integrations how it's implemented and therefore also in terms of validation makes the processing pretty hard to handle all the scenarios.

• Some integrations only support setting temp
• Some integrations supports setting temp and mode
• Some integrations (can) support settings temp for non-running mode
• Some integrations sets temp and then switch mode
• Some integrations sets mode and sets temp
• ...

Another alternative (as you mention) could be to change the definition of the hvac_mode in the set_temperature method to be not changing the mode but only to update the temperatures for it. However I think that would be very difficult for both users and developers to bridge from current implementation to new.

[elupus]

Just found this discussion too: #1071

[BradleyFord]

How would this affect Daikin heat pumps?

For Daikin the setting of mode and temperature are totally independent.
At the moment I need to use a HACS Climate Template to translate between HA (Mode + Temp together) to and from Daikin (Mode + Temp separate)

I am using BACNET, but the same approach is also needed for Daikin via Modbus, and I think KNX.

[PeteRager]

An alternative could be that the validation manages the call for setting the mode and then sets the temperature instead of right now it's integration specific to handle it in the same call.
That would solve the problem of min/max that can be different per hvac_mode and we would not mix the two things in the same service anymore.

I like this.

The challenge is set_hvac_mode is a request to set the mode and returns once the request is sent (zwave/nest); and then later on an update is received from the device with its new mode and HA updates the hvac_mode,

For NEST, this takes on average 1.8 seconds (time from issuing the request to hvac_mode updated in HA); with a 2.2% retry rate (meaning the change does not occur within 10 seconds and needs to be resent)

For Zwave, this take on average 0.1 seconds with a 0.4% retry rate.

I know this because I woke up in the cold one two many times; and then implemented scripts (https://github.com/PeteRager/hass_rs) to automate the process of retrying and collecting stats.

If we deprecate the mode in this call; users will have the same challenge; as they will need to issue the mode action; delay or use a wait_template for the mode to update; and then call set_temperature - to get the correct validation.

This is becoming complicated because the underlying climate data model is insufficient for the use case. If the model represented setpoint ranges for the available hvac_modes - this would be easy. Right now min / max may be mode specific and as being discussed in another arch topic - sometimes min and max are not even known or available for the device and are defaulting to arbitrary values. Hence, it may make sense to update the model so we can accurately support the setpoint validation code.

In my lennoxs30 custom integration; I probably have over 100 lines of code to validate all the permutations of setpoints and thermostat modes - so if we can get this right; we can eliminate lots of redundant (and probably inconsistent) validation code.

[balloob]

Just a note for people that like to set both values in a single action, scene.apply is the way to go to specify all values in a single call.

[elupus]

I think most want to set the temperature for a given mode, "without" affecting/changing current mode. But yes for the use case of changing the mode, scene apply would make sense