Architectural review of climate entity about architecture

[marvin-w]

I'd like to suggest extending the available operation modes to be able to support the most frequently used KNX operation modes.

For those who don't know KNX and the association behind it: It's an association with the goal to deliver smart home and building solutions with more than 70.000 partners (!= not the people using it) in 190 countries. Currently there are about 7000 products from different vendors who support KNX.
Sources

With that being said the KNX Standard(section 4.9) has a lot of different HVAC control data points which makes it very hard for us to implement it accordingly. Not only do we currently have to map for instance Comfort to Heat but also we can't just map them back to the specific KNX operation mode as Heat is also a valid HVACControlMode.

From my previous knowledge and whilst working on XKNX I can say that the most frequently used are as follows:

Comfort (this is used more frequently than Heat)
Heat (already there)
Cool (already there)
Night
Economy (we have that already - 'eco')
Standby (this is mapped to 'idle')
Frost Protection (or Building Protection)

Which means that my suggestion is to implement the following new operation modes:

Comfort
Night
Economy (well, just leave eco)
Frost Protection

As of implementing (if it would be accepted) we could partially use home-assistant/frontend#2381 (without the stupid hacks) to add support in the frontend and I'd also take care of the necessary backend implementation.

IMHO accepting this would make a lot of people very happy (including myself).

[fanthos]

I think the state should be current running state, like heat, cool, idle and off. Off means the component is turned off. There also should heave operation_mode, it shows current mode, auto, off, heat, cool.

[andrey-git]

A comment on on/off as I added that:
off is not the same as idle. On/Off is a setting while idle is an observation. A device can switch on its own from idle to another state.
While we could merge idle into off I think we would lose important information.

That said, maybe operation_mode should be an attribute and not a state?

[fanthos]

I think the off state means manually turned off and should not turn on by temperature or other reason. idle means the component is in "working" state and it will turn into heat or cool when temperature goes cool or warm.

[TinusK]

KNX is 'the' most used and standardized automation system in the world and is being used in millions of Homes and Offices.

From my perspective, the current 'climate' function in HA is derived from a single device that heats, cools, dry, etc (air-conditioner for example). But a building is not heated, cooled or off. It is set to a mode that corresponds to a certain temperature. The system then controls the devices in such way that the selected temperature is being reached. This can be a combination of heating, cooling, or simply off. Hence the usage of modes and not states.

Come to think of it, maybe, besides a climate entity, there should be an thermostat entity?

From a HMI perspective it makes more sence to set a mode (e.g., comfort, night, frost protection, asf.). Setting a device to a state, e.g., cool or heat, will be interpreted as if the device will constantly heat or cool until manually switched off.

[dgomes]

Fully support the idea of splitting thermostat from climate. They are two different things, climate should address the boiler/heater/fan/AC and thermostat should stick to the remote control. Here is the deal: Many of us have several thermostats controlling a single "climate source" (my case a Heat Pump)

And here is the thing: Google/Alexa should control thermostats and stay away of the source which usually has its very own control mechanisms.

[dgomes]

This thread has become very long, but I believe we are getting somewhere :)

Could we possibly reach an agreement on splitting climate into thermostat and HVAC ? (vote 👍 and 👎 )

@balloob could you enable wiki functionality in this repo in order to draft a joint spec for both components ?

[pvizeli]

We need a abstraction how a thermostat should look like on HomeAssistant.

I think the state should be the current temperature. All others are attributes. Like before the refactory of this components.

[balloob]

@trisk about the overlapping part: we should make it a separate component or else we end up with a lot of if…else things. The same reason light and switch are different components.

[Adminiuga]

These are more fundamental issues I think should be addressed before go further, consider: HVAC vs thermostats

Agreed and IMO climate component in HA represents a thermostat in current incarnation and not a HVAC unit

HVAC (common, I think, in the US) has multiple 'dimensions' (temp, humidity, airflow speed/volume), thermostats (UK/Europe) have only one (temp).

I think you are conflating HVAC & Thermostats again here. A HVAC unit (HEAT Pump, heating furnace, air conditioner, electric baseaboard, combination of the above etc) is source of Heat/Cold and may include FAN if it is a forced air unit. Per se HVAC unit doesn't care about temperature setpoint. It operates based on "demand": you demand "cooling" -- HVAC will operate air conditioner. You demand "heat" it will provide heat by turning on furnace or switching heat pump to make it cooler outside and warmer inside. These demands are coming from:

• Thermostat(s)
• Zone controller
  In other words HVAC unit will provide heating/cooling as long as the respective "demand signal" is on.

There is a difference between (say) six independent thermostats, and a bunch of six thermostats controlled by a central hub

I don't know about "smart systems" but in regular HVAC, thermostats are connected to the zone controller and zone controller operates the HVAC unit and opens/closes the required zones. You can say thermostat controls the zone controller/HVAC, but not the zone controller controlling the thermostat.

I think as was mentioned in #22 (comment) splitting climate into proper HVAC & Thermostat would make things much clearer.
From that perspective I actually like how Nest climate platform is implemented in HA, makes logical sense.

[Adminiuga]

@dgomes is #22 (comment) for thermostat or HVAC unit?
BTW Zigbee Cluster Library is using the same approach of splitting Thermostat/HVAC Units, check chapter 6

@OnFreund

In this case I don't see the advantage of the split, for two reasons:

1. In all systems I've seen (granted, limited experience), most of these are controlled through the thermostat, not the source. The source is usually just on/off, and sometimes a systemwide heat vs. cool

Yes, they are controlled through thermostat and we should keep it that way, but for my automations I need to know the HVAC state, whether it is On or Off. In other words whether the thermostat is demaning heating/cooling and how big the demand is. For example Thermostat is set to HEAT, meaning it is on. However if the ambient temperature is within the temperature setpoint, then it means there's no demand for heating/cooling and therefore HVAC state is Off. the further away the ambient temperature is from the setpoint temp, the more demand for heating/cooling there is -> HVAC state On, HVAC mode heating/cooling.
As I said, I like the Nest platform implementation, while it is true all of these could be implemented via accompanying sensors/binary_sensors to represent HVAC unit state, it would be nice to have it implemented as its own component.

[tinloaf]

Some obervations, some of which come from the stale home-assistant/home-assistant.io#3910 :

• Regarding on/off: Yes, idle is an observation, @andrey-git . I think that every property of a climate device should have a current_* and a requested_* version. Thus, if the requested_operation_mode is e.g., auto, the current_operation_mode can still be idle to indicate that the device is currently not doing anything. Obviously, when the requested_operation_mode is set to off, the current_operation_mode should also go to off, or the device is doing something wrong. This way, we can get rid of the separate on/off property, I think.

• I'm all in favor of throwing out econet. Maybe it should become its own component that offers some switches or something?

• I still think we need to split up the values we allow for operation_mode, something like the suggested action (which has a very limited range of allowed values, e.g., off, auto, heat and cool). Maybe we would then need to add the same thing for humidity (humidity_action? With values off, auto, humidify and dry?) Everything else should go somewhere else. A value of electric or fan_only just isn't the same type of choice as auto vs. heat.

[andrey-git]

@balloob that would be enough for automation, but would be less usefull for visualization.

Hvac_mode could also be fan or dry.

[KlaasH]

This is an attempt to summarize the target implementation of mode/state/profile, since there has been a bit of discussion which I think has evolved and clarified things since the initial comment. But it's an opinionated summary, including some opinions I don't think have been expressed above.

Operation mode

Defines what action(s) the thermostat is instructed to take. Where verbs make sense, use imperative.

Values: heat, cool, auto, off, auxHeatOnly, dry, humidify

State

What the thermostat is currently instructing the controlled system(s) to do, i.e. the action of the system based on the mode and target temperature (/humidity). Use progressive verbs to avoid confusion/conflation.

Values: heating, cooling, idle, drying, humidifying

Profile

This concept is less clear and much more device specific. Maybe it defines what approach should be taken in carrying out the action (i.e. eco, normal, comfort, boost)? Or what motivates the current targets (home, away, bed, override)? This might not be clear enough, but then again it might be OK for this to be a more nebulous category for anything the thermostat uses to describe its operation that doesn't clearly fit into "operation mode" or "state" as defined above.

Notes, guidelines, questions:

• Avoid using the same word more than once, i.e. all modes, states, and profile names should be unique, even if the most obvious names would overlap. Confusion will continue to arise, so we should do everything we can to keep the target concepts clear.

• you're right that HVAC state can be derived from comparing current and target temp (#22 (comment))

  Putting this here just for reference, in case people see the argument but not the counter-arguments here and here, which I think are persuasive.

• I don't like the "FAN" HVAC mode because we already have a "fan mode" property. In case a unit is set to fan, I expect fan mode to be set to "on" and hvac_mode set to off. (#22 (comment))

  This seems sensible to me.

• It is currently out of scope for our climate entity to also represent a multizone setup with temporary overrides. We first need to fix it up to a place where it will support the majority of the thermostat models out there.

  Hear, hear! I would also argue that devices that control climate but are so different from a typical HVAC thermostat that they can't be properly implemented on this model should be handled separately rather than allowed to stretch the bounds of what the climate component needs to handle.

[MartinHjelmare]

The top post isn't updated. Please read the summary I linked above.

State

What the thermostat is currently instructing the controlled system(s) to do, i.e. the action of the system based on the mode and target temperature (/humidity). Use progressive verbs to avoid confusion/conflation.

Values: heating, cooling, idle, drying, humidifying

[zxdavb]

I'm taking a look at the Tado component to make it work with all the available features. One thing that is totally handled differently than, I assume, most other thermostats is...

Actually evohome is the exact same! The system has a controller that handles Away, Eco, etc., and the heatings zones (i.e. TRVs) are in one of three modes:

• FollowSchedule - same as your smart schedule?
• PermanentOverride - the TRV does it's own thing, until the user intervenes
• TemporaryOverride - the TRV does its own thing, until some datetime (TIMER, or until next setpoint)

You could look at climate\evohome.py to see how I've had to do it:

# the Zones' opmode; their state is usually 'inherited' from the TCS
EVO_FOLLOW = 'FollowSchedule'
EVO_TEMPOVER = 'TemporaryOverride'
EVO_PERMOVER = 'PermanentOverride'

# for the Zones...
ZONE_STATE_TO_HA = {
    EVO_FOLLOW: STATE_AUTO,
    EVO_TEMPOVER: STATE_MANUAL,
    EVO_PERMOVER: STATE_MANUAL
}
HA_STATE_TO_ZONE = {
    STATE_AUTO: EVO_FOLLOW,
    STATE_MANUAL: EVO_PERMOVER
}
ZONE_OP_LIST = list(HA_STATE_TO_ZONE)

[zxdavb]

These are more fundamental issues I think should be addressed before go further, consider: HVAC vs thermostats

HVAC (common, I think, in the US) has multiple 'dimensions' (temp, humidity, airflow speed/volume), thermostats (UK/Europe) have only one (temp).

HVAC systems usually monolithic (whole house, but maybe 1-3 zones), thermostat systems can often be a two-tier system with a hub/controller and multiple thermostats (I think not uncommon for say 12 such zones).

1. Should thermostats be a separate types of entity from HVAC controllers I say yes, just the same as, say, the fan entity is already separate (see below, re: fan, humidifier, thermostat, etc.)?

2. How should an entity handle multiple features/dimensions (e.g. heat/cool vs humidify/dry vs fan speed vs air source - fresh or recirc.). For each dimension, we have a current value (or not), a target_low and/or a target_high (and so on). The system may work to stay only above a low, below a high, or between the two.

Having an entity with multiple dimensions introduces complexity - is there a way to implement entities with single dimensions, and just 'plug' them together somehow? Would a HVAC just be a thermostat, humidifier and a fan plugged together?

3. How are multi-zone systems to be accommodated - There are many systems where the performance profile (say away mode) comes from a hub/controller, and the zone 'inherits' this, unless there is a local override.

There is a difference between (say) six independent thermostats, and a bunch of six thermostats controlled by a central hub (thus HA 'requires' my evohome hub to have a current temperature, when only the zones need one - I used teh average of all zones).

[elupus]

All nibe heatpumps are linked up to a REST api called nibeuplink. For example a Nibe 1155 ground heat pump: https://www.nibe.eu/assets/documents/18905/M11975-1.pdf.

I have a custom component for this at: https://github.com/elupus/hass_nibe. For now it exposes all internal data (50 or so items) as sensors. With climate entities for the case of controlled climate systems. You can see some screenshots here: https://community.home-assistant.io/t/nibe-uplink-api-component/18173

It can work in termostat mode with indoor temperature sensor, but also just standalone with external temp sensor and heat curve. It can also support smart termostats (ie external temperature sensors +setting) to control the heating requirement on the pump.

[elupus]

@swamp-lg does that really matter? If the entitity called termostat controls settings for a zone. Does it really matter if that is actuated by the heater? The hvac entitity would handle global things. The termostat entities zone local things.

[cdce8p]

I don't know if a idle current state is necessary. It's the same as currently off. Otherwise thats the way HomeKit handles it as well @fanthos.

[cdce8p]

Isn't that covered by operation_mode=Auto? Or should that just be a list of supported modes?

[trisk]

Regarding feature flags, the Alexa.ThermostatController design allows thermostats to report whether they support single, dual and triple setpoints (target temperatures).
There's an extended series of examples here:
https://developer.amazon.com/docs/device-apis/alexa-thermostatcontroller.html#thermostat-setpoints
Note that these may be the same thermostat device but in different operational modes.

There may certainly be thermostat devices out there that only support an upper and lower setpoint in certain modes (though it is unspecified in the Alexa documentation which setpoint a AdjustTargetTemperature request would apply to). Our climate entity has assumptions that there is always a target temperature value separate from the higher/lower ones, so it does not provide an accurate representation of these devices.

[trisk]

I think the off state means manually turned off and should not turn on by temperature or other reason. idle means the component is in "working" state and it will turn into heat or cool when temperature goes cool or warm.

You seem to be describing climate.STATE_AUTO, which is the state where the device will automatically maintain temperatures between the high and low target temperatures. climate.STATE_IDLE means the device is not operating, but will accept operation mode or target temperature changes.

I agree that there should be an "off" state for when the device is not allowed to be turned on/operated through software.

[trisk]

Regarding operation modes:
Looking at implementations of "eco" mode such as Nest and Honeywell it appears to behave similarly to "away" mode in that it changes the target temperature range, without replacing the current setpoints. There may be limitations on the target temperatures allowed, such as in the case of Nest.
While this may be considered a variant of "auto, "heat", or "cool" mode the way "away" mode is, given the independent setpoint(s) it may be necessary to express this as its own mode.

I believe "high demand" mode only applies to water heaters. "performance" mode seems to also be for water heaters, though climate.toon is abusing climate.STATE_PERFORMANCE to mean "auto" mode right now.

[trisk]

There are a lot of commonalities between thermostats and water heaters (or other temperature control devies) that make it attractive to use a single entity type (and in some cases such as climate.zwave, platform) to support them. Perhaps it is sufficient to have operation modes that are distinct for e.g. thermostat devices, and use a feature flag to specify the type of device?

[balloob]

