Hi Rich, the link to the incompatible 1.x addons in the tutorial is broken.
Sorry that I step into this already “dead” frustration thread, but I had to mention that there are people which already influenced the direction of OH. Somebody for example decided to split OH into ESH and OH. For me this was a really bad decision. So much time got lost for that and after so many months, I, as a normal user, don’t see any benefit from that. On the contrary it feels like it makes OH2 less stable, reliable and user-friendly.
Another bad decision: Somebody decided to not use a simple wiki for documentation as it was for OH1. I would say that anybody can use a wiki and therefore was able to contribute. Now it feels that I have to be a fully trained software developer to fix a typo in the docs.
There are still many more points I could complain about, but I think the core for me is: OH1 still was something for techies. OH2 feels like rocket science. And the developers and professionals here pretend that everything is great and totally easy.
Maybe you missunderstood my statement or it was written a bit unclear.
I never wanted to say no one has influence in the direction.
I wanted to say that you can’t force open source developers to influence in a special direction if they don’t want it themselves.
I have (at least partly) different opinions about the topics you complained about.
GitHub wiki is a mess in my view (ok for a small amount of pages) and docs contribution is not that hard.
The entry level is definitely higher, but this is no rocket science (in the end it is markdown like it is used in the wiki too) and the techie homepage build stuff is managed by people who know what they are doing. And if one asks we always do our best in helping and explaining the process and the tasks.
I can’t say much about the other topics since I am a 2.0 OH from scratch user.
Maybe I missed the ‘good ol’ times’. Anyway I can’t compare the two versions on a valid base.
I disagree with that assessment but I’m not going to argue it. A lot of this is kind of subjective.
But I do want to comment on why the split and creation of ESH occurred. I was not privy to these discussions but based on forum postings and @kai’s blog (please correct me if I misstate anything) the reason to split off the core of OH onto an official Eclipse project had more to do with enabling investment from corporate sponsors than anything.
From a technical perspective, the changes that have been made during the split would have been made to OH regardless. They were required to implement things that were already planned like automatic discovery and configuration of devices, a new rules engine, etc.
But by making the core part of Eclipse that makes it far easier for IOT companies to use ESH as part of their offering because of the governance and intellectual property policies that come with and to a large degree guaranteed by being an Eclipse project. And if these companies are going to base their products on ESH, they are going to contribute to it. This is one of the ways to get corporate investment in an open source project.
And if I recall correctly, this has already paid off. The initial development and contribution of PaperUI was done by a corporate entity.
I don’t think the maintainers think everything is fine. That is why there is tremendous amounts of effort to make it easier to use and improve stability. But I will say that the number of users of OH 2.x, and particularly the number of non-technical people who not only use OH but have become expert enough despite being not-technical to help others solve major problems. If it is rocket science, there are an awful lot of closet rocket scientists around.
4 Likes
First I have to admit I never used 1.x, so I have no experience in that. I too have been frustrated about configuring things many times. Initially I found it very difficult that some things are in Paper UI, others textual and then there’s the cinsole.
One important note though. I think it’s vital to consider the “core” and the bindings separately. Many challenges I’ve faced are due to bindings not yet fully embracing OH2’s capabilities. The version 2 bindings I currently use (Netatmo, Air quality, Squeezebox, Kodi etc.) have all been a breeze to configure with the UI.
It’s not always easy, but it’s not rocket science either.
First 2h of migration spent. I copiedmany parts out of the old openhab.cfg into new files. That was a part where I already imagined that would be done automatically. Am I asking for too much? I know, there’s probably not much motivation to write code that will only be executed once by a subset of users…
Feedback about the migration tutorial: I got lost with the versions, sometimes there is a legacy mode, there are 1.9 versions, and I still do not know when and how the version to load is determined. It is all a blur of half-automatic and half-manual configuration and installation, I am quite lost now.
I realized that I will still be getting into trouble with the two self-written bindings (one for power meters before there was a generic binding, and one for my paul novus air ventilation system). And I further realized: I will only be happy, if without exception any single item, feature, binding, rule, persistence or action that worked previously will also work in OH2, and after 2 hours spent, I assume this will take me 4-10 evenings… I just read about problems with mysql? 
edit: I wish I weren’t so negative, since I really appreciate all the development effort that is put into this program. I’m just a little bit frustrated right now… Ok, i need to switch back to OH1 now otherwise the water won’t warm up…
Just a quick update.
I managed it. OH2 is running since several days with no issues.
My pitfalls:
Mysql persistence; only non JDBC worked and standard parameters needed to be adjusted to have it stable
Config in files will be restored after restart. E.g. Define something in file and de—install via gui will be back after restart.
When to use which method(paper, habmin, text, console)
I mainly migrated 1:1 and suggest not using the admin—guis except for binding/feature installation in the beginning. Paper UI was for me unusable. Not sure if I made mistakes, but would recommend not using it for the first steps.
Sitemaps:
The order of the items in OH1 was based on their position in the items file if not specified. With OH2 it seems one need to put each item in the sitemap in order to have them sorted.
Classic UI should be default recommendation for migration.
In general a few suggestions:
If you can, try to build up an environment where you can go back anytime. I had to do it a few times when I messed up. I actually thought it works and had to switch back.
Best case is to have the two running in parallel. I had implemented a concept that OH is collecting all information but only triggers actuators when a global switch is on. This made it easy to have OH1 and OH2 running in parallel and switch forth and back until I was satisfied.
Finally I cleaned a lot up in rules and items where a lot of test and deprecated stuff was in.
Moving to 2.x bindings: it is harder than originally thought. E.g. Astro works in many cases quite different. I has sunset/ sunrise triggers with different offsets which has changed. Make sure you read the docs upfront.
Or Fritzbox & Homematic. Seems one need to accept things first before they can be used. I think that is part of the migration guide if I remember. But lost some time before I found out and hat to use the gui.
As a summary: I am happy I did it. It did not bring new functionality. Performance seems to be worse (at least startup takes forever) on a RPi3.
But I cleaned all up and improved a few rules with things I always wanted to do but never had the drive or guts to change the running system
Somehow it was too much text…
To end my post:
Thanks to all the contributors here, OH still seems to be a good project in V2.
Cheers
SJ
2 Likes
It is an opensource project. Unless someone volunteers their time to write something it won’t be written. However, not only would such a script or whatever be used infrequently but it would quickly become out of date and potentially introduce errors of its own if the config for a 1.x version binding changed.
Legacy specifically refers to bindings where there is both a legacy 1.x version of that binding and replacement 2.x version of the binding. By default PaperUI will not show you legacy 1.x verisons of bindings unless you set legacy = true.
I assumed that the explanation in the docs:
required to install the 1.9 version of an add-on for which there is a 2.0 native version
and the cfg file:
# Include legacy 1.x bindings. If set to true, it also allows the installation of 1.x bindings for which there is # already a 2.x version available (requires remote repo access, see above). (default is false)
was sufficient. What can be added to make this more clear? I’m already planning on reworking the tutorial to make the three approaches of performing the upgrade a little more clear.
Each version of an addon is a unique and separate add-on. If you install zwave1 you will get the legacy 1.x version of the zwave binding. If you install zwave you get the 2.x version of the binding. They are distinct and separate addons. It is even possible to have both bindings installed at the same time, though only one can have access to the controller at a time.
The tutorial gets you started with all 1.x and legacy bindings. You do not have to worry about 2.x version bindings until you are ready.
With 1.x and legacy version bindings there is no automatic anything. So that should help clear up some confusion I hope.
You should be able to get those working using the http://docs.openhab.org/developers/development/compatibilitylayer.html#how-to-use-openhab-1x-add-ons-that-are-not-part-of-the-distribution
unless they require some library or something incompatible with the Karaf console.
If you can step back and describe just one problem you ran into (probably the first one would be most useful) and what you tried to make it work perhaps we can help.
I have a Paul Novus 300.
Can you tell me more about your binding for the novus?
At the moment I’m sniffing on the rs485 bus.
This is rather off topic, but since others may be interested: The binding is also using the RS485 bus and is able to determine the mode set on the device, i.e. the manual ventilation level, if automatic is enabled, or the away mode etc. I was not able to detect if the bypass is active, nor was I able to access the temperature sensors or set the ventilation level via RS485 - but that is also not in the intention of the manufacturer. I use the 10V analog input and set the ventilation control to “program controlled automatic mode”, and I use a DMX line and a DMX 0-10V converter to control the ventilation in openHab on a percentage level.
@yannick_hein: Here an update for the Novus 300 integration.
I can now successful read out the temperature sensors and detect the bypass mode. To set the percentage level I now use a tinkerforge 0-10V output.
My documentation and a python integration “hack” is available on github:
In the next months I try to create a new openhab module to integrate this without the “python hack”.
1 Like