Migrating from Openhab 3.0 to Home Assistant

1

After many years of using openhab from V1 thru to V3 I made the very hard decision to move to Home Assistant. I had tried HA a few times but found it quite a learning curve and stayed with OpenHab.

However after the upgrade to V3 I just found that each upgrade was getting more difficult to deal with as it kept breaking and I was reverting back to previous releases. (Note I was on stable release).

I did struggle to with the V3 interface for a while and never really spent time working out the dashboards (my own fault there). The frist straw that broke the back was the upgrade in Zwave that needed a few updates to allow various parameters to be returned to the correct values.

The final straw however was the last update the broke the node-red integration and required an upgrade to the new Open Hab 3 nodes (which also needed the latest version of Node Red - my bad on the issue there on not finding the issue I was out of date). It did however require me to update all my node red nodes for open hab and that was abit of bridge to far given most of my automations are in Node Red.

Then it came down could I learn anough about home assistant vs openhab and after it did take time as has a different approach. But once I learnt how it works with node red I was set and even now while I havd not coverted fully over I have use both.

Also if any read from the openhab main team, there was also the huge transition to javascript which I program in, but there were so many ways to do it and none really worked that well. The split in ways to make this work was terrible. then also the split in python my language of choice and and it was awful. I could not make any thing work.

I could chat about the communtiy and on that OpenHab wins as it is very friendly and I’ve been part of it for many years. I do wish all the community well and hope maybe Openhab V4 will resolve the lanissues on why I left. It is an amazing platform but does need some clear direction on the scripting. Maybe you will find the language to program in and go forward.

Please know all this is not a sledge against open hab. It has run my home for many years now, but i do think it needs to find itself again with regards to scripting and user interface. it just got to complex to work out.

1 Like
2

I am not happy too, that Python (Jython) is left behind, as this is a much better working solution.
@5iver was maintaining the Jython integration but vanished from the forum and nobody is stepping in.
I migrated all my rules from DSL to Jython and am delighted with how it works (I’m still on 3.2.0).
Alternatively, I am now looking at the HabApp solution, which would be a Python 3 solution.

I just made a glance at the Home Assistant, as it seems they have some YAML-based scripting. This is definitely something I never go for.

3 Likes
3

I just want to provide some background on Jython.

First of all, it depends on the upstream Jyhton project. That upstream project appears to be all but abandoned with only a couple contributors continuing. The only released version of Jython is based on Python 2.7 which has been end-of-life since 2020. There is still no Python 3.x version and the current rate of development makes that unlikely to happen any time soon.

Despite this, the Jython add-on is still a part of OH and it is still maintained to at least keep it running and compatible with OH. However, the Helper Libraries repo was never made a part of the openHAB project. @5iver was the only maintainer there and was the only one who had commit authority. When he disappeared (and he truly did disappear from the Internet, at east under that username) there was nothing we could really do.

The work he did to make the Helper Library an add-on wasn’t ever published anywhere that I could find so that appears to be lost.

But it’s not true that no one has stepped in. @CrazyIvan359 forked the repo and did a whole lot of work to make it work with OH 3. GitHub - CrazyIvan359/openhab-helper-libraries: JSR223-Jython scripts and modules for use with openHAB and I believe that it is now at parity with what was there in 2.5. The work that was done to make the helper library an add-on was lost but if someone really wanted to they could probably recreate it somehow. I spent some time trying to figure it out myself but didn’t get very far.

But there hasn’t been much work since then because there isn’t much work to do. There have been no updates to the core Jython library. The add-on remains compatible with OH 3 as does the Helper Library. I don’t think there have been any new features added to OH that would require a change to the library.

But Jython support is on thin ice given the tenuous nature of the upstream project. There is also still hesitation to make the Helper Library a part of the official repo. Ideally, at some point, someone will volunteer to perhaps bring in GraalVM Python which is actively maintained upstream and which does support Python 3. But until that happens, there isn’t much to do with the Jython add-on and Help Library.

