It seems like maybe we should move line 341 (case "auto") to above line 336 (case "heat_cool"). Do you recall why we made the "auto" and "dry" cases be no_op, @ymerj? I can't remember who did the debugging on that portion, but wild guess might be that the other attributes could be missing or something. Seems like we might have done it the way it is for "auto" for some reason.
According to HA, "auto" means The device is set to a schedule, learned behavior, AI. Since HE does not have that option it is droped off. Maybe we can replace it with something else.
Thanks @ymerj. My device is indeed set to follow its built-in schedule. I still value though the ability to monitor it via HE and to override the set schedule via HE rules in response to events.
@tomw Maybe we can map "auto" to "heat_cool" ("auto" in HE) like you suggest but what about "dry" mode? What to do with "device is drying" state?
@ymerj and @jason5, do the "auto" and "dry" modes from HA still have all of the other attributes, as shown here?
def current_temperature = response?.event?.data?.new_state?.attributes?.current_temperature
def hvac_action = response?.event?.data?.new_state?.attributes?.hvac_action
def target_temperature = response?.event?.data?.new_state?.attributes?.temperature
def fan_mode = response?.event?.data?.new_state?.attributes?.fan_mode
def thermostat_mode = response?.event?.data?.new_state?.state
def target_temp_high = response?.event?.data?.new_state?.attributes?.target_temp_high
def target_temp_low = response?.event?.data?.new_state?.attributes?.target_temp_low
My only concern would be that the HA response wouldn't include all of those, and it could break our assumption later in the HADB code that they are all there.
A quick test @jason5 would be to check what those attributes are reported as in HE when you use your modified version that supports "auto" coming from HA.
Hi @tomw,
My thermostat displays all 7 of those attributes in HE while operating in 'auto' mode from HA. See screenshot below. Some attributes are guessed by HADB (e.g. fan_mode, coolingSetpoint) rather than parsed, but that's due to gaps in my thermostat's feature set rather than 'auto' mode. I've also pasted a log excerpt below if you want to see some raw data from HA.
The only bug (feature gap?) I've encountered is that HADB can't turn on 'auto' mode after it's been turned off (activating 'auto' in HE turns on 'heat' mode). I'm guessing this is because HADB interprets the 'auto' command as 'heat_cool' whereas HA interprets it as "resume schedule". These seem like two different features overloaded onto the same control/attribute value, so you might want to consider teasing them apart. I was able to workaround this via a "Resume schedule" virtual switch in HE, which triggers an automation in HA to re-enable 'auto' mode on the thermostats.
I can't comment on 'dry' as my thermostat doesn't support that mode, so I would suggest leaving the code for "case dry" as-is.
Example log entry for Drayton Wiser thermostat in 'auto' mode on HA:
parse(): description = {"id":1,"type":"event","event":{"event_type":"state_changed","data":{"entity_id":"climate.wiser_breakfast_room","old_state":{"entity_id":"climate.wiser_breakfast_room","state":"auto","attributes":{"hvac_modes":["auto","heat","off"],"min_temp":5,"max_temp":30,"preset_modes":["Advance Schedule","Cancel Overrides","Boost 30m","Boost 1h","Boost 2h","Boost 3h"],"current_temperature":19.5,"temperature":19.0,"current_humidity":50,"hvac_action":"idle","preset_mode":"Override","window_state":"Unknown","window_detection_active":false,"away_mode_supressed":false,"heating_type":"HydronicRadiator","number_of_heating_actuators":0,"demand_type":"Modulating","target_temperature_origin":"FromManualOverride","is_boosted":false,"is_override":true,"is_heating":false,"control_output_state":"Off","heating_rate":1200,"boost_time_remaining":0,"percentage_demand":0,"comfort_mode_score":0,"control_direction":"Heat","displayed_setpoint":19.0,"schedule_id":2,"schedule_name":"Downstairs","current_schedule_temp":19.5,"next_day_change":"Thursday","next_schedule_change":"21:30:00","next_schedule_datetime":"2022-12-29 21:30:00","next_schedule_temp":7.0,"icon":"mdi:radiator-disabled","friendly_name":"Wiser Breakfast Room","supported_features":17},"last_changed":"2022-12-29T06:36:14.893041+00:00","last_updated":"2022-12-29T15:55:03.630777+00:00","context":{"id":"<REDACTED>","parent_id":null,"user_id":"<REDACTED>"}},"new_state":{"entity_id":"climate.wiser_breakfast_room","state":"auto","attributes":{"hvac_modes":["auto","heat","off"],"min_temp":5,"max_temp":30,"preset_modes":["Advance Schedule","Cancel Overrides","Boost 30m","Boost 1h","Boost 2h","Boost 3h"],"current_temperature":19.5,"temperature":19.5,"current_humidity":50,"hvac_action":"idle","preset_mode":"","window_state":"Unknown","window_detection_active":false,"away_mode_supressed":false,"heating_type":"HydronicRadiator","number_of_heating_actuators":0,"demand_type":"Modulating","target_temperature_origin":"FromSchedule","is_boosted":false,"is_override":false,"is_heating":false,"control_output_state":"Off","heating_rate":1200,"boost_time_remaining":0,"percentage_demand":35,"comfort_mode_score":0,"control_direction":"Heat","displayed_setpoint":19.5,"schedule_id":2,"schedule_name":"Downstairs","current_schedule_temp":19.5,"next_day_change":"Thursday","next_schedule_change":"21:30:00","next_schedule_datetime":"2022-12-29 21:30:00","next_schedule_temp":7.0,"icon":"mdi:radiator-disabled","friendly_name":"Wiser Breakfast Room","supported_features":17},"last_changed":"2022-12-29T06:36:14.893041+00:00","last_updated":"2022-12-29T15:55:07.953159+00:00","context":{"id":"<REDACTED>","parent_id":null,"user_id":"<REDACTED>"}}},"origin":"LOCAL","time_fired":"2022-12-29T15:55:07.953159+00:00","context":{"id":"<REDACTED>","parent_id":null,"user_id":"<REDACTED>"}}}
Sould we support feature that are oblivious to HE? There is no such equivalent as "HA auto mode" nor "dry" in HE. While developping climate support we focused on those attributes which are native to HE. The fact that auto mode in HE trigger heat_cool in HA is exactly what it is supposed to do. The two platforms have a different name for that mode. Even though they both have a mode call "auto", it does not refer to the same setting and therefore, they are not interchangeable.
That said, maybe HA auto mode could be map to heat_cool in order to make the device visible by HADB but it would be at the expanse of conformity ( @jason5 thermostat supported mode are "auto, heat and off" but "heat_cool" assume "cool" mode is also present ). It could be harmless though. @tomw What do you think?
(Deleted and reposted my reply to clarify my thinking)
Having dived into this deeper, I think I now understand the issue: the HE platform has 4 built-in thermostat modes (cool, heat, emergency heat, and 'auto'), so 'auto' needs to mean either "heat_cool" or HA's 'follow schedule" but we can't have both. @ymerj @tomw Have I got that right?
A suggested solve is to give users an option via a toggle in the HADB driver on whether they want HE's 'auto' to mean 'heat_cool' (default) or HA's 'auto'. Folk who choose 'heat_cool' would get the current HADB behavior with 'auto' events suppressed to avoid breaking any rules and apps. Meanwhile folk like me who have heating-only systems and want the ability to set HA's ‘auto’ mode from HE would choose the latter option. I've got this functionality working now in my fork.
Let me know what you think and/or if you would like me to propose the code change.
1 Like
I follow your thinking on this @jason5.
My preference would be to not expose a configuration option for this at the HADB driver level, because it's fairly niche and specific to that device type. It will quickly get cluttered if we open the door to adding domain- or device class- specific features like this into the HADB driver.
If it works for you to customize your local copy of HADB, and with the rate of changes in HADB having slowed down a lot, hopefully it isn't too onerous for you to keep your custom version.
If this becomes a more common issue or something more widely requested, let's revisit. Seem reasonable?
1 Like
That works for me. Thank you.
1 Like
First: This is great! It works well and was easy to setup because of the great instructions.
Does the filtering only happen on the HE side? I selected to import only a few devices from my HA instance, but when I turn on debug logs I see messages for updates on all my HA devices.
I sort of wished I got single devices with all the attributes, instead of one generic component device per attribute. E.g., my Ecobee sensors come over as 4 devices. But I understand why this is necessary.
2 Likes
HA sends updates for all devices over the websocket connection and doesn't have a way (that I'm aware of) to pre-filter to a subset of devices the events that it sends.
The filtering selection on the HE side just tells the HADB driver to drop events from the non-selected devices with the minimum processing possible.
2 Likes
Thanks, that's what I thought might be happening. I apparently have some chatty devices on my HA instance; e.g., it picked up my border router and keeps reporting upload/download rates every 10 seconds. I don't want that in HE, but I'll assume the overhead of receiving and ignoring that firehose of data is small. HADB is running on my 2nd hub, and I'll be using Hubmesh to share the devices I care about back to my main hub.
One thing I haven't figured out is why my Ecobee occupancy entities aren't coming over. Getting local access to my Ecobees (via HA Homekit) was why I set this. I'm getting the motion and temperature entities, and on HA I see the occupancy entity being updated, and they are all certainly selected.
Please share a HE debug print of an event on your occupancy entity. We can take a look to see if it would be easy to support.
1 Like
The Ecobee sensors report motion and occupancy - the occupancy just appears to be motion that clears after 30 minutes. This is a trace of the motion and occupancy being triggered for one of my sensors.
Looking at the data, the only real difference is the value of device_class - motion vs. occupancy. I think you can just treat the occupancy as motion.
Seems straightforward. We can alias occupancy to any other binary sensor type. Does presence or motion make more sense?
1 Like
I duplicated the motion line in the mapping inside translateBinarySensors and changed the key to occupancy, and that seems to have worked:
motion: [type: "Generic Component Motion Sensor", event: [[name: "motion", value: newVals[0] == "on" ? """active""":"""inactive""", descriptionText:"${friendly} is ${newVals[0] == 'on' ? 'active':'inactive'}"]]],
occupancy: [type: "Generic Component Motion Sensor", event: [[name: "motion", value: newVals[0] == "on" ? """active""":"""inactive""", descriptionText:"${friendly} is ${newVals[0] == 'on' ? 'active':'inactive'}"]]],
I created a pull request with this change.
1 Like
I went with motion, since I've always felt it's a delayed motion inactive.
1 Like
So basicaly you don't want occupancy to be distinguished from motion
Correct.
