I would suggest to avoid abbreviating to temp here to remain consistent with the target_temperature. I'm wondering though if this is not something to be implemented by the platforms themselves or be done with automations?

I think that some platforms allow to set a min / max temperature corridor, i.e. "start heating as soon as the temperature drops below target_temp_low, start cooling as soon as it exceeds target_temp_high". I would have to go through all the platforms though to verify this.

Yes, I merely meant that the names should be target_temperature_high and target_temperature_low so that they are consistent with the "base attribute".

Yes, I would certainly do that, as well as renaming any "temperature" or "humidity" without a "current_" or "target_" into the respective one, to avoid all the confusion.

There are multiple settings here:

• min and max temperatures = used to avoid freezing or overheating by mistake
• tolerance = most thermostats implement this around target_temperature
• other targets = this is used as separate values for special modes (away, holiday, etc.)

I have to agree that min/max could be reused for away for example and use min for heating and max for cooling, however it really depends on the granularity that most users already use.

As mentioned by @MartinHjelmare, this sounds too device-specific (if there is a need, how about allowing platforms to specify what types of "heating modes" they support?

Sounds reasonable, I was trying to standardize as much as possible…

As in the case of Generic Thermostat it really depends on the platform implemented. There might be the case that the component in home assistant will allow the ability for people to use a component that allows combining of a gas heater with an A/C unit under the same component and provide "auto" modes.

Shall the calls trying to control the device be just ignored by the component if this is set to preset, and leave it to be handled by the platform, i.e. allow only executing e.g. target temperature changes when this is set to manual? What is the expected outcome? What happens if a preset is "boost warming" but the action is "cooling"?

Good question. Personally I would think that as soon as e.g. set_temperature is called, the control property is changed to manual, i.e. presets are inactive from this point on. If the user calls set_temperature, he obviously wants the temperature not to be whatever the current preset says.

Thinking about it, that's nonsense. Setting a temporary temperature until the next scheduled temperature change happens makes a lot of sense.

I've seen this feature on Tado, where you can have some standard settings and the ability to diverge from those manually based on a condition (until manually moved back or until next automatic change comes into effect).

This would be a good feature to add, to allow comparison between presets and automation (in case the component allows it) and manual changes done to temperature through the UI.

Some devices support a specific away mode, but should this either be done with help of automations, or made more generic (considering that also other sorts of devices could benefit from it). eq3btsmart provides this currently through its operations list.

So… would "away mode" possible be a candidate for another option in the control property? Then it would be auto, manual and away, basically making away a special kind of auto.

I think that sounds fair, but I'm not sure if everyone agrees with it, and would prefer to let a separate service to handle that :-)

If you have auto, manual and away then you would rather have: home, sleep, away, vacation, manual.

This sounds like an attractive setting if you could publish metrics around it to graph it properly.

Would it make sense to provide a more generic interface to let platforms inform the component what kind of modes are supported?

You mean that platforms should be able to dynamically add properties? That would certainly be possible, but really go into the opposite direction than "standardize as much as possible", right? Also I think this would not be nice for the frontend…

Agreed, I was just thinking whether those are too specific for a broader "climate" device, but maybe it makes sense to expose "SUPPORTS_SWING_MODE" and "SUPPORTS_FAN_MODE" and leave them like proposed.

In my opinion away mode should change the temperature, but should also restore it when removed to previously set value.

After looking through various implementation (some of which I find wrong), I think operation_mode makes sense.
operation_mode should be determined by the component and specify what types of function could your "climate" component perform.

Some climate devices can do only heating, some can do only cooling, some can do both, some can do both and switch automatically between them, and some should have "off" which would ignore any other commands.

That's why I suggest the action property. It's basically just a change in name (and some semantics) for two reasons:

• To make clear what the property is used for (I think 'action' is a more clear wording than 'operation_mode'). While "economy" might be an operation_mode, it should be pretty clear that "economy" is not an action (but rather a preset).
• To have a clear separation between the old set of attributes and the new set of attributes.

I have to agree, that a change would allow for easier refactoring. Also I really like the "preset" idea. That would move people away from hacking operation_modes and fiddling in weird ways with "hold" modes.

This is what in my opinion should have been the options for operation_mode. I would rather fix that instead of adding a new one.

I'm not talking about adding. I'm talking about replacing.

I think Operation expresses better than Action the types here. But that is my personal view and preference of course.

This I have to agree that is confusing, especially as many platform mixed this with operation_mode and created even more confusion. Presets do sound like a better choice.