@tinloaf aaah there the issue is! I was looking for. I remember us talking about it but couldn't find it.

I think that idle is not a correct operation mode. There is a difference between "current operation" and "current operation mode". Ours is the latter. Being in an operation mode doesn't mean that you are currently doing something. For example, a climate component in heat mode with a target temperature of 21 and a current temperature of 23, will not be doing something, yet it's mode remains "HEAT".

I would expect "off" to be a correct operation mode as it means that we will not do anything regardless of target and current temperature.

[Landrash]

Adding some from my thermostats that gets registered as climate entities.
Off and Idle are two different things.

• Idle with mine equals to it waiting and adjusting temperature when necessary.
• Off equals to it doing no actions.

Those two should most likely not be merged since it could vary with each device.

[trisk]

• Idle with mine equals to it waiting and adjusting temperature when necessary.
• Off equals to it doing no actions.

What thermostat model is this? Most thermostats only adjust temperatures when in the operating modes "heat", "cool", or "auto". Both terms "idle" and "off" are usually reserved for modes where the thermostat will not attempt to adjust temperatures, though there may be a separate mode for when the device must be turned back on manually.

[trisk]

This is where the current state and operational mode differ: some devices report a state to indicate whether a heating or cooling cycle is actually running at a moment in time and this should not be confused with the (user selected) operational mode, which determines which setpoints the device will try to adjust temperatures between.

[balloob]

Trisk is right and our current naming is confusing, we actually want to represent "HVAC operation mode" but named it "current operation", which is confused with the current state. Oops.

So to make it clear, let's add hvac to the name and rename them. I suggest:

• Introduce a new property hvac_mode. Limited to off, cool, heat, auto, auxHeatOnly (for ecobee). Operation mode values are defined via constants starting with names HVAC_MODE_.
• Propertyoperation_list will be renamed to hvac_modes. It will list all available HVAC operation modes for this device.
• current_operation property will be renamed to hvac_state and will be limited to off, cool, heat. Current operation values are defined in constants starting with names HVAC_STATE_.
• state will return hvac_state

Some popular climate APIs that I checked that all use "off" for hvac mode:

• ecobee
• Nest: hvac_mode and hvac_state
• Honeywell

[fanthos]

I suggest that HVAC_STATE have both idle and off. idle for turned on but idling, off for HVAC_MODE is off.

[balloob]

By adding idle as a state we are again conflating mode and state. Look at mode to see if a device is off, look at the state if a device is cooling/heating a room.

[andrey-git]

@balloob, is there a way in your proposal to distinguish between HVAC set to heat and actually heating and one set to heat and doing nothing because the room is hit enough?

[pvizeli]

@balloob most of thermostat device can only heat and other can cool. That make the state in 70% to a constant and we store no constant into statemachine?

100% of a thermostat is the temperature in the focus of device. All other will be construct around this value. I vote for a temperature state and other will be construct around this as attribute.

EDIT

Hmm, there are other device they use also humidity and they make the temperature as state a bit wired. Difficult, but the state like you describe will be also bit mess.

[balloob]

@andrey-git set hvac_mode to heat and hvac_state is either heat or off

@pvizeli you're right that HVAC state can be derived from comparing current and target temp. We can't have the decice state be a temperature because target temperature can be a range when device is set to hvac mode "auto".

I guess HVAC mode is not that important as it indeed can be derived from target and current temperature.

We should change state to be just HVAC mode. Because HVAC state can be confusing. You'll see off but the actually heating but is not currently heating.

[balloob]

The frontend can calculate itself what the current state would be? We should aim for single source of truth and if data can be derived from other pieces of data, we should not include it.

After reading this article on what "dry mode" is, I agree that we should include dry. (tl;dr: it dehumidifies the air)

I don't like the "FAN" HVAC mode because we already have a "fan mode" property. In case a unit is set to fan, I expect fan mode to be set to "on" and hvac_mode set to off.

[hthiery]

As maintainer of the fritzbox thermostate implemenation I can tell that there is no way to get the actual state of the thermostate. The thermostate is a device directly mounted to valve at the radiator and controls the state of the valve always automatically. Its only setteble parameter is the desired target temperature. The other parameters like eco or comfort temperatures are only values that come from the schedule form inside the fritzbox webfrontend to plan the target temperature change. The state of the valve (open, close or something in between) cannot be read.

Additionally an away mode (for holidays) can be set and also a mode where the valve is forced to close (for sommer).

So my suggestion for these kind of devices is to have an automatic mode, away mode and maybe something . But I dont't know how to handle the state.

[balloob]

We already support away mode and you don't have to implement the set_operation_mode service either. Eco and comfort are profiles, and are not related to hvac modes.

[trisk]

Given the fact that some devices cannot report if e.g. heating or cooling equipment is currently running, if we keep the operational mode as an attribute, what should the the entity's actual state be? A placeholder state like STATE_UNKNOWN or STATE_ON that never changes?

@balloob When a device is in "eco" mode it will use different (not exposed directly) setpoints than when it is in "auto" mode. How should this be expressed to the user?

[cgarwood]

"The frontend can calculate itself what the current state would be?"

Not necessarily. I know with my Nest atleast the heat is set to not kick on until it drops 2 degrees below the setpoint. If we're just comparing mode against current and target temps, HA will be saying the unit is running a lot more than it actually is. Most of the smart thermostats report back their current state in the APIs, I think that's the best source of truth for what the state of the device is, as opposed to trying to calculate if it's actually running or not based on other factors.

I think "heating" "cooling" "idle" "off" etc would be the best states for the actual climate entity.

[trisk]

"The frontend can calculate itself what the current state would be?"

Not necessarily. I know with my Nest atleast the heat is set to not kick on until it drops 2 degrees below the setpoint. If we're just comparing mode against current and target temps, HA will be saying the unit is running a lot more than it actually is.

Agreed, we don't always have access to all of the parameters for the state machine used by the device internally, which in modern devices may be more complex than "start heat/cool when above/below X with a hysteresis of Y". This is almost certainly not something that can be simulated by a generic frontend. We could suggest that platforms which don't report the current state to simulate it if the logic is known and the necessary parameters are exposed by the device (and fixed between firmware updates) but this is not applicable to all platforms.

I think "heating" "cooling" "idle" "off" etc would be the best states for the actual climate entity.

Is there value in including "off" as a different state from "idle"?

[cgarwood]

Is there value in including "off" as a different state from "idle"?

Good point, probably not. My initial thought was using "off" if the thermostat was set to off, and idle if it was set to heat/cool but not actually running. But you could figure out the difference there based on what mode the thermostat is set to, so there's not really value in separate off and idle states

[balloob]

@trisk: When a device is in "eco" mode it will use different (not exposed directly) setpoints than when it is in "auto" mode. How should this be expressed to the user?

So Eco is just AUTO with different setpoints. The setpoints would be target_temp_high and target_temp_low?

[balloob]

