Comparison to Home Assistant

65

I’ll post my experiences here too :slight_smile:

I asked myself the same question over 4 years ago and tested HA and OH.
In the end, OH convinced me more.
Not only did all devices work with it without having to mess around with the code, it was also open for complicated things.
I started with OH2, completely got to grips with the change to OH3 and now really like OH4.

I even created a video with my opinion and experiences with OH over a year ago.

HA definitely has a much larger community and apparently various manufacturers of smart devices are jumping on the HA bandwagon to label devices as “compatible” with it.
When something new comes out, there is a plugin for HA after a short time.
As a “stupid” buyer, I naturally like this because it seems to work without any problems.
I don’t know how well it works in the meantime. I haven’t looked at HA for a while.

Nevertheless, I have noticed a few things during my time in OH that have made me think about switching to HA from time to time.
HA’s Android app is apparently much more advanced than the OH version.
There are push services even for desktop systems such as Windows to receive notifications directly there.
The connection of e.g. SnapCast is possible, but I think the binding is currently managed by one person if necessary. With HA, this is built in directly.
As far as I know, Mopidy cannot be connected at all.
I also had to deal with Modbus over the summer just to be able to integrate the PV system and the battery in OH. That was a real pain.
The integration of Frigate as a surveillance camera is possible directly in HA, but there is no binding for OH.
Zigbee can only be used via Zigbee2MQTT, the binding is useless for me. Unfortunately, there is no direct integration of Zigbee2MQTT for OH, but there is for HA.
The dashboard could also be a little easier for newcomers, e.g. to customize the colors to their own wishes.
What would be really ingenious would be if there was also an app for LG’s WebOS, for example, so that you could also use OH via the TV. (Yes, the thing has a web browser, but a customized app would somehow be cooler).

For newcomers, I still miss an extended tutorial guide in OH.
After you have selected the necessary bindings at the first start, a window should appear with the slogan “hey, let’s create your first switch together and display the temperature on the dashboard”.
I myself created some tutorial videos in German, which were apparently well received by many people because they only understood the procedure so that OH would work at all.
Since HA has a larger community, there are (automatically) more videos with possible solutions on YouTube.
In my opinion, there is not so much for OH.

The positive things for OH are, for example, the Blockly editor or the somewhat prettier dashboard from OH3 onwards.
However, the most important finding - which has already been mentioned here - is the stability of the application itself.
A smarthome system has to work and not break after the next update.
When I’m not at home, the system has to run and take care of various things. A failure would be really bad.
OH has never really let me down so far, so a big compliment to the developers for stability!
Even if my OH remains cloudless, I can access it from anywhere if necessary - Wireguard takes care of it. (Sorry, my OH is simply not allowed to access the OH cloud)

So what now?
I’ll stick with OH, because it works and the community is ready to help with problems.

3 Likes
66

In what ways?

When you can charge for a service you have more options available to you as a system for things like push notification services.

What would you improve with Getting Started - Introduction | openHAB?

This is in work. The Developer Sidebar is being expanded with little in-place point tutorials along these lines. On a first load of MainUI, the Developer Sidebar will appear (assuming a large enough screen) and you’ll see the tutorials which show you how to do things like that.

5 Likes
67

I’m currently trying out HA just to get an alternative view, my setup allows that if disabling corresponding rules. Im using in OH not many bindings, Zigbee via Zigbee2MQTT (by adding the required channels for devices by hand), icalendar and shelly. So far, i can see following advantages in OH:

  • If getting more advanced, you are required to script very quickly, but have more powerful possibilities
    • Access to historic data is much easier in OH
  • The architecture is much cleaner as there are different types of plugins
    • HA seems only to know integrations, which is quite universal, but somehow also not clear
  • The docs are more clear

On the other hand HA has some advantages:

  • Automations (= rules in OH) can be triggered by a state + time
    • Triggers for rules in OH are only a point in time. To implement something similar, i had to write some code and i’m using it in multiple rules. The rule itself would be much easier when OH had a similar mechanism
  • The android app is a very well integrated into HA, there is no break because there are multiple UIs as in OH (at least i think so)
  • The development pace seems to be much higher
    • my PR to icalendar is now some months old without review, that a little bit frustrating, but it seems not relevant enough, i’m pretty sure i would have to rebase again (!) because of the age
    • in HA you have to review another PR before getting your own merged, maybe that would help, too

