About to migrate from HomeAssistant: what should I pay attention to?


I am a current HA user looking for a low-maintenance alternative to HA, since I cannot afford the time to maintain my HA setup. I’d like to have ‘set it and forget it’ installation. My current HA setup is only for monitoring purpose: temperature, humidity, CO2, camera, and some values from the heat pump and photovoltaic controller. Current devices:

  • Conbee II stick as Zigbee Gateway
  • Xiaomi Aqara sensors
  • Xiaomi Xiaofang Dafang Camera 1S IP T20L Chip
  • a heat pump, data pulled using NodeRed
  • a photovoltaic controller, data pulled using the REST add-on for HA

I did some searching on alternatives to HA and OpenHAB seems a good fit. Before I pull the trigger, I’d like to ask for comments/advices from OH users to make the migration efficient and avoid potential pitfalls.

Thank you in advance for any comment and resource/link to get started.

Welcome to the community!

While I’ve been told that OH is a more stable than HA I do want you to realize going in that to achieve “set it and forget it” requires a lot of work up front and the longer you wait between upgrades the more work it will be on you.

Coincidentally I just wrote a quick tutorial with some advice for how to achieve this at I don't want to upgrade! How to put it off as long as possible but the overall tl;dr is don’t change anything!. So you truly need to set it and forget it, no new devices, rules, UI widgets, OS upgrades, additional software, anything. It also means limited reliance on external services like cloud based APIs. Any change you make after first setting it up might break something and if it’s been a long time since that version of OH was released there will not be many who can help left and if it’s a bug, you’ll have to upgrade to get the fix anyway.

I believe the deCONZ binding is what you will need to use as the Zigbee binding doesn’t support this coordinator I believe. Xiaomi is notorious for adding on to the Zigbee standard so I don’t know whether that binding supports Aqara sensors or not.

I don’t know this camera but if it supports RTSP or ONVIF. That camera is not reported as working but it’s also not reported as not working. IpCamera: New IP Camera Binding

There is a Node Red add-on for openHAB support. Node Red can also be installed with openHABian.

openHAB has an HTTP binding that likely will work for you.

I’ve not migrated from HA so I can’t point out anything there. In general some advice getting started with OH includes:

  • Use the docs. Even if you think you know something if you run into trouble look at the docs again.
  • Use the forum. Search and if you don’t find anything ask a question. Don’t spin your wheels for hours and hours. But when you do ask on the forum, show your work. If we see you’ve tried and what you’ve tried it makes it easier to help.
  • Start small. OH has a lot of concepts that need to be understood individually and how they work together.
  • Use the Getting Started Tutorial as a guide. But realize that it presents examples. You’ll need to get good at generalizing an example and applying it in a different context. For example, the Adding Things Advanced page talks about MQTT but the HTTP binding is going to work very similarly.
1 Like

Good advice above.

Looks like @rlkoshak has you mostly covered from your binding/addons point of view.

What automations did you have in home assistant? As that might be where you spend your time short of everything being accessible.

Also note…as someone who looks at both, not all addons are created equal in both eco systems. For example, shelly for Openhab, easily pulls in my Shelly Temperature sensors and displays values as needed. Home assistant on the other hand, finds the device, and that very first time it’s awake gets a value, but forever after then will display unavailable, requiring me to look at something else. So while we can say “yes there is a binding for that” your milage may vary with how well implemented it is. Remember these are both user driven opensource projects.

Other than that welcome to the community.

1 Like

I think you’re in the right place. If your looking to only upgrade every 6 to 12 months that is what a lot of our users do. Openhab does daily and monthly (Milestone) builds and since V3 is new I would recommend you use the Milestones whilst you setup the software to gain the latest features and then once your happy drop back to using the Stable builds only which occur every 6 months.

Unlike Home Assistant that forces you to upgrade all integrations and core at the same time, openHAB allows you to drop in any integration into a folder and without needing to restart the new/updated integration is available. If there is a bug you can keep the core at whatever you have and drop in the fixed or an older version of just the problematic integration. Most of the time this works and it is handy if your on an older core and you want the new features for a new product you just ordered.

Welcome and hope you stick with the learning curve as changing is going to take some time.

1 Like

thank you very much for your warm welcome and advices, I am impressed. I feel that OH is a better fit for me than HA, so I am going to give it a try.

I was running HA on a very old Intel NUC (1st) and my original plan was using the same hardware for OH. However I see that OH provide an installation method on Synology NAS, which I happen to have one. The NUC is in the living room and connected to the Conbee II stick (for Xiaomi Aqara sensors). The NAS is in the basement, and having the Conbee II stick in the basement is perhaps problematic, since it needs to talk to all Xiaomi Aqara. sensors.

Any hint how to handle this please? Sticking with the NUC is one way to do that, however I’d prefer the installation on NAS if doable.

It’s worth the warning that this doesn’t always work. There are lots of moving parts and occasionally there will be breaking changes, regressions, and other incompatibilities that might pop up over time that can make this approach not always work for all bindings. But most of the time it does as the core is pretty stable in most of the ways that matter so it’s good advice. Just not always guaranteed to work in all circumstances.

Beware that Synology has dropped support for USB devices, as I understand it, so openHAB on the Synology may not be able to access the Conbee stick anyway with that sort of deployment. There are ways to host the stick on one machine and expose it for integration over the network (see Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide) which might work but frankly, I only see people on the forum who have troubles running openHAB on Synology or QNAP.

OH will run very well on that NUC. Most users tend to use an RPi with openHABian which could be another option.

1 Like

I think that is probably the best option for someone that wants to spend the least amount of time fault finding. Stick to where the bulk of the users are and allow them to test and find the bugs before you upgrade. I would probably go with a pi4 with 4gb of ram and spend some time setting that up whilst your HA is still running on the nuc. Then when your happy, repurpose the NUC to do object detection with your cameras on a separate network switch to keep the traffic away from your openHAB server.

1 Like

Further to this, there were issues with the RPi4 8GB, so while the extra RAM sounds like a good idea, it’s not worth it for an OH server. The issues may have been solved, but OH is generally fine with 4GB.

1 Like

thanks again for the insights. I will stick with the NUC route for the time being, since it seems the path of least resistance to me.

I want to shortly share my experience here since I’ve had a simliar situation. (HomeKit → openHAB → Home Assistant → openHAB)
When I went into the smart home topic I just had some hue lamps using HomeKit. My preference though was to use something more open, so I stumbled across openHAB and Home Assistant.
Also I was growing my device list which was then consisting of:

  • Conbee 2
  • Aqara Door Sensors
  • Ikea Fyrtur Blinds
  • Hue lamps
  • Hue dimmer
  • RF roller shutters controlled with MQTT

A colleague of mine used openHAB so this is what I started with initially. Since I barely had any idea about all of the smart home concepts and the UI was a bit confusing at first (OH3 was just released then), I gave up on openHAB and moved to Home Assistant. It was very nice to be able to achieve a lot of things quite easily in a short amount of time. After I while I began to notice things I didn’t like:

  • HA has to be restarted/reloaded quited often resulting in empty dashboards for some time (HA doesn’t save the last state of entities. This was quite noticeable at the Tesla integration as it only gets the battery when the car is online.)
  • the RPI distribution was so locked that you had almost no access to the system
  • HA would suddenly stop responding and I had to restart the Pi
  • sometimes HA would need several restarts of the Pi to come back again
  • logs were only accessible through the UI by default and after a restart you couldn’t see enough of those to actually see what went wrong
  • the Ikea blinds never really worked well. I got 3 and 1 would always not respond
  • my deconz (zigbee) integration lost some settings, I had to repair devices and things became out of sync with HA
  • my SD card broke after 2 months of using HA (this never happened to me before)
  • I found no good way of writing automation without using the UI (nodeRED was my choice then)
  • configuration as code was important to me but having everything in YAML felt wrong
  • updates broke the UI and some integrations, and updates came in quite frequently

The high maintanence time ultimately drove me back to try out openHAB again. I even ran both in parallel during migration which was quite nice. I started to put deconz into a Docker container using Ansible and connected HA to it. Then I added an openHAB container and connected it as well.
After I’ve moved everything over I could just shut down HA.

openHAB has been stable for over a year now, the SD card still works and being able to have the configuration in files is a big plus for me. Also writing rules in code felt more intuitive to me since I’m a software developer myself. There hasn’t been a single crash or slowdown so far and my maintenance time just consists of adaptions to the rules (if my requirements change) and the change of the container version every 6 months. The updates have also been smooth and did not break anything, yet. The only thing that I did not get to work properly is to get the battery usage of the Fyrtur blinds.
A huge plus is that changing the configuration doesn’t require a restart.
Since I have the configuration in files, I can simply fire up a container on my local machine to develop/test changes before syncing them to my Pi.

