[RELEASE] Home Assistant Device Bridge (HADB)

10% of gross sales will be fine. :stuck_out_tongue_winking_eye:

1 Like

Those things stick like glue to HE too for whatever reason. It’s the motion sensors, contact sensors and temp/humidity sensors that have given me the most trouble unless they were on a Xiaomi controller, and now the ConBee 2 has proved its worth as well.

Thanks for posting this...I decided what the heck, let's take a look. Got the install on my pi done, but HA is coming up in Korean....

I do have support for Korean enabled on my laptop, but current language is ENG (image ) and every other web site or page I access on my pi comes up in English. Browser (Chrome) is set to EN:

Any suggestions - the only option I see to change language in HA requires you to already be logged in. :slight_smile:

I am learning Korean, but nowhere near ready to do HA in Hangul. :slight_smile:

I see I'm not alone...

Comes up in Firefox OK, so something in Chrome is confusing HA. Launched and setup account using FF, confirmed it's set to EN in the HA settings.


Logged into HA w/Korean UI using account info from FF login, changed language from Korean to English in HA on Chrome. Onward. :slight_smile:

1 Like

:man_shrugging: Some Chrome translate plugin? Maybe there's something that got added to the configuration.yaml file as a result of your available system languages. Really reaching for ideas, but Chrome is suspect since Firefox shows it in English. Anyway, the workaround should be fine.

1 Like

The funny part is, I've never run HA before today, so no real use for this yet, just had a Pi sitting there, only running a lonely Ecobee Deebot integration, so figured it would be interesting to see what HA looks like.

Now I need to know what are the cool/recommended devices that HE doesn't support and HA does, that I should be shopping for. Can someone start a list for me? :wink:

  1. ConBee 2 (all those Aqara devices that are giving you trouble, will just pair right up and stay there, happy as can be). Then this driver will bring them into HE and it will be like they were joined to HE directly, but they won't drop. :grinning:

  2. Many cloud integrations. I was running the HE integration for my Ambient Weather station, but I had some issues that I couldn't directly point to it for, but I also didn't have anymore issues once it was removed. So I gave up on it, but then when I noticed it in the list of integrations on HA I thought I'd try it. Works great and I now have my weather station back in Hubitat where I wanted it. :+1:

  3. If you already have a Xiaomi hub that supports HomeKit, you can use the HomeKit Controller integration to join it to HA. All the devices and their capabilities that show up in HomeKit will then show up in HA as native devices. Then our handy driver here will pull them into HE as devices. You now have HomeKit devices in Hubitat! :grinning: And if they're on a Xiaomi HomeKit compatible gateway, you have them in Hubitat by way of HomeKit Accessory Protocol and HA. The only two downsides to that I've found is that HomeKit doesn't support everything. So no barometric pressure for example. And if you want to remove just one device from HomeKit Controller, you can't. Have to remove the entire integration. That, it turns out it is one of those weird decisions that the HA group made. You cannot clean up removed devices from the database. You can only hide them. :man_shrugging:

Update: I just learned that with this integration at least, you can click the gear on the top right, change the device name to delete and it disappears. :grinning:

1 Like

Total Noob question. I have read HA has better HomeKit integration than using HomeBridge. I am specifically curious if HA has local control of Ecobee via HomeKit and if this driver may expose those. My uses of Ecobee via HE are very simple but I find the stock driver disconnects annoying but the community solutions way too complex for my needs. Hoping HA may be a better solution if I can still control via HE or NodeRed.

Thanks! The Combee II sounds a little interesting...I do like those tiny Aqara contact sensors and their button and they appear to have an RPI plug-in module for Zigbee. :slight_smile:

1 Like

I would highly recommend the USB stick and an adapter instead so you’re not locked into a RPi. You may decide you want to use it on a computer with deCONZ at some point, and the USB stick also allows you to put it on a USB extension and more easily get it away from WiFi routers and other controllers, as well as placing it in an orientation that is ideal for best signal.

1 Like

There’s two parts to their integration. One is kind of like Homebridge (which I prefer over their integration), and the other uses HomeKit Accessory Protocol, which makes it sort of like an AppleTV (eg. A HomeKit hub) that accessories can join (except there's no support for bluetooth HomeKit accessories and no access to iCloud for syncing and remote access).

There’s no support for thermostats in this driver, so while you could join an Ecobee to HA via their integration (cloud based) or you could join it to HA via HomeKit Controller (local) you wouldn’t get the thermostat control back into HE. Also, keep in mind that the Ecobee HomeKit integration has to first contact their cloud. So if it loses connection (like WiFi goes down or power goes out) it has to first reach out to the cloud again to authenticate before you get the HomeKit control back again.

1 Like

Wait, stop the presses...
I tried for a week to get my xbee3 as the coordinator on HA, what a nightmare, I finally gave up and got the conbee2.

Please let me know if you're successful and do share brief steps.


Just started playing with HA a week ago, originally for its superior dashboards (Lovelace or HomePanel that I plan to pair with Dakboard because it’s pretty). And this is after just getting into HE 3 months ago after a few years on ST. But this bridge has already allowed me to almost ditch ST completely, removing the need to keep it around for the few remaining devices that HE didn’t have an official or community driver for, like Arlo cameras (motion sensor events and battery status only in HE, of course, no video feed), and Meross bulbs, wall switches, and a power bar. (Too bad the Nest SDM API doesn’t provide an HA entity for motion, only camera.)

All that I have remaining now are my two oldest smart home devices, namely 1) a GarageIO controller and 2) an August Lock (early BLE-only model) + Connect WiFi bridge. Since there’s no integration for GarageIO in either HA or HE, the resolution for it is either a) live with status-only via ST Multipurpose (tilt) sensors I installed on the doors, with manual door operation through the native GarageIO app, or b) I learn enough Groovy to port the ST driver to HE, since nobody else seems to want to do it. Any volunteers? If not, I haven’t coded much since graduating from University almost 30 years ago, so wish me luck. :nerd_face:

For the August Lock, I just need to either a) persevere with the beta community driver in HE that doesn’t seem to want to work with my model, or b) move all my automations involving the lock to HA, (more likely).

Unless there’s a way to map the August Lock entity in HA to the Generic Component Switch, (seeing as there’s no Generic Component Lock)? I would prefer to keep all my logic and automations in one place. Would this be possible?

It’s by no means comprehensive, but you can check out https://www.hadevices.com.


It’s been a long time (relatively speaking) since my August lock (2nd Gen BLE with a bridge) was alive. But as I recall, the bridge could work with HomeKit. So if you bring the lock into HomeKit controller on HA, you’ll have it in HA as a device. From there, you can use @jason0x43 ‘s HE to HA integration to expose HE virtual switches. This will allow you to make two simple HA automations for control and status. Two switches from HE virtual switches will give you the ability to control and get status. One from HE to control the lock, and the other could flip with the lock changing state, which will serve as status on HE.

Not perfect, but a decent stop-gap until your August lock finally dies or you replace it. If you want, you can also create a simple rule on HE to allow a Virtual Lock to control the switch and the other switch I think could control the virtual lock with custom commands IIRC.

[Edit] maybe it’s possible to make a virtual switch in HA so you don’t need to use the second integration on HE. But I’ve no clue how to do that. The other possibility I’ve never tried would be to install Jason’s integration, just to get virtual switches to appear on HA, then maybe they continue to function with Home Assistant Device Bridge when Jason’s integration is disabled. :man_shrugging:t3:

@gswalker88 and @SmartHomePrimer

There might be a plugin in Homebridge you could use for the August locks not sure.

@erktrek and @SmartHomePrimer, the thought had occurred to me. I’d hate to have to install/configure/maintain homebridge just to support a single device. Although I forgot to mention I also have a Kwikset Premis (model 919) BLE-based HomeKit-compatible touchpad lock on the side door. If I could get homebridge to allow me to manage lock codes for that from HA as well, that would be worth it. Otherwise, I would just upgrade to a newer August model, which would increase the WAF, as the Connect bridge is kind of flaky and the newer products aren’t quite so bulky.

[Edit: Considering the effort involved in setting up Google SDM API for my one and only Nest Camera, this should be a piece of cake, so I shouldn’t use that as an excuse!]

Yeah one device would be overkill - I have found HB to be very useful even before I started using the Apple Home Hub am able to respond to events from Nest and Ring in Node-RED and HE. Not sure what you mean about the lock though - that is already in HK and HB won't be able to see it as far as I know it only bridges devices to HK.

I don't know if they're any better since being purchased by Assa Abloy (which also owns Yale), but I will never buy another August Lock. After 3 years, the flexible ribbon inside the lock broke because is wasn't designed properly and was allowed to flex where it met with a tiny circuit board that held the accelerometer. August refused to send me a part or help me in any way. Buy another lock was their answer, so I did.

I own two Yale locks and they are excellent. Have had the first since 2018 and the second since 2019. No problems with them ever (other than a bad module one that they replaced without issue) and they a fully supported in HE.

That would be because when it comes to HK & HB, I’m talking out of my ■■■. :upside_down_face: No worries, I’ll figure it out.

Despite the fact that the first few smart home devices I bought years ago were HK-based, (Apple was going to rule this space, right?), there was never enough of an ecosystem around HK, at least nowhere near the range of supported devices as I got into Alexa. And then I realized the limitations of Alexa, (good cloud-based device support, but local device support limited to Wemo and Hue AFAIK, and only the most rudimentary automation/routines), so I got into Z-Wave and ST. That really opened my eyes to home automation, by which time Apple had been sitting on its hands for 3+ years before it finally got back into the game with HomePod.

All of this is just to say that I totally agree with @SmartHomePrimer on there being no one perfect hub to rule them all. And as frustrating as ST became in the end, I learned a lot, and I think this HE+HA combo should last me for the next few years. I’ll follow with interest what’s going on with the Connected Home over IP (CHIP) community, but I’m skeptical and cynical enough to not expect a panacea from it.


Thanks for the advice. I wasn’t automatically going to go with August if I do replace it, since I think Z-Wave would be better, and nobody picks August as a go-to for Z-Wave, (there’s only one model, I think).

I do like the way that August pioneered replacing only the inside of the deadbolt to preserve the exterior look—another very important WAF consideration!