Replacing USB drive, is it time to switch to Openhab 2?

I had a USB drive failure and will have to start from scratch with a new drive for my openhab setup. I was wondering if anyone had any input about moving from 1.8 to 2. I have been hesitant to level up, everything was working well for me and I didn’t really see the need to break into something new. I have all of my config files backed up so I could just drop them back into a new 1.8 install and be done with it. OR I could start fresh with openhab2.
Are there any addons still not working with 2? I use hue, http, squeezebox/squeezeserver, ddwrt, exec, mqtt, wol and network health (maybe a couple of others).
What is the consensus regarding the improvements over the old version? I suppose if I was going to switch now is a great time, is the process of integrating my existing setup more trouble than it is worth (ie does it make more sense for someone just getting started with Openhab to use 2 since they don’t have anything to carry over from a previous iteration).
Any input is appreciated!

Well, as discussed here and elsewhere on the forum, you’ll have to move to OH2 anyway (some day), so I’d say yes, this is a good reason and point in time to make that move.
Any OH1 binding is still available for use under OH2, they continue to work with your OH1 config, too.
While you seem to not have any ‘large’ binding to migrate (one to have many devices), it’s still easier to migrate OH1->2 bindings one by one. Biggest hurdle probably will be to migrate your rules which is what you need to do in one go when you move the OH core from v1 to v2.
Make sure to follow the migration tutorial.

I think most everything worth saying has been said in this thread:

I do not think so but you can always check to see if an add-on you care about is listed here. If it is listed it is known to work with OH 2.

I think the overwhelming consensus is that OH 2 is a big improvement in many areas. There are many who are not happy but, in my humble and completely biased opinion, I think most of the complaints are because “someone moved their cheese” than complaints about OH 2 itself. That being said, there are lots of areas where OH 2 is still a work in progress. PaperUI, while having made great strides over the past year, is still inefficient in many areas. There is still a bifurcated configuration environment where using 1.x version bindings cannot be configured via PaperUI forcing some users to choose between UI management and text file management or both.There have been some stability problems as well with some bindings (the bug in the Astro binding for 2.1 release was a real problem for many).

As discussed on the thread linked to above, please review the Migration Tutorial and judge for yourself.

My recommendation is to take it one small step at a time. First get your current set of 1.x version bindings, configs, and Rules up and running on an OH 2 core. Then migrate your bindings, one at a time and as time and desire allows, to the newer 2.x versions of those bindings.

If you gets stuck, ask for help rather than spinning your wheels and getting frustraited.

Thanks for the input! I have decided to try and introduce openhab 2, going with an Openhabian install. I believe I followed all the instructions for the install and then the migration but now that everything is up it gets a little fuzzy.
Everything is installed and running but my understanding of how the items/things work for some of the bindings just isn’t there.
I have motion sensors feeding input through the http binding which is installed but the documentation doesn’t mention anything about creating Things for each item yet the rules aren’t being triggered. In my events log I can see that the motion items were being recognized for a while, perhaps until I chose to install the http binding (I’m not sure about that but there hasn’t been mention of the states being changed since around the time that I installed the binding through paperUI).
Do I need to do something in the karaf console as well?
The http and exec bindings are quite important to my setup, what is the best way to get those up and running again?

Also, since I’m already here:
1.I might have had paperui discover my Hue bridge, is this going to be a problem? It seems like the documentation suggests either text based (especially if you are used to 1.x which I am) or PaperUI but not mixed together. Do I go ahead and add all of the lights that PaperUI has found or can I step back and undo the discovery to manually add the bridge so that I can create my own Thing file?

Well, (off my memory), http binding is still v1, that is it hasn’t changed.
So you configure it just the way you are used to (using .items file), and that means no things or channels for this. If the rules don’t trigger the reason must be elsewhere. Possibly they trigger but don’t execute properly because there’s some things you need to change when you move OH1->OH2. See migration docs.
You should do log:set debug org.openhab.binding.http and
log:set debug org.openhab.model.script.rules to get to see more in openhab.log.

Yes go ahead, use the things PaperUI has found for you.
Generally speaking, do NOT create .things files. Leave that to PaperUI and its discovery mechanism.
Speaking items, it’s the opposite. You could mix here (define some via PaperUI and some via .items files) but this can become confusing and a problem at times, so I’d recommend to use files only.

Speaking items, it’s the opposite.

So items I should create textually, things are hopefully taken care of by PaperUI?
Thanks, I will keep going.
Also how do I change the keyboard layout in openhabian from UK, we have no pounds in Canada.

Yes. @rlkoshak: I think this is what will confuse new users most and those to come from OH1 in particular.
Can you change the migration tutorial to be more prominent in stating this ?

Google for that one … I believe it was dpkg-reconfigure keyboard-configuration or some such.

So this item that I have using exec:
Switch Kitchen_led "Kitchen LED" {exec=">[ON:python /srv/openhab2-conf/BlackBeanControl/ -c K_LED] >[OFF:python /srv/openhab2-conf/BlackBeanControl/ -c K_LED]"}

would be this Thing? (how does the ON/OFF get handled in a Thing?)

Thing exec:command:Kitchen_led [command="python /srv/openhab2-conf/BlackBeanControl/ -c K_LED"]

You truely want to hit the sweet spot, don’t you?
No things files (yes it could work, but see my recommendation).

For exec, you would need to (manually) create things in PaperUI (discovery cannot work, obviously). Doing so will present you with an “input” and an “output” channel, that’s where you can enter the corresponding shell commands in UI.

For exec, you would need to (manually) create things in PaperUI

I just saw the description on the exec binding readme page. In PaperUI, when entering a new Thing for Exec , what is meant by ‘Location’? And the command is just this?
python /srv/openhab2-conf/BlackBeanControl/ -c K_LED

any (physical) thing has a location. No meaning for virtual things like exec.

I guess. But come on, try for yourself first, please. You can get back to the forum on points like this if it still doesn’t work after you’ve tried to debug.

Yes of course, I was just referring specifically to syntax. Thanks for your help.