[RELEASE] Home Assistant Device Bridge (HADB)

And FWIW, the Ecobee Smart Sensors don't respond quickly enough for most automations. A more appropriate term might be "Occupancy Sensor." It can take quite some time (sometimes maybe a minute or so?) for motion to trigger the sensor as active. My guess is that the thermostat is only polling (or the sensors only wake-up and report) every minute or so in order to maximize battery life. The motion sensor in the actual thermostat seems to report almost instantly, though.

I've also taken a version of the HADB driver and stripped it down just to the climate domain in order to tinker with the way it handles thermostat setpoints. Don't hold your breath waiting for me to "fix" anything, but I'll certainly pass along anything I learn.

1 Like

Correct. Ecobee sensors are occupancy sensors. Their reset time is 30 min.

1 Like


I got a new instance of HA running and I have the bridge configured. Will there be support for bulb and media player?

I have a sisyphus table and the only way to connect to it is through HA but I'd need to be able to discover the light with on/off/brightness control (no RGBW) and the media player which is just a handler for running the 'tracks'. I'm most interested in being able to just turn the light on and off in HE. Will this eventually be available if I'm patient?

1 Like

Bulbs (dimmer) are already supported. ON/OFF only can be supported by switch if that's all you want. As long as you get the correct entities in HA for the light, it should work.

What is it you want to do with the tracks in HE? One simple solution if you need to control the media player on HA from HE, is to use the HE to HA integration and share virtual switches from HE. Then just create automations in HA the control the media player when the virtual switch is triggered.

There's no problem using both of these integrations together. I've done it myself before with no problem. Just don't add the virtual switches to the Home Assistant Device Bridge.


After an evening of tinkering, my opinion is that one of the HA components of this integration is misbehaving. HA appears to have issues when the thermostat is in dedicated heat or cool mode, and does not always react well when the device is controlled by a second or third-party (locally at the thermostat or via the Ecobee Cloud API). This testing relied solely on an Ecobee as the end-device connected to HA via the HomeKit Controller integration. Perhaps it would work better with a more basic thermostat, or one that was connected via zigbee/z-wave rather than HomeKit. I feel relatively confident in saying the issue is with either the HA device driver or with limitations in the HomeKit protocol. I took some notes on what I observed, but I don't have the skills to take it any further. I would suggest that the HADB driver code remain as-is until someone can test it further, potentially with some other devices.

On the up side, I still think it will work to replace my MQTT broker/client setup. I am using this only to monitor what the Ecobee is doing and trigger other automations (operate zone dampers, run humidifier/HRV, etc.). I don't actually send any commands out to the thermostat this way. So there should be no issues migrating those rules into Rule 5 using the thermostat device created by HADB.

1 Like

This is a great app/driver and I've been playing with it a lot. I have a couple requests that I got working, but I am unsure if they go with correct app/driver design, etc., so I'm not sure if they would be a good PR but I've been playing with remote and other binary_sensor.

  1. I have an Xbox One Remote device in my HA that is setup through the Xbox integration. I added the following code to the driver:

case "remote":
remote: [type: "Generic Component Switch", event: [[name: "switch", value: newVals[0], type: origin, descriptionText:"${friendly} was turn ${newVals[0]} [${origin}]"]]],

and the following code to the app:

if(["fan", "switch", "light", "binary_sensor", "sensor", "device_tracker", "cover", "lock", "remote"].contains(domain))

And it works to turn the Xbox on and off from within Hubitat. While this doesn't cover remote/toggle and remote/send_command, it does still work for remote/turn_on and remote/turn_off.

  1. I have a SmartDry clothes dryer sensor through a custom YAML integration and while motion works when setup through a binary_sensor, it makes more human readability sense for this to be a moving sensor in HA so I got it working by adding the following to the driver:

moving: [type: "Generic Component Motion Sensor", event: [[name: "motion", value: newVals[0] == "on" ? """active""":"""inactive""", descriptionText:"${friendly} is updated"]]],

This works just as well as motion and might be able to apply to other motion-esque entities like vibration etc.

If these are within the scope of the project I can add to a PR, I'm just new to this so I'm learning.

Glad you're liking this project!

My opinions:

'moving' seems to make sense (aside: can you explain why HA has both motion and moving)?

'remote' only exposing on/off as a switch seems like overkill for this project. Could you expose that functionality as a virtual switch in HA and then use the switch integration that this provides?

I am not sure on why there are so many movement-like binary sensors here but the way I think about it is "moving" is for the sensor device physically moving and "motion" is for sensors that detect movement of other objects/people through IR, etc., like a motion detector light switch. In my case the device is a magnetic sensor in my dryer drum and would detect vibration/movement as it physically moves to know that the dryer drum is moving. I still think the Hubitat motion component thing works though and it wouldn't need a "moving" custom component in my opinion.

For remote, I haven't played around with virtual switches on HA but may I ask why just controlling the remote directly wouldn't work, just so I can learn? Is it because it's forcing it into a switch and not having full remote device functionality (toggle and send_command)? I'd guess adding a virtual switch is just controlling the remote device through a template device in the configuration, but that takes some YAML lol.

1 Like

Yes, that's what I was thinking. There isn't really a good universal remote type in Hubitat. And I assume remotes in HA have a wide variety of functionality that people may want. This integration is really mostly about mapping simple and/or relatively standard device types.

Ok, ya, remote/send_command has volume_up, mute, etc., but I'm also mainly trying to avoid duplicate devices in my Lovelace UI (remote from integration and virtual switch).

What are your thoughts on moving, vibration, other simple binary sensors? I don't have any others but I can see the use cases. For mine it works as a motion sensor but how it's displayed and textualized in Lovelace looks like there's a person walking in my clothes dryer.

1 Like

I think all binary sensors are potentially fair game, especially if they can be mapped to a built in Hubitat for (like moving->motion).

Agreed. In the case of a HA sensor that is detecting the sensor itself is 'moving', we'd probably map that into the Hubitat "Acceleration Sensor" capability. This would probably help to avoid confusion between a traditional 'motion' sensor and what HE users have come to expect for an 'acceleration' sensor. But, this would mean using the built-in "Generic Component Acceleration Sensor" driver.



The anticipation is killing me! I've seen all the work done on the thermostat device in the Github repo...any guess when 0.1.38 might be ready?

@ymerj is fixing a couple of bugs I left behind, and then we'll be needing some testing help before the updates get merged in to a release. But it should hopefully be close if that all goes well.


The two platforms handle climate control differently, making it tricky to integrate. We aim at providing a simple means to import devices into hubitat while avoiding unsuported method that could generate error or inconsistency. I'm not sure we can acheive a perfect match between them.

@dylan.c and others: Since none of my smart thermostats are hooked-up to HA, I can't test it myself. If you can test the new version, it would be appreciated.



Hello and thanks for your response. I'm not a HA expert, I literally only have this ONE device on HA for this ONE integration.

You said that bulbs are supported for on/off as long as I have the correct entities in HA.

I definitely see that these devices are created and appear accurately in the device entities list in HA.

As I wrote this post, something happened and suddenly the light was able to be detected in the HA bridge app (I think I had previously copied the http into the IP address and perhaps that's why it wasn't showing devices). I selected it, finished it out but now I can't find the device in HE. Where does it put it? I only see a device for the bridge. Do I just change that driver for the bridge to a light driver?
Additionally, it didn't have the media player in the list of available devices to pull over. I will investigate this further now that I can at least confirm the connection.

What do I want to do with the media player? Hell, I don't know. I will probably run an erase track at night before shutdown and then start playing a playlist on startup. The media player isn't the important part, it's just a bonus.

The light is the priority because every light in my house dims at 945 pm except this one and it's driving me nuts :rofl:

Only certain categories of devices will show up in the drop down list for you to check the Box. Right now I don't think the device type "media player" is supported and so it would not show up in the list.

The 1st time the device changes state, for example turning on or off, it should show up in the device list as a child device underneath of the home assistant device bridge parent. This assumes that you have the device selected in the drop down section of the parent application.


It sometimes pays to think about what you want to do the other way around. If your intent is relatively simple then setup a device in HE that is mirrored into HA (using another integration) or use a HA device like a binary switch with a paired HE virtual. Now change the state of the device within HE as wanted and setup an automation in HA triggered on state change that will do what you want like ‘erase track’.

Alternatively .. I am not sure if this integration supports HA automation script triggering from a virtual device in HE but if it does you could do it that way too.

I know you’re very new to HA and probably shy of writing an automation script there but it’s fairly easy. Holding out for support within this integration for media players is a big request as it’s one of the most complex devices

1 Like

I get this error when trying to save the updated driver code...

 expecting '}', found ']' @ line 410, column 129.

fix underway...

1 Like

Download the Hubitat app