Add the optional temperature_unit argument to climate entities set_temperature action call

[mib1185]

At the moment the set_temperature action does not allow the user to define the unit in which the temperature setpoint(s) are given. Further it does an automatic conversation of the temperature setpoint(s), which assumes the given temperature setpoint(s) are in the same unit as the home assistant unit system is set to.

Besides this, from a (voice) assistant point of view, it would be beneficial for the user to allow using written commands like "set the temperature to 23 °C", but also natural sounding voice commands like "set the temperature to 23 degrees".
We've already the definition for the HassClimateSetTemperature intent, which also foresees to optionally provide the unit for the set temperature command.

My proposal is, to add the temperature_unit argument to climate entities set_temperature action call. It is optional, so if not given, the behavior is unchanged and the unit of the configured unit-system is used. If the unit is defined in the action call, it will be used in the conversation.

• PoC: Add HassClimateSetTemperature intent core#134316

[MartinHjelmare]

How often does the user want to set the temperature with a unit other than the system unit?

[frenck]

I am not in favor for adding this for this very specific case. The main reason is that this may spiral into many other that we should consider in that case.

For example, number and input number entities have a similar thing. Color temperature of lights, similar but currently separated in multiple fields. With that in mind, I think we should look broader.

From an UX perspective, this could be part of a selector? Showing a single row with two fields: the numeric input and a unit selector?

For the latter we could consider accepting a mapping for numeric values being set (eg with value and unit) that matches the selector output

[mib1185]

I like the idea to think broader and think about a more generic solution for multiple use cases and scenarios 👍 But I assume this would require much more efforts, since it needs a new selector (frontend and backend) and adjustments in multiple places/components in the backend?
Because of this, I would suggest to remove the temperatur unit for now from the HassClimateSetTemperature intent (and my PR) and add it later, as soon as this broader approach has been designed and implemented.

[gjohansson-ST]

Without judging on the other examples, I think for climate it's not logical to run it in C and for some reason want to set a temp in F and it would just create additional complexity for hardly no use. So I'm against the proposal.

[mib1185]

I can imagine some really edge cases, like your HA is using the metric system, but you've a guest who is used to use the "US customary" system (or a guest house). But yeah this is really edge cases