Wow…
Here is a quote from that thread on HA forum:
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.
you wanna switch to HA… go for it!
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.
Very interesting.
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:
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).
Based on your answers, @rlkoshak I see that OH v4.0 is far more user friendly as it was at v.2.5 times. I like this trend.
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.
Whether you use HA or OH, if you stopped updating it for 4 years, expect a bit of work when you try to upgrade. It’s the nature of progress.
You can’t expect improvements whilst still clinging to the same old ways.
Windows try to do this and look how bloated it is.
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.
I disagree or do not see your reasoning behind this statement and clearly HA devs do not agree either. I fully use the UI for admin tasks and love the fact that now a binding can select the default ITEM type, state d., metadata etc… for each channel to be what is the recommended way by the binding maintainer. The newer versions of openHAB have a lot of stuff done in the background that an average user would not see, and not all bindings take advantage of what is possible.
I believe Nabu Casa (HA) are trying to make a toaster/appliance style solution. They are selling hardware and are making choices towards this goal. I like that someone is trying, and we do benefit from some of the work they do, like the MQTT home assistant discovery.
They are not any better. Probably the easiest way to describe their way VS ours is to say they do a monthly release with a feature freeze with only bug fixes for x amount of time and then next month they start from scratch and nothing goes back into the previous months release. You can see how many people are upgrading at the below link. OpenHAB does daily releases, monthly releases and biYearly releases. Only the twice a year ‘STABLE’ releases get the feature freeze and bug fixes rolled back into them for a short period of time.
As for the analytics, I find it interesting that they claim they put privacy first, yet you have to opt out of data leaving your network to what is a private company collecting data. Many people leave the tracking turned on as this is how they decide how much kick back they will get when they swing the axe to kill a certain feature.
Due to needing to fix issues with cloud connections, or keep libraries up to date to fix security issues, (which often bring breaking changes in them), you really can not do what you are suggesting. At some point you have to draw a line and move to a new version. Also new improvements can not be rolled back otherwise your now describing the creation of a new version.
There is a niche case that Markus and others pursue which is different from the general case. They are not just building their own home automation system, they are building and maintaining an automation system for many, in some cases for money. The requirements change somewhat when you have to do that and being able to easily combine several “modules” of configuration is an important capability. An all UI config approach makes doing that challenging (not impossible).
I’m not certain that Home Assistant would even allow a use case like this to exit though.
For almost everyone else, I’m on the same page as you. Users are making their own job harder and more miserable by not using the UI for their configs. But for those users, they only have to set up and configure each device once so the little bit of drag caused by clicking through to do it is made up for by the inline documentation and automation.
But f you have to set up that same light 20 times, once for each customer you are supporting, having to click through each time is a burden without even the benefit of the inline docs as after the first one or two they already know everything they need to do and don’t need the docs any more. In a case like this, being able to just copy over a few files you already know work is a significantly better approach.
Hi all,
I’m using OH 3 now and I decided to move to OH 4.
I skipped OH 2 so I moved from OH1 to OH 3 directly.
Also for me it was a big jump because I wrote many lines of code and I integrated many devices, in that case (and I think that I will make the same moving to OH 4) I installed a fresh instance of OH and I used both of them for a while, also to avoid the wife trauma 
I tried also HA just to have a chance, but I prefer OH cause (but It’s a my opinion) HA seems less configurable or configurable with less granularity and I prefer to write code instead of using graphical tools that make the job for you but you don’t have the full control, maybe because I’m too old
To avoid confusion and FUD, there is almost nothing that can be done in the text config files that cannot be done in the UI and there are a number of features that are only available in the UI. I very carefully want to avoid the impression that using managed configs means giving something up or having less control.
I wonder how many people are stuck with OH2.5 and consider hard to upgrade to OH3 or OH4? I was one ot them until I switched to HA. No regrets so far…
I’m sure there are quite a few. But I wonder if it would be any easier for a user of HA to stick to a four year old version of their software and then try to upgrade to the latest version. The longer one waits to upgrade for any software but particularly one that is undergoing very active development, the more work it’s going to be.
I would say it was not easy to upgrade from OH2.5 to OH3.0, in my current setup at least. I wonder what keeps the current OH 2.5 users not to do the upgrade to the next version (not the latest). This would be an interesting and usefull topic.
I don’t know how upgrades work in HA, some software solutions are using rolling upgrades, from the old version to the next, next… until it reach the latest. Maybe it’s the same also for HA. Jumping from OH2.5 to OH4.1 I’m sure that it is a serious challange, knowing how OpenHab keeps the legacy compatibility… :))
I’ve seen the following categories to be the case:
If it’s not broken, don’t touch it until it breaks.
I’m mad that they dropped support for 1.x bindings and refuse to move to the newer equivalents.
I depend on a 1.x binding and there is no newer equivalent.
I shouldn’t have to do any work to upgrade; somehow OH should continue advancing and give me new features and capabilities but nothing I do now should have to change. (I want to have my cake and eat it to).
For category 1, all I can say is what that mostly does is make is so that when it does break, all that work you’ve avoided by not touching it is going to have to be done all at once while everything is broken. But we will do our best here on the forum to help.
For category 2, all I have to say is OH is an all volunteer effort. There was only one person who was maintaining the 1.x compatibility layer and that layer was becoming harder and harder to maintain. He got fed up and was no longer going to maintain it. Calls were made to find someone to volunteer and there were no takers. So the layer had to go. If there’s no maintainer for a complicated piece of code which is adding significant complexity to the rest of OH overall what else could be done? But the decision was not made lightly and there were ample opportunities for someone to step up and keep the support.
For category 3, that’s the reason the Remote openHAB add-on was developed. The developers tried to mitigate all possible problems they could think of. Even today there are still some users running an old 2.5 OH with the Remote OH binding to continue to use a 1.x binding for which there isn’t a 2.x equivalent.
For category 4, I’m sorry but I have no sympathy for you. It’s an unreasonable expectation. But you’re not going to find it better over on HA which, as I read more in their github and on their forums, has almost a contempt for their users when it comes to “non-backward compatible changes”.
And it is very true, that the upgrade from 1.8 to 2.0 was was very hard because all the new concepts of Things, Channels, and Links were introduced (which enabled automatic discovery of devices which was impossible with 1.x) but that was the very first one, it’s bound to be hard.
The upgrade from 2.5 to 3.0 was nearly as difficult primarily because 1.x bindings were dropped and changes that needed to be made to rules because of changes to the underlying Java which the OH project had no control over. There were also a lot of non-user facing changes required as OH dropped Eclipse Smart Home and modernized the build system which limited the amount of attention that could be paid to making the upgrade painless and easy.
But the upgrade from 3.0 to 4.0 was super easy with only a few breaking changes that end users had to deal with and even among those the users who were primarily affected were text file config users as the upgrade tool was able to “fix” the breaking changes automatically in many cases. A number of PRs and issues are in work to make this even easier in the future for end users, possibly even with support for automatically upgrading Things, running old bindings on a new OH core, and stuff like that.
It’s almost as if openHAB as a project is getting better and maturing with each new release.Maybe the developers actually are trying to make upgrades easer and better for the end users.
I’m glad you are happy on HA and I hope you continue to be so.
In truth, it’s no more difficult than upgrading from 2.5 to 3.0 really. Nothing that 4.0 “broke” is relevant to a 2.5 configuration. You’ll have to fix all the same stuff you’d have to do for 3.0 but 4.0 introduces nothing else that would need to be fixed. The breaking changes in 4.0 are changes to the way features introduced in 3.0 work. There is no “legacy compatibility” lost in 4.0.
But I think the overall point of this whole thread is if you have moved to HA because you think HA is better than OH about preserving “legacy compatibility” I suspect you will be sorely disappointed.
I see that you refer to me on category 4. I never said that I was not open to update some things during OH version upgrade, I did tried to figure out what is wrong and how to make them work with the new version. Unfortunately I did not manage to find/fix the compatibility issues so I gave up. I was thinking the same like the title of this topic, invest more time by upgrade/migrate to the newer version of OH or invest time in a brand new hopefully better solution like HA? My decision is pretty clear what it was. If HA is that bad how come it got such a big success? I’m not saying that OH is not good, but it got some problems that are pushing users to look on other directions. Software should be smart, not hard. This include also the SMART home automations hubs. Don’t get me wrong, I enjoyed OpenHab, it was the first love in the home automations area. I still consider that with the right decisions it is going to beautifully evolve. As I was saying also on other topic, I’ll keep an eye on the project and hope for the best.