I have no long-time experience yet, currently i’m driving both at same time.

One thing i saw here simply not true: HA can also run without internet and completely free. It’s cloud connection is just not free. That’s a little difference. I can run my HA instance the same way like OH beind a reverse proxy. This is neither pro nor con.

1 Like
68

I will throw my experience in too. I have been using both integrated together because each have their strengths. In my opinion, OH is way more customizable, you can pretty much make it do whatever you can code. It is great for complex systems and even if it was a charge I would still prefer it for that aspect. One negative of that is, its not as user friendly for non-coders. OH has made great efforts to improve this and I must say its gotten pretty good but due to HA having such a huge user base (I really don’t understand how it got so popular) it is even more user friendly in certain aspects.

The only reason I even use HA at all is because they have more integrations that work for my needs. For example, the Roku emulation, I use that with Harmony and the Sofabaton remotes. I wish I was a better programmer where I could create a similar binding for OH but I’m still getting there. I use rest to link the 2 systems so I can make each do what I want for an ultimate system.

Lastly, I must say the differences in the community are shocking. OH seems way more personal, way more helpful and it is relatively easy to find info. Compared to HA, the documentation is confusing at times and then when you ask a question people just share the links to the documentation you are asking about even if you have a direct question from it (The FB page is even worse). There’s been times it felt like they actually don’t want their community to grow. It’s very strange.

4 Likes
69

For example, there is an app for smartwatches, there are more functions for the widgets for the desktop and the app is generally more intuitively integrated into the overall system.

I fully understand that. It’s just things that I’ve noticed in the meantime.
An implementation with e.g. ntfy.sh or similar would also be a possibility.
There are many ways to receive push notifications at least for Android. For iOS it is apparently a little more complicated.
Personally, I’m currently using the push-messages via the Signal app.

Then I’m curious to see what that looks like :slight_smile:
Seems to possibly solve my point of criticism.

Something else that occurred to me in the meantime is that it is possible to create users.
But you can’t really manage these users very well.
It would be nice if I had a checkbox for each user with simple read and/or read and write (change) rights, for example.
This would allow you to give some people only limited access to OH.
Admin and user groups is sometimes not enough.

70

I created Threshold Alert and Open Reminder [4.0.0.0;4.9.9.9] for that use case. When configured it will call a rule when and Item remains in a given state for a given amount of time. It has a lot of other bells and whistles (do not distrub periods, initial alerting event, still alerting after a configured time, no longer alerting, repeating the alert if it remains in the alerting state) but that’s the basics of it. I use it to get alerts when a door is open too long, control smart plugs connected to dumb humidifiers, alert when a sensor stops reporting, etc.

Sounds like a good candidate for a library.

It depends on the repo and for add-ons whether there’s an active maintainer for that add-on I think. also, HA has employees, OH doesn’t. You can go faster when you have someone who is paid to do the stuff that a volunteer might not want to do.

Sounds like a good idea to me.

Better and finer grained access controls is something that constantly comes up. There were even two separate full implementations of very fine grained access controls built into OH. But apparently once implemented and these academicians got their papers publised, they lost interest. They never submitted the implementations back to the project. :cry:

There is a PR open right now with a good start at implementing this but I think it’s stalled out.

It’s not an easy problem to solve.

1 Like
71

Someone has started on it and posted in the forum, maybe contact them and ask to help test as that also helps them assign more free time to it if people are asking. From memory you need MQTT for the two to talk.

EDIT:

1 Like
72

Thanks but I have way over 25% of the things migrated to HA. I work with both systems in parallel for the moment, HA and OH. I don’t know how is OH3 and OH4 by starting clean, but about HA I don’t find any dificulties so far. I discovered a lot of information on the web, due to the huge community they have. I love how they manage to integrate certain standard things like Generic Thermostat, few lines in an yaml file and that’s all. Also the integration of Unifi in HA was few clicks away. I know that OH2 is old old old but my migration to HA is huge leap. I tried the remote binding in OH, in the idea to do the dirty fix on my current situation and prolong his life. It listed all the items but nothing worked. I’m sorry but my decision to move forward was to do the change. At the end, I’ll post a github repo with all my OH2 work, maybe it is going to help somebody, it would be sad to just delete them. My OH2, in the current situation, it is working very good, event that it start to fail by connecting to the outside up to date world. I’ll keep one eye on the OH world, as I did on HA until now. Good luck! :slight_smile:

1 Like
73

It is very easy to make the change from V2 to V4 with the only stuff you need to learn is the Semantic Model (fancy way of saying grouping into locations and also grouping items together into a single piece of equipment) and the new UI although you can still completely use basicUI and keep your old sitemaps. The only major hurdle is if any of your bindings are no longer are supported if they were V1 based. Some minor breaking changes to deal with like the date and time in rules was updated as an example but having to update small amounts of code means your not starting from scratch. It would be less work then going to HA.

Since you have made the change and are happy, then I wish you a happy future. Like you have stated, I also like the idea that there is more then 1 opensource project for home automation and want both projects to continue getting better and stronger.

6 Likes
74

Thanks for the suggestion but HA would be the solution for me at this moment. The learning curve is not that bad. Hopefully is going to be more sustainable than OH on the long therm.

2 Likes
75

Hi all,
Here my experience with OH.
I started from OH1 and gradually moved to 3.4.

I am very happy with it but due to my permanent curiosity I also started looking around for other platforms especially for the following reasons:

  1. there is no a real mobile app. the sitemaps are too primitive and old fashion and do not get a serious upgrade since OH2. Considering that we live with our phone in our hands 18 hours a day, a serious app for iOS and android should be part of the roadmap and of the core.

  2. backward compatibility architecture: i have now 3.4 version and didn’t want to move to 4.0 as I don’t see the reason to do it and don’t have the time now (family reasons) to check the breaking changes and correct them. But the bugs of some of the bindings I use have been solved only for version 4, in other words the new version of the bindings do not work in version 3.4. I find this an architectural limitation. (Tapo, ViCare, etc).

  3. talking about V4, I personally don’t see what is the major change that asked for a major release change from 3 to 4.

  4. a roadmap would be very helpful for the community to understand the future of the platform. But I see that in many posts this is a forbidden topic.

76

Well, there’s many users that see this different. Real home automation is that, automation.
The relevance of functionality and look of an app are vastly overrated, you wouldn’t even need any app at all if your home was automated well.
And in the context of this thread, automation is where OH IMHO outperforms HA.

That being said, check out sitemap changes in 4.1:

That’s a common misunderstanding. Major updates don’t mean major new features. They mean
something fundamental changed, but it’s mostly stuff “under the hood” you don’t get to see as users.

You don’t have to be afraid of a 3->4 migration no more than of any other change. There’s even a config migration script to handle most of the stuff. We’re constantly improving OH in various areas, and things including migrations keep constantly getting smoother ever.

Backporting is a lot of work and not worth the effort when you can upgrade instead.
That’s not a limitation, let alone an architectural one. Other software creators incl. HA handle it the same way. Just upgrade to OH4(.1) and you’re set.

Not forbidden but it’s simply that a roadmap cannot exist as we’re no company to dictate what’s to be worked on.
(and frankly, having been employee in big corps to define roadmaps, I can assure they’re not worth believing in anyway so effectively a roadmap wouldn’t provide you with anything of value to make use of).

2 Likes
77

On the mobile app don’t use sitemaps use the UI instead. It’s heaps better. I don’t use sitemaps at all. No need to.

1 Like
78

I use the sitemap in my mobile app too.

I guess, it needs really a lot of effort in porting this to the main UI of openhab.

For my setup I’m a huge fan of using the sitemap to visualize, organize and handle 886 items.

1 Like
79

And hopefully that stays the way it is.
If you want fancy charts and buttons, use MainUI, if you want simple icons, text and numbers (and even charts), use sitemaps.
Both can be displayed in the mobile app, so nothing is missing :+1:

7 Likes
80

What is your definition of “serious”? The Android app, in my experience, is pretty comprehensive with native integration with the OS, Tasker, and supports the three UIs and will send info about the phone to OH.

There is ongoing work to support this but it’s not there yet.

