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.
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.
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.