I sometimes wish that both systems would take more cues from Homey (Athom). It has a simple user interface, customization options, and is understandable even for non-programmers. For more advanced stuff, you can put together your own solutions using a sort of JavaScript. I’m very happy with it and only use openHAB as a background solution on a PI to control my EnOcean roller shutter motors. Unfortunately, Homey does not support EnOcean.
I can relate to this.
Having said, that starting a “Smarthome OS”-war isn’t helpful in any way, what I’m still missing is a
easy[1] to setup
easy[1] to maintain
easy[1] to configure
solution, which also offers
in-deep ruleset, if needed
“professional grade”[2] application setup, if needed
[1] easy meaning a simple “setup assistant”, which covers 80% of use cases, especially for “simple” needs of users, who just like to “have one of those smarthomes” to switch lights or use simple logics.
IMHO HA is much closer to this, than OH - even after the new UI and some really simple click-rules. you have to find out, how to really configure Bindings and learn differences between things, channels and items. sometimes you have to do that in a really technical way.
[2] on top of that easy entry-level system, you can build rules and logics yourself and can use really powerful solutions tailored exactly to your needs.
IMHO OH here is really leading over HA (and all the other systems I tried). You have to master a steep learning curve, and after that you can master mostly everything. In HA that is really painful (at least for me) to achieve complex rules, which rely on information of different devices and their respective states…
I didn’t find that in any solution yet, which incorporates both “worlds”. So i try to build my use cases with OH, which I’m able to do really closely - and I’m trying to help out others in this forum with their learning curve as my time allows…
to be fair - I also use Node-Red to collect information, which was a pain in the *** to configure via openHAB!
I’m thinking of Web-Hooks, which aren’t capable of using OH’s REST-API, or even the integration of my solar inverter via Modbus. It’s so much easier and more clear in Node-Red as in OH. But yeah, I’m thinking I’m more of a power user as I’d like to be!
I’m an openhab user since 12 years now and I never regretted.
My personal opinion is that the development of openhab is a little bit slower or more conservative. Means the release cycles a slower and sometimes it took more time until something new is getting into the core system.
The benefit is that it is more stable.
But the biggest advantage is the rule system where you have full control about nearly everything. I’m using python to react to events, cron triggers, thing state changes etc.
My assessment, after reading a lot, is that the home assistant is sufficient for simple smart home setups with around 100 items and a handful of technologies. You can also quickly achieve satisfactory results. But if you work with thousands of items and want to implement sophisticated automation rules, you can’t ignore Openhab.
To give an impression about what I’m talking… My Setup has 886 Items, 95 Things and 10.743 lines of python based rules.
Conclusion from my side, Home Assistant is for beginners and simple setups. Openhab is more for experienced users and more complex setups which requires some kind of clean and well structured core system. So if you plan to fully automate your house and go for it during the next 10-20 years, you should definitive start with openhab.
If these are Jython you might want to start looking at starting to slowly migrate to HABApp, JS Scripting, or jRuby (JS Scripting will probably be the most similar to what you are doing now). The upstream Jython library is all but abandonware and it only supports 2.7 which is not years past end of life. Python 3.x support is nowhere in sight. And eventually something is going to break and we here won’t be able to fix it. At that point Jython support will be lost to us.
I keep hoping someone will bring in GraalVM Python to replace Jython but no one, including me, who has the skills to do it has volunteered.
Anyway, because of the tenuous nature of Jython support, you’ll be well off starting the migration early and taking it in your own time rather than all at once when Jython dies suddenly.
I view this a widespread challenge with technology in general.
Things that are designed to be “easy” tend to limit users’ choices, which becomes frustrating when you want to go beyond those limitations.
Things that are designed to “do everything” tend to overwhelm new users with too many choices.
I don’t really think either of HA or OH are beginner-level, because the initial setup work is still much more than the vast majority of consumers want. If I had to tier it:
Beginner/novice = Alexa/Google/Siri/TP-Link/Tuya. Everything works on the WiFi router and smartphone you already have, someone else maintains a cloud server for you, and the automation is very simple.
Intermediate = Insteon/SmartThings (and other proprietary systems). The automation is usually still simple, but the user is broadening their device selection beyond WiFi.
Advanced/Expert = Home Assistant/Homey/MQTT/openHAB/Tasmota. Technologies with steep learning curves that require serious individual effort to set up and maintain.
Note that this is about a user’s desires, not their expertise/capabilities. Lots of very smart people prefer the simpler iPhone experience, and lots of not-so-smart people prefer the complex Android experience. It’s just a question of what they want out of their technology.
From what others have said, it sounds like HA is more on the “Advanced” level and OH is more “Expert”. But they’re both far more powerful/complex than the vast majority of consumers want from home automation (in my opinion).
I’ve sometimes thought that would be a great for openHAB to define levels for different functionality. We wouldn’t prevent users from jumping straight to the expert levels right from the start, but would help inexperienced users to avoid more complex tasks until they feel ready. Kind of like the beginner/intermediate/expert slope ratings at a ski hill. Easier said than done, though.
Oh, I was referring to the modbus binding, which just makes my head explode. In Node-Red it’s much more lucid. And I send the values via mqtt, so openhab can easily catch them and others also. In my case openhab uses Node-Red to consume and steer the solar Inverter and evcc also gets the values via mqtt.
I don’t think, it could get along with GET parameters of my weather station. But Node-Red can. And - you guessed it - ot sends mqtt to OH.
I didn’t find a way to let HA do any of that, also btw…
Thanks for the hint. I will see it as a chance to refactor and simplify my own code I think I will choose JS Scripting, because I want to avoid to be in the same situation like now in >= 5 years. And because the Javascript engine is included in the graalVM, the chances to be on the safe side are pretty good.
I worked pretty hard to do the setup on my current OH, a lot of rules, a lot of things, worked on the gui, but unfortunately the lack of legacy support made my system stuck on the latest version of OH 2. I tried to upgrade to OH3, nothing worked. Rules, Items, all the configuration… My setup is based on MQTT devices that runs ESP Easy on ESP8266, I had also a connection with my Unifi network to check if my family phones are home or not. I manage to conserve the setup using docker containers and I thought that I would continue to use the current configuration for a longer time, unfortunately after my USG-PRO-4 router died, I had to upgrade to UDM-PRO that has integrated controller, guess what, it is not compatible with OH binding that I have on OH2. I tried OH4 in the hope that things have change. Same problems like the moment I tried OH3. I give up, now after 4 years, I migrate things from OH to HA and replicate the OH setup somehow. It’s not easy, because I have to learn from scratch, but I hope it is going to worth moving to HA… as I can see until now, it is more open to the future and got better integrations. I also hope that the future versions of HA are going to be compatible and it is going to have better legacy support.
I agree with your assessment that HA does a better job than OH with legacy support. I have previously raised this as a concern for OH and was told this an edge case and that it was not that big of an issue for the OH user community. I disagree, but it is not something that is highlighted by users as they just move on to HA or something else. With future updates to OH this will become a larger problem IMHO, as more legacy devices are left behind. I have a few bindings that support a large number of my devices, and those bindings were not updated and will not work beyond OH 3.x. My solution was to use the “Remote openHAB Binding” to federate OH3 with OH4. I run my legacy bindings in OH3 Docker and everything else in OH4 Docker, including all of my rules which are extensive. I have seriously looked at HA, and continue to do so, but to replicate my current OH using HA is just not reasonable. This is something you may wish to consider at least as a stop gap. Thoughts on Best Practice for Federating Multiple OH Installations
Could you please tell us a bit more, what you call a legacy device and what bindings you are missing ?
Bindings from the openHAB 3 distribution have been included in openHAB 4 too, there should be no lack.
If you are talking about bindings not released for openHAB 3, ask the author to adopt it for openHAB 4.
Trust me, it’s not something that I like to do. HA is pretty new to me so I take everything from zero. The only experience that I got is that I know what I want to accomplish, basically clone what I have on OH to HA and maybe improve things over time. Migration is going to take months but I’m sure that it is going to worth it. I don’t like to have stuck old software no mater what. It’s going to be crazy, but step by step things are going pretty good with HA so I’m confident that it is going to be a step forward. As for OpenHab, I would like to thank the community for the great experience until OH3, but I don’t see it as a project for the future as things are going…
I’m also glad that somehow thigs are moving forward for OH. The only thing is that for me at the moment is not a solution anymore and I’m sure that I’m not the only one that switched from OH to HA, even than this would take a lot of time to do. Anyway, it would be sad to see that HA would remain the the only one, so good luck OpenHab.
@hmerk, the bindings I am referring to were supported in 2.5.x and not officially migrated to OH3.x. A few users did “unofficial updates” to get them running in in OH 3.x and that was the EOL for these bindings. The bindings I am referring to are ISY/Insteon binding and Panasonic Viera TV. These were highlighted and discussed here
and the primary motivation for starting that thread.
I just think it is unreasonable to expect users to abandon many thousands of dollars worth of equipment/devices just because a binding is not updated. My OH system is heavily automated and complex, moving to another platform would be far more painful then just running multiple dockers with different versions of OH that support the legacy bindings and are federated in way that they provide a seamless system. This works for me, but is clearly not the ideal or best solution for everyone.
All bindings in the official distribution are automatically upgraded with each new openHAB version. The only exception was when we moved from OH2 to OH3, we lost the bindings relying on outdated OH1 architecture. When moving from OH3 to OH4, no binding with OH2 architecture was lost and they were all rebuilt with the last core framework.
So maybe you are talking about unofficial bindings. We can do nothing for that.
That being said, it does not mean that each binding in the official distribution is hardly maintained. We are relying on free contributions for that.
I think I will choose JS Scripting, because I want to avoid to be in the same situation like now in >= 5 years. And because the Javascript engine is included in the graalVM, the chances to be on the safe side are pretty good.