OH2 vs OH1 - Why one should migrate

Dear all,
I am a very satisified OH1 user. More or less all in my house is “automated”. Most of it via MQTT, a few Homematic devices etc.
Anyhow, it runs. No issues and I am happy. However I have the urge to upgrade to OH2. So I got myself a second environment and deployed OH2, installed it and connected it similar as my OH1.
Both are currently running in parallel. First steps were painful, got myself confused a lot with the various UIs and consoles etc. I am still not so sure about some of the concepts and if I like or disslike them. I get that OH2 was designed to make things simpler. For me this is the opposite as I ended up using different tools for the same task (activate binding in habmin, having a thing discovered, configuring it in config file).
I also have some doubts about the stability: the mysql connection broke quite frequent, also noticed it saves less datapoints then OH1 did (same config, -everyChange- etc.) - needs more testing and more time.

To make my point: I am currently looking into some solutions which are only available with OH2 and as this seems to be the future, someday it needs to be done.
However at the moment, I just don’t see THE reason. I am happy with the UI on the various devices, the capabilities etc. it is quite stable, minimal issues (due to my rules, bad coding skills).

So, why should I change?

The only reason I have: it will only getting “better” if people participate and not let the others do the job of “beta”-testing etc.


I am about in the same position, maybe not yet so far advanced as you. I upgraded my odroids Ubuntu to allow OH2 installation, and that was already a lot of pain for me. I know that if I upgrade to OH2, it will cause several days of malfunctioning subsystems, and with the heating, warm water, shutters and lights controlled by my home automation, and my free time being mostly used by my kids, I am really struggling to get myself motivated for the upgrade.

I think amazon Alexa is one reason for an upgrade (does not work with OH1, last time I checked). Also, I am hoping to have an improved stability maybe? (I programmed a watchdog that needs to restart my OH1 about twice a week because something internally crashes…)

Same here.

Meanwhile I started the 5th attempt (no joke!) to get OH2 into same state as my well running OH1.8.3 but I have to say that the expected benefit isn’t visible at all, even worse - I’m struggling again and again with issues (Hue, Zwave, charts, slow performance, distribution of several configuration to many places, etc.).

My reason for migration was that I wanted to switch from Windows 10 machine to RPi3 in order to use the ComfoAir-binding (this is not working with the serial interface on my windows machine). My expectation was that I would struggle with the Linux stuff (to be honest: I’m not at all a fan of Linux) but at the end it turned out that this is the easy part (thanks to @ThomDietrich for his hassle free linux setup) - getting OH2 with all its new concepts into a similar state like OH1 - this is the painful thing. And I haven’t been at that point that I could start testing the ComfoAir binding.

Now, I am at that point that I try to get OH2 running on my windows machine - even when that means to go without the ComfoAir-binding but still there are a lot of issues that I also had on Linux, some I could resolve but there are also some new.

Long story short: in case a OH1 instance is running smoothly and a binding for the desired technology is available - from my point of view there is no need to migrate.

The disappointing thing is: I can’t even say whether I am too stupid or the technology is not mature enough or usability for non-techies hasn’t been considered properly or if it is a lack of documentation/tutorials. Most likely a bit of everything.

This is a difficult topic and I truely understand those to hesitate.
I myself have gone through a painful migration that took about a year.
The short answer to the thread topic’s question is:
You will have to go OH2 because there’s no further development and no bug fixing with OH1, and there’s less and less people left to use it (to be able to support you here).
The day will come that you happen to need to have OH2 running for your smart home to work.
This will either be because you need to or want to make changes to your installation and it just doesn’t work in OH1. Or it might turn out you need to move to a new HW, Linux or Java or helper package that no longer works with OH1. For me, those ‘breaking’ changes were the ZWave COLOR and SECURITY commands (those will not be back-ported to OH1).

I know you won’t want to hear and it’s mean to tell, but as a veteran IT pro, I’ve encountered this scheme on a number of occasions.
Let’s face it: the open question is not if this will happen to you but just when.
And the earlier you start the higher your chances are you’re done before you have to be done.

