Upgrading to Openhab2 right now on stable system - good idea or not?

I currently run OH1.8 on a Pi3 and on a slave Pi2 connected via Ethernet and MQTT. On the whole it works well, although the Master Pi3 is heavily loaded and response times are affected at busy times so I’m thinking of offloading some of its work to the lightly loaded Slave Pi2.
As Openhab2 is the future I’m wondering whether now is the time to upgrade the Slave Pi2 to OH2, and then slowly migrate things across, testing thoroughly on the way. Before updating the Master Pi3 to OH2.
Can anyone comment on whether this is a good idea or whether I should await later versions? I value stability particularly on the Slave Pi.
I call the Jessie command line to do a few things, and have a LOT of rules and Timers. Both systems run read only Raspbian Jessie with NoSwap and Openhab installed on a seperate RW partition with logs redirected to a RAM drive to limit SD Card Write cycles

My Bindings on the slave are:

mapdb persistence

on the master:

mapdb persistence

With the exception of RFXCOM and OneWire the bindings can be moved between either Pi with a bit of MQTT work.

You say thay your Pi is heavily losded, I would recommend that you først verigies that you are NOT using openJDK. It is performing significantly worse CV than Oracle Java. There is diskussions about it in This Forum.
When that is Said Most og the listed bindingsværk seems to Work om OH2. I would tale om RPI and installation OH2 and then migrate binding by binding.I am dping that right now. It Will require some Work, but it sjould be possible.

I’m currently running
java version "1.8.0_65"
Java™ SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot™ Client VM (build 25.65-b01, mixed mode)

I have made an effort to upgrade from 1.8 to 2.0 the last two weeks. The 1.8 (and 1.7.1) system has been in production for more than a year without major issues.

My main driver for migrating to openhab2 was to try out the amazon echo binding.

Moving the configurations and tweaking some of the rules scripts wasn’t to hard but I have the following issues that are really stopping me from making the move to 2.0.

  • Rules don’t execute properly. They spit out the following in the logs:
[ERROR] [.script.engine.ScriptExecutionThread] - Rule 'BrightnessMode calculation': Script interpreter couldn't be obtain

The problem appears to be the same as discussed here:


or here:


Both are closed, #1393 in June 20th but its at least not working for me.

  • Some of my z-wave switches cannot be controlled. They give the following error when switched via e.g. the basic ui
NODE 7: Generating message failed for command class = SWITCH_BINARY, endpoint = 0

The switches with problems are Philio Tech PAN11-1B. All other switches work fine (about 15 items).

  • One door sensor is not recognised and shows up as an unknown device. Its an Recessed Door Sensor gen5 by Aeon Labs.

  • I cannot get the hue-emulator binding to make the devices discoverable. Discover messages are finding its way to openhab2 but alexa is not able to discover any devices.

The z-wave issues are probably solvable by some troubleshooting and providing information to the z-wave binding developer. Same is likely true for the hue-emulator binding (it may simply be a misconfiguration from my side). What really is holding me back is that rules are not executing in a reliable way.

I will back out from running 2.0 in production but will continue to play around with it. To me it cannot yet replace the stable 1.x system.

  • Magnus

Thanks very much for the reply, whilst I don’t have any Z- Wave or Hue, rules not operating reliably is a deal breaker.
I’ve just moved 3 bindings and a bunch of rules from master to slave and it seems to have given me back my responsiveness, so I’ll leave it alone for now.

I also have problems with PAN11 … what are yours?

I can switch them … but no other stuff like “power consumption” etc is working.

In my case they are not even switchable. Have not tested any other channel then the binary switch.

When swiping on/off the following error is given in the log:

Generating message failed for command class = SWITCH_BINARY, endpoint = 0

When using paper ui to toggle the switch the following is printed in the log:

Received HTTP POST request at 'items/SwitchLightLivingroomSW' with an invalid status value 'On'.

Are you running the latest snapshot?
Did you delete the thing and readded?
Are you using the automatically created items? Or manually?

Re-tested last night with snapshot build #464. Clean install. Re-added items.
Same issues as previously described.

This is using the docker image openhab/openhab:amd64-online. I did last week test by downloading the distro itself and ran it and same issues then as well so I don’t think its the execution in a container that cause the problems.

There is a new issue opened: https://github.com/eclipse/smarthome/issues/2117
Can you confirm that this is exactly what happens in your case as well?

Yes - that is exactly the behaviour I have observed.

Did a clean install and created one very simple rule… then of course it works as expected.

Just noticed that there is a commit made by you in this area. Once available I will check out if the issue can still be reproduced using my original set of rules.

Ok, cool - the latest Build #469 contains this fix already. It would be great if you could test this!

Its works fine now with build #469. Rules execute as expected.

My PAN11 eleven switches also got functional… What a great day!

Thanks Kai for looking into the issue - Much appreciated.

1 Like

Also “Metering” ? Or only on/off ?


I don’t have any metering item configured. But if I turn on the switch I do notice the power consumption increase to the same amount as expected if looking at the thing in Control page of Paper UI.

you mean you see values here: ?

Yes - Values are shown:

:fearful: ok I don’t understand why my only can be switched but show no values at all… :frowning:

any config parameters or associations you changed for the plug?

I actually tried anything but find no solution that it shows values - I have 4 of these … and they all show nothing

hey @chris since now the PAN11 work for @sirwio do you think maybe the “Hauppauge” labeled ones should actually be NOT recognized as PAN11 by discovery?

I’m not sure - I don’t know what your thinking is here, but often we find that a device is made by one company, but sold as a different one, and it still has the original manufacturers information in the discovery data. So, it all comes down to the identifiers in the device as to how it will be discovered.