Closed balloob closed 3 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.
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.
... 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).
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.
There is no support for dislpaying actual state (idle, etc.) of device in case it can report state. Should it be added?
It's in the suggestion: https://github.com/home-assistant/architecture/issues/22#issuecomment-440167281
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.
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
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.
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
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!
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 intervenesTemporaryOverride
- 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)
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?
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?
—
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).
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.
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.
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.
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
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.
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).
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.
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
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
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:
@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.
@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
@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 likeautomation.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.
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).
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.
@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.
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 ?
@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.
I was going to wait for the wiki but here goes nothing:
state:
operating
- possible values: True, Falseattributes:
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
In this case I don't see the advantage of the split, for two reasons:
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.
@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?
@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:
- 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.
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.
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.
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 :)
@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:
@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 /
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 @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?
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
@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.
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.).
@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.
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.
@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.
@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.
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.STATE_*
toOPERATION_MODE_*
Operation mode
Operation mode describes in what kind of operation the thermostat currently is. This is what we have right now:
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