Remove auxiliary heating from climate entity model

[frenck]

Context

The climate entity model of Home Assistant currently has a property for auxiliary heating.

This is implemented by:

• ecobee (actually toggles a HAVC mode which is odd )
• econet (which enables emergency heat)
• elkm1 (which enables emergency heat)
• ephember (activates a boost, should be a preset?)
• honeywell (sets the "emheat" mode when turned on, sounds like emergency heat)
• mqtt (free for all, you could toggle your lights with it 🤷‍♂️)
• nexia (which enables emergency heat)

This indicates our implementation is actually Emergency heat. A thermostat with auxiliary heat will automatically turn it on, in case it can't produce enough heat or it is in defrost mode. Which should mean it probably should have been read-only?

Auxiliary heating also causes some confusion: What is the difference between emergency heating, auxiliary heating, and boost?

The history of auxiliary heating and why it is part of the climate does not exist. We have no records that indicate motivation or reasoning for it. It was probably modeled after other existing device APIs.

Proposal

To remove auxiliary heating as a property/feature from the climate entity.

Instead, integrations that use it can use a switching entity and add it to the device, or, in case it is a read-only property, be exposed as a binary sensor.

Consequences

The climate entity component will no longer have auxiliary heating.

For this deprecation:

• We remove the auxiliary mode from the UI / more-info.
• We add the "deprecated" keyword to the service description.
• We deprecate the climate.set_aux_heat service call, raise a repair if a user uses it, and write a warning in the logs.
• We create issues in our issue tracker for the seven core integrations that need to be migrated.
• Add a deprecation notice/docs in the related code parts in the code base.
• Remove the relevant parts from the end-user and developer documentation to prevent them from being used/implemented.

After a deprecation period of 6 months, we fully remove the capability from the climate entity.

Other considered alternatives

• Renaming auxiliary heating to emergency heating, as that seems to be its primary use case. However, changing the property will also be breaking; thus, moving it into a separate entity makes more sense in that case.

[frenck]

Just came across: #791, which would become obsolete if this was accepted.

[balloob]

Let's do this 👍

[gjohansson-ST]

Implementation is done in home-assistant/core#112532

[make-all]

Please deprecate it properly. There is no announcement of this deprecation, and the backend documentation for developers and end users still mention it as a normal part of the climate entity API. But in 2023.9 it was removed from the UI, with bug reports about that referring to this discussion as the justification for closing without fixing the issue.

[frenck]

The decision has been made, but not fully applied yet (hence it is still open).

[mkmer]

This is a decent description of the EM heat function.
https://tekclimate.ca/em-heat-what-is-it-and-when-to-use-it/

Looks like it's a way to over ride the 2 stage thermostat configuration to only use the second stage...
Since many thermostats do support EMHeat as mentioned above, removing AUX_HEAT we probably should add in EM_HEAT.

[stadros83]

Hello, could it be because of that that I have an issue with my heater ?

My heater can only be controlled when climate.NAME_thermostat is set with system_mode: "[<SystemMode.Emergency_Heating: 1>]/heat"

If I have this it is NOT working :
system_mode: "[<SystemMode.Auto: 1>]/heat_cool"

zigpy/zha-device-handlers#2921
https://community.home-assistant.io/t/thermos-card-enable-temperature-control-while-in-heat-cool/676973

[brianegge]

Per the linked page, the difference between emergency heat and auxiliary heat "Emergency heat is when you use your “second-stage” by itself without using your “first stage”.

It's important to know if you are using auxiliary heat, in order to save money on heating. If you are using emergency heat, that means the first stage isn't running. Non-communicating thermostats don't know when this occurs, but heat pump systems do.

[frenck]

Right, not fully following what you mean with this comment here. You can still add entities to a device if it needs or wants. This is about removing this specific attribute from the climate entity.

[brianegge]

I agree Aux Heat can be its own entity, but the rational is not that it's the same as emergency heat "This indicates our implementation is actually Emergency heat."

In the ecobee case, the boolean value doesn't map to anything directly in the API (hence the mode change). Turning aux heat on with the ecobee integration could actually turn your heat pump off, which may come as a shock if you are trying to 'boost' the heat in the room. ( https://www.ecobee.com/home/developer/api/documentation/v1/objects/Settings.shtml )

