Add HVACActionReason to Climate entity

[swingerman]

The Goal

Integrations or automation can set the reason for the current HVACAction

Current Situation

Integrations providing a climate entity can set the current HVAC action to inform about the actions the climate performs. This is also reflected in the UI, which gives helpful feedback to the user.
There are some cases when more information is needed.
Users usually control their climate based on various triggers.
Some custom integrations also use more advanced logic, such as ha-dual-smart-thermostat.
These include presence, schedule, opening, overheating protection, and emergencies.
The ability to set this value could help explain, through the UI or automation, why the climate integration is in its current state.

Proposal

Introduce a new climate entity property: HVACActionReason here
This property could be a string type or a defined list we agree on.
String type would be more flexible, while a predefined list would add translation possibilities.
The Generic Thermostat Card should support this on the UI as an optional (hidden by default) feature.

Proposed predefined list:

class HVACActionReason(StrEnum):
  """HVAC Action Reason for climate devices."""

 PRESENCE = "presence"

 SCHEDULE = "schedule"
 
 EMERGENCY = "emergency"

 MALFUNCTION = "malfunction"
  
 MISCONFIGURATION = "misconfiguration"

 OPENING = "opening"

 LIMIT = "limit"
 
 OVERHEAT = "overheat"

[gjohansson-ST]

Typically we don't want to add more attributes to the entities if it can be avoided.
so why should this be part of the ClimateEntity and not just a SensorEntity?

[swingerman]

The proposed property doesn't seem to make any sense in the context of the sensor. Does it?
As HVACAction itself is the property of the Climate entity, my suggestion is entirely related to that.
I missed your point. Simply adding a SensorEntity would make more sense.

[Jc2k]

We are moving away from putting such things in all encompassing entities and instead breaking them out into their own entities that are related to the primary entity by the device registry.

In this case it would be tagged as a diagnostic entity.

It has been said elsewhere that even the climate entities "current temperature" might have been a sensor entity rather than an attribute if designed today.

[swingerman]

I see. Thanks for clarifying. I agree it will make more sense. I just saw what's in the code right now; from that point of view, it belongs there.
However, creating a sensor that provides this information would make sense. I will look into that solution, and if it works, I will close this request.