search

home-assistant / architecture

Repo to discuss Home Assistant architecture
314 stars 100 forks source link

Architectural review of climate entity #22

Closed balloob closed 3 years ago

balloob commented 6 years ago

This issue was triggered by https://github.com/home-assistant/home-assistant/pull/13340 which was adding Alexa controls for our thermostats. I also just did a rewrite of Google Assistant and made it so it only supports our official operation modes.

I think that it's time to do a review of our climate entity. Clean it up and then be better in code reviews in enforcing the rules of the climate component.

Supported features

We have individual support flags for setting a temperature, setting the upper bound of a temp range and setting the lower bound of a temp range. This is still an artifact from when supported features was used to show/hide frontend controls.

Cleanup of made up values

The goal of our abstract base class is to specify which values can be used. That way we can build things on top like frontend, Alexa integration, Google Assistant integration or compare the usage history of two thermostats from different brands with machine learning.

However, there are a bunch of platforms that return their own values for properties. Especially operation mode suffers a lot here. Instead of using the STATE_* constants, these platforms return their own made up values. It works with our frontend because we also allow returning an operation list. It does not, however, work with Google Assistant or Alexa. Both have been coded now to be very strict and ignore any non standard operation.

Operation mode

Operation mode describes in what kind of operation the thermostat currently is. This is what we have right now:

STATE_HEAT = 'heat'
STATE_COOL = 'cool'
STATE_IDLE = 'idle'
STATE_AUTO = 'auto'
STATE_DRY = 'dry'
STATE_FAN_ONLY = 'fan_only'
STATE_ECO = 'eco'
STATE_ELECTRIC = 'electric'
STATE_PERFORMANCE = 'performance'
STATE_HIGH_DEMAND = 'high_demand'
STATE_HEAT_PUMP = 'heat_pump'
STATE_GAS = 'gas'

Here are just some initial observations:

Actually: I noticed that we have a platform called econet that is not a climate device but is a water heater. It's the only one that uses STATE_GAS, STATE_HEAT_PUMP and STATE_HIGH_DEMAND (they are also used by Wink, but that's because Wink represents econet via their API). I think that econet should not be a climate device.

State property

This should be just operation_mode. Right now it's a combination of is_on and operation_mode. By trying to blend two attributes, we've made the value pretty much useless.

is_on property

Do we need this? Can we blend this in with operation mode? For example, if something is an on/off device, it could just have operation mode be heat/idle or cool/idle. Idle and off are obviously the same kind of action: nothing is happening.

References

KlaasH commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

... 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 commented 5 years ago

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: https://github.com/home-assistant/home-assistant/pull/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 commented 5 years ago

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

MartinHjelmare commented 5 years ago

It's in the suggestion: https://github.com/home-assistant/architecture/issues/22#issuecomment-440167281

definitio commented 5 years ago

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.

MartinHjelmare commented 5 years ago

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

marchingphoenix commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

Yes this also is exactly the same for tado :-)!

Op 17 dec. 2018 om 22:47 heeft David Bonnes notifications@github.com<mailto:notifications@github.com> 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?

—

marvin-w commented 5 years ago

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 https://github.com/home-assistant/home-assistant-polymer/pull/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).

TinusK commented 5 years ago

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 commented 5 years ago

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.

TD22057 commented 5 years ago

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 commented 5 years ago

There's a lot of variability out there:

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 commented 5 years ago

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 https://github.com/home-assistant/home-assistant-polymer/pull/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 commented 5 years ago

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 commented 5 years ago

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:

services:

gohassgo commented 5 years ago

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 commented 5 years ago

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:

OnFreund commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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.

zxdavb commented 5 years ago

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).

Adminiuga commented 5 years ago

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:

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 https://github.com/home-assistant/architecture/issues/22#issuecomment-454546894 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.

OnFreund commented 5 years ago

@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.

dgomes commented 5 years ago

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 :+1: and :-1: )

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

OnFreund commented 5 years ago

@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 commented 5 years ago

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

state:

attributes:

services:

Observation: We might want to split the fan

OnFreund commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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?

Adminiuga commented 5 years ago

@dgomes is https://github.com/home-assistant/architecture/issues/22#issuecomment-463165708 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.

elupus commented 5 years ago

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.

TD22057 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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

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:

TD22057 commented 5 years ago

@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 commented 5 years ago

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:

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

OnFreund commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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.

elupus commented 5 years ago

@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.