Do we have a binding that discovers and tries to integrate OH with Home Assistant?
I noticed they discover OH and give basic integration caps like sending commands. Can we do that too? It would be in best benefit of users who have some things working here and some other things working there.
No. Both, Home Assistant and openHAB are designed to be ‘master’ control systems and not to be controlled by any other entity. I’d even say that any such home setup is flawed by design.
If you really want to run it like that, you can use MQTT to exchange commands between those two, but usually there’s no need for HA as openHAB can directly talk to almost all devices.
Thats rather optimistic. I would hope we stay in that position for longer.
But they got Python and Shell integration and over 600 plugins and counting. Mainly because its easy for contributors to write scripts than heavy Java jargon that OH requires from contributors. There can be no master, we talk to Philips hub for Hue lights, I believe. Its just like that. We can’t put user into choosing OH or HA exclusively, at least they (HA) don’t. Systems should co-exist, we got docker, vm-ware, virtualbox, we can run windows, mac, linux simultaneously on same device and benefit from their unique features. There can be no master.
Well I guess that if there had been a real need for or benefit of HA integration, someone would have written a binding. But I haven’t heard of anybody doing that.
I strongly disagree on “systems should co-exist”. It does not make sense to have another control system inbetween if you can directly talk to the devices or hubs, let alone inserting a system that is as universal as is HA. That’s just complicating things a lot.
As I said it can be done using MQTT. But I know of people who tried running multiple openHAB instances in a master/slave fashion (also using MQTT inbetween) and most of them failed in one way or another.
No real need for a binding. But because OpenHAB does have the eventbus you can send a lot/receive a lot of commands from Home Assistant.
There are some benefits to HA, their homekit component is a little more advanced, allowing for motion sensors and alarm panels. Features still being included in the OpenHAB binding (and yes before you ask, I did try looking into it, but feel the user requirements for development a little steaper in OH that HA. Also their alarm panel (mqtt one) didn’t do what mine needed (case sensitivity etc and the commands for arming…it took me about 30 seconds to copy their alarm component and make a custom one that worked for me).
Their rule engine is more like the experimental rule engine for OH…but there’s tasks that I do in OH I have no idea how i’d implement using their automations scheme, so that is hard to deal with.
Oh and grouping, OH is so much more intuitive in this respect, get an item, plonk it in a group, done. In HA, you define the entity (item), then go fine the group definition and retype all the entities that should be in that group. Say what? Hard work.
But I think they work well together, and theres aspects of each that “win” over the other.
World is infinitely complex, we cannot always be sure to integrate with everything out there. Some bindings could be buggy here and user may choose to use HA’s reliable binding for that specific device. I am saying, he should have a middle path instead of totally having to abandon OH or HA for that matter.
You don’t expect that to be an argument in the eyes of any OH developer, do you ?
Obviously the “right” solution would be to fix the binding, then.
Again, that’s just your opinion (that of a more or less independent user) but yes, we’re biased to OH here, and that probably isn’t valid from a developer’s point of view.
Either way. OH supports generic interfaces such as MQTT (and HTTP or others) that you can use for that purpose, so feel free.
(yes, I’ve used those a couple of times myself already to integrate otherwise “unsupported” devices).
HA seems to have a rest api for control, status and discovery. There is also websocket api, but thats more for direct UI integration.
It would be fun creating proxy things in OH for things in HA. Need to create dynamic ThingTypeProvider and a discovery tool (probably in Python).
The question is whether there is an API on the HA side OH could query. OH does provide a nice REST API for this purpose so it was probably pretty trivial to create such an add-on to HA. Does HA provide a similar REST API?
I personally do not have any heart burn about such a binding. It is definitely along the lines of Node Red integration. A fairly large group of OH users use Node Red as their Rules engine. But, again, the plugin is on the Node Red side. I’m not sure what sort of API Node Red would support (short of setting up MQTT) that would give OH insight into what is going on in Node Red.
There are several perfectly valid use cases for doing this. It can indeed be much more complicated but I wouldn’t call it an anti-pattern. I personally run two OH instances quite successfully connected through the MQTT event bus. It made the most sense for connecting two separate HA systems separated by 65 miles.
I tend to agree with Markus on one point though. Either users are using the existing bindings to interact with HA (HTTP binding or MQTT binding) which may not be too hard or there really isn’t that much of a demand for this on the OH side. Maybe that is a bad indicator or maybe it isn’t. I think this is the first posting I’ve seen talking about such integration.
Personally, I’d rather see effort go into getting the MQTT 2.x binding over the finish line which I believe would address some of the awkwardness of using MQTT in OH 2. But of course, it’s your time and I’m pretty sure were you to submit such a binding it would be accepted.
I am no expert on MQTT but definitely in future if that binding requires dev time, I would be glad to help.
Right now their (HA’s) rest api seems to be well documented. I can deliver this to our (OH) community, I myself need such an integration for my own needs.