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
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 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:
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.
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.
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.
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.
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.
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.
ok I don’t understand why my only can be switched but show no values at all… 
