So I have been avoiding the upgrade. Finally had some time and read through the migration tutorial and it got me to thinking…it seems like a good walk through but seems way more than I need and am wondering if it would just be faster for me to start from scratch.
I don’t use any bindings except exec based on the hardware that I use. I have some 433 outlets getting controlled by a script on my RPi that send signal out a board via GPIO. Pretty basic. I also have a hardware rooted Winkhub 1 that I control by way of a script that hooks into the aprontest function on the Winkhub to control my Cree bulbs and a few Zigbee outlets. The aprontest over ssh is actually very responsive so it works, plus I like the local only availability. Finally, I have a Linux server that I am running a Smart Things bridge to facilitate my Echo devices.
A lot of what I was reading about in the migration tended to be about migrating all of your bindings, and other custom settings. Again, don’t really have any.
Finally, I heard that the 2 version of the exec binding is implemented totally different now? Can I still use the 1 exec binding on 2? It works great for me.
So I’m wondering if trudging through the migration is even worth it for me. I do plan on focusing more on customizing and adding a lot more once I am on OH2 but for now it is simple.
My biggest concern is getting it done in one sitting if possible so I don’t annoy the family with it suddenly not working!
Yes, and I still do because last I checked, the exec2 binding doesn’t have the same functionality. I can’t remember off the top of my head exactly what, but it was a showstopper for me. You can use all of the 1.x bindings with OH2. You just need to install the 1.x Compatibility binding (you’ll find it in PaperUI).
It sounds to me like starting from scratch would be a good option for you. It won’t hurt to try, as long as you keep a backup. You can still use your .items files, and the bindings will stay the same as long as they are 1.x. The only odd thing I recall was motion sensors changed from Contact to Switch, but that was for the Zwave 2.x binding.
Keep your old setup in place and start OH2 fresh. Copy in what you need, one piece at a time. If it’s taking too long in one sitting to get OH2 going, shutdown the new and fire up the old. OH2.2 is pretty good, and has single item triggeringItem, but group triggeringItem is a feature that’s worth going to the snapshot for, if you have a bunch of rules that you can use it in.
I had a very similar setup! Using a hacked Wink hub is great, but grab a Zigbee dongle, or a Zwave/Zigbee combo dongle, and use the Zigbee binding. I have a bunch of GE Link bulbs and an Centralite/ST outlet that are doing great with it. I turned off my ha-bridge recently and moved over to the Hue Emulation service (still all local). The integration with OH made it simpler to setup and it has been just as solid. But if you want to stay in the cloud, there is an Alexa skill too. And get rid of ST for good!
Thanks for the thorough reply. Wow, another hardware rooted OG Wink Hub user in the wild! I think it was a rare breed to begin with
I have thought about getting the dongle, but never really went forward with it since the hub was working fine. I liked the idea of all the radios but now that I think about it, I don’t ever use but one and any other radios can be replicates with add ons to the Pi. Though, one question I have is range…does a dongle offer the same amount of range as the Wink Hub? I’m assuming so, but always a question I had. Any suggestions on a model?
I didn’t think about switching off 2 and going back to 1 if I didn’t get OH2 right at first. I’ll make a full backup of my card before I start anything as well. I really need to get motivated to add more to my setup and really tighten it all up and leverage all the great work ppl have done on OH and think 2 will be a good start.
I would say my HUSBZB-1 has better range than the gen1 Wink hub. And the response is better too. I’ve liked the HUSBZB-1, and use it with a bunch of zwave devices too. I think Chris (Zigbee binding maintainer) would probably say Telegesis-based Zigbee dongle, since that is the latest he’s added. I don’t recall if they are available in the US though. Probably some info in here.
If your running it on a Pi, could also just throw in another SD card and swap between them? I haven’t used it, but people seem pretty happy with openHABian.
Yeah… shorting those pins was pretty scary… and I never got the nerve to upgrade to see how the local API would work. But there is also a Wink hub binding floating around, but I don’t believe it is using the local API yet.
The biggest problem I had in doing it was seeing the pins to count them. I had to use a magnifying glass to get in it. I was actually surprised (lucky?) I got it on the first try. In fact I did something that made me lose root (I think upgraded something) and had to do it again and got it on the first try again. Maybe it was made out to be harder than it was. I’ll admit it was a pretty cool feeling to get it done.
I’ll check out those dongle suggestions and will probably pick one up to see how it works well. It’d be good to be able to use actual bindings with better integration. Less dependence on external scripts.
You only need the compatibility later if you are using a 1.x binding that had not yet been ported to run on OH 2. Exec 1.x had been ported so you just need to install it.
So you really only have to follow the migration tutorial to the half way point. The tutorial had two parts. 1. Get you current setup running on the OH 2 core work there minimum amount of changes top your existing setup. If you plan on sticking with the exec 1.x binding then at this point you are done. I did this step in about 3 hours, and I was slowed down by taking notes to write the tutorial and I had almost a dozen bindings.
Once your current setup is working but only if you want to you can look at the 2.x Exec binding and migrating your Items to use the Exec 2.x.
I recommend following the text based path through the tutorial.
If you do, it will basically be the same as starting over from scratch anyway so that party of the question is moot.
That’s interesting… or I’m misunderstanding! I was under the impression that all 1.x bindings needed the 1.x Compatibility binding to run under OH2. By ported, do you mean to a 2.x binding? Or, if you mean some 1.x bindings can run without 1.x Compatibility installed, how do you know which 1.x bindings need it? You may have removed a binding from my setup!
Once a 1.x version binding is shown to work in OH 2, there are a few changes that need to be made too it, mostly having to deal with the fact that the core classes have moved packages and changing the loggers and such. Once that is done the 1.x version binding is ported and can run on OH 2.x just fine.
Any binding that appears in PaperUI or can be installed through the karaf console or addons.cfg have been ported in this way. You only need the compatibility later if you have to download a jar file and drop it in the addons folder. I don’t think there are any bindings, or there after very few bindings that have a README in the docs that have not been ported. So you will really only need the compatibility later if you download and use a 1.x binding from a third party.
A 2.x version binding is a complete rewrite of a binding that takes advantage of Things and such.
Thank you for explaining this! I misread the migration tutorial a long time ago, and have been running the 1.x Compatibility binding since migrating. I don’t think the documentation has changed, and it still reads to me that the 1.x Compatibility would be needed for all 1.x bindings, even though I now know better. Maybe it could be rewritten to make this clearer?
Well… I uninstalled the openhab-runtime-compat1x Feature, and after a restart of OH, known of my 1.x bindings (MQTT, Zoneminder, Caldav, etc.) started. After putting it back in, all is back to normal. The only way I can explain this is if the openhab-runtime-compat1x feature is needed for any 1.x binding. Hmmm.
Theoretically one should be able to just enable the openHAB 1.x Compatibility Layer, copy over the existing add-ons and config files and have it work. However, while the compatibility layer is very good and very capable, this approach will result in errors and end up being more work than the steps below. Therefore the first steps will be to get it running using the 1.9 version of the bindings installed through openHAB 2’s new add-on management system.
This paragraph is meant to say "we are not going to just enable the compatibility layer and copy over addons. Instead, we are going to use the following instructions to install the bindings.
And it explicitly states “Therefore the first steps will be to get it running using the 1.9 version of the bindings installed through openHAB 2’s new add-on management system.”
The following sections do not mention anything about the installing the compatibility layer until you get to the section titled “Installing Unofficially Supported openHAB 1.x Add-ons” and by the time you have reached this section you should have already installed most of your 1.x version bindings already.
How did you install these bindings? I’m running expire. http1, nest1, and mqtt1 installed through addons.cfg and I do not have the compatibility layer installed and they all work fine.
You only need the compatibility layer if you install the 1.x verison bindings by copying the jar file to addons. If you install it through any of the 2.x mechanisms (karaf console, addons.cfg, PaperUI, etc) you do not need the compatibility layer.
Originally through PaperUI, but they are in addons.cfg too. After poking around, it looks like the Expert installation includes the openhab-runtime-compat1x feature and org.openhab.core.compat1x binding. This is what I used when I first set OH up. On a test system, I setup a Standard install, and it did not include either of them. But after installing a 1.x binding through PaperUI, they were both there. So, it makes sense now that a 1.x binding that is not in the distribution would need the feature to be manually installed. But if a 1.x binding is installed through PaperUI or Karaf, the feature will be installed as a dependency and does not need to be manually installed. That’s the bit that I wasn’t able to glean from the documentation. Also, if you stop the org.openhab.core.compat1x binding, all 1.x bindings that you are running will stop.
If you’re running a 1.x binding, I bet you’ll get similar results to these…
openhab> bundle:list -s|grep -i compat1x
241 │ Active │ 80 │ 18.104.22.168802191719 │ org.openhab.core.compat1x
openhab> feature:list|grep -i compat1x
openhab-runtime-compat1x │ 2.3.0.SNAPSHOT │ x │ Started │ distro-2.3.0-SNAPSHOT │ Compatibility layer for openHAB 1 add-ons
I was under the impression that part of the work to make the binding work on OH 2 was to free it from the compatibility layer. Perhaps that isn’t the case. I don’t have access to my server at the moment but will try it when I get a chance.
But it is true that we do not have to install it separately unless we are using not officially supported bindings installed through the addons folder.
Actually, they do…in a way anyway. It doesn’t explicitly say to do this, but this line under the Text-based config indicates the following:
package = expert - expert is a good choice here. It will include the standard UIs, all transformation services and the 1.x compatibility layer, though you can choose your UIs and add-ons individually later.
(In fairness though, it doesn’t say it is required, just that it installs it) And I’m totally not trying to prove you wrong here, just pointing out that it does basically automatically install the comparability layer if you choose expert here.
I am ready to do the upgrade and am thinking it may not matter so much in my situation, but if you are saying it is not needed for most supported bindings, but it actually installs as indicated in the above line, considering the problems that @5iver has with not running it, should I carry on with it, or is there another option I am missing?
I will study more about the exec binding2, maybe I will understand it better and not be so worried about it
Ok, so I am full on into the process…so far much less daunting that I had thought, most likely helped by the fact that my setup is simple thus far and that I have literally no bindings I am using other than exec.
In that note, is exec a “special” binding that does not have a section in openhab.cfg (from OH1), because I didn’t see it. And because of that, is it also true that an exec.cfg (or whatever it would be called) file is not created in the services folder? Am I correct in assuming exec sort of just works out of the box after install in the same way it did on OH1? Meaning, I should be able to control and use the same exact commands to get my devices to work in OH 2? Granted, from what I am reading there may be some permissions issues but I think I can sort that out. Thanks!
OK, this is really weird. So I check for the Exec1.X binding in Karaf console. Find it, install it. Then I check started features and it shows, but literally within seconds, as you can see in the log, it uninstalls itself? What gives here?
This is really weird. I see no other mention why this is happening.
EDIT: OK, I got it sorted and it was simple, actually. Essentially, I didn’t actually add:
'# A comma-separated list of bindings to install (e.g. “sonos,knx,zwave”)
binding = exec1
This seemed to solve the problem, BUT there is a reason that I didn’t add it here. Since the tutorial was discussing adding bindings that were found in the openhab.cfg file and my openhab.cfg file didn’t have a section for the exec binding, I didn’t know if I needed to add it here. (Hence my question just before this on).
Now that I have gotten it working properly, it make sense to me; however, running through the tutorial it wasn’t exactly clear. I love the tutorial and it is as good at being as simple as possible, since so many users utilize the exec binding, one suggestion I would have is to add a section specifically for the exec binding in this case.
In fact, I have no problem creating the content to add here if you think it is a good idea @rlkoshak
I’m all for it. The backlog of things I have to do just related to OH is starting to be overwhelming. Adding improvements to the migration tutorial is one among many. Please do add exec as an example and any other improvements you can think of.
You can add it directly to the tutorial on GitHub. Just browse to the file and click the pencil icon and add your changes. Easy as that.