This is a weird one. Just grabbed a fresh version of OH2 to check in on progress since I last played with it months ago. Same device that ran it previously, though I get this :
pi@BANANAPI /opt/openHAB $ sudo ./start.sh
Launching the openHAB runtime…
Java 1.8 or higher is required. Aborting launch.
pi@BANANAPI /opt/openHAB $ java -version
java version "1.8.0_73"
Java™ SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot™ Client VM (build 25.73-b02, mixed mode)
Any ideas?
How did you install the java updates?
I didn’t. The same exact machine and setup runs a version of OH2 from about 2 months ago without any issues. It’s actually running it now, which makes is seem so strange to me.
right, 1.8u73 was out 2016-01-30… you could try to update java to 1.8u91, but I think, there is something mixed up, OH2 should definitely work with 1.8u73…
Could you check whether your JAVA_HOME is maybe pointing at a 1.7 version?
Could you check whether your JAVA_HOME is maybe pointing at a 1.7 version?
Nope, there is only one version on the Pi. I’m going to flash it back to a stock install and try again. Just odd, as a version of OH2 from 2 months ago starts and is running fine.
I would guess that this was a version where the Java check hadn’t been implemented yet. You can try to debug runtime/karaf/bin/setenv to see why it is failing - this is where the check is done.
Roger that. I’m going to drop in a new card and mark that one for later playing. I just want to fire up OH2 to see if it’s usable for my setup yet. It’s been a while, just wanted to check in on progress. 
OH1.8.3 broke all my sliders, and the dimmer buttons don’t work, so I’m looking to get things back to a working order without having to revert back to OH1.8.2(prior to the slider code being backed out).
Thanks for the reply!
This should have been finally fixed last night, see here. It would be great if you could try the latest 1.8.3 snapshot before it is going to be released!
Just updated to the dropbox’d version, and really no change. Dimmer buttons still broken. Holding the UP button does seem to work, but if you try to dim down, it seems to dim down fine, but as soon as you let go(as if you wanted to stop dimming, and liked the level) it just turns the light off. GUI also does not reflect that off state, it stays where you “stopped”.
Any reason why we can’t just have the slider back the way it was? It was so much better than this clunky button thing. I know that there was a restriction that you needed to have a [%s] at the end of the label, but that’s better than a dimmer that flat out fails to work.
What kind of dimmer do you use, and which binding?
Mostly Leviton DZMX1, though I do have a few older GE ones floating around. I have about 70 zwave devices, and a ton of dimmers so having a rule to handle the increase/decrease for each is a bit annoying. I could of course put them in a group and handle it that way with a little hacking but one would think that having a working dimmer/slider would be pretty important.
I can’t say I understand why the old slider was pulled, instead of fixed, honestly. It’s been months without a working slider or working buttons. The old way worked fine, just needed to have the [%s] designation in the label and it was fine.
Yes, same here, i have knx dimmers which don’t know about increase/decrease, so absolute dimming is the only option. The absolute dimming through the classic ui was introduced with ~ OH 1.8.0 but there were stability issues, so the pull request was reverted. In OH 2 (basic ui) there is absolute dimming available, so I’m stuck at OH 1.8.0 (having none of the related issues so far) using some improved bindings from OH 1.9.0 but looking forward desperately to OH 2 
I get the revert, but what I don’t get is how such a major function is completely broken due to the revert. I’d setting for instability over my dimmers doing whatever they want when I try to get them to dim. Thankfully for me the slider through Habdroid works. I’m going to revert the revert I think tonight and put the sliders back, not really worried about what’s going on the 1.8x series as it’s obvious that it’s taken a back seat to 2.0.
Tried 2.0 again last night, and still pretty far from where it would need to be for me to use it “in production”. Making good progress, but some key points that I would need are just not there yet. Video support is a big one for me.
still pretty far from where it would need to be for me to use it “in production”.
Why? I would expect it to be as stable as 1.x if you use it with the 1.x KNX binding. What makes it “far away” for you?
Which issue do you refer to here?
It’s certainly been stable and running fine in a test environment here for a while, quite a bit slower to startup than 1.8.x was but that’s not a deal breaker for me. Problem is I use some things in the sitemap that don’t work in 2.x yet. Video being a huge thing, I have a bunch of cameras, which get viewed remotely quite a bit.
Video url=“http://192.168.1.200/videostream.cgi?user=admin&pwd=123456” encoding=“mjpeg”
Presents you with a broken video player in 2.x, works perfectly for a bunch of different IP cameras in 1.8.x. I haven’t tried to point habroid to my 2.x instance to see if it works over the proxy yet, because it doesn’t even display locally.
I see that Harmony now works, which is great as that was one of the big things stopping me from moving over. It’s certainly made progress from where it was 2 months ago(last time I checked out 2.x), but it’s not quite there yet for me.
The only other downside I see is documentation. It’s pretty limited, and pretty confusing as to what a thing is, linking, etc. The old way made more sense IMHO. I get why it’s gone this direction, as things can now be “discovered”, but without some decent documentation it’s all pretty much “click this and see what happens, or if I broke something”. I guess I’m just used to 1.8, 2.0 will come with time, for now though it’s not much easier than it was before for me. It discovered something which is great, but now I’ve got to fire up the text editor anyway.
I am not aware of any problem there - is there an issue anywhere about it? If not, would you please care to enter one?
The only other downside I see is documentation.
Good news here is that this is heavily under construction now.
I guess I’m just used to 1.8
Please note that you should be able to use 2.0 just the same way you are used to on 1.8. You do not need any discovery & things & Paper UI at all - just use your 1.x bindings exactly as always before and do everything in a textual configuration.
HI
I got exately the same problem: I just installed java, never had it before, and start.sh throws error that there would be no java:
magnus@blablubbb:/opt/openhab$ sudo ./start.sh
Launching the openHAB runtime…
./start.sh: 16: ./start.sh: java: not found
magnus@blablubbb:/opt/openhab$ java -version
java version "1.8.0_91"
Java™ SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot™ 64-Bit Server VM (build 25.91-b14, mixed mode)
I do not understand what/where/how to debug.
I just tried to run the designer with a similar result, but this time the error message is making more sense:
A Java Runtime Environment (JRE) or Java Development Kit (JDK)
must be available in order to run OpenHAB-Designer. No Java virtual machine
was found after searching the following locations:
/opt/openhab-designer/jre/bin/java
java in your current PATH
So somehow it searches java in a subdirectory of the designer, which does not exists. On the other hand I went to the java webpage and their webpage confirms that I have the latest version sucessfully installed…
I found a solution:
sudo apt-get install default-jre
Another solution may be to really create this directory and placing there a link to the bin folder of java.
No, that’s wrong, because you would install openjava which is known as faulty in question of openHAB.
Instead of this, setup java the right way, either extract the oracle java jre to /usr/lib/jvm/oracle-java-1.8.0_91 and tell debian to use this version:
update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/oracle-java-1.8.0_91/bin/java" 1
Or use the web upd8 repository to install.