Having the climate entity should have the same behavior across integrations, as that's clearly not possible with they way aux heat is modeled.

[frenck]

Sorry, I am really not following your comments and what they bring to this proposal.

That said, this proposal has been finalized and accepted. Aux heating has been deprecated as an attribute.

[mkmer]

I believe @brianegge is saying some implementations are using "aux heat" as "emergency heat" - where "emergency heat" only turns on the aux heat source and disables the primary heat source (in most cases a heat pump).
My original comment/thoughts were that we should replace "aux heat" with "emergency heat" as it appears ALL two stage thermostats support the "emergency heat" mode.

[WillCodeForCats]

On Temkar thermostats "emergency" heat is actually its own mode selection between heat/cool/auto/emergency and not a toggle or modifier. As it is now I just fake it to the climate entity by returning HVACMode.HEAT when the thermostat is in emergency mode.

https://github.com/WillCodeForCats/tekmar-482/blob/f676a78cdbaa5ddf962b12dc9d67096713bc66c0/custom_components/tekmar_482/climate.py#L217

I don't know that this is the best way to present it, but there is no other way in the HA climate entity to indicate that mode is not actually in "heat".

[mcaminiti]

Ecobee was updated to do the same thing. I have to create a template sensor from the equipment running to know if my heat pump is running stage 1/2 heat and Aux or just stage 1/2 heat without aux. I also then need to look for aux only since the mode is removed and mapped to "heat". Not a fan of the decision to just call heat, heat when it's not all the same but found ways around the sensor side of it.

[spelton]

I know the decision has been made on this but I had a great use case using AUX with Ecobee. Many heat pump installations still have a gas furnace as back-up aka AUX heating. Air-sourced heat pumps' COP (efficiency) decline as outdoor air temperature drops, ours for example becomes very inefficient below -10C. Also we have an electricity TOU plan with very expensive electricity between 4pm-9pm. Our ecobee would force AUX with expensive electricity or cold outdoor temperature. I disabled all the ecobee AUX/emergency heating logic and used my own.

[make-all]

You can still do that, just with a separate switch entity instead of the aux_heat attribute of the climate entity (which has been hidden in the UI since the new climate card was introduced)

[xinde1989]

My honeywell EM Heat switch doesn't work at all. I toggled the switch to turn it on, a few second later it went back to off automatically.

[claudegel]

can anyone point me where to look for how to implement a switch attached to the climate device that have aux heat

[make-all]

The switch and the climate entity just need to register with the same device_info.
https://developers.home-assistant.io/docs/device_registry_index

[claudegel]

@make-all , do you have an example of a component that implement this ?

[make-all]

Sorry, I don't have any recommendation of what is well written and easy to follow, most components that support more than one entity platform will do this, but it isn't always easy to follow, as in my own tuya-local, due to being written generically to support many devices with different combinations of entities rather than a simple implementation for a single device with fixed entities.

[PeteRager]

I think this is a good decision as aux was cumbersome. What Lennox does is provide a separate hvac_mode called "Emergency Heat" which when enabled forces the system to use the furnace instead of the heat pump. Many of my users use this mode to run off the gas furnace when electricity is expensive. Inversely some choose to run off the heat pump when electricity is cheap even if it's too cold outside for the heat pump to be efficient, they do this via some exposed number entities that allow adjustment of the "balance point"

Because heat pumps and furnace combinations are becoming more common, I'd like to gauge interest from this group on adding a new hvac mode. If there is I'm happy to open a new discussion here to work through that decision. As the ideal solve for me would be to remove aux and add in support for the new mode.

here's the way I wrote the integration docs, to adapt for the ability to only partially model it.

Emergency Heat - Lennox systems that have a heat pump and an auxiliary furnace, have an additional HVAC_MODE to run just the auxiliary furnace. In the S30 App this is shown as Emergency Heat. Home Assistant does not allow this mode directly - instead Home Assistant provides support for turning aux_heat on and off - independent of the HVAC_MODE. The integration has the following behavior:

If Emergency Heat Mode is set in the S30, the HA climate will show Heat and the Aux Heat switch will be on.
If the HA Aux Switch is turned on, the S30 Heat Mode will be set to Emergency Heat
If the HA Aux Switch is turned off, the S30 Heat Mode will be set to Heat
If the Lennox Auxiliary Heat is running, the aux attribute in the HA Climate entity will be set to True and the HA Climate Entity will show Heating

