Upgrade or move to Home Assistant?

, ,
21

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.

1 Like
22

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.

7 Likes
23

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 :slight_smile:
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 :slight_smile:

3 Likes
24

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.

1 Like
26

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… :slight_smile:

27

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.

2 Likes
28

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… :))

29

I’ve seen the following categories to be the case:

  1. If it’s not broken, don’t touch it until it breaks.

  2. I’m mad that they dropped support for 1.x bindings and refuse to move to the newer equivalents.

  3. I depend on a 1.x binding and there is no newer equivalent.

  4. 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.

5 Likes
30

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. :slight_smile:

1 Like
31

No, I figured you were a 1 or a 3.

Did you ask for help here on the forum? Even now there are lots of people who would have been more than happy to figure it out and present options to make it work.

Overall I think what irks me the most is OH is being judged based on what it was four-five years ago as if the past almost half decade of work simply never happened. We’ve made no progress over all these years.

Because as a commercial entity they are able to move faster and market better. I wonder how many HA owners know that OH even exists. HA has pretty much become synonymous with “open source home automation” and is almost the only one mentioned in the press.

32

Me, 1 or 3? No way. I had OH 2.5 on an old Ubuntu as the first setup. Than I thought it is not good to run ancient software so I planed to migrate everything on a newer OS and run everything on Docker to exclude problems that could occurred due to software dependencies. Another advantage was that I can run tests in the idea to upgrade OH to the newest version possible. Last time, I was running OH2.5 and OH4.0 in the same time (not from the same config folders, off course). Unfortunately with no success.

Each time when I did asked for some help on the forum, you where the only person that answered. Thank you for that. Sorry, but I don’t see where those a lot of people are… I know, I know OH is based on volunteers.

Why OH is judged based on what was four-five years ago? Probably because those people are stuck with software that old? Lol

About HA, I have no problem if there is a commercial entity around the project. My opinion is that those have better probability on long therm existence. I know some good projects that died in the same time when the enthusiasm of the developers died for some reason.

33

ehhh… I don’t know about that. More often when a tech dies it’s because it wasn’t making a profit and the commercial sponsors dump it

34

Well,

[Home Assistant] is the world’s largest free and open-source smart home platform, powering 1 million households globally. It’s built on the principle that a smart home should serve its users, not big tech companies, and prioritizes privacy and local control. Powered by a worldwide community of open-source developers, it was ranked the second most active open-source project in the world in 2023 by GitHub.

[Nabu Casa] was founded to ensure that the development of Home Assistant would remain sustainable as it kept growing. We now employ more than 30 contributors from all over the world to make sure they have the financial freedom to focus on Home Assistant and other open-source projects that help drive the Open Home vision.

Nabu Casa is profitable, has no external investors, and our only funding comes from people subscribing to Home Assistant Cloud and buying Home Assistant hardware. That means the only stakeholders we have to concern ourselves with are our employees and our users.

Our [Open Home vision]defines the values that we put at the heart of every decision we make. It’s woven into our architecture, licensing, community, and everything else. The Open Home vision is about privacy, choice, and sustainability.

35

Technologies die when there aren’t enough people using them and/or no one wants to put further effort into them. Doesn’t matter whether they’re commercial or not.

I perceive that people often make the same arguments for preferring commercial or open-source software, and usually out of fear of the other. They’ll cite a vendor that retired a product line when it wasn’t profitable, or an abandoned Github project that was run by a handful of developers who moved on. In both cases it’s simply that the people in charge lost interest, regardless of the motivations.

1 Like
36

Let’s be clear here. No one is taking shots at Home Assistant for how they operate. It’s just factual that the model they use enables them to operate differently from us. I don’t think one is better than the other. They’re just different.

2 Likes
37

Your statement made me to look for this video link: simple made easy. Its something which was referred to me by colleague who got into FP. One of first quotes within this talk is:

Simplicity is prerequisite for reliability
(Edsger W. Dijkstra)

Can we say that openHAB core is simple? I don’t think it is, it does several things and, even if it operates on semi-trivial concepts, it builds fairly complex infrastructure around it. It was mentioned already several times above that HA is simpler and more constrained in some areas. I believe this is semi objective measure. To me it seems to be often winning argument, cause moving from complex system to simpler one is always easier, because someone exercising this, already got experience from more complicated solution. As mentioned above, some of our community members attempted to make OH->HA transition and refused to do so due to simplifications HA imposed on them. Some other people, like you made transition, acknowledged simplified concepts, and are happy with it.

We need to keep in mind that while “simple” remains objective, the “easy” part remains subjective. What is easy to me, doesn’t have to be easy for someone else, but what’s simple for one, should be simple for others too.
If we look closer at how commercial software projects are being made, very often they will consist of people with different backgrounds who, in order to deliver, will seek for simplicity even to communicate. I don’t know how HA is being developed internally. On open source project side they still seem to have BFDL model, just like OH still do, but it might be counter balanced by commercial interest.
I suspect, that OH might be missing this particular edge, making it fine system for people who adopted it before, who know how to run/modify/adjust it, yet making new comers a bit hostile.

38

HA is good and is a success, it is just not right currently for me. I hope it improves and becomes better, as I do not want just 1 or even 2 software to choose from. I am happy that they are moving towards getting rid of older integrations which only work via textual, this is one of two main reasons for me. OpenHAB had this issue with V1 bindings, and now HA has to deal with the same problem/ technical debt. I am interested in hearing what people think are OH’s problems if done in a nice way of course :slight_smile: What is it that makes some people prefer to move over upgrading? Did they try the newer version and not like it, if so why?

Totally agree with this. Its completely understandable that people will use this time to trial HA and it is done very well. The first hour experience of using the software has been miles ahead of OH for many years now, so the work being done on this area, I am really thankful for and probably wont get seen until the next stable release due to improvements still getting done. After the first hour is up, both platforms have the same hurdles and challenges, but a lot of people make up their minds based on a first impression. Most people leave and never post why as they simply do not want to argue their choice.

3 Likes
39

I agree here.

velbus thermostats are an excellent example of why a well designed Items template file is so much quicker.

Most installations have at least 5, some well over 30 thermostats.
Having to create the correct groups and multiple items for each Thing would be painful in the UI

But a quick find and replace of the Thing ID and room names in a text editor means systems can be online in a matter of minutes.

Because my (duplicate) Items are text files, I found minimal issues migrating, once I knew what the changes needed to be, the “find and replace, across all files in a folder” feature of Notepad++ made light work of the process.

40

Migration from 2x to anything up is quite easy.

  1. spin another instance in your environment (vm or anything)
  2. move over config folder
  3. see the logs what is complaining about what
  4. fix it, adjust it as you go

from my expertise not EVERYTHING will be broken, good amount of things will just works. Which will not, you will quickly figure out.

  1. When second instance is running smoothly, switch over
  2. do not remove your old one for couple of weeks

it’s quite simple

btw: once per year I just spin HA to see what’s what. Man I cannot say how much I hate UI only configuration!!! …
so OH is far more better (at least for me) as I dont want everything to be automatically discovered, assigned and so on. I want my manual text-config to control whatever I want and how I want it.

dear OH members, please do not ever drop text-based configs. That’s what this makes so great :slight_smile:

6 Likes
41

There are no plans to do so, and I guess most maintainers use much file-based configuration.
(I personally for example use a mix of UI-based and file-based config, where Things are UI-based and Items and Sitemaps are file-based.)

As you can see with the new YAML based configuration file for custom semantic tags, the trend is I think going to YAML so there might be support to define Items etc in YAML in future releases.

1 Like