I just migrated from OH2 to OH3 and my system seems now to be very slow in seeing state changes of ZWave on/off sensors.
Problem is that my upgrade path was rather complicated, so I am looking for tips about where to start.
My main goal was to migrate from OH2 to OH3. But I thought it would be cool to upgrade the hardware platform from a Raspberry Pi v3 to a Pi v4. But my ZStick was one of those Aeotecs with the Pi v4 hardware bug. So I migrated to a new model Aeotec without the Pi v4 hardware bug.
I used the Aeotec cloning software to copy all my sensors from the old stick to the new stick. And then I added the new stick in a clean install to my new OH3 Pi v4. It discovered all the ZWave sensors in the Inbox, and I added them all to my OH system. And they all report as âonlineâ (all green).
However, as I mentioned before, the new system seems now to be very slow in seeing state changes of ZWave on/off sensors. For example on/off contact monitor sensors seem (sometimes) to take a few minutes when the input contact changes state. And push button sensors scene signals (sometimes) seem not to get through at all.
Iâd ask how long ago this was, the stick config-copy business might not leave the mesh in a good state,neighbour tables etc. It might get better over a dayâŚ
Thanks Bruce, that is a good point. As far as I am aware, the signals that are slow, are not encrypted ones. But do you think that different keys might have a performance impact on transmission of other sensors?
Thanks @rossko57 It is at least ten days now. I held off posting until I was sure that it wasnât a transient problem. And yes the stick is set to heal every night.
Because many times I experience delays, the java process sometimes hogs the CPU.
Still havenât seen this on OH3 though.
On my Ubuntu server 18.04LTS sometime a process called agetty also hogs the CPU.
That said, in my case the transfer from 2.5.11 to 3.0.0-1 has been silk smooth for Z-Wave.
Aeotec gen5 stick. So there is hope.
I would suggest setting the zwave binding to TRACE logging and also look for hints in the events log.
Another thing you could try is putting the zstick on a powered USB HUB, just for testing.
I run a pi4 system at my summer house, and had to do that with a Conbee Zigbee stick. Seems the pi4 is noisy if you have it too close. Could apply to Z-Wave as well. Worth a try âŚ
@OMR many thanks for the suggestions. I am just hoping that it can be solved via software. And that I donât have to reset everything, and then spend many days crawling around in the dark and narrow spaces in my house.
PS I have my Pi âisolatedâ inside my (metal) 19 rack cabinet (with all the modems, routers, and switches), and the stick is outside and away from the cabinet, connected via a 2m usb extension cable.
The cable is certainly nothing special, and it is only USB 2.0. Currently it is plugged into one of the Piâs USB 3.0 ports. The Aeotec stick is itself AFAIK USB 2.0 so there would be a conversion from USB 2.0 to 3.0 at some point anyway. Therefore I wonder which of the following alternatives might be bestâŚ
Change to a higher quality USB 2.0 cable
Change to a higher quality USB 3.0 cable
As 1. but on the Pi plug into one of its USB 2.0 rather 3.0 ports
As your prior suggestion, change to a powered USB 3.0 hub
All four USB ports on the device are connected to the USB 2.0 hub, whilst the USB 3.0 ports (blue) are ALSO connected to the USB 3.0 bus via the USB 3.0 specific pins in the socket.
I think this means that a USB 2.0 Z-stick will always connect via the USB 2.0 pins on its plug (via the USB 2.0 cores of a USB 2.0 extension cable, if any), to the same USB 2.0 serial bus inside the Pi 4, regardless of whether it is plugged into a USB 2.0 (black) or USB 3.0 (blue) port on the device.
So in other words, for the Aeotec USB 2.0 Z-stick, neither the USB 3.0 socket pins, nor the USB 3.0 extension cable cores, nor the internal USB 3.0 serial bus, are touched by this device at all.
And furthermore (IMHO) using a USB 3.0 extender cable for such a device is probably counter-productive because it exposes the extra cores of the USB 3.0 serial bus over that cable (to act as a potential interference radiating antenna) even though nothing is connected to those cores.
So my conclusion isâŚ
One needs a good quality USB 2.0 extension cable (WITHOUT USB 3.0 cores)
Such a USB 2.0 cable can be plugged equally into any of the four USB ports on the Pi4
EDIT: but if you do use a USB 3.0 cable, plug it into a USB 2.0 (black) port (which means its USB 3.0 cores wonât be connected to anything inside the Pi4).