Some hints to at least ease the pain a bit:
Setup a ‘dry’ OH2 w/ full debugging enabled. Simulate running using smarthome:send action in Karaf console. Use this to fix your rules upfront.
Setup OH2 with as many of the ‘big’ OH1 bindings (big in terms of # of devices/items) in compatibility mode as possible.
For the ‘simple’ bindings like astro, ntp etc you can start with OH2 native bindings right away.
Migrate the OH1 bindings to OH2 replacement ones last, one-by-one.

Good luck!


At least for me this is a valuable hint: I tried for every price to use the new bindings but after reading this I will only change the runtime but not (yet) the bindings.

Thanks Markus

So, @parachutesj, @yannick_hein, @JohnnyX, are you aware of and did you try to use the Migration Tutorial? If yes, do you have suggestions that would make that tutorial better?

The tutorial takes the upgrade step by step. First it gets your OH 1.8 configuration running on OH 2.x using OH 1.x bindings only. It provides instructions for both text based only configs as well as instructions that use the UIs. Once everything works using the 1.x version bindings you can migrate binding by binding to the 2.x versions, if desired.

In short, if you follow the tutorial, but the time you get half way through you should have an OH 2 installation running close to the exact same as your OH 1.8 system.

Most people who have problems who have posted to the forum for help have had problems because they didn’t know of the Migration Tutorial or chose not to follow it and instead try to do an all or nothing type upgrade. But if there is room for improvement to the Migration Tutorial suggestion are welcome.

1 Like

Yes, I did. This was my first and second attempt - both from scratch with brand new flashed image.

Are you married and do you have children? Have you ever heared about the famous WAF?

The game goes like this:

  • convince your wife that a smart home is something cool and worth to spend money --> achieved
  • keep her calm over more than 3 years when something is not running as expected --> achieved
  • make her hungry on new features, rules, automized things, gadgets --> achieved
  • ask her for some free time (I got 2 days) to do the upgrade but have everything that she knows (and meanwhile loves) running --> FAILED, for the 5th time

What do you think how many men have same stress at home? Make the upgrade because its end of life but keep your wife happy with your technology games. To be honest: there is only one way to do that …how did you say? All or nothing.

I don’t want to make OH2 bad (I still love my OH1.8.3). I also really appreaciate the time of so many developers who are helping to make it growth. But sometimes some honest words must be said: OH2 is still far away from being plug-and-play-out-of-the-box-mainstream-ready. And, because Christmas is ahead, my wish is that this is the area where the effort is spend - not more features and fancy stuff - make it hassle-free.


And where was the tutorial insufficient? Where did you have problems? We can’t fix anything if you don’t give us any information. We also can’t help you.

Which is exactly what the Migration Tutorial tells you to do. That is exactly my main point as well. Rather than trying to do everything all at once, do it in stages. You can have your current setup up and running on an OH 2 core using all 1.x version binding using your existing configs with only minor changes to your openhab.cfg (it is now split) and .rules files.

Yes. Yes, and yes. And for the record, I’ve achieved all of your bullet points to include upgrading to 2.0 AND you can add in writing the Migration Tutorial while I did the upgrade.

The key is I didn’t ask for 2 days, I did it in an hour here and a couple of hours there, usually when no one else was home, and all the while my OH 1.x continued running until my 2.x was ready to take over, which frankly was after the first 30 minutes of the upgrade. From her perspective, there was a grand total of 15 minutes of down time.

I would say exactly the opposite. The only way to do that is to be slow and deliberate in how you upgrade by making as few changes as necessary at each step to maximize the likelihood of success and minimize down time. Which is what the Migration Tutorial tells you to do. Which is what I said in my post to do. Which is what Markus said to do.

I think a lot of people would disagree with that assessment, but that is beside the point.

However, if there are some concrete problems or suggestions you can make that the developers or I can actually act upon please state them.

Otherwise, all we have to go on, based on your description, is that you have tried to do too much all at once and failed.

Then tell us where you are having problems! We can’t fix it if we don’t know what is broken.

1 Like

yes, I followed the tutorial. And I have to say I am within IT for 20 years and got confused. I cannot tell you exactly where but especially the part with text, Karaf and PaperUI is not clear. Also what took a lot of time for me, when you define in addons.cfg this is the state it restores anytime you restart. Even you install/deinstall something via PaperUI.
I finally figured this and dumped paperUI as not usable (for me).

As said, it runs. took me about 2 evenings. Not too much, I run most on OH1 bindings except NTP, weather and astro. But then again with astro, there is no straight migration possible as it handles events differently.

Anyhow: my major issue at the moment seems to be mysql which is not running stable (OH2 binding). Besides that I am more or less ready to go to OH2 - even I do not see too much benefit yet.

@mstormi: I know exactly what you are talking about. Quite a few of my customers try to stick to old technology as long as possible until they face a major event and then panic. Thats one of the reasons why I wanted to do this.
I was just asking myself if there are other (obvious) benefits.

I think I am in a comfortable position and can run both in parallel for some time and get things eased and solved. If I would transfer completely my wife would probably kill me.
As I am running it on a RP3, the investment for a 2nd one wasn’t too high and in general I think it is good practise having it around in case of the main one fails or I need to do some developments and test before going live in the future anyhow.

Finally, something concrete and actionable.

So the Tutorial currently states:

There are three approaches one can use to install and configure bindings, an all text based one, using the Karaf console, or using one of the administration GUIs (i.e. PaperUI or Habmin 2). While all three approaches are presented below, the text based approach is the recommended one for those coming from openHAB 1.x as it will be more familiar and flexible.

What can I change, add, etc to the above to make it more clear so others will avoid the confusion?

If I add a sentence to the section that talks about addons.cfg saying that the contents of addons.cfg takes precedence and no matter what you do in the karaf console or any of the UIs that OH will return to the set of addons listed there would that be sufficient?

Have you opened a discussion here on the forum or opened an issue on this yet?

If all you want is to continue running the way you always have with text based configs, without automatic discovery of devices, and without the ability to configure OH through the UIs your primary benefit will be getting bug fixes and features that are being added to the core. You will also have a wider selection of compatible add-ons to choose from as most new bindings and other add-ons are being developed as 2.x bindings and development on legacy bindings (i.e. 1.x version binding for which there is a 2.x version of the binding) has largely ceased for those legacy bindings I’m aware of.

1 Like

Hi Rich,
it is hard to say after I understood the description seems feasible. Thats propably the reason why the authors wrote it as it is.
I personally would prefer if there is only one suggested way (it is written) and maybe mention that there are others (paper, karaf) but do not add them at that point. It should be rather a clean cook book from A to Z. Also some examples might be helpful. In addition I think in the first part, the suggestion to install the Eclipse Smart Home Designer is missing. I was just wondering how to maintain my stuff after went to OH2 in the first place. I was looking into the habmin and opened the rules but wasn’t able to safe (you know, there are a few necessary changes to be made like includes, undefined vs. NULL etc)
I am still not sure if this is an installation issue that I cannot save or if this is by design and just for display purpose.
And there are quite a lot of those pitfalls which are not obvious. We cannot expect that someone who goes to OH2 has spent the last 2 months in the forums and knows everything already. I struggeled with the missing sunset/sunrise events or that sendmail shows an error…

Anyhow, for me text seems better and autodiscovery etc. might be nice in the future but not necessary for a “power user”.


I will give the tutorial a try, but I am still afraid of the time I will need to spend just to keep it up to date. Home automation should result in more comfort, not less. When I have to spend several evenings just to do an upgrade that I do not (yet) need, this adds a lot of weight on the contra-side of home automation.

Nice to hear how others also struggle with the WAF. We’ve all heard “her” sigh when the light does not work the way it should, and you probably can guess the reaction of my wife when the water heating is not correctly triggered in the night…

1 Like

It is not that I do not get time to work on it and to be honest if I sit with her on the couch and watch Netflix or be in front of the console and tweak OH doesn’t make too much difference in meaningfull off time.
The problem is whenever working on the productive installation, she should not be around because a restart sometimes brings strange things up. I think I found over the time all but you never know and then a major light goes out and all you hear is “nothing is not working” besides it was just a small incident fixed with a flick of a switch.

I cloned my RP3 and started there. As said, two evenings and it was 90% running. Just get the OH1 in compatibility mode and tweaked some of the rules.

This is DIY HomeAutomation, that involves time. Try thinking about all the time invested by developers (and not to mention the forum helpers) to give you the opportunity to do HA. They also have wifes, children and little sparetime.

As @rlkoshak mentioned, giving feedback on how to make the migration (documentation) better and easier would actually help everyone (and their wifes).

Anywho, regarding the mysql problem mentioned. I’ve been using the mysql binding for months, and it’s been working fine. Have you tried debugging the binding? Could there be connections problems? wifi?

sorry but you are not getting the point.
As it is all open source and for free there is no critics allowed?

I know that I have to dedicate time to this. I could also instead of providing feedback (which I did here) just move on to FHEM, nodeRed, Domotics or others. But I am not. I like OH and how it works.

I don’t use Habmin much, mainly to just configure zwave devices, but I do know that Habmin is a work in progress and not at all completely functional. That might be one area where it is not complete yet.

To play devil’s advocate, given that there are over 200 add-ons, five user interfaces, seven persistence add-ons, and 14 actions we are looking at nearly 100,000 combinations just considering the add-ons. Every potential pitfall simply cannot be covered in one tutorial. Some of the more common ones perhaps could see some attention, in particular Astro and Weather.

The tutorial is absolutely missing one key piece of information which is to look at the new binding’s README to determine its capabilities and how to work with the new 2.x version of the binding as they will be across the board different and most will contain breaking changes.

Given the first principal of the OH docs (Do not repeat something documented elsewhere) I would be somewhat limited in how much I can address these, but I will make an effort.

Once you go from 1.8 to 2.1 it will take not more amount of time to keep it up to date than it did for you to update from 1.7 to 1.8.

To reiterate Markus’s point, if you wait until you need to you will be under the gun and the upgrade will likely take longer to achieve and definitely be much more difficult to accomplish because you will be rushing and under more stress.

We absolutely welcome criticism. But far too often the criticism is so vague and lacking in detail as to be useless.

Bad criticism:

  • “I tried to follow the Migration Tutorial five times and failed. It sucks. OH sucks. Why can’t this just be easy?”

I can’t act on that. I can’t change anything to make it better. All I know is you are not happy.

Good criticism:

  • “I tried to follow the Migration Tutorial and I got lost when I tried to uninstall a binding through PaperUI.”

I can act on that. OK, the tutorial is unclear about when/how to use the UIs or not. I can make changes based on that. The original criticisms on this thread were bad ones because they did not provide enough information or details to act upon. The more specific criticisms posted by you at the bottom part of the thread are good ones. I can actually do something about them.

That is @lfs_alp5’s point. We welcome good criticism because it helps us make OH better. We do not like bad criticisms because in the best case we have to play 20 questions in order to get to where we have enough information to address the problem, or we have to just ignore it. I hate to just ignore it becuase that leaves the users unhappy and the underlying problem in OH unaddressed.

Rich - I appreaciate the time that you spend to help users. I also had the luck to get a rule only due to your help running - thanks a lot for that. But: I really don’t like the tone you bring up here. It’s true, my critic is very unconcrete but first this doesn’t require to bring a gun to a discussion and second, as I stated previously

And this is still the case. I’m simply not able to ask a concrete question. All you would do is either point me to another thread or maybe give me some hints how to resolve my problems but in the end it will turn out that due to some special parameters in my setup all available solutions are not applicable and I should go with compromises, or without desired features etc. I’m not that blind that I cannot assess the situation where it is likely to get an answer in a forum and where not.
I can read and use a forum. I can use google. I helped myself a lot with doing that while setting up OH1.x But: I’m not a techie and OH2 is still designed to be used by people who have in-depth know how of developing software. This is what I am saying - not that OH sucks!

Last but not least 2 points: is something wrong when I ask the developers to concentrate on stabilization and simplification instead of adding more and more features that will not work setup.exe-like? Second: I personally don’t like verbal fights in a forum - in case you want to continue please send my a private message - there you can call me easier “Id**t”.

Simple answer nope there is nothing wrong with it.
But since this is open source, you and me and no one else has the influence to change the direction.
People are developing here voluntary and no one can force them to do task x or task y first.

I think there are already many people working on improving stability, but that does take its time.

And third:
There are many new bindings pending from people who build them for their own usecase and share them now.
And there is nothing wrong with this.

For one, tone is very difficult to get across in text-only communication. And if I had any tone intended, it was a response in kind to the “Are you married and do you have children? Have you ever heard about the famous WAF?” which comes across as condescending and dismissive. So lets just chalk this up to a mutual misunderstanding caused by the limits of text-based communication.

My point though was that you fault the Migration Tutorial because you chose to not actually follow the tutorial. Now if the tutorial was not clear that you should not try to upgrade everything all at once, I can and will address that. If you simply ignored that, the problem isn’t with the tutorial.

You can start by describing in detail what you have done and where you started to see errors or have problems. “It didn’t work” doesn’t help us help you.

When you create a new thread in the “Beginners” section now the posting comes prepopulated with the following:

  • Platform information:
  • Hardware: CPUArchitecture/RAM/storage
  • OS: what OS is used and which version
  • Java Runtime Environment: which java platform is used and what version
  • openHAB version:
  • Issue of the topic: please be detailed explaining your issue
  • Please post configurations (if applicable):
  • Items configuration related to the issue
  • Sitemap configuration related to the issue
  • Rules code related to the issue
  • Services configuration related to the issue
  • If logs where generated please post these here using code fences:

Start by providing some of this information.

No but:

  • The developers are already working on stabilization and simplification, but without specifics from you about what is specifically not stable who knows if what they are working on would be relevant. No one is going to work on anything unless someone opens up an issue with a specific stability problem documented. A generic “its unstable for me” is not something we can act upon. My setup is rock solid stable. Without knowing your specific setup and the speicific problem you are having how can I hope to reproduce the problem and therefore fix it?

  • This is an opensource project. The developers are going to volunteer their time to work on the things they want to work on. There is no way to direct the efforts in specific directions. So you will always have the balance of development more towards new features than overall stability. But if someone files a specific issue that can be acted upon then there are several developers who would jump on the opportunity to improve the core stability because it is what they like to do.

  • No system like this will ever support a simple setup.exe like install and configuration. Like I said above, there is nearly 100,000 addons configurations possible and each add-on is separately developed, of differing maturity, and interfaces with vastly different technologies. And that is just the add-ons and ignores rules. Any system that supports this many technologies will always be complex. If you want simpler you would probably be happier with a commercial and less capable solution like Vera or SmartThings. But even those products are not simple by any means.

I don’t believe I have ever called nor ever meant to imply anyone is an idiot on this or any other forum and I certainly did not mean to imply it here. If that is what you read in my posting, know that it was not my intended meaning and I apologize.

I take issue with not following the tutorial and then blaming the tutorial when it doesn’t work but that doesn’t mean I think you are an idiot. And if there are ways I can modify the tutorial to make it more clear that you should not try to upgrade everything all at once I need to hear that so I can fix it.

So when I say “That is what the Migration Tutorial said to do” you can respond with “That isn’t how I read it” and boom, now I have something actionable I can use to go improve the tutorial. That is all I want.