What do people think of the video? Who’s looking forward to the next release?
4 Likes
Ignoring your title - I have to say that I like the video. While he skipping text based configuration & automation (my preferred way to interact with openHAB), he has a point when he points out that it is confusing that openHAB has many different UIs with different feature sets - especially for beginners.
Never having used Home Assistant, this video was a nice insight. Without a well founded opinion on my own, the consents in the openHAB forum seems to be that Home Assistant is easier on beginners and people without an software developer background while openHAB might be more stable and has more options if you are willing to invest time and effort.
Please stay tuned for the release of openHAB 3.0.
Some of the “issues” mentioned in the video are addressed and solved:
- User/Admin role in MainUI
- First time setup assistent
- Config editing on mobile devices via UI
just to name some new features …
If you have a spare server available, you can try the SNAPSHOT version
1 Like
Hmm, the video was fine in the beginning… we all know OH has a steepish learning curve and the critics on confusing UIs is absolutely valid of course but as @hmerk already mentioned this is being addressed in OH3.
However, after the mobile app part , the video IMHO fell completely short.
He’s showing habmin rules which haven’t been maintained since 1.X, and he doesn’t even mention text programming. The automation comparison was missing for the most part.
And to rate HA more stable than OH is… well, kind of a bad joke to tell someone who just spent hours on reviewing some other contributor’s code. Python has no strict type checking and I don’t think HA even has that review process.
And quantity/frequency of releases and posts doesn’t mean quality, does it.
7 Likes
The following is my personal opinion of this topic. I moved from Home Assistant to openHAB a little over a year ago. I watched the video up until his conclusion section.
The first goal of any system should be stability. If this person ran HA for over a year, following all releases, with no stability issues, he is in the minority. In my experience, you want to wait until tat least the second patch release before trying any new release. Even then, the developers appear"sloppy" Recently, I decided to check out their new Z-Wave2MQTT functionality written by one of their major paid developers. I happened to try just after an infrequent new release. I had to work around some bugs to even get it to function.
I moved to OH relying on the truthfulness of Kai’s roadmap posting in March 2019. He said OH2 was moving forward while development started concurrently on OH3. That did not happen. IMHO one reason for OH stability was the 3 tier release method. That was abandoned after 2.5 was released.
Personally, I hope somebody forks OH and improves on it. I expect OH3 to mainly move away from ESH and fix the UI issues mentioned.
I really miss the HA ease & flexibility of community addons. OH insists all addons be part of the distribution with only a manual approach to installing anything else. HA has an approved (moderated) community addon repo in addition to permitting anybody to use the UI to add functionality.
HA has built-in, customizable security. OH 3 is supposed to add some very basic security.
For me, ideally I would like to see a fork of OH including more flexible, user-centric options.
2 Likes
It didn’t ? Core was frozen yes but binding development continued so not sure what else you expected following his announcement.
There’s still the (ESH) marketplace and technically, you can drop in any new binding. Did that e.g. for HTTPv2. That might not be drag’n’drop targeting unexperienced users but it’s available, isn’t it.
That’s what OH3 does, but then why fork (again) ? OH3 effectively is a fork of the core.
1 Like
I expected OH3 & OH2.5 to be developed concurrently as he stated. Instead they waited until 2.5 was released & then started on OH3. That did not happen & the users were not informed any differently. At least that was my understanding.
It is not easily accessible from the UI and goees against the direction of breaking free from ESH.
From my discussions with Kai, the main decision making developers are not as user focused as I believe is necessary. That is my personal opinion though.
1 Like
Well I don’t remember the exact words of the original statement but I don’t think he meant to say what you understood. Regarding addons, he kept his word. Regarding core, development ressources were shifted to OH3 and focus on the major issues with OH2 (UI join/replacement, security) which is quite targeting main needs, isn’t it ?
Any parallel development would have been a waste of (scarce) developer ressources.
It remains to work for OH2. I don’t know the status but as @hmerk states a replacement for this is on the roadmap, too.
The first snapshot has just become available. Check it out to have a first hand update instead of speculations. It’s a promising start:
1 Like
Then your expectation was wrong or based on some misunderstandings. If you read back several official posts, there had been 2 major things to be solved in 2019.
- Reintegration of ESH codebase
- Moving to a new build system.
These two tasks unfortunately took al very long time, which lead to the final 2.5 release in December 2019. I am not quite shure, when development on 3.0 core started, but it did not make sense before the above mentioned tasks had been finished and a stable system was on the shelf.
So under the bottom line, noboday was waiting to start 3.0 development, all core contributors had a lot to do in 2019 and they still have nowadays.
AFAIK, there have been discussions around how to create a replacement for the ESH marketplace, but there is nor solution yet. So yes, this is on the roadmap too.
Please check the new UI concept introduced with openHAB 3.0. This is user focused and especially addresses new users and non techies.
1 Like
OH 2.5.0 was released broken for some new users due to an issue ignored since Milestone2. It almost did not get fixed in 2.5.1 because Kai thought it would need a core change. They found another way to work around the issue.
I am keeping my eyes open. I hope to look at OH3 when I get some spare time.
Just a few first impressions.
I’m not sure his comparison between OH and HA is fair. He chose the worst case for OH and what appears to be the best case for HA. Only a couple of bindings require the user to create and configure Channels manually. The majority of bindings do not even require the manual creation of Things.
The UI issue should be straightened out in OH 3. It will be possible (and probably the recommended approach) to use just the replacement for PaperUI for everything. BasicUI and HABPanel will of course still be there. How you log in will determine whether or not admin based stuff is presented or not so there will be just the one UI for both admin and for the end users.
Automations will also be supported “out-of-the-box” on the PaperUI replacement. The whole discussion about HABMin is a little misplaced but understandable. But it will be gone in OH 3 too.
I’m not sure where he got the 2004 binding number. That seems way high. Also, I’ve been told that the comparison between HA and OH bindings isn’t one-to-one as OH encourages fewer more comprehensive add-ons and HA encourages smaller and more targeted add-ons.
There was a huge cut in the discussion of automations. Not sure what was lost there. But it is well known that PaperUI’s rules UI was never completed and full of bugs so the comparison there is never going to show OH coming out ahead. But from what I’ve seen, the replacement UI is looking really good.
I don’t think giving the stability rating to HA was fair since it was just based on the number of posts. As we are all aware, people seem much more likely to reply to a two-year-old post here than to start a new thread. Also, “everythings broken with the last release” is going to result in more posts so the pure post count isn’t a good measure for reliability.
Over all, I think the review suffers from the same thing that all such reviews tend to suffer from: familiarity is confused with usability. The product that we are familiar with is always going to seem easier to use. His lack of familiarity with openHAB also lead him down some paths that really don’t apply to openHAB 2.5, though many new users also fall into that same path.
He did a good job but the scores should have been closer. He does make some good points but I think most of them are being actively addresses or are on the roadmap to address in OH 3.
5 Likes
True, but the HA equivalent of Items are created automatically.too.
Newbie here. I use a QNAP NAS to run Plex and OH. I refuse to use docker, my NAS supports them but it becomes unstable after some time.
I’ve tried both HA and OH, packages for both can be found in qnapclub. I’ve run both HA and OH in parallel during some time until HA releases ceased to work in QNAP. So my only option now is OH.
HA’s UI is nicer and more powerfull than OH, but when advanced functions were needed I’ve found OH easier than YAML, so probably I would have stayed with OH anyway.
I think that sums up my findings nicely.
Openhab 2 has the majority of bindings with discovery and all the features needed for Openhab 3 to streak ahead. HA is the opposite the bindings are more like V1 versions and are only text based setup, no discovery and often poorly documented. They only moved to a V2 style binding a year or two ago and of the 2000 they claim they have, it’s probably only 200 of them are V2 style.
HA on the other hand compared to V2 does auto item and sitemap generation to give you a working setup much faster. Time has been spent in the UI and not on getting the bindings up to speed.
It’s a case of first impressions last and most people don’t test past a few hours of effort trialling the basics. The areas that Openhab excels in does not get seen if they don’t test both for multiple hours to days.
I’m looking forward to V3 and what it brings.
5 Likes
Well, being on this forum, most people here would have at least a slight bias for OH.
As mentioned before, stability is key for home automation. In my situation it’s not different (WAF).
I started out with OH1, then OH2. After that I tried HA for a while. While on HA the untested updates drove me crazy, rendering the whole system unpredictable and unreliable.
I moved back to OH2 and am currently very happy with it, despite the somewhat messy UI and inconsistent configuration issues. Absolutely love jsr223 (233?) and looking forward to OH3.
I believe the bottom line to be that home automation is not mature, But OH being one of the most stable and mature players in it.
My 2cts.
3 Likes
I’ve been using OH for 3 1/2 years now. It does have a bit of a learning curve, but once you get it, you got it. I tried HA for about 3 months earlier this year. It was simple to setup, but I think his comparison of automations was a bit unfair. I’ve always used rules with OH. I think you can get much finer grained control using rules. I have not tried the Rule Builder yet. Here is one use case I feel HA fell down on. It may have been my lack of understanding of the HA platform, but here goes:
I had a motion sensor for an area of the basement that would turn on a light when motion was detected in that area and turn it off when motion stopped. There was also a smart switch that could turn the light on/off. Now if the switch is used to turn the light on and then motion is detected in the area, the light would turn off when motion stopped in spite of the fact that the switch was pressed. This is not what I wanted. In OH, this is a simple issue to solve. Just use an Item as a flag in the associated rule when the switch is engaged, and check the flag in the the motion sensor’s ‘off’ rule. Maybe 3 lines of code altogether. I asked how to address this the HA forums.
How to keep a motion controlled light on
The answers were probably solid, quality answers, but really? Both solutions seemed overly complicated for such a simple problem. As a programmer by trade, I have a pretty basic principle when solving a problem:
"Simple problems should not require complicated solutions. If they do, then either you underestimated the problem, or you over thought the solution".
Three lines of code in OH:
- An item definition
- postUpdate(ON) to it when the switch is pressed ON
- Check its state when the motion sensor stops detecting motion
- postUpdate(OFF) when the switch’s OFF button is pressed.
OK, so four lines a forth actually This and a couple of other things caused me to drop it altogether use my existing OH installation to control my basement. The basement was to be my test bed for HA.
I’ve not tried using OH’s automations yet, I’ll get around to it at some point. But writing rules is quite intuitive for me. That’s not the same for everyone, I’m sure.
It’s a thoughtful attempt to provide an unbiased, accurate comparison that, like many similar attempts, demonstrates the challenge of achieving it.
Although I used openHAB for only 6 months, and nearly 2 years ago, I was still able to detect a few things in the video that made me question why that particular aspect was compared (because it’s either stale or the wrong thing to compare). I’m sure experienced openHAB users detected the same things and much more. In addition, having used Home Assistant for nearly 2 years, I also heard things about it that were either over or undersold.
My own experience, anecdotal as it may be, is that I have had no stability issues with Home Assistant’s core functionality nor with the integrations I use (and I’ve gone through at least 20 releases in the past ~2 years). However, I do recognize that some integrations (that I don’t use) have proven to be a headache. As a result, the tendency is to characterize all of Home Assistant to be ‘unstable’. All this to say that instability is case-specific.
The author indicated that there’s a major release of Home Assistant every 3 weeks. If you understand version numbers to be:
major.minor.patch
then there has never been a major release of Home Assistant, only minor and patch releases (current version is 0.114.4).
Effectively, it’s still in beta and every three weeks brings a boatload of new functionality that may include Breaking Changes, notably for its integrations (Breaking Change = Evolution of functionality that is not backwards compatible). You can see that for yourself here where most PR’s tagged with ‘breaking change’ apply to integrations.
For most other software, this kind of behavior is reserved for major releases, but in this case the roles of major and minor are redefined. Before you upgrade to the next minor release, it’s crucial to review the release notes. Blindly upgrading to the next minor release can lead to an unplanned evening’s worth of research as to why your system is now “misbehaving”.
The only comment about the scoring is that it represents one person’s subjective perspective and is not based on any objective scoring criteria. Frankly, I think the result ought to have been closer to a tie.
I fully endorse the author’s suggestion that people should try both and choose whichever suits them best. Although I started with openHAB, Home Assistant proved to be better fit for me. Others started with Home Assistant and switched to openHAB. It’s good to have choices; find out what’s best for you.
6 Likes
…and no-one mention the excellent Z-Wave implemention OH have…
No fiddeling around with xml files that users of other sytems seems to do reguarly.
Next up is the zigbee binding. Mybe it do not support so many devices as the others, but those that works just works.
If I should sum up OH: Programability and stability.
The learning curve to get into OH is steep,
but there is a difference between beginer friendliness and user friendliness 
1 Like
That is a main reason I moved. HA, a year ago used an old Python fork of openzwave that did not have good support for US devices. As thanks, I spent 4 months auditing our Z-Wave device database. I recently helped with the scripts for the new database server home.
A few months ago I took another look because openzwave is introducing z-wave2mqtt. Apparently, HA again decided to fork it. I tried shortly after an HA release of that. I had to work around bugs in the release code to get any functionality. 
That for was written my one of their main, paid developers.
It is a community maintained database. Any device not currently in it can be added, assuming the vendor adheres to Z-Wave standards. Some vendors seem to ignore that.
1 Like
Oh, I was thinking about Zigbee for this one.
It is coming along just as strong as z-wave 
1 Like