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.
No, if you are talking about legacy bindings, they have been openHAB 1.x Bindings, running in openHAB 2.x with the „legacy-layer“.
Plain 2.x Bindings have been migrated to the next major versions.
You may be right. That is beyond my expertise as I only started to use OH at v2.2. From a user perspective it appears as though they 2.x bindings and are listed as such Add-ons | openHAB
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.