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.
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:
On the other hand HA has some advantages:
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.
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.
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 
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.
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. 
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.
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:
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!
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.
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.
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:
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.
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).
talking about V4, I personally don’t see what is the major change that asked for a major release change from 3 to 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.
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).
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.
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.
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 
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.
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.
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 
Ah, well, the world is not a perfect place, so I am eating camels daily…
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!
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:
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).
HA has Google fit integration.
In Openhab i wrote a python script that should be launched in the exact Moment when im on the scale and send over mqtt…
But no idea how to read Blood pressure and Heart rate…
I like much more openhab…
But openhab Is dead… 4.1 and 4.1.1 doesnt add nothing new…
Just maybe some incompatibilty with old bindings.
Example: in Amazon Echo control stopped working the last command feature…
There Is a new binding that cannot be merged… Because some object names (or something similar) are not conform with new openhab standards…
So are these the new features of openhab?
I have 3 setup One Is stuck on openhab 3… And i don’t see any significant differenze…
Except that in openhab 4 for several months Sonoff integration was broken…
Please freezer developement, and develope bindings … Maybe open a donation channel for developing bindings…