A move to a new version of Java is always going to be the driver to a new version if OH. And these become opportunities for breaking changes, for which there are a lot in OH 4. Most of them though are developer facing (i.e. add-on developers) than use facing. And the new upgrade tool hides all lot of the braking changes from end users too.

I won’t repeat the release notes here but there were many user facing breaking changes too.

It’s not forbidden. It’s just pointless. This is an all volunteer effort. No one can force anyone to sick to any sort of roadmap. Creating one is just going to piss people off when we inevitably fail to stick to it.

While absolutely true, I do think a number of the new features added to OH 4 qualify as major new features or changes/improvements to existing features to qualify.

It depends on what you want or if a “port”. The over all structure and ways of arranging widgets is vastly different between the two. If you want to control every little aspect then it’s going to be a lot of work. If you are happy with the Overview page tabs, it could be very little effort.

81

I agree with you as there is no huge changes like there was with 2 to 3, that’s not to say there are no new features or breaking changes to be aware of. The change was made because you need to upgrade to the latest LTS (long term support) java version. We live in a world where you need to keep all software up to date and all security fixes updated so moving to the latest Java is necessary and the reason for V4. You can not easily change between the V3 and V4 point due to the java change so a major version was used.

Not forbidden, just people are tired of repeating the same answer so may poorly respond. There is no roadmap, we are volunteers that work on what we want to and when we have time. This works both ways, and no one single person can dictate the removal of textual config for example. Currently there are at least three people that were thanked in the V4.1 release notes for working on making new users have an easier time learn openHAB, and this will continue to be improved I’m sure. Usually a developer has a wish on what they want for their own home and then works to implement their wish. If we tried to dictate what people spend their free time on, we would quickly loose volunteers.

Have a great Christmas and enjoy your family time, this is much more important then a stupid home automation project when compared to what really matters in life.

9 Likes
82

I find it quite amusing that HA (that is written in Python) is more qumbersome than openHAB (written in java) wrt writing rules in Python (via habapp).
And I have learned to hate java thru the years…
As I probably have became a grumpy old man, I DO really like configuration in .conf files.
Configuration that ends up in .json/.xml files seems to be like a sick joke to me :wink:
Ah, well, the world is not a perfect place, so I am eating camels daily… :slight_smile:
I do consider running HA as a paralell instance to openHAB for some things…
Just to add; I see no reason to switch away from opemHAB as the main automation framework in the near future!

4 Likes
83

It is completely useless to compare HA and OH in detail, because when two do the same thing, it is not the same thing after all, everyone will use the most suitable automation for their own case.
A few notes / suggestions for OH:

  • migration from OH 2 to 3/4 is not completely painless, it is always necessary to adjust the configuration (Rules, Items, Channels, Things) it can be done in a few hours even with a clean installation and hand made migration of historical data - don’t worry it’s easy, but isn’t piece of cake,
  • from OH3 is not a completely stable solution for GPIO control, which causes reluctance of some users to migrate,
  • system changes from OH 3 to OH4 were carried out continuously step by step, but users were often surprised by the result of the changes, some users stopped updating regularly (for example, some links in Transformations and JS stopped working),
  • The model is great, but its correct setting takes a lot of time,
  • the quality of the documentation has improved,
  • responses to https://community.openhab.org/ have been accelerated
  • the mobile application provides much more extensive functionality,
  • many positive changes in the main UI and Sitemaps,
  • perhaps it is worth mentioning more support from OH for the expansion of integration options:
    Tasmota Documentation - Tasmota (many different Peripherals and Components for various Modules, options for basic automation - own Rule)
    https://docs.openmqttgateway.com/ (many interesting extensions for BLE, RF and others)
    https://homebridge.io/ (2000 potential extensions for OH)
    maybe even a less complicated way to integrate MQTT Things for Beginners
  • I believe that many positive changes will come as in the case of TasmotaPlug - Bindings | openHAB
84

I think it’s worth noting here that the reason that changed before OH 4 was released is so that those migrating from OH 3.4 to 4.0 and were using JS transformations would not have to change anything. This was a change to deliberately avoid a breaking change between 3.4 and 4.0. Unfortunately that meant a breaking change between OH 4 M2 and M3 (IIRC).