-
-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Architectural review of climate entity #22
Comments
A comment on on/off as I added that: That said, maybe |
Some obervations, some of which come from the stale home-assistant/home-assistant.io#3910 :
|
We need a abstraction how a thermostat should look like on HomeAssistant. I think the state should be the current temperature. All others are attributes. Like before the refactory of this components. |
I think the |
I don't know if a |
I think the |
Isn't that covered by |
Regarding feature flags, the Alexa.ThermostatController design allows thermostats to report whether they support single, dual and triple setpoints (target temperatures). There may certainly be thermostat devices out there that only support an upper and lower setpoint in certain modes (though it is unspecified in the Alexa documentation which setpoint a |
You seem to be describing I agree that there should be an "off" state for when the device is not allowed to be turned on/operated through software. |
Regarding operation modes: I believe "high demand" mode only applies to water heaters. "performance" mode seems to also be for water heaters, though |
There are a lot of commonalities between thermostats and water heaters (or other temperature control devies) that make it attractive to use a single entity type (and in some cases such as |
@tinloaf aaah there the issue is! I was looking for. I remember us talking about it but couldn't find it. I think that idle is not a correct operation mode. There is a difference between "current operation" and "current operation mode". Ours is the latter. Being in an operation mode doesn't mean that you are currently doing something. For example, a climate component in heat mode with a target temperature of 21 and a current temperature of 23, will not be doing something, yet it's mode remains "HEAT". I would expect "off" to be a correct operation mode as it means that we will not do anything regardless of target and current temperature. |
@trisk about the overlapping part: we should make it a separate component or else we end up with a lot of if…else things. The same reason light and switch are different components. |
Adding some from my thermostats that gets registered as climate entities.
Those two should most likely not be merged since it could vary with each device. |
What thermostat model is this? Most thermostats only adjust temperatures when in the operating modes "heat", "cool", or "auto". Both terms "idle" and "off" are usually reserved for modes where the thermostat will not attempt to adjust temperatures, though there may be a separate mode for when the device must be turned back on manually. |
This is where the current state and operational mode differ: some devices report a state to indicate whether a heating or cooling cycle is actually running at a moment in time and this should not be confused with the (user selected) operational mode, which determines which setpoints the device will try to adjust temperatures between. |
Trisk is right and our current naming is confusing, we actually want to represent "HVAC operation mode" but named it "current operation", which is confused with the current state. Oops. So to make it clear, let's add
Some popular climate APIs that I checked that all use "off" for hvac mode:
|
I suggest that HVAC_STATE have both |
By adding |
@balloob, is there a way in your proposal to distinguish between HVAC set to heat and actually heating and one set to heat and doing nothing because the room is hit enough? |
@balloob most of thermostat device can only 100% of a thermostat is the temperature in the focus of device. All other will be construct around this value. I vote for a temperature state and other will be construct around this as attribute. EDIT Hmm, there are other device they use also humidity and they make the temperature as state a bit wired. Difficult, but the state like you describe will be also bit mess. |
@andrey-git set hvac_mode to heat and hvac_state is either heat or off @pvizeli you're right that HVAC state can be derived from comparing current and target temp. We can't have the decice state be a temperature because target temperature can be a range when device is set to hvac mode "auto". I guess HVAC mode is not that important as it indeed can be derived from target and current temperature. We should change state to be just HVAC mode. Because HVAC state can be confusing. You'll see off but the actually heating but is not currently heating. |
@balloob that would be enough for automation, but would be less usefull for visualization. Hvac_mode could also be fan or dry. |
The frontend can calculate itself what the current state would be? We should aim for single source of truth and if data can be derived from other pieces of data, we should not include it. After reading this article on what "dry mode" is, I agree that we should include dry. (tl;dr: it dehumidifies the air) I don't like the "FAN" HVAC mode because we already have a "fan mode" property. In case a unit is set to fan, I expect fan mode to be set to "on" and hvac_mode set to off. |
As maintainer of the fritzbox thermostate implemenation I can tell that there is no way to get the actual state of the thermostate. The thermostate is a device directly mounted to valve at the radiator and controls the state of the valve always automatically. Its only setteble parameter is the desired target temperature. The other parameters like Additionally an away mode (for holidays) can be set and also a mode where the valve is forced to close (for sommer). So my suggestion for these kind of devices is to have an automatic mode, away mode and maybe something . But I dont't know how to handle the state. |
We already support away mode and you don't have to implement the set_operation_mode service either. Eco and comfort are profiles, and are not related to hvac modes. |
@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).
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 |
@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. |
In many ways HVAC & thermostats are similar. You could even say thermostats are a true subset of HVAC. I think thermostats should be separate because they are common, and much simpler than HVAC (thermostats have only one 'dimension', temperature). Much like |
This should also consider the generic_thermostat, which has no scheduling or similar capabilities of its own. At the moment, with generic_thermostat heating schedules have to be set via automations, and these override any temperature set by "away mode", rendering it unusable: see #20154 |
Here are my thoughts, coming from a primarily heat pump/air conditioner user perspective rather than boilers/radiators
Additional -
|
Trying to generate some momentum with this thread: To me Operation Mode ≠ State. Operation Mode should be the system's current setting (as @jnimmo put it: Heat, Cool, Fan_Only, Dry, Auto, Off). State should be what the system is currently doing: Heating, Cooling, Idle, Drying, Off. I can have my For Finally, Side note to @balloob -- is there a way to implement polls or a better location for this conversation to help drive consensus on these issues? Maybe it'd be better to break this up into separate sub-issues that we can discuss? EDIT: Just also wanted to add--borrowing from the UDI WSDK which has it's own mini-bible of Units of Measure/State--here is a potential more "exhaustive" list of valid modes: Thermostat heat/cool state: 0 - Idle, 1 - Heating, 2 - Cooling , 3 - Fan Only, 4 - Pending Heat, 5 - Pending Cool, 6 - Vent, 7 - Aux Heat, 8 - 2nd Stage Heating, 9 - 2nd Stage Cooling, 10 - 2nd Stage Aux Heat, 11 - 3rd Stage Aux Heat Thermostat mode: 0 - Off, 1 - Heat, 2 - Cool, 3 - Auto, 4 - Aux/Emergency Heat, 5 - Resume, 6 - Fan Only, 7 - Furnace, 8 - Dry Air, 9 - Moist Air, 10 - Auto Changeover, 11 - Energy Save Heat, 12 - Energy Save Cool, 13 - Away Thermostat fan mode: 0 - Auto, 1 - On, 2 - Auto High, 3 - High, 4 - Auto Medium, 5 - Medium, 6 - Circulation, 7 - Humidity Circulation Thermostat fan running state: 0 - Off, 1 - On, 2 - On High, 3 - On Medium, 4 – Circulation, 5 - Humidity Circulation, 6 - Right/Left Circulation, 7 - Up/Down Circulation, 8 - Quiet Circulation |
Hi! Not sure this is the correct place to bring this, but it seems mostly related. |
I locked this conversation because over 105 coments are not able to track anymore and second this issue is fix with climate 1.0 For things after climate 1.0 / open a new issue |
Can we close this now that the climate 1.0 PR is merged? |
The ADR itself still needs to be made? |
Do we need to do ADRs for component api changes? I'd assume that the api and dev docs speaks for itself. |
Quoting @balloob who I asked this question before: "ADR should be everything changed to core.", that makes it a yes I guess? |
Alright time has come to close this one up 👍 |
This issue was triggered by home-assistant/core#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
The text was updated successfully, but these errors were encountered: