I recently wonder how can one use devices hooked up to HA in HE. At the time, the proposed way of doing it involved a lot of tinkering. So I decided to try a different approach. The result look to me much simpler.
With my limited knowlege I managed to cook up a driver that suit my need with the following qualities:
No virtual devices to setup except one for the parent device.
No automation on either side.
No man in the middle.
No individual setup for individual devices
As soon as a device is installed in HA it show up automaticaly in HE and it is fully functionnal.
Currently it only support on/off switch and plugs because these are the only things I have hooked up to HA (36 of them). All my real stuff is directly installed into hubitat.
It is too bad that nobody with knowlege seems to be willing to take this further because I think it would benefit people with less technical habilities.
LOL. You made a new post and didn't link it to the previous thread where we first started discussing this. I thought you had given up because I didn't see any updates there.
Awesome start! Yes, I do hope someone will contribute to this. I get that it works with MQTT, but it's so much work and extra parts needed from the user perspective and web sockets is so straight forward. We don't need HE to HA direction. That's already done.
The Apps and Rule engine are what is attractive in HE. What many ask about in regard to Home Assistant is all the cloud integrations people want and their community has created. Plus there are a few Zigbee devices that can be paired there, that are not yet available on HE.
For Z-Wave, I see little point in bringing that from HA to HE, but if someone wants that, I guess . But moving devices from HE to HA, and then trying to automate with their in-built method seems like someone must enjoy pain. And to move it there, but then just use Node-Red seems crazier, since if you're willing to run the extra miles needed to get Node-Red integrated, you can use Node-Red to do all this anyway, and don't need HA if you don't want it.
@ymerj - I was curious about this integration so I decided to give it a try. I was able to get your code running with ease. Nicely done! I then decided to try to add support for a basic dimmable light (e.g. a normal Dimmer Switch, not a CT/RGBW bulb.) Here is the result, which seems to work very well in my very limited testing. It is still a work in progress...
EDIT (interim code removed as it is all now in @ymerj's GitHub Repo)
UPDATE: I finished adding in the HA to HE dimmer level updates as well. Again, it is work in progress, and there are opportunities for some code refactoring to clean things up a bit, and to simplify the design. Thanks again @ymerj for kick-starting this effort!
UPDATE2: Fixing some edge cases and simplified the code a bit.
UPDATE3: Fixed another bug in the dimmer logic
Looking forward to trying out @ymerj's HA->HE integration in the next few weeks! Maybe one of you would have added thermostat support by then, at the rate you all are going!!
Funny, @ogiewon, I started thinking about the opposite direction (HA->HE).
I was curious how complicated it would be to maintain the mappings for device classes and attribute names between the two platforms.
This is a quick hack that correctly supports contact sensors statuses coming back from HA.
The catch is that it treats all HA binary_sensors as Contact sensors. So, it happily also reports @SmartHomePrimer luminance sensor as if it was a contact sensor.
binary_sensor also has device_class to further subdivide, but it'll take some work to map them all and to identify which ones can't be sufficiently disambiguated from their responses.
(Interim code removed. Now integrated into ymerj's GitHub repo)
Nice! There's something that doesn't allow that children to be recreated one you delete them. So I could see sensors in the logs, but the child devices were not created after deleting them from the driver that @tomw sent me. Same thing with the light. Now that it's deleted from your parent driver, it cannot be recreated.
Tried removing the parent and regenerating child devices. The websocket opens, but no devices are created after the children are deleted the first time. I also tried rebooting the hub in case something was still open and restarted HA. No effect, still cannot generate the child devices a second time.
Ah, that is funny. Still, it if was an HA light sensor (or motion or presence or ...) it would have the same issue with my quick hacked version. I think that the mapping isn't as bad as I initially thought, though. I'll post some additional thoughts on parse today.
I just deleted two of my Parent's child devices, and then manually changed the physical in-wall dimmer switches and the children were immediately recreated. I have not tried removing and recreating the parent device, though.
Also, it appears you're attempting to use a COLOR light. I have not support for color lights in this code, just a simple/basic "Switch + Level" dimmer. From what I see in some of your logs, your HA Color LED device is not sending the 'brightness' value in the JSON.
Here's a stab at genericizing some of the handling and also mapping component device types for more binary_sensor types: door, garage_door, moisture, motion, opening, presence, window
I started from @ogiewon's "UPDATE3" in this post and then added binary_sensor handling on top.
(Interim code removed. Now integrated into ymerj's GitHub repo)
EDIT: note that I changed the signature of createChild to account for the device_class entry where it was needed (just send null for that parameter otherwise), so make sure you pay attention if you mix-and-match code between different posts.
Wow! I'm happy people who knows what they are doing expand its fonctionalities.
@SmartHomePrimer Originally, for a child device to be created an event has to occur on HA. If a child device is deleted, one would need to trigger an event in order to recreate the child device. That's what @ogiewon did by physically flipping the switch.
As a side note, while developping that integration, I disabled the sun.sun integration on HA side because it litteraly spam the event bus every minute with a ton off useless information (to me that is). Not that it is important. It just prevent the parent device to be solicited every minute for nothing.
Maybe one of you would have added thermostat support by then, at the rate you all are going!!
[Kevin's MQTT app ([Beta] MQTT beta 3d (released 5th July) - #376 by kevin) already supports the "climate" device class. I can't compare it to this app/driver but I just started using MQTT for local status updates from my Ecobee. Seems to be working quite well.
I don't have slot of expertise in this area but the MQTT side of things does feel a bit clunky at times. Maybe this method will be cleaner?
I made a pull request for changes by @ogiewon and me. @ogiewon, you may want to review and make sure you like the couple of tweaks I made that impacted your sections.
. But moving devices from HE to HA, and then trying to automate with their in-built method seems like someone must enjoy pain. And to move it there, but then just use Node-Red seems crazier, since if you're willing to run the extra miles needed to get Node-Red integrated, you can use Node-Red to do all this anyway, and don't need HA if you don't want it.