We can include an hvac_state attribute but as it stands right now in the frontend, we won't show it because state will become equal to hvac_mode. If it it's not available for a device (because we can't know), we'll just return None.

[trisk]

So Eco is just AUTO with different setpoints. The setpoints would be target_temp_high and target_temp_low?

"eco" mode overrides the original setpoints with temporary values (like away mode) and restores the original setpoints once the device leaves "eco" mode. The "eco" mode setpoints usually require different API calls and in some cases do not allow arbitrary changes (just a range, or read-only).

Not sure if the regular target_temp_* attributes should reflect eco mode or if they should be in a separate attribute. Regardless there needs to be some way to indicate and enter/leave eco mode.

[balloob]

So a profile attribute right? Profile is "normal" or "eco". target_temp_* should represent the current used setpoints. If a current set point is not used because a different profile is selected, it should not be part of the current state.

[zxdavb]

IMHO, there is a hierarchy of modes/states. The zone thermostat may be in Auto, but it would be 'overruled' by the hub, which is dictating (say) Away or Eco mode... Unless the zone itself detects an open window, and sets the target temp to 5C until the window is closed...

Many of the newer heating systems have a relatively complex hierarchy regarding Operating Mode, maybe like:

• Openwindow mode --> Zone local setpoint --> Hub/Controller mode --> Scheduled setpoints

We have to be careful about derived values - for example, setting a heating object to IDLE just because its target temp is lower than its current temp is folly. For example, the zone calls for heat, even though its current temp is higher than its target temp because it knows that in 30 mins it needs to be (say) 5C higher than it is now.

TL;DR - HA cannot expect to encompass all climate objects, and so some flexibility is required. For example:

• climate objects that have no temperature (e.g. operating modes only, for example the evohome controller)
• climate objects may not have either an On/Off or Idle/Active state, for example evohome zones are always on; in essence, they only have a current temp and a target temp
• there should be a distinction between evoking an operation and any resulting state (e.g. two distinct operations leading to the same state - this is subtly different to the REQUESTED_* and CURRENT_* mentioned above)
• it would be useful to log operations made (described as a setting, above), as well as the operating state (described as an observation, above)

========================

I am in the throws of re-writing the EU (US is different) Honeywell evohome component, as a custom component because the existing (honeywell) component is no longer up to the task. I have some observations that are directly relevant to the above, and some additional issues. It may be useful to describe how the evohome system works...

An evohome account has multiple locations, each with multiple gateways, each with multiple controllers, each with up to 12 zones. The vast majority of installations would consist of one account/location/gateway with one zone (and the existing code assumes this).

However it is sufficient, I think, to assume a 1 to many relationship by merging account/location/gateway/controller into one, to get a controller:zones(s) setup in 1:many (I know others have asked for multiple locations, but the underlying API actively does not currently support this). The zones (each is a collection of actuators and one thermostat) act as you'd expect but have 3 modes (this is not strictly true):

• FollowSchedule: follow the scheduled setpoints/target temperatures
• TemporaryOverride: have some fixed temperature for some time (e.g. until the next setpoint)
• PermanentOverride: have some fixed temperature indefinitely

Note that zones do not have an On, Off, or Away state; they are always on (and it is not possible to know if they are active, or idle). For an Away mode, the target temp may be set to (say) 10C, and for Off, it would (usually) be 5C.

The controller has no temperature, and no target temperature. It does have the following modes (in addition to 'Auto' - follow the programmed schedule) that override the target temperature of any zone in 'FollowSchedule' mode

• AutoWithEco: all target temps dropped by (say) 3C,
• DayOff: pretend today is (say) Saturday,
• Away: all target temps to (say) 10C,
• HeatingOff: all target temps to (say) 5C,
• Custom: impose a different schedule on some zones

Note again, there is no Off state - the system is always on, but it may (for an Off mode) configure the setpoint of all the zones to 5C. There is also a situation where two Operating modes (Auto, AutoWithReset) lead to the same State (Auto). An in other cases, it can revert back to Auto after a period of time.

Sorry if I have rambled on.

[zxdavb]

So a profile attribute right? Profile is "normal" or "eco". target_temp_* should represent the current used setpoints. If a current set point is not used because a different profile is selected, it should not be part of the current state.

I agree (but there would be a hierarchy of these profiles). The way I think about it is that the schedule consists of a whole bunch of setpoints (from a particular time the target temp is...), unless overridden by a mode (you say profile), or some other state.

The hierarchy of operating modes (and other event-driven modes) is resolved against the schedule to produce a current target temp. Thus, the target_temp and current_temp are states of the zone. If I want to know the scheduled setpoint, then (for evohome), the only way to know is to interrogate the schedule.

Only if the Controller is in Auto mode and the Zone is in FollowSchedule mode, would the target temp then be the setpoint, unless (for example) the zone is in 'OpenWindow' state (there are other such states).

So Eco is just AUTO with different setpoints. The setpoints would be target_temp_high and target_temp_low?

With evohome, if the Controller is in AutoWithEco mode, the the zones that are in FollowSchedule mode follow their scheduled setpoints, only 3C lower; they only have a target_temp.

[balloob]

The state of a climate component should always show the actual state. So if we're in eco mode and because of that the target setpoint changes, we should show the eco target as our target temperature, as that's what is the current state. What is overriden is not important.

We will include both operation mode and operation state as attributes and will make the state be equal to the operation mode.

It is currently out of scope for our climate entity to also represent a multizone setup with temporary overrides. We first need to fix it up to a place where it will support the majority of the thermostat models out there.

[zxdavb]

Actually, it would be enough to decouple operation mode (as requested) from operating state (as it eventuates for whatever reason) - the controller can be instantiated with different supported_features to its zones.

How do you feel about a climate object without a temperature?

[maufl]

Just for your information, here's the way MAX! thermostats work (and also the eq3 bluetooth smart, basically the same device with different RF).

The are mounted directly on the radiator. You can program a weekly schedule. Then you can switch between three operation modes, manual, auto and boost. (There is also temporary, but I don't remember what it does).

In manual mode, the thermostat tries to keep the currently set temperature. In auto mode, it follows the weekly schedule. In boost mode it fully opens the valve for a configurable amount of time and then goes back into the previous mode.

Modes like heat, cool or idle don't make much sense for these devices. The auto mode is probably not very interesting in the context of homeassistant, as most users would probably use automations and not the schedule in the thermostat. Manual is the preferred mode, because the thermostat will then not change the target temperature it self. However, boost mode is also interesting as it can be used to quickly heat up a room.

[worm-ee]

For HomematicIP_cloud the same as for MAX! thermostats holds. A STATE_BOOST and several STATE_AUTO1...5? for different time/temperature profile would be great.

[balloob]

Profiles are not hvac states, they are profiles.

[worm-ee]

Hi @balloob, but you have also to admit a time/temperature profile is a kind of automatic state for devices like a radiator thermostat. I just have implemented the climatic platform for homematicip_cloud and I had in mind to implement the profiles as different automatic modes. This has been refused and I also fully support this if you wanna keep things consistent.
home-assistant/core#14388

[maufl]

What's the status on this? This seems to block some climate platform implementations.

[balloob]

Somebody needs to implement it.

[maufl]

Is there even a consensus on how to implement it yet? Implementing the changes would probably also require rewriting all existing platforms right?

[balloob]

Correct. It will cause some breaking changes

[pilehave]

Obviusly this needs to be sorted out, before adding anymore fancy bells and whistles, like new gauges and a new UI. Important stuff first, please ;-)

[balloob]

Thanks for summarizing it @KlaasH. It looks like you included humidify for operation and operating mode, but we should remove that. It's the same as dry (as per this comment).

[KlaasH]

I included it based on this comment and because it seems reasonable that there'd be a corollary to dry for increasing humidity. But I don't know if there are actually systems that have an operation mode specific to targeting higher humidity (in my head it's possible, maybe in the desert?), and if it's not a real thing then it definitely shouldn't be taking up space in the component. I edited the comment to strike them out.

[KlaasH]

Actually, looking at the comment that suggests "humidify" again, it seems like it's saying humidity control should be a whole independent mode, so that things like "heat/humidify", "cool/dry", and "cool/humidify" would be possible.

That seems like it would be more complex than is necessary. Having "operation_mode: dry" mean "ignore temperature, target humidity" would be simpler and seems like it would cover the air conditioning case well. I don't know if it fully covers the case of heating systems with built-in humidifiers, but I'm not familiar with how thermostats actually model that type of system.

[zxdavb]

TL;DR - should HVAC and heating be separate component classes? I suspect so.

I suspect that people, like me, have experience with only one or the other, and this is contributing to the difficulties discussing/resolving the architectural challenges with the climate class.

I don't have a lot of experience with HVAC (I do own one MVHR unit), but I am familiar with quite a few systems used in the UK for heating - they have smart TRVs to control the flow of circulating HW through radiators, and fall into 3 'designs':

distributed: 'Smart' TRVs that work in isolation from each other - they have internal 'room' thermostats (e.g. bluetooth eQ-3) - in this case, there is a separate/distinct on/off 'house' thermostat that will ask the boiler to provide circulating HW for the radiators - this is common because it has the lowest barriers to entry

centralised: A smart 'house' thermostat (hub) that devices whether the boiler will provide circulating HW or not - the TRVs are 'dumb' (e.g. Hive, or Nest) - also common

mixed: A smart hub, with smart child TRVs. The key in the mixed model is that the TRV can 'call for heat' (where it asks the hub to instruct the boiler - in some efficient way - to provide circulating HW), and we configure when the TRV does that, and when the hub responds to that (e.g. tado, evohome) - this is where things are moving...

HVAC systems, will probably always be centralized/usually single zone, whereas heating will inevitably be mixed/multi-zone (to start, all you have to do is replace a manual TRV on a radiator with a smart TRV).

Yes, I know there is no appetite for multi-zone setups, but I actually have a suspicion that HVAC & heating might well be best implemented as separate component classes.

[zxdavb]

... seems like it's saying humidity control should be a whole independent mode, so that things like "heat/humidify", "cool/dry", and "cool/humidify" would be possible.

I completely agree they should be different. I have a MVHR unit that is only concerned with controlling humidity. I have CH that is concerned only with temperature. I know of other that have a unit that does both, but independently controllable.

Let's call these measured elements (temperature, humidity, whatever): 'dimensions'

By trying to have one operating_mode control two dimensions, you just made things too complicated - why not just have different component classes? If it's a single device, then just treat it as a hub with two components?

Regarding operating mode: I note some systems actively work to keep their dimension within a range, and others only above, or only below a limit.

The classic is temperature (I know these things may not currently be that well defined):
off - do nothing until instructed to be on, regardless of current_temperature
cool - when required, work to lower current_temp below a target (but do not/cannot raise current_temp)
heat - when required, work to raise current_temp above a target (but do not/cannot lower current_temp)
auto - when required, work to keep current_temp within a range of upper/lower temps

on is a bit tricky - actively/continually heat (or cool) until told to be off, regardless of current_temperature (should this be two modes?, or can we tell the difference with state?) - they may have their own thermostat, but this would not be exposed to the client api.

My system heats, or does not, with a goal to keep that dimension (current_temperature) above the target. Thus its operating modes would be: off or heat only.

In the case of the humidity dimension, some systems will lower humidity only, others raise it (more rare, I guess?), and others keep it in a range. - again, this would imply at least 4 operating modes: off, auto, dry, and humidify (i.e. increase humidity to above a specified level).

I agree with the proposed definition of profile. I do think eco (currently implemented at as mode), away are profiles.

I think FollowSchedule is the base profile (hey heaters: go from off to heat operating mode at this time).

Another example is ``DayOff` (the system pretends it is a Saturday - e.g. useful if the kids are at home on a public holiday Monday).

[bryanyork]

This problem is made worse by the fact that some units have a dedicated on/off command, and a separate heat/cool/heatcool(auto) mode.

Google now supports the action.devices.types.AC_UNIT type which allows the OnOff trait to be used. I think this refactor should support this method.

It looks like we are currently doing the right thing with the Alexa by yielding the PowerController interface:
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/alexa/smart_home.py#L741

I'm working on a PR that supports the same for Google:
home-assistant/core#18544

However, I think we still need to refactor the Google Assistant platform to allow for ON_OFF climate devices to present as an AC_UNIT type.

In this refactor I'm hoping we can support every platforming natively and not try to shoehorn everything into an operation mode. Both Alexa and Google Actions support dedicated on/off and an operation mode now.

Besides that I'm all for cleaning up the platforms to make developing easier.

[definitio]

There is no support for dislpaying actual state (idle, etc.) of device in case it can report state. Should it be added?

[MartinHjelmare]

It's in the suggestion:
#22 (comment)

[definitio]

I saw it. I mean, state should be based not only on the mode and target temperature like in suggestion, but on actual state of devices that can report it. In this case state is what device do instead of current command.

[marchingphoenix]

Do we have any conclusions for this? Just ran in to another instance of a climate component not conforming to the climate.__init__ and breaking the Alexa/Google Assistant integrations.

[balloob]

Conclusion is that we have to start building this. It's going to be one of the projects Pascal will tackle once he starts working on HA full time

[kloknibor]

I'm taking a look at the Tado component to make it work with all the available features. One thing that is totally handled differently than, I assume, most other thermostats is that there are overlays.

An overlay basically is a way to tell the thermostat when to return to the smart schedule after you manually change the temperature. Options are: The user needs to manually returns to smart schedule (Manual), After X amount of time (TIMER), at the next automatic change in the smart schedule/going away (Tado mode).

How would we be able to use in the future? I assume we can just always choose the Manual mode for things like Alexa/Google home integration. But it would be nice if we can extend the climate entity to use the different overlays/modes as well!

[zxdavb]

Just an addenda to the above post ...

When a Zone is on FollowSchedule/Smart Schedule/etc. mode, it should 'inherit' it's operating_mode from the Controller/Schedule.

For example, when the controller is in Away mode, and the zone in FollowSchedule, the zone will operate as if it is in Away mode.

Is this the same for Tado?

[kloknibor]

Yes this also is exactly the same for tado :-)! Op 17 dec. 2018 om 22:47 heeft David Bonnes <[email protected]<mailto:[email protected]>> het volgende geschreven: Just an addenda to the above post ... When a Zone is on FollowSchedule/Smart Schedule/etc. mode, it should 'inherit' it's operating_mode from the Controller/Schedule. For example, when the controller is in Away mode, and the zone in FollowSchedule, the zone will operate as if it is in Away mode. Is this the same for Tado? —

[TD22057]

Another argument for not trying to auto-derive the current mode is that some systems will overshoot the target temperature by some amount. For example my heater target temp is 72F but it will really heat to 73 or 74 which is fine and it won't have to turn on as often. If we try to figure out what the current mode is it would see that 73 > 72 and decide that it's cooling which would be incorrect.

[Swamp-Ig]

There's a lot of variability out there:

• There's systems that just heat, just cool, and automatically switch.
• There's drying, recirculating air, and outside air sometimes too.
• There's ones where there's separate on/off as well as the mode.
• There's ones that have a single target temp for heating and cooling, as well as ones that have a split range (Google Assistant actually handles these OK if you set it up right, but single targets aren't working currently causing at least 3 reported issues I saw).
• There's performance profiles.

From what I can see the current system isn't a complete disaster, except I think there needs to be more consistency in setting capability flags and using standard modes. You're never going to be able to force a messy world of devices into something consistent, but if a unit has a Wombat mode there's no real reason not to display it in the HA UI, only with the understanding that it won't get passed on to google assistant or homekit, and the platform maintainers need to realise that.

Just define a basic set of capability flags with a defined meaning, and set up the UI and the GA / Homekit integrations to be smart enough to figure out what those mean. Maybe allow the extra modes, maybe allow performance profiles too.

Anyhow that's my 2c

[shbatm]

I'm working on implementing ISY controlled insteon and z-wave thermostats and I'd just like to throw my comments in the ring:

State:
I agree with the comments above that state should be reported separately from current operation mode. This can be inferred if the device does not provide it directly, but if the device supports it, it should use the devices value.

For example, ISY Zwave/Insteon will report CLIMD as the current assigned mode (heat, cool, auto) and CLIHCS as the actual current action the device is performing (heating, cooling, etc).

Modes:
I don't see any current support for devices that differentiate between constant modes (Cool, Heat, Auto) and program/schedule modes (Program Auto, Program Cool, Program Heat). I attempted to add them in home-assistant/frontend#2714 before I was made aware of this discussion. These are separate from other Hold, Energy/Eco, Home/Away modes, and I would like to see them implemented in the spirit of @Swamp-Ig's comment:

You're never going to be able to force a messy world of devices into something consistent, but if a unit has a Wombat mode there's no real reason not to display it in the HA UI, only with the understanding that it won't get passed on to google assistant or homekit, and the platform maintainers need to realise that.

My thought is maintain the 'core' modes that can be extended to Google/Alexa/Etc, but if a device has additional modes, allow them to be supported in the HA front-end. For me, Home Assistant will never replace my existing controller (e.g. ISY) if the UI can't support (or be extended to support) all of the features of my devices.

[shbatm]

If you'd like some inspiration from another development platform, I thought I'd share this Gist here which contains the Climate Device Modes used by the ISY:

https://gist.github.com/shbatm/a64995166e0bb16f5fae0e065cd57cfe

This is an excerpt from the ISY Node Server Developer’s Manual, which has a dictionary of various Units of Measurement (akin to the constants used by the different platforms within HA).

[OnFreund]

Since I recently contributed a climate platform, I thought I'd add my 2 cents here (TL;DR for the impatient towards the end):

First of all - I think the situation isn't that bad. While writing the platform I went over a few other platforms to understand the component better, and it seemed relatively consistent. Of course, it could be that the platforms I didn't review are the problematic ones, and there's always room for improvement, but overall, given this will be a breaking change, I would advise caution, and make sure the effort is worth it.

As for the arch review itself, I think it helps to start with what kind of devices are available. From what I know, there are two main types of climate devices (I'm not proposing we split them, but it's important to understand the differences):
The first type is the central heating device. These are relatively static in configuration - you turn them on when fall/winter starts, and off in spring. Target temperatures are also relatively static, but you might switch from/to "away" or "eco" profiles frequently.
AFAIK there are no cooling devices that work like this, but I might be wrong.

The second type is an A/C. It's mostly used for cooling but it can also heat. Configuration is very dynamic - you turn it on/off several times a day and you can change target temperature every now and then. These devices usually have several modes (e.g. "cool", "heat, "fan_only", "dry") that change once in a while, but usually don't have profiles (e.g. "eco", "away").

As @dgomes mentioned, there's also a distinction between a thermostat and the actual climate source (pump, furnace, VRF system, etc...), but I believe that if you have a good representation of the thermostat, most sources can be modeled as one switch (on/off), or potentially two switches (an addition of "heat" vs "cool" switch for VRF systems). Also, I believe most climate sources are either not "smart" enabled, or not under user control (e.g. central heating in an apartment building), or both.

This is, of course, based on my experience, so if I'm missing anything, I'm happy to learn more.

Given those two types, I would argue that this interface makes sense:

Some thermostats can be turned on and off. This is orthogonal to their mode, and is well represented by the existing component.

The target_mode is what type of action we want from the thermostat. The values I've seen are "heat" (increase temperature), "cool" (decrease temperature), "auto" (increase or decrease temperature), "fan_only"/"fan" (don't change temperature but keep air circulation) and "dry" (decrease humidity. I haven't seen the opposite).

The current_operation is what the device is actually doing, rather than what it's programmed to do. For example, if the target_mode is set to "auto", and the room temp is significantly higher than target temp, the current_operation would be "cooling". This can also be "idle" if the device is on but has nothing to do. I believe most devices are not going to report that, so while I understand why it's helpful to have it as an attribute, I would argue against making it the state of the entity.

(as an aside, it looks like modes frequently need to be translated for the device, and a pattern emerged of creating two dicts for that. I would love to push the translation code into the component, so platforms only have to define the dicts, but not do the actual translation.)

The current_profile is in a sense the algorithm that's used to make decisions by the thermostat. This could be "eco", "away", etc... I don't have experience with aux heat, but I'm assuming it belongs here. The chosen profile can also affect target temp and target temp range, but I'm assuming that many devices are not going to report those changes. If I'm wrong, it might make sense to separate the "set" or "desired" target temp and range, vs the actual target temp & range.

fan_speed is usually available for A/Cs, regardless of target mode. It's perfectly normal to have the target mode set to "heat", and fan speed to "low". I therefore don't think that the "fan_only" mode should be implicit - it's an explicit mode regardless of fan speed. Typical values I've seen are "low", "med", "high", and "auto". I've also seen "very low", and "very high". CoolMasterNet, the platform I added, is a device that integrates with most major VRF systems, and has these 6 modes, and by default does not not expose "very high", and "very low", and since fan speeds are mostly for A/C systems, I think it's a good reference. I would feel comfortable with just the basic 4 modes.

Of course, there are other attributes, such as swing_mode, target_humidity, current_humidity, etc...

An interesting question is what should be the status of the entity. I would argue that for A/Cs the most logical status is "on/off", but for central heating it doesn't make sense. I would therefore go with the attribute that is common to both device types on the one hand, and is not mostly static on the other, which is the current room temperature. Of course, anyone could always create template sensors based on other attributes.

TL;DR - my proposal is:

state:
Current room temperature

attributes:

• is_on
• target_mode - possible values: "heat", "cool", "auto", "fan_only", "dry"
• current_operation - possible values: "idle", "cooling", "heating" (what else?)
• current_profile - I would suggest to keep this free form, but possible values could be "default", "eco", "away", etc... Does aux_heat belong here or is it a separate attribute?
• fan_speed - possible values: "low", "med", "high", "auto"
• target_temp
• target_temp_high
• target_temp_low
• target_humidity
• target_humidity_high
• target_humidity_low
• current_humidity
• swing_mode - free form?

services:

• turn_on
• turn_off
• set_target_mode
• set_profile
• set_fan_speed
• set_target_temp
• set_target_temp_range
• set_target_humidity
• set_target_humidity_range
• set_swing_mode

[gohassgo]

Fwiw...

Some Trane HVAC systems using Nexia thermostats also have fan mode called "Circulate" which cycles the fan on/off for so many minutes per hour.

For states, f they have multi-stage compressors, they also track which "stage" the compressor is running in. In the Nexia app, they look something like:
Heat
Heat 2
Heat 3
Cool
Cool 2

[Adminiuga]

state:
Current room temperature

In this case what should be the state when thermostat is off

Some Zigbee Thermostats allows control of the display, like displaying outdoor temperature and time. I vouch to have a service like:

• climate.update_display specifying what type of "display update" it is, eg: 'outdoor_temp', 'time' etc allowing platforms extending the update type

[OnFreund]

@Adminiuga most thermostats I've seen can report the current temperature even when off. An alternative is to have some type of N/A.
In general, I don't think there's any reported attribute that will be available for all devices, and I believe current temp will have the biggest coverage.

Your update_display suggestion is really interesting, but I don't think it should control the state, as it might break generic behavior that's based on state. Additionally, it can probably be programmed through templates and automations without component support.

[Adminiuga]

@OnFreund my point being that "off" is a legit state of a "thermostat", and having temperature as state won't represent the "off" state.

the climate.update_display is not meant to control the state, it is more like automation.reload type service call. It is not meant for the platform to push state data into ha state machine. It is a service to push data from ha state machine -> thermostat display, eg I have sensor.outdoor_temp and I want to push the data from this sensor to thermostat display

[OnFreund]

@Adminiuga

my point being that "off" is a legit state of a "thermostat", and having temperature as state won't represent the "off" state.

Yeah, that's why my initial inclination was "on/off" as state, but since there are many devices out there where it doesn't make sense, current temp is second best. I don't think we should mix and match temp and "on/off" in a single state though.

the climate.update_display is not meant to control the state, it is more like automation.reload type service call. It is not meant for the platform to push state data into ha state machine.

I completely misunderstood this the first time, sorry. Really cool option, but if support is scarce, I would say implement this as an extra service in the platform, not in the component. Another alternative is to have a display component (maybe there already is?), and thermostats that support customizable displays will implement both a climate and a display platform. The display component will then have non climate platforms as well.

[OnFreund]

@zxdavb @Adminiuga I believe I addressed this here:

As @dgomes mentioned, there's also a distinction between a thermostat and the actual climate source (pump, furnace, VRF system, etc...), but I believe that if you have a good representation of the thermostat, most sources can be modeled as one switch (on/off), or potentially two switches (an addition of "heat" vs "cool" switch for VRF systems). Also, I believe most climate sources are either not "smart" enabled, or not under user control (e.g. central heating in an apartment building), or both.

[OnFreund]

@dgomes will help if you share the proposed functionality of an HVAC component so we can evaluate the pros and cons. If it's simply a glorified switch, I might be in favor, but if to operate your climate device you now have to constantly alternate between HVAC and Thermostat than I'll probably be against.

[dgomes]

I was going to wait for the wiki but here goes nothing:

state:

• operating - possible values: True, False

attributes:

• operation mode - possible values: "heat", "cool", "auto", "fan_only", "dry", "idle", "off"
• fan_speed - possible values: "low", "med", "high", "auto", "off"

services:

• turn_on
• turn_off
• set_operation_mode
• turn_on_fan
• turn_off_fan
• set_fan_speed

Observation: We might want to split the fan

[OnFreund]

In this case I don't see the advantage of the split, for two reasons:

1. In all systems I've seen (granted, limited experience), most of these are controlled through the thermostat, not the source. The source is usually just on/off, and sometimes a systemwide heat vs. cool (but individual thermostats can still be on "fan_only", for example, when the source is on "heat". It's just heating vs cooling that needs to be controlled centrally, in case the system can't support both simultaneously).
2. The resulting API looks very similar to what you'd expect out of an A/C thermostat anyway (with the exception of the missing target temperature).

[elupus]

Many hvacs are controlling the forward pipe temperature based on outdoor temperature. They have a mapping curve that maps outdoor temperature to forward pipe temperature with controllable offsets. So it's not really just heat/cool.

[OnFreund]

@elupus do you have an example of such a device so we can understand better? Also, what is the interface? Is it connected in any way?

[TD22057]

state:
operating - possible values: True, False
attributes:
operation mode - possible values: "heat", "cool", "auto", "fan_only", "dry", "idle", "off"
fan_speed - possible values: "low", "med", "high", "auto", "off"

I don't understand the distinction here. In my mind, a state is something that describes the current state of the system (i.e. something that can change). An attribute is something that describes the hardware (something that is configured). Having on/off for the operating mode is a huge handicap in the UI and problem for many systems. It requires that the user interface code have HVAC logic built into it to figure out what's happening and that's a really bad idea. What does "AUTO" -> ON mean? What about multi-speed systems like mine? How does it know which cooling level is being used?

Here's my system (which is reasonably typical for US forced air system): There is a combined furnace/AC/fan system. In my case, it's a multi stage system meaning there is a high and low setting for heat and cool. It's connected to two independent thermostats each of which controls a zone. While it's true those are separate systems (thermostat + climate), that's of no real value to me because the climate system (furnace/AC) has no way to get any information from it or to it. It's an embedded system without any feedback - there is no way to get it's state or control it. The thermostats have states and can be controlled, not the climate system.

I'm concerned about reporting only on/off as the current state. If the requested mode is AUTO, what's the state when it's ON? What about multi speed systems like mine? I don't want to make the UI code responsible for figuring out when I'm in COOL2 vs COOl1 when the thermostat already knows that and can tell me directly. There was a post awhile back that made a more sense to me - but I would split the fan out into a separate set of states. Not all devices will or should support all modes - they'll have to provide a list of supported states. I'd shorten the names, but that's not that important as long as we're consistent and clear. "Mode" is what's requested, "operation" is what's happening.:

mode : "off", "heat", "cool", "auto", ...
operation : "idle", "heating", "cooling", "heating2", "cooling2", ...
fan_mode : "off", "on", "auto", ...
fan_operation : "off", "on"

This way the UI can tell me whether my system is off (mode==off) or what's currently happening (operation) directly from the attribute.

[dgomes]

To me the HVAC component would be similar to the weather component. It would require a proper GUI for monitoring purposes (not to act upon) and some of the attributes could be more "important" then the actual state (just like temperature, humidity in the weather component are attributes)

My HVAC is an Heat Pump connected to an inertia tank, the role of the heat pump is to maintain the temperature of that tank, only control is ON/OFF and HEAT/COOL. The tank supplies heat to an hydraulic radiant floor, a system of manifolds directs the heat to each of my rooms according to a thermostat placed in each of the rooms. Currently I have various DIY mqtt sensors monitoring all these aspects, which I would really like to see all backed into a single UI.

As for the thermostat component, I'm pretty happy with the current one :)

[OnFreund]

@elupus @Adminiuga @dgomes thanks for the additional context and examples.
Seems like your need to get source information is much more advanced than mine so I'm not going to get into the details of the HVAC source side, but I will mention two things that I think are important:

1. I think it's critical that we keep the Thermostat component as the main way of interacting with the system, and that people w/o advanced needs from the climate source don't even have to know what a climate source is in order to control their climate devices in HA. I'm a bit afraid of things slowly creeping into the source side, until one day we find ourselves with no ability to run a climate device by using just a Thermostat entity.
2. With the exception of Nibe heatpumps, I think a lot of these climate source devices are going to be built on a generic platform that aggregates different sensors like @dgomes described.

[Adminiuga]

@TD22057
mode state : "off", "heat", "cool", "auto", ...
operation : "idle", "heating", "cooling", "heating2", "cooling2", ... --> this should be split to HVAC component and not to thermostat
fan_mode : "off", "on", "auto", ...
fan_operation : "off", "on"

What about multi speed systems like mine? I don't want to make the UI code responsible for figuring out when I'm in COOL2 vs COOl1 when the thermostat already knows that and can tell me directly. There was a post awhile back that made a more sense to me

Multi-stage heating/cooling should not be a thermostat property, but a HVAC component property.
IMO HVAC component should have the following state attributes

• heating_demand - 0% -- 100%
• cooling_demand - 0% -- 100%

if the HVAC unit support multi-stage, then each stage is equal to 100 /
for example 3 heating stages and 2 cooling stages, then
HVAC component:

• HVAC State:
  a. off heating_demand and cooling_demand are 0
  b. heating heating_demand > 0
  c. cooling cooling_demand > 0
  d humidity control??? when both heating_demand and cooling_demand >0
• HVAC heating demand
  a. 0% -- no demand, HVAC is OFF
  b. 33% -- Heating Stage 1
  c. 66% -- Heating Stage 2
  d. 100% -- Heating Stage 3
• HVAC cooling demand
  a. 0% -- no demand, HVAC is OFF
  b. 50% -- Cooling Stage 1
  c. 100% -- Cooling Stage 2

[TD22057]

@Adminiuga So how does that work? Like I said, my HVAC unit has no ability to communicate anything in or out. The thermostats (in this case radio-thermostats) request (and report) 1 or 2 stage heating and cooling directly. So it's the thermostat that's setting the staging, not the HVAC hardware. Would the radio thermostat have to create both an HVAC component and a thermostat component and push it's states into each one of those?

[Adminiuga]

I'm not implying "splitting HVAC" component off requires the HVAC unit to be smart and controllable.
I'm saying the underlying "climate" platform should "feed data" into two or more HA entities, with presentation for Thermostat and HVAC units (I still don't know how to handle Fan/humidity), for example lets take a Nest thermostat:
Physically it is a single device, low-voltage thermostat. I can control only the thermostat, but indirectly I control the HVAC unit as well.
I can turn it off:

• Thermostat is Off,
  I can get indoor temperature, there's no setpoint target temperature and thermostat is not requesting any heating/cooling from the HVAC unit

• Thermostat is on, set to HEAT
  now I have the target_temperature in addition to ambient temperature
  a. target_temperature < = ambient_temperature -- thermostat is IDLE, there's no demand for heat, the white and red wires are not shorted: this should be represented by HVAC having heating_demand of zero value, so heating_demand = 0% => HVAC State is OFF
  b. target_temperature > ambient_temperature -- thermostat is going to demand heat from the HVAC unit by shorting the white and red wires this should be represented by HVAC changing heating_demand to a non-zero value, depending on how many stages HVAC supports, in my case it is a single stage so heating_demand = 100% => HVAC Staet is HEAT

• Thermostat is on, set to Cool
  now I have the target_temperature in addition to ambient temperature
  a. target_temperature >= ambient_temperature -- thermostat is IDLE, there's no demand for cooling, the yellow and red wires are not shorted: this should be represented by HVAC having cooling_demand of zero value, so cooling_demand = 0% => HVAC State is OFF
  b. target_temperature < ambient_temperature -- thermostat is going to demand cooling from the HVAC unit by shorting the yellow and red wires this should be represented by HVAC changing cooling_demand to a non-zero value, depending on how many stages HVAC supports, in my case it is a single stage so cooling_demand = 100% => HVAC State is Cool

• Thermostat is on, set to Auto
  now I have the target_temperature_high & target_temperature_low in addition to ambient temperature
  a. target_temperature_low < ambient_temperature < target_temperature_high -- thermostat is IDLE, there's no demand for cooling/heating, the wires controlling heating/cooling demand not shorted: this should be represented by HVAC having cooling_demand & heating_demand of zero value, so cooling_demand = 0% & heating_demand = 0% => HVAC State is OFF
  b. ambient_temperature > target_temperature_high -- thermostat is going to demand cooling from the HVAC unit by shorting the yellow and red wires this should be represented by HVAC changing cooling_demand to a non-zero value, depending on how many stages HVAC supports, in my case it is a single stage so cooling_demand = 100% => HVAC State is Cool
  c. ambient_temperature < target_temperature_low -- thermostat is going to demand heat from the HVAC unit by shorting the white and red wires this should be represented by HVAC changing heating_demand to a non-zero value, depending on how many stages HVAC supports, in my case it is a single stage so heating_demand = 100% => HVAC State is HEAT

PS: the above is over simplification as there could be a green wire representing fan_demand

[OnFreund]

@Adminiuga

I'm saying the underlying "climate" platform should "feed data" into two or more HA entities

That's something I want to be careful with. If in the real world I'm controlling this through a single device, I want to make sure we're not overcomplicating in HA. Reiterating my point from earlier:

I think it's critical that we keep the Thermostat component as the main way of interacting with the system, and that people w/o advanced needs from the climate source don't even have to know what a climate source is in order to control their climate devices in HA. I'm a bit afraid of things slowly creeping into the source side, until one day we find ourselves with no ability to run a climate device by using just a Thermostat entity.

If it's just presentation of advanced values, that makes sense. The problem is that if the underlying device doesn't communicate these values, then I'm not sure what value they have. The algorithm you laid out works for some thermostats, but not all (many thermostats don't have a high and low, but rather a target temp and an implicit tolerance, and modern A/Cs, such as inverters and VRFs are sometimes more complicated). Additionally, the logic you laid out can be easily created with templates.

[shbatm]

If I'm following correctly, I would agree it sounds like there is a need for two categories of devices. It sounds like 1) is a thermostat, which is an external device that performs the action of controlling a climate unit, can report back its status and details of current settings and operations (Nest, Honeywell, Insteon, etc.). 2) would be an HVAC controller in which Home Assistant takes the significant portion of the inputs and acts as the "controller" brains for operating an external unit. This is what I would envision the device and settings @Adminiuga is referring to would fall under.

With respect to the thermostat category, I still agree with the proposals further above:
state : "off", "heating", "cooling", "idle", ...
current_operation : "off", "heat", "cool", "auto", "fan_only", "dry"
fan_mode : "off", "on", "auto", ...
fan_operation : "off", "on"

And I would suggest that the primary UI (e.g. cards) maintain functionality for a core set of functions (for which Alexa/Google support would be maintained), but the various different devices can report additional modes they support, they would just be reported as something like "other" on the card (or via text not icon) and available to be set via the more-info drop down box (e.g. 'heating stage 2' 'cooling stage 2' 'program auto' etc.).

[zxdavb]

@OnFreund asked: > @elupus do you have an example of such a device so we can understand better? Also, what is the interface? Is it connected in any way?

A lot of heating systems are all about moving heat from A to B - e.g. as warm air (I guess HVAC, but I've already demonstrated my relative inexperience there), or water (i.e the hydronic central heating systems as per UK/Europe).

With my 3 different makes (brands) of combi boiler (I'm in the UK), they all have means to vary the temperature of the CV (the Circulating Volume of water that leave the boiler, passes through all the open radiators, and returns to the boiler to be re-heated).

With the combi boiler/CV system, there are two considerations: a) having the return temperature of the CV (i.e. before it is re-heated) below 55C (makes them much more efficient), and b) modulating the CV temp to compensate for how quickly the house loses heat to the outside (the heat gradient).

1. Assuming the target temp for a room is 20C: outside air temp @ 15C , then CV = 45C, or if @ 0C, then CV=65C (to compensate for increased rate of heat loss to outside) -- google 'Weather Compensation' (curve). On my boilers the curve parameters can be adjusted, and the outside air temp can either be from a device attached to an outside wall, or an Internet source.

2. Or, it the target temp is 20C: current room temp @ 14C (just left 'away' mode, then CV=65C, or current temp =19C, then CV=45C (to prevent overshoots) -- google 'OpenTherm'.

Quite a few boiler support adjusting the upper limit of the CV via an api. One of my boilers allows the parameters of the entire curve to be adjusted via an app (not a public API, but hackable). All boilers support WC or OpenThem or your choice of one of the two.

(BTW, there are other considerations, like when the radiators are too small for their rooms, etc - this is less likely for HVAC as they'd have a tendency to be better designed.

[OnFreund]

Thanks @zxdavb
Seems like there's indeed more complexity in the source than I've initially thought. I'm not sure if there's a common interface to be extracted here, but that's a separate discussion.
In any case, what I want to re-iterate, is that any such split between source and thermostat should keep the thermostat fully capable to run the day to day operation. In the physical world, the thermostat is the interface through which 99% (or more) of the daily interaction goes, and I think we should keep it as such in Hass.

[Swamp-Ig]

@OnFreund Not always. On my ducted aircon system the thermostats are there for each zone (room) and are quite simple essentially on-off devices, the temperature they pick up determines the airflow into the area. The HVAC system master controller has all the essential modes like heat/cool/auto and fan speed, and is even used to set the target temp for each zone.