@David_deMarco all I can say is good luck and I hope you find what you are looking for in HA.

I’m not sure I understand this part. There really hasn’t be a transition to JavaScript at all. JavaScript is available sure but there hasn’t been any sort of transition to it. There will never be a transition to any language really. Maybe the confusion had to do with the fact that there is the legacy ECMAScript 5.1 and a separately installable JS Scripting add-on that brings in ECMAScript 11 and a helper library to make interaction with OH pure JS instead of messing with a bunch of Java Objects.

But if one were to identify a default rules language even today, it would be Rules DSL, same as it always was. So I’m not sure where this impression came from.

4

I’ll start by wishing @David_deMarco well. I’m a strong believer that there’s no reason to see competition between open-source home-automation platforms, because we aren’t for-profit companies concerned about market share and balance sheets. People should just choose what’s going to work best for them at the time

I’m happy to plug along in RulesDSL, but that’s largely due to the fact that I’m not a programmer and have no strong attachment to any scripting languages. When I started using OH2, there was no reason for me to learn anything other than RulesDSL. But I can see why others have introduced alternatives that they prefer.

That’s the double-edged sword of openHAB (and similar projects). The power and flexibility comes from being able to do anything you want, but that freedom typically leads to added complexity and confusion as people go in different directions while doing anything they want.

This makes it very difficult for new users to figure out “what’s best”, because they’re overwhelmed by choices. Life is often easier when someone says, “this is what you can do, and there’s no other way to do it.” Pick a direction and move forward.

Incidentally, I think this is why a lot of people prefer iOS over Android. Like Steve Jobs and his turtleneck-and-jeans ensemble, it enables you to focus on things that are more important to you. I use Android devices because I like the flexibility, but it can get exhausting trying to remember the different ways to do things across different devices and versions.

I also appreciate that Apple made some poor usability decisions long ago, and has stuck with them rather than forcing change on users who’ve grown accustomed to them. Google doesn’t get that.

Anyway, I hope Home Assistant serves up what you need, @David_deMarco. If you find anything in particular about HA’s philosophy that you think could benefit openHAB, I’d personally be interested in hearing about it. You’re always welcome here.

2 Likes
5

I’m not in any way trying to persuade you from not moving to HA, but my 2 main reasons for moving from HA to openHAB were:

  1. stability (or rather the lack of it)

    HA has an impressive release cadence but it comes with costs:

    a. every release which at the time (don’t know if it’s still the case) was every 2 weeks required some level of massaging your config/install as they will happily introduce breaking changes, deprecate things with little to no warning and so on.
    b. if you instead hold off on the releases and say “well, I’m just going to update every 3 months instead”, you will be left with a sizable chunk of work to get everything going.

  2. text files are no longer first-class citizens

    Many of their bindings will no longer support configuration via text files but instead require you to use the UI. Having to click around is bad for reproducibility and ironically automation.

Admittedly, this was a few years ago and good for them if they have since changed things.

My migration was made relatively easy by the fact that I had all resources defined outside the home automation system so I could simply generate a second set for openHAB while HA kept doing it’s thing.

6

If you were happy with Jython then you’ll definitely go crazy for HABApp.
Creating rules with it is just so much better in every way.

They have the AppDaemon application which is the HABApp equivalent to openHAB (except it’s a first class citizen to HomeAssistant).
When I tried HomeAssistant I took some inspiration from it and created HABApp so it makes many things different and/or better than AppDaemon.
Ironically I switched back to openHAB because of the better Z-Wave support and now HA has the better and more up to date implementation.

We’ll see how long it stays that way with openHAB. With concern I’ve observed that text files are more and more neglected and/or ignored by the active maintainers. Let’s just hope someone who likes to uses them steps up and helps out with development.

2 Likes
7

Mainui is sadly not textual/file based. I’m glad basic UI is still supported

8

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.