https://github.com/PeteRager/lennoxs30

[WillCodeForCats]

Personally I would like to see emergency heat as a HVAC mode. That's how it works Tekmar communicating thermostats.

[88fingerslukee]

I fully agree that Emergency heat should be an HVAC mode for all the reasons you have mentioned above.

[PeteRager]

Let's open a new architectural item around adding emergency heat as an hvac mode.

FWIW, for my custom integration I'm not adding a new switch since the aux switch modeling never really mapped well. I'm adding a new select entity called hvac mode, that contains all the valid hvac modes + emergency heat.

[claudegel]

With the Sinopé devices there are many thermostats that implement aux heat. Low voltage thermostat, floor thermostat, wifi and zigbee.
I'm currently setting an emergency heat for them so I'll have a look to your S30.
Instead of a specific switch for each device that implement em_heat, could it be possible to set a service_turn_on_em_heat and service_turn_off_em_heat. The user can call that service instead of switching each switch for each devices that need to transfer to em_heat ?.
Thank you

[jf-navica]

Why can't aux heat be added to HVAC modes instead of creating separate entities? https://developers.home-assistant.io/docs/core/entity/climate/#hvac-modes
This is something that exists on many thermostat models and is not considered a preset.

[mcaminiti]

I agree that Emergency Heat / Aux heat should be a mode in HVAC. On the ecobee integration it currently maps that mode to "heat". so the only way of knowing which "heat" is running is to see the running status of equipment. I do think some thermostats will need both though.

1. The ability to have the thermostat in mode Emergency Heat / Aux Mode. This is when the stages are only running that emergency heat.
2. The switch to allow another mode on a stage 2 heat pump to have Heat + AUX running at the same time. This is something @spelton is using and I am using today with the aux mode. I control the aux heat based on run time or outside temp to make sure it's not just costing money to run together. This is not a "mode" in ecobee but a switched on service. Seems each integration would have to add this back as needed as a switch to control turning on and off the service if allowed on the device while in another mode.

[iampegram]

I don't understand the change here... Why are we moving the climate entity to a model that includes less information about the state of your HVAC? That would be like taking the current implementation for lights and spinning off separate controls for on/off, dimming, and color for a tuneable LED bulb because not all bulbs support color.

The current state of your HVAC system is not trivial. If the thermostat is capable of engaging each heat source independently or concurrently, the climate entity should have a framework in place to allow implementers to control that aspect and display the current status. Control is in the mode list. Display could be as simple as a heat icon with a 1, 2, and 1+2 to indicate (respectively) that the primary heat is engaged, secondary heat is engaged, and both primary and secondary heat is engaged.

It would then be up to the integration implementers to properly make use of the climate entity.

primary heat	secondary heat	dual heat

[mkmer]

@iampegram I think the problem is more around AUX_HEAT vs EMERGENCY_HEAT - many integrations were using AUX_HEAT as EMERGENCY_HEAT. I thought we should ADD EMERGENCY_HEAT but it was already decided by the time I found out.
There is also multi stage, which is more like what you are describing, where stage 1 is a heat pump and stage 2 is gas or electric, or with newer high efficiency gas it's 2 or 3 stages of gas burners/ AC speed (doesn't really matter what it's controlling). In general, users don't need or want to control the stages, but in the event of a failure you want to over ride the first stage in the case of a heat pump.

[jf-navica]

I think AUX_HEAT and EMERGENCY_HEAT are the same thing: a second stage that comes on automatically or not when the primary source is unavailable or unwanted. It depends on the thermostat model. Daikin has an emergency mode but describes it as "only use auxiliary heating elements"

[WillCodeForCats]

The Tekmar 557 that I use has 5 operating modes: Heat, Cool, Auto, Emer, and Off. Home Assistant only covers 4 of the 5 possible modes. Auto mode includes all of heat, cool, and emergency.

For Tekmar "EMER" (Emergency) mode is "for heat pump installations whereby the heat pump is forced off and the backup heat is manually turned on".

[frenck]

Alright, locking down this architectural discussion.
The aux has been deprecated and will be removed from the climate entities. Devices that support such functionality (or similar or similarly named functionality) can re-add support using a normal switch entity (which can be tailored to the specific device).

../Frenck