Should I upgrade to openHAB 4 or move to Home Assistant?
I am currently on OH 2.5 with about 170 things and many rules, and some of them rather complicated.
When reading comments, it seems best not to upgrade from 2.5 to 4, but instead set up a new instance and gradually move over.
So, that is the same process as moving to HA.
All of my friends are using HA.
HA seems to be winning new users, maybe rendering OH unsupported in a few years’ time.
On the other hand. When I first looked at OH and HA in 2017, I was persuaded, solely, by the notion that OH would be the more stable of the two. Unknown if that is still the case.
Well, I am not sure if you can help me decide, but it’s worth a try.
Thanks!
It’s going to be way less work to move a working 2.5 config to 4 than to learn a whole new framework and platform and reimplement everything from scratch.
It depends on whether you want to take advantage of all that OH 4 has to offer or if you just want to minimize the effort. OH 4 supports pretty much all the same config files that 2.5 does. The rules syntax hasn’t significantly changed. Sitemaps haven’t significantly changed.
But there are some breaking changes between the versions so you will have to make updates to the configs you have.
But, much like the old saying that “you can write Fortran in any language”, you can configure and use OH 4 just like it’s OH 2.5.
The only place where there might be a significant amount of work is if you are still relying on 1.x version bindings. And even there you can use the Remote openHAB binding to continue to keep those 1.x verison bindings up and running but still be able to use them on OH 4 until such time you are ready to move to the newer versions of those bindings (where available).
If you do want to take advantage of managed configs, MainUI, the semantic model, etc. then yes, you will get more out of OH 4 if you move over gradually because it’s going to be less tedious and time consuming. For example, it’s way faster and easier to recreate your Items from your Things using “create equipment from thing” than it will be to retrofit your existing Items into the semantic model.
People who move from HA to openHAB complain about how often HA deploys breaking changes forcing you to re do major portions of your config with little or no warning. If that’s what you mean by “stable” then I think OH still has the edge there.
We also are reported to have a much friendlier forum. If you run into problems upgrading to 4 you might get more help here than over there.
But all I have to go on is what’s been reported.
If this happens in a few year’s time I’ll eat my hat. Looking at just openhab-core, there have been on average (I’m just eyeballing the bar chart here) 6-8 commits per week all of this year. openhab-addons averages closer to 20 commits per week.
If not challenging, certainly a time-consuming process.
It’s my own fault for letting the system get so far behind on an old OS.
So basically need to build a new system alongside the current one and then run the upgrade process.
When I moved from 2.5 to 3.0 I’ve decided to replace textual config files by UI. But I could have stayed with textual config.
Migration from OH3 to OH4 was harder because of UoM. Suddenly the bindings started to report status using UoM and I had to change several roles. Pls note that you will also have this “obstacle” in HA.
So the real trick, as said before, is if you are using OH1 bindings.
HA is moving faster than OH. That is a fact. I subscribe a telegram channel with 1000+ HA users and only 2 OH users. From what I’ve seen every now and then HA version migration has its “headaches” that, even if promplly solved, create instability. I never had instability in OH, and IMHO this is by far the main reason why I stay with OH.
Sure, the HA addicts try to convince me to move showing the very nice cards that HA includes for Android on iOS. But I give no value for that. My house is self regulated, I would only need those nice screens to show to friends, not to actually control my house. To have remote access to their home, HA users either have to pay a lot to use HA’s cloud or need to incur on complex technical setups. Finally, if you have complex rules, chances are that you will need to complement HA with node red (many HA users do it because of HA’s not so powerfull automation, although this is improving).
I’m the same. Rules and Google Assistant mean that I rarely need to consult a visual UI. That would be different if I were more interested in collecting data.
I primarily use the Android app to receive notifications that trigger Tasker routines.
Make rules hardware-independent, e.g move them to NodeRed or similar engine. Then it will be quite irrelevant if you use OH or HA for bindings. I‘m still on OH 2.5
That is the entire idea behind things VS items to make the items fully independent from the hardware. If x hardware breaks, you can change your thing and link the new thing and channel up to the old item that you keep, and all your rules keep working the same way. If your new hardware uses a different unit of measurement like inches instead of mm, the framework handles the conversion for you. The advantages of moving from the very out dated 2.5 your using to the newer V4.x
The only advantage of using NodeRed is you can then only learn 1 way for rules if your using both HA and OH at the same time, but really you have made it more difficult by then having to learn and deal with the breaking changes of 3 pieces of software so it can be debatable on what you have gained.
We have our own way to work that makes sense to us, and that is all that matters.
I personally have to weigh up the cost of my time VS the cost of buying new hardware, which is already supported and working well. Sometimes replacing hardware with newer models can work out cheaper then the cost in time of moving software packages.
Yes that is still the case, I have developed a bad habit of upgrading to every milestone update every month and not backing up, not waiting to see what feedback is from other users and often leaving only an hour or two to test and fix issues before bed. I have not hit an issue in years now so this holidays I plan to get my backups in order.
The forum thread below shows what is considered normal for many in HA. Plus if you like doing textual configs, HA has been killing support for that over different releases and in some case you have to use UI and others you can only do textual, not consistent. With openHAB you can do both and with OH 2.5 you can do a hand edit and upgrade the things and items over to the newer OH4.x if you spend some time learning as it is all supported, documented and plenty of users here can help.
Literally every release comes with a litany of “backwards incompatible changes” (the artist formerly known as “breaking changes”) that everyone who is affected by has to deal with.
Reminds me of the Facebook motto: “move fast and break things!”
Is that what you would want for your home ?
I still keep failing to understand what’s good about moving fast particularly when your hardware doesn’t change.
Here’s another favorite of mine:
Cheap, fast, reliable - pick any two !
Proven in decades in working with the telco industry. Yeah, those guys that don’t sell stuff one-time but operate long term services.
The problem is that for many users migrating to a new OH version usually breaks not only the bindings, but also all configs, UIs and rules. Why? Cause many users stay at the same version until it’s not possible anymore (Don’t change working system rule). As the result there is a challenge of starting all from scratch while learning a lot of new stuff. Keeping the software modular - e.g. rules in one engine (like Nodered), bindings in another - OpehHab, and possibly UIs in 3rd party software, allows independent upgrades of each part with much less required effort each time. The only thing you have to care about - is to keep interfaces between them standardized.
You’re using openHAB 2.5 which was released on 15 December 2019, which is 4 years ago! It is possible to upgrade, just the effort to do that is larger compared to doing smaller efforts spread over time. It becomes worse the longer you leave it, as users that can help in the forum have forgotten what was needed, and harder because you have to look up multiple release notes to see what was changed and manual changes you needed to make.
The don’t change what is not broken, does not really apply anymore as the world is changing. With AI and scripts that a 15 year old can use to cause trouble on old software with known security flaws. We know that old software is broken in relation to security, so staying on old software could be seen as ‘refusing to change what is already known to be broken’ IMHO.
If your ‘stuck’ on v2.5 because of a V1 binding is needed, then you do need to plan a way forward or stay stuck.
If you think it is different over at HA, then it appears that they are making moves towards a similar V1 binding removal. Any binding/integration appears to be refused to have any changes made to it unless it is upgraded in full to their new format. A format which does not support textual configs anymore. Both projects have the same issues and have the same hurdles, just openHAB has already jumped some of these growing pains and are on the other side. HA did not want to keep textual support as it would slow them down, and no one stepped up because none of the paid developers were assigned. With openHAB we had volunteers step up and have continued support for textual and even BasicUI is still getting new features in 4.1 Stable.
Interesting to see that they have a quality scale.
You do not need to start from scratch. openHAB 4.x fully supports things and items from files, you can do some editing, or use scripts to update these files and use 4.x the same way your using 2.5 with the only huge exception of no V1 bindings supported. You can still use BasicUI and mostly forget about learning the newer mainUI if you wish. You have choices and a way to ease into the 4.x way of doing things.
Textual config is a prerequisite to real automation. You cannot build software systems that autoconfigure and auto deploy when you are that much depending on graphical UI input.
Such as what Deutsche Telekom did with their smart home product based on ESH a while back and what I’m doing with my OH based (commercial) energy management system today.
I’d consider this a barely visible (yet) but vastly underrated advantage of OH over HA.
Well, I would say with longer time the efforts become constant - reinstall everything, learn new stuff. Also the longer you wait, more bugs (potentially) become fixed, so you have less hurdle.
I continuously disagree with the way of fixing the issues by migrating to a new version, rather than issuing a bug fix or a workaround for existing users. It’s working for development environment but we have thousands of users already, who use use this software in production environment, where this way is not really accepted. As far as I know, HA is better in this sense, making it more suitable for such users, which was also one of the reasons I wanted to move, when I was upgrading from 1.8->2.5.
At the time I was migrating to v2.5 the issue was with MQTT event bus binding, which surprisingly was “forgotten”, so I had to use v1 for this. The funny story is that in V4 there is a still a kind of workaround for this binding using some rules instead(maybe it is a typical way in OH v.4.0, I don’t follow it so much): Marketplace MQTT Event Bus
So the best plan for that IMHO is really to stay stuck, and once you really need upgrade:
check your requirements - what bindings, features etc you need for you instance, normally the list of requirements will be quite small.
look in the forums and manuals, ask community how it is implemented in the software of your choice right now
check if there are any potential or unresolved issues, which can affect you
estimate upgrade efforts, including all above,
at the best try to reproduce the new setup on a non-production small instance (e.g home laptop, or unused RPi) and test your scenarios
and then select the final solution and a way to migrate
For example I did this with Homeassistant, FHEM and OpenHab, at the time of migrating from v.1.8 and OH clearly won despite issues with V1 MQTT binding.
I often wear a T-shirt when teaching some beginning programming classes that says (sing it to 99 Bottles of Beer on the Wall):
99 little bugs in the code
99 little bugs
take one down and patch it around
123 little bugs in the code
I’m not sure what makes you think that. And their casual attitude towards " Non Backwards Compatible" changes makes me shutter think how they backport bug fixes. But a brief looking around doesn’t show any evidence that they actually do backport bug fixes at all. Maybe I missed it while looking around.
But it’s worth mentioning bug fixes are backported in OH. That’s why we have 4.0.4. That’s four new releases of OH 4.0 backporting a dozen or so bug fixes including fixes for core, add-ons, and the UIs. But for new features yes, of course you need to upgrade to a new version.
It wasn’t forgotten. It’s now implemented via a rules (and it was implement as such within months of the release of the 2.x MQTT binding, I know because I implemented it). See Marketplace MQTT Event Bus for OH 2.5 and a very thorough tutorial. See MQTT Event Bus Publication [3.2.0;3.4.9] for a rule template (i.e. just install and configure, no coding required) for OH 3 and MQTT Event Bus [4.0.0.0;4.9.9.9] for OH 4+ (as you point out). I only reiterate this to point out that since OH 3, installing and using this rule template is no different from installing and using the old MQTT event bus add-on, and in many ways it’s even easier and definitely more flexible than the MQTT 1.x MQTT Event bus add-on since it’s not all-or-nothing (i.e. you can choose which items are on the bus).
In a nutshell: You can switch to HA because it’s more beginner friendly or because you like the UI more or maybe because certain hardware is supported earlier. But you really cannot switch to HA because of less breaking changes: HA has breaking changes in literally every release.
And you should consider that you need the Nabu Casa monthly payment if you want to attach smart speakers from Google home or Alexa or need any cloud functionality.
… and frankly imho the all community and volunteer driven project of openhab is much more sympathetic.
4-5 years of development, even on a volunteer project, can move a project forward quite a bit.
But I think the must important takeaway from this is that the volunteers who contribute to OH really do care about usability, stability, making upgrades easier, and everything else that people tend to complain about. We all really do care and we all really do want to make everyone’s experience with OH as good as it can be.