Disclaimer: My intention is not to bash HA here but to show you reasons why I’ve moved back to openHAB.


Just to be clear, SD cards will always break down after a lot of wear. It’s less frequent if you use Z-RAM (which is included in openHABian), but it will happen if you use a card long enough. Be prepared with a UPS and proper backups.

There are a few other things in your list that could also be said about openHAB, depending on a user’s setup and expertise.

I appreciate the disclaimer, but it’d be better if you bumped it up before your list of frustrations, because it certainly sounds like you’re bashing HA up until you say you aren’t. Others are fine with that, but I personally think it’s better when we don’t view open-source software as a competition.

In the context of this thread, let’s focus on helping @Tony3 get a good start with openHAB.

1 Like

Then you have basically three ways forward.

  1. Try openhabian as a set of installation scripts on top of any Debian (Ubuntu) install that you prefer. But understand that no one tests for issues using openhabian that way and in the past I have hit issues doing this. Have not tried this recently, but it is worth a try first to see the result.

  2. If your capable then just do a apt package install following these instructions. Install any linux you prefer (ubuntu headless server if you don’t have a preference), install the 64bit version of the Zulu java, and then these instructions…

openHAB on Linux | openHAB

  1. Install windows on the nuc if you prefer this as your OS, java and then openhab.

thank you for sharing your experience, I find it very relevant and it’s good to know OH works nicely for this situation.

You mentioned that you run OH on Docker. The docs say that running OH on Docker comes at a cost. Apart from the requirement to know Docker (I can use Docker), what are the main disadvantages of this route?

I am going to install minimal debian on the NUC to get started.

I am trying to decide between:
(1) install OH as a docker container
(2) install OH via instructions for debian-based distros (apt and the likes).

I’d appreciate a brief comment on props and cons of each route.

  • It’s mostly to do with the Exec binding and executeCommandLine. The openHAB Docker image, like any good image should, is pretty minimal. If you depend on external scripts (e.g. a call out to a Python script) this is going to be challenging to do from the Docker container. Not impossible but it requires a good deal more work.

  • Getting access to Bluetooth is a huge pain. I’ve yet to get it to work frankly. As a result, I’m running external services to push sensor readings from by Govee temp and humidity sensors and my AirThings Wave2s even though there are bindings built into OH to handle those.

  • It requires more RAM in general which can be a problem when running on an RPi or some other machine with limited memory.

  • There might be some networking issues.

after some searching on this forum and also googling, it seems to me that installing openHABian on top Debian on the NUC is perhaps a more suitable choice for me?

I run on an x86, so I installed Raspbian and then installed OH via Openhabian.

openHABian will give you a more complete solution and some tools to help set up and configure stuff outside of openHAB such as Mosquitto as an MQTT Broker, MiFlora sensor service, Node Red, etc.

It also helps us help you since we will be able to make assumptions about the system.

I think there is a problem with openHABian on Ubuntu but it should work with Debian just fine. Just follow the manual installation instructions.

@rpwong You’re right about the SD cards. I was just surprised since I’ve never experienced that before.
Regarding the disclaimer: Absolutely, I should’ve placed it earlier. To be honest, HA is an amazing piece of software but it doesn’t fit my way of doing things as nicely as openHAB does and has a much higher maintenance cost.

During my time with HA, I also used the bundled MQTT broker, which I missed at first, when moving to openHAB via Docker. So that’s something you need to consider if you use Docker. There are a lot of “convenience-addons” missing. AFAK openHABian comes also with Frontail, which I also had to manually configure (I use that a lot). Right now I have containers for openHAB, Mosquitto, Frontail and Deconz.
As @rlkoshak mentioned, openHABian is probably a good start here since you get many nice things for free. Especially looking at Node Red because I haven’t found a way to install and configure it for openHAB besides using openHABian.
If you’re interested, I can probably share my Ansible+Docker setup so you can better decide if that’s something you would want to invest in.

1 Like

When I look back migration from OH2 to OH3 there’s one thing I would do differently.
First play around with only a few bindings, things and items. See and experience what the impact on certain decisions is on the outcome. Same with your semantic model.
As soon as you have that clear, then spend the effort in creating all your stuff.