OH2 vs OH1 stability. OH2 sucks!

Well, 2.* has continued to suck. Stopped talking to the InsteonPLM again yesterday but at least kept running. Tried ‘logout’ and it would NOT die. Had to kill -9 and restart OH which picked the PLM right up and was working again fine. Still BS. 1.* could run for months and 2.* will barely run for days.

I’m not going back to OH1 at the moment, but i have been playing with Home Assistant this week and have been surprised with the discovery of various devices off the bat before I even began configurations. Still learning configs. It may be a solution to start pulling together things I have wrestled with OH2 to accomplish and I’m now working on just tying both together via MQTT. Kind of defeats the intent of a singular home automation bus “HAB”, but might be the best workaround for now until I map a future for my home systems.

I had high hopes for OH2 and perhaps that was my mistake. After all, its a free opensource project. Again, I really do appreciate all that I have gained along the way and will continue to keep abreast and work on solving my various issues within OH. Thank you to all that keep working to make this project as functional and user friendly as possible.

I think you make some good points with mysterious configurations reappearing, http binding errors, database config mysteries, etc. The debugging has definitely increased while stability and functionality has decreased overall. Not a good sign of health from a layman’s point of view here. Really the only reason I’m still trying is because i need omnilink binding for my HAI omnipro II, options limited there.

Sorry about your issues.
OH2 introduced a couple of fundamental changes such as to build on top of Karaf and Eclipse Smarthome with its thing concept. The price to pay for now is instability. The interim phase is frustrating and can turn out to be very long.
We need ESH and Karaf to stabilize in a literal sense (no more crashes) and as an API (no more breaking changes).
And there’s still bugs to be found in there, particularly those to show up on startup (bad caching, circular dependencies and 100% CPU usage in some hard-to-determine cases).

But as another veteran IT pro, I’ve encountered a scheme like this on a number of occasions in software from reputated vendors that you do pay a lot for in SW and support (and of course you cannot expect any Open Source project to provide the same level of professional maintenance to ensure backwards compatibility, particularly in this fast moving space). And I’m still convinced that these strategic decisions do make sense in the long run.

Don’t get me wrong. As an end user, I too, had a very hard time moving my working 1.8 based house to OH2.
Had to figure out how to distribute the config and fully understand the dependencies. Needed to rewrite all of my (numerous) rules. Spent a whole year migrating my house forth and back from OH1 to OH2 multiple times just to encounter another severe issue that I couldn’t resolve quickly (a device or rule to not work any more). Kept running around the house to ex- and reinclude many of my devices. My wife refused to talk to me at times. Found myself stuck in the situation where OH2 did run, but I had to shutdown it every time I needed to reconfigure my (zwave) devices because the 2.X based UI (habmin) didn’t work with the 1.x binding.

Then again, let’s stay fair: it just happens to people to migrate from OH1 to OH2. And it’s (almost) always the binding(s) to cause trouble, not OH2 as a whole. It does not apply to people to start with OH2. It does not apply when you use the 2.X bindings. It just happens because of issues with specific tech you’re using in your setup.

Cold comfort, I know, but thing is, you need to get engaged: you need to methodically analyse and track the issues you encounter, and post or open Github issues for them.
@kai, @chris and other core developers are working truely hard and in a very responsive manner to fix issues and even to resolve and explain real-world setup problems, but if you don’t tell them, they have no chance to help.

And the reason for this post of mine is good news: the end is near ! The end of frustrating days, that is :wink:

Starting this morning, I finally do have my all-OH2 house setup working.
Admitted, it’s bleeding edge (snapshot #1030 and the development version of the zwave binding), but

Don’t give up!

1 Like

What end is near? Why the vague reference?
I moved to the 2017/9/6 snaphots and PaperUI is broken as well as Habmin (PaperUI Items link is missing, Habmin deletes items when you unlink them) moving back to the 2017/8/22

Based upon enough general research and communication in IRC the primary issue is InsteonPLM in 2.. It is HORRIBLY UNSTABLE. Would lead one to thing it was the PLM if they were only using OH2. 1. could runs for months easily. Even then I rarely ever had a crash. More likely added, modified, or updated something requiring a reboot.

Ok, so your problem is specific to the tech you use (Insteon and PLM mode), i.e. the problem is in the binding code, and if you did run OH2 without Insteon binding, it would likely turn out to be as stable as OH1.
I have no idea how Insteon works or looks like and as it’s tech that’s only popular in the U.S. (UK, too?), probably neither of the core developers do.
So it’s unlikely that it’ll work out “all by itself” without the help of Insteon users like you just because there’s so many more people to experience the same problems (then there’s also many more to help identify the cause, usually resulting in a quick fix once identified).
Did you ever raise a Github issue or talk to the binding contributor (Bernd Pfrommer? not sure) ?

To avoid any discussion with @notanatheist on the religious dimension of this statement :wink:
Seriously, reread my statement, there wasn’t anything vague in there: the end of frustrating days is near because snapshot #1030 works fine.

That’s a new issue, and it seems to be specific to items configured via UI. Now since all OH1 users were used to configure items via file, most stayed with that method when moving to OH2.
So just like @notanatheist’s Insteon problems, it’s hitting a very limited number of users only (and btw, stuff like that to show up is to be expected from a “snapshot” version, isn’t it?) and it’s not fair to attribute that to OH2 as a whole.

According to this, that issue was introduced by the underlying framework (i.e. not OH(2) itself), affirming my introductory explanation three posts up.
Oh, and it seems there’s already a fix, so check out build #1034.

I would have written that in capital letters! If you want a stable system, use a stable release!

quote: “I would have written that in capital letters! If you want a stable system, use a stable release!”

But 1.* doesn’t work with new Java…

Besides that obvious answer, if I chose NOT to use the InsteonPLM binding I have 75% less reason to use OpenHAB at all. My switches, lights, rules are almost all entirely Insteon.

To use the “stable” OH1 version would mean to use old Java, too. Install the Java version that was current when OH1 was still under development and you’re fine.

If the developers did think like that, too, and chose to just support what they need OH to work with, they would have 100% less reason to provide you with any Insteon support at all.
Community software doesn’t work without contributions, and that’s not just coding but it’s testing, tutorials, providing help to users etc. … in short: stop complaining and start getting engaged. Enable tracing and provide a useful bug report that helps in hunting down the problem.


Java 7 can no longer be downloaded without creating an account. I tried. I really really wanted to stay on 1.. I’m really bummed there wasn’t like a 1.9 release with newer Java supported. Outright letting 1. die is a huge bummer.

And FWIW, I’ve provided quite a fair bit of help to new users through the unofficial IRC channel while still expressing my distaste for 2.. I’ve even helped people get things working in 2. but more so in 1.*. I’ve even converted others to OH and done a presentation to our local Linux Users Group and even uploaded the overwhelmingly positive talk I gave to Youtube!

You’re the first and (to my knowledge) only one to claim 1.X isn’t working with current Java, and it just isn’t true. I’ve been using it with Java build 1.8.0u131 (like you) and even 1.8.0u144.
The point is: Your specific setup doesn’t work with it, but many others do. And if you forget to save ‘your’ java before upgrading, don’t blame others, please.
While I understand that’s an annoying situation, it does not entitle you to put up this claim, or, worse even, to blame anybody for “outright letting 1. die”.
I repeat: Get engaged to make 2.X work for you. TRACE. Submit a useful GitHub issue.

PS: searching for libNRJavaSerial yields a number of results like this one. I had seen it at times, too, many others did. All issues I saw turned out to be config related and could be solved that way, such as the openhab-transport-serial bundle not being loaded, bad permissions on serial interface, or the serial interface name not being passed to java binary on startup.
So it’s unproven and even unlikely that your problem is a OH1 code Java incompatibility issue.

The issue with the configuration files should be solved now (the files itself need a specific first line though). See https://github.com/eclipse/smarthome/pull/4216.
In a modern OH2 installation, fiddling with text files should not be necessary though.

Mqtt will soon be available as OH2 add-on as well.
A show stopper is at the moment, that we don’t want to store passwords on disk in plaintext anymore (paperui as well as text files). This needs to be resolved first.

Cheers David

I began working with home-assistant to see if I really wanted to migrate. Was really impressed with the ease of setup, discovery. However I also recommitted myself to banging my head into OH2 one more time to flesh out the remaining issues to get back to the functionality I had with 1.x. I have about a 95% working install. MQTT was one of the final issues to get working (turned out to be a broker issue I believe) but now have it working although I see a 2.0 version is coming. Still more difficult to get it together, but it’s all coming together and I am interested to learn more about the eclipse platform around OH2 and the possibilities that can bring.

So all in all I am still able to get what I need for now, but am also playing with HAAS and using MQTT to share functionality between the two systems for fun and has been a good learning exercise as well for HAAS. Hanging in there.

After doing some judicial KARAF console work to ensure my my things/items/channel links etc all were spiffed up…very stable.
@Kai and crew…admirable job here and while my prior posts dont make it clear. Thanks for letting me stand on the shoulders of giants. My family is enriched by this project and I wish I had more time/money to make a meaningful contribution.


I’ve been running a snapshot from right before or after 2.1 and it has finally been stable. The initial 2.0 release and subsequent snapshots were horrible from the reliability front. I also added some Zwave stuff to my setup and I won’t likely be willingly adding much more of it when comparing to dual band Insteon devices. So while I’m finally content with 2.* I’m looking forward to a smoother experience. In fact, I’m not the guy to do this but I’d like to see a bounty started to be able to do Insteon pairing within OH.