Bridging OpenHab and Home Assistant

Disclaimer: By writing this post, my intent is not to be little one platform VS the other. In my humble opinion both OpenHab and HomeAssisntat have their “positives and negatives”. Also being active in both respective forums I see people migrate both directions some come here because for any reason they can’t work with Home Assistant and vice versa. However, there is a niche group like myself which need both platform to run their home automation needs so lets jump to it:

The easiest and the most efficient way is to run both platforms from Raspbian or any other compatible linux distribution. Please note that if you are running Home Assistant from HassOS this will not work for obvious reasons.

Since most typical instant of Home Assistant (HA) is installed through Docker Environment so every other addon you add to your HA the openhab v2 pallet for Node Red will not communicate with OpenHab (OH). Hence you need to run two instant of Node Red and connect them through mqtt pallets. Don’t read beyond this point if do so is not an option.

So you install both MQTT broker server addon and NodeRed addon on HA (I haven’t tested to see how HA pallets will work outside of docker so I am not going there). Before you proceed make sure you stop NodeRed on HA. Than click here and follow instruction to install another NodeRed on your Raspberry Pi (RP). NOTE: Node-Red installation method that is prepackaged with Openhabian-Config doesn’t run as a service. Which means every time you want to Run node red you have to Start and your can use your Raspbian terminal while node red is running, so I highly recommend installing from the instruction provided in the link.

Since you can’t run both Instant of Node Red from one port you have to change the listing port of at least one of th Node Red. This is self explanatory in HA addon. On RP you have to change the node red system file. Once you configure both Node Red instances at different port numbers you can start Node Red on HA.

Using OH pallet on RP and MQTT pallet on both Node Red installs you can bridge almost any items from OH to HA.

Hope it helps, please let me know if you have any questions.

3 Likes

I assume you are using the term pallet to mean Docker container. Updating the post with the proper term would help readability for others.

1 Like

Thanks for reading my post. Pallet means custom components for Node Red which contains multiple node. Pallet here is strictly a Node Red terminology.

1 Like

Thanks for sharing how you setup your system, would be great to see a video showing off the best of each platform without putting either one down. Most people have trouble learning 1 system well enough, let alone two, so finding the right person to show off them both would be next to impossible. You must be constantly playing with your system as having two systems running you will have double the breaking changes, double the bugs, double the…

2 Likes

Great point. I think the direction the open platforms for home automation is going (this is btw my own opinion and can be completely wrong) is that node red is becoming a standard platform for having integrations/addons talk to each other ei the brain of automation. Now the preference between home assistant or openhab comes down to which of the platform support the devices that you have better and neither of the two is perfect for every smart device out there. In my case I have to run both to get best support for my devices. Last component of home automation is user interface and that really comes down to personal level of comfort to design and work with either of the platform. Integrating a device is into OH or HA is a onetime deal, however it is the user interface that is evolving all the time.

To be fairly honest I just started tipping my toes in OH once I get more comfortable working with it, I would definitely make a video comparing the two. :slight_smile:

Hi why can’t you run OH and HA with node red on the same network ?
if i understand you right this is what is going on here …

I believe they will simply offer more choices to work in different ways and each of those ways are improving all the time. Openhab supports nodered and it supports writing rules in Python (jython?) and many more ways to do the same thing. I don’t like node red (personal choice as I like streamlined low level code), but the more I see of it in recent times the more I am blown away with what it can do. The more you increase the ability and flexibility of any system the more it becomes more complex and harder to use/learn/master. You can apply this any home automation platform, the simple ones that are easy to learn and use are not as flexible and you become limited at some point. I believe a key to becoming successful will be the platforms that have the flexibility, yet ‘hide’ this from the user so it is easy to use when new, then allows the extra flexibility to be ‘unlocked’ when the user is ready to learn more, many will not desire to use the advanced stuff. Openhab 3 is something I am looking forward to working with as the UI is getting a big make over.

Totally agree, a single person that knows their ‘stuff’ can make a big difference in how a device works on a platform. Just because something is listed as ‘working’ does not mean it works stable, fast to respond to commands, all features work, and is efficient use of the hosting CPU.

2 Likes

I think this statement applies to pretty much anything with a learning curve: technology, cooking, driving, swimming, playing an instrument, etc. I really wish more people appreciated it.

I’m 100% with you on this. Make it simple for the people who just want it to be simple, and let them know that there’s more available if and when they’re ready for it.

1 Like

Well I am running both of the on the same machine and the same network. However, typical and most stable with add on capabilities of HA installation comes in docker environment. Some apps and smart devices really don’t communicate well over docker containers unless configured, properly. Hence I am ended up running two instant of Node Red and bridge them with MQTT. One for Openhab and the other for HA.

For me node red takes the complexity of coding, most especially templating away. One needs to know basic java to utilize node red, but mostly it is all visual programming which make it relatively simple to create and more important simple to diagnose and debug. Like lets say if I create a script, I have to go over it line by line to find what is wrong, where in node red you can pin point the problem to a single node and it is matter of digging through that node to see what is wrong. But again as you said it really comes to personal preference and level complexity one is willing to play around with.

Hi if it works it works right :slight_smile:
i have some pretty wired stuff going on my setup
also somthing like 3 node reds
but each on a diffrent PC

Interesting thread. I am running both HA and OpenHAB on the same wired network. Each on its own RPI4. My thinking was to explore/learn both in parallel then decide which is more suitable to me, in terms of ease of setup, supported hardware, etc. I must say HA seems easier to setup (at least initially). I have their App on my iPhone and it is working fine. It was rather easy to have it auto-detect devices on my network and auto-populate the main screen. I have no fancy automation schemes nor scenes or else (yet). Time will tell which way this is evolving.

Here is a question though: Can OpenHAB and HA run concurrently and control the same devices? Would either ‘complain’ or misbehave if they do not have ultimate/absolute control? Any issues with ‘collisions’?

If you’re just turning things on and off, it doesn’t matter whether you’re using OH, HA, SmartThings, Alexa, Google, or physically pressing the button. The device will turn on/off, and all of the other services connected to it should update accordingly.

The issue comes if you set up logic/rules in multiple systems. Since each system is reacting to the trigger, you might end up with rules that conflict with each other. But that’s something that can happen with two rules on the same system…so it actually has nothing to do with there being multiple systems.

There’s nothing wrong with programming rules in two different places, so long as you document what you’re doing and why you did it this way. Otherwise, six months later you’ll be pulling your hair out wondering why a light keeps turning off exactly five minutes after you turned it on…all because you forgot that you set up a rule in another system.

Saying this, if you can avoid having rules in multiple places, I think that would generally be a better solution.

1 Like

Thank you @rpwong. Very valid points. My thinking is to compare both, get a feel for both, and then even run them alternatively once I get to automation. All of this assumes I have a lot of time to spare/invest … which is very far from the truth :slight_smile:

Absolutely ! That’s a no-go.
There may be use cases where it is not immediately apparent as the extent of havoc you do depends on the type of device you use but you must never ever run 2 concurrent controllers, be it 2x OH or whatever other system.
All decent technologies and devices expect there to be only one.
For example a ZWave device has a ‘lifeline’ association where it sends updates whenever there are any. The controller will only be in one of the two boxes.
Same for Shellies: which IP to send to ? And about any other.

Good point @mstormi. Here is a simpler question then. I have multiple Apps installed on my iPhone, one for each family of smart devices I have (TP-Link, Wyze, Feit, Nest, Ring, Sense, …). I now access those devices from both their dedicated App and from OH/HA. Some of the devices have some simple automations. For example: I have a timer on some lights and other lights that are triggered by a motion sensor. The question is this: Once I give OH ‘full control’, is it best to totally disable control/automation by the individual/dedicated Apps? My thinking is a bit simplistic and I want to retain the individual Apps functionality while experimenting more and more with OH. Is that feasible at all or ultimately problematic? I see this as: OH is in charge of overall controls and ‘intense’ intra-devices behavior, yet the individual Apps give me the option to override OH whenever needed.

Thoughts/Comments/Risks ?

Yes I would disable automation by any app. It’s in contradiction and conflict with any centralized automation (i.e. OH).
If you properly setup OH to have “mirror” items you won’t need the apps any more.

Ok, thank you very much. I’d have to be careful not to introduce any unnecessary issues then.

What your asking is very difficult to answer as it depends on the hardware/brand.

Doorbird cameras will refuse to work when the app has control for example, but other camera brands I have working 100% in home assistant and openhab at the same time.

I usually power off the HA box as you also can’t rule out that some devices may crash more often it they are busy answering multiple platforms.

Lastly the concept I prefer to use is for devices to operate in stand alone mode and only use openHAB to over ride the hardware when needed. This way if I ever need to rebuild I don’t have an entire house not working for days as all devices keep working with openHAB turned off.

Multiple approaches, which I prefer to decentralise and distribute the intelligence if I get the chance/choice.

Thank you, I think you’re right-on i.e., the key is to ‘decentralize’. I’m facing multiple challenges, or I’d rather say ‘learning opportunities’. Thank you also for the link, that is a good read.

  1. Like most on here, I have devices from multiple vendors: Smart Plugs, Cameras, Smart Bulbs, Dimmers, Security System, Thermostats, and a multitude of others… a total of 50+ IOT devices, though not all of them need to be on OH. And, some of those devices have bindings available, others not (not yet).
  2. This fully integrated Home Automation is a continuous learning curve, and it’ll take sometime to get everything working together smoothly. Thus, I’d like to plan/execute this undertaking correctly, integrates the devices few at a time, and ultimately retain some individual control should anything go wrong in the process.

For example, I have some grow lights (for winterized plants) that are on a timer/smart-plug. The idea is to do something a bit smarter with OH e.g., if there is enough light from the window, then there is no need for the extra light. And there are many small tasks of the sort, I’m not after a central system to command everything.

Still a lot of learning and that’s the fun (and at times frustrating) part.