climate entity: Make min/max setpoints optional, do not validate using assumed setpoint ranges

[AlCalzone]

I'll use thermostats as an example, but the principle applies to all setpoint types of climate devices.

Background

When changing setpoints of thermostats, recent releases (I'm not clear which PR did it) validate that the new setpoint lies between the min and max, and don't accept any setpoints outside of this range. For some devices however, it is not possible to determine the range of valid setpoints, so the defaults of 7...35°C are chosen, preventing users from setting valid setpoints outside of this range.

Some examples are Z-Wave devices which implement Thermostat Setpoint CC version 1 or 2, which are still pretty common.

This has been reported in home-assistant/core#123612

While validating setpoints sounds reasonable, enforcing them when the range of valid values is assumed seems wrong however. In addition, this violates a Z-Wave certification requirement:

Yes, I'm aware that HA does not model its entities after a single protocol, but in this case the Z-Wave requirements follow common sense in my opinion: When the range is not known, leave the choice to the user.

Proposal

• Make min_temp, min_humidity, max_temp and max_humidity optional.
• Do not enforce that the setpoint >= min when min is unknown
• Do not enforce that the setpoint <= max when max is unknown.
• Where both limits are required, e.g. for display purposes in the UI, keep assuming the default values for the missing properties, as long as this does not lead to an invalid range, e.g. when max_temp < DEFAULT_MIN_TEMP.

[EnochPrime]

I think I found where this was introduced.
home-assistant/core#118649

[PeteRager]

I like the approach as it gets us out of the current issue and the work for each integration is minimal or none if it's defaulting to the base class implementation.

Two notes.

a) Right now the UI limits may be modified by the user by using "customize" in configuration.yaml
b) Just because a thermostat supports a heat range of 44-99 doesn't mean I as a user of the thermostat want to allow that range. Most thermostats allow the limits to be customized by the owner. I'd propose the same for HA. Allow the user to set range limits. For example, for my home thermostats I'd set heat limits to 55-71, for the garage 40-45 and I'd want the UI and the validation code to use there limits rather than the range the thermostat supports.

[PeteRager]

Branch that prototypes the changes for the base climate entity temperature that are being recommended. Note: The zwave_js climate.py also need to be updated to return None instead of DEFAULT_MIN_TEMP and DEFAULT_MAX_TEMP ..

home-assistant/core@dev...PeteRager:core:climate-range

[gjohansson-ST]

With this we seem to cure a symptom by making these optional for the validation.
As noted in the initial background it should be possible by the user to define the range but that's not included in the proposal, so the statement that this invalidates a cert requirement does still mean after this modification would be implemented, that the cert requirement is still not valid as the user can still not set the range.

Perhaps it's not a bad suggestion to make the validation optional (especially for generic integrations such as zwave) but the background for the issue seems incorrect.