Add new CURRENT_HVAC constants

[ribbal]

Context

I am working on the Heatmiser climate integration. The Heatmiser devices can be put into a 'standby' mode, and they automatically active a 'preheat' mode to bring the home up to temperature for a scheduled daily time (e.g. the thermostat maybe scheduled to come on at 4pm, but the heating comes on prior to this time to ensure that the home is up to temperate by 4pm - this is the 'preheat' mode)

Proposal

Add the following constants to homeassistant/components/climate/const.py

CURRENT_HVAC_STANDBY = "standby"
CURRENT_HVAC_PREHEAT = "preheat"

Consequences

It would be better to use the above common constants in the Heatmiser integration, rather than creating bespoke Heatmiser values. I've already created a PR: home-assistant/core#64194 (Sorry, didn't realise this needed architectural approval beforehand).

[frenck]

I think we don't need CURRENT_HVAC_STANDBY, as this can be represented by the existing CURRENT_HVAC_OFF already.

CURRENT_HVAC_PREHEAT is kinda interesting maybe; although, in general, this is comparable to CURRENT_HVAC_HEAT in most cases for most heaters. Do we need this distinction even? If, so, why? Which other integrations make a difference between heating and preheating that could benefit from such a distinction?

[ribbal]

Agree with your comments about CURRENT_HVAC_STANDBY.

I've just done a quick search and both Hive and Nest thermostats support a preheat mode (though they use different terminology). I think it would be useful to draw a distinction between standard heating mode (CURRENT_HVAC_HEAT) and the preheat mode.

[Jc2k]

I think the threshold is historically around 5 integrations and a compelling use case.

Is there any practical difference between heating and preheating?

[ribbal]

Practically, the preheat mode simply turns on the heating (but, the timing is dependent on the current room temperature and the target temperature). It would be useful to know whether the heating has come in standard mode or whether it's on because of the preheat mode. My use case is that I have notifications informing me of when the heating goes on/off. Currently, I do not get a notification when the preheat mode has been activated; further, I would like to know if the heating has come on because of the preheat.

Also, I believe this would be useful in automations and for logging of historical heat on/off/preheat changes and the temperatures.

[Adminiuga]

I see little distinction between heat and pre-heat. Pre-heat just means that the duty cycle of heat and idle is high, cause "you are heating the room" vs when it temp is on target setpoint, when duty cycle of heat is low, just to compensate for the heat loss. But in both cases handlers do exactly the same: they produce heat.

If pre-heat us added, then pre-cool (pre-chill ?) Should be added too, cause thing happens for cooling.

[frenck]

Well, behold, I've just run into 2 cases that could benefit from pre-heating:

• Toon
• Plugwise

I've been working a bit on the latter lately, and now run into a case that would help there (especially in multi-zone cases in case of Plugwise).

OpenTherm Gateway is another one that could possibly use this, as preheating is part of OpenTherm specifications (which is why Toon and Plugwise have those in the first place).

So that makes:

• Heatmiser
• Toon
• Plugwise
• OpenTherm Gateway

That could use such an action state.

As for the suggested pre-cooling/pre-chill above, I think that would be a compressor state in such case? Although, I think we should leave that out of this architectural change/discussion and learn if that is needed based on demand. Lastly, for the suggested standby, that can be mapped as idle, which we already have.

My counter-proposal for this proposal is:

• Add HVAC_ACTION_PREHEAT
• Adjust frontend to be able to translate that state
• Adjust frontend show a light yellow ring on the thermostat dial when preheating (compared to orange when heating)

[frenck]

It has been a while, but I've discussed this change (as we have changes to the UI for climate pending, which made me go through a couple of Architectural discussions), with Paulus, Erik, and Martin.

Time has passed a bit, so things changes a bit in Core. The final and approved proposal for this would be:

• Add preheating to the HVACAction enum (thus creating HVACAction.PREHEATING)
• Add translations to climate strings.json

../Frenck

[frenck]

home-assistant/core#94677

[frenck]

Closing the dicussion, as the change has been merged.