A word about HA -> HE integration

Didn't see a pull request from you in @ymerj's GitHub repo. So I made the changes as you suggested as I was in the code added a comment for my change to the 'door' entry.

2 Likes

Thanks. Obviously I didn’t do it right :joy:

1 Like

Wow what a massive disappointment the Xiaomi Aqara vibration sensor driver is in HA. Shows time of vibration event only and their overall battery reporting is crap. Compare that to what @markus created for HE. Pretty clear to me I'll never personally use these sensors anywhere but directly joined to HE, otherwise you lose all the really cool benefits of owning them.

Xiaomi sensors are way more capable than even Xiaomi themselves take advantage of. They only show tilt and vibration events on their gateways. I was really surprised to learn from @aaiyar that there's even temperature on the Aqara contact sensor, but it's only currently possible to see it via zigbee2mqtt.

HA
Screen Shot 2021-02-07 at 12.06.48 PM Screen Shot 2021-02-07 at 12.06.21 PM

HE

1 Like

Zigbee2mqtt exposes everything that is in @veeceeoh/@markus' driver.

@chirpy has developed (and continues to develop) a universal Hubitat driver for Aqara sensors/button. I told them about the temperature sensor in the Aqara contact sensor, so perhaps we'll see that soon in a Hubitat driver.

BTW, that temperature sensor is slow to respond, but still works well enough.

3 Likes

The temperature sensor is now available in the driver. Thank you for pointing it out to me.

3 Likes

So little I can contribute here other than looking for issues and encouragement. So here's my pep talk :wink:

@ymerj You're a rock star for getting this ball rolling. For someone that claimed not to be a developer, your work is smart, clean, simple and I'm blown away by it! And a huge thank you to @tomw, @ogiewon and @stephack. I'm so pleased you have brought your talents to this effort.

Personally, I already have a method that works for getting my Xiaomi devices from their gateway to HE using Apple HomeKit automations. But honestly, it's so much less streamlined that this, and prone to soliciting intense swearing if anything goes wrong with Homebridge and I lose all my carefully created automations. Backup of HomeKit is possible, but it's not perfect.

I'm so impressed by what I'm seeing here, that I'm now planning to eventually move my Aqara HomeKit Hub off of my AppleTV and into HA's HomeKit Controller where I can then use this brilliant driver to bring Xiaomi devices into HE. This will allow me to replace a ton of virtual switches with the actual HomeKit device. I'm also very happy that I'll be able to compare Humidity from two Aqara sensors, something I could never have done before without joining them both to HE directly and dealing with the occasion drops off the Zigbee network. The only Xiaomi devices I plan to keep directly joined to HE will be the vibration sensors because of the huge amount of data I get, and the leak sensors, since they have never dropped for me and I'd prefer safety devices don't have to rely on three hubs (although I don't anticipate any stability issues with this setup).

If one is willing to buy a Xioami HomeKit compatible hub, and add HASS.IO (which really is dead simple to do, with no special configuration or yaml needed) to accomplish the hand-off to HE, this will open up the most common Xiaomi devices to be added with almost total immunity of the connection issues you often experience when you try to join Xiaomi directly to HE. :+1:

This is going to be quite awesome for use with @bravenel's Thermostat Controller. Inexpensive, small, and stable Aqara temperature sensors in every room of the house!

3 Likes

:point_up:

Ditto - to what he said!

1 Like

What I did in the MQTT app is place these sensor values into a virtual multi/omni sensor or failing that into an RM Connector variable so that you can display or use the value in rules.

I like this ‘KISS’ approach as it’s going to be fast and much easier for people to use. There are going to be a few hurdles ahead with more complex devices but do keep it as efficient as possible.

For me I need MQTT as I’m using more than two controllers but this will suit most users well.

I know some of you have interest in HA to HE with a thermostat device, like ecoBee. When I implemented this I found that the virtual Thermostat Device that HE includes implements it’s own internal ‘smarts’ and these conflict with ‘smarts’ that HA also tries to implement. So I created a device driver for HE called ‘Remote Thermostat’ which is essentially just a way of visualising and controlling a remote thermostat (HA or MQTT).

Although my MQTT code is not yet released with an open license you are welcome to use/adapt my ‘Remote Thermostat’ driver should you wish. It will be released with beta3e in the next few days (or is available by request)

Other virtual device drivers in HE like garage door and shades also implement ‘smarts’ like timed closed

3 Likes

All,

For anyone testing this new integration, please know that I have spent some time this weekend on refactoring the Parent Driver code. The new version should allow future enhancements with greater ease and simplicity. Please feel free to upgrade your parent from https://raw.githubusercontent.com/ymerj/HE-HA-control/main/HA%20parent.groovy and give this new version a try. Feedback is always welcome and appreciated.

4 Likes

@tomw Pressure child device deleted, but no notes. I assume an issue with it?

Nope, it would have worked, but I wanted to wait for @ogiewon's refactor to go live so I could add it properly in one pass. The goal would be to put it in without being too invasive and leaving a quick path to migrating to an in-box Hubitat driver if it is added in the future. I'll have a change today that adds them back.

2 Likes

Just a heads up, I did push a very minor update this morning to correct a typo in a log.info statement on line 141. I will back off and let you have at it! :slight_smile:

1 Like

Just joined Xiaomi Temp/Humidity/Pressure sensor directly to HA. I have temp and humidity components in HE, but no pressure yet. I still have the parent and child devices from last night loaded. I'll keep an eye out for pressure to be reported. I don't know it's frequency, but I would have thought it would be there on initial pairing.

Which version of the Parent do you have? I only ever added it in private versions...nothing was in the 'official' parent.

If you want to jump on it you can check my branch here: (EDIT: code merged to main in version 0.1.13). I'd appreciate the testing feedback both on the new devices as well as the ones that were already there (making sure that I didn't break them :wink: ).

I added an HPM packageManifest.json (that you can install in HPM using the 'From URL' option) since the multiple files become sort of cumbersome.

Not an HPM user. I don't mind manual.

Will check it out. Currently I have 0.1.11 Parent.

2 Likes

No Pressure state in HE

Screen Shot 2021-02-08 at 12.45.45 PM

Sorry, bad copy/paste error on my part. Grab an updated version of the parent from my branch.

1 Like

No pressure Generic Component at all now. Getting Temp and Humidity and they're reporting OK.

@tomw there is no event handling or parse method in your community component drivers. That's why the state values are not being added/updated.

@SmartHomePrimer, I loaded the parent and component drivers in the repo linked and they were created for me..but as stated above they are not reporting values.

1 Like