ZWave: system migrated: on/off sensors now very slow

Tags: #<Tag:0x00007f1731e331c8>

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.

Any thoughts?

Have you checked the Java process cpu usage with top?

If you have any secure devices, the encryption key is stored in the binding, not the stick.

1 Like

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…

2 Likes

If healing is enabled.

No I haven’t. But why do you suggest this?

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

Don’t think so since you are able to control your devices.
And you still have your old stick you can put on a powered USB-HUB.

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.

1 Like

Are you sure it is a high quality cable in good condition? If the signal gets distorted that could cause slowness.

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…

  1. Change to a higher quality USB 2.0 cable
  2. Change to a higher quality USB 3.0 cable
  3. As 1. but on the Pi plug into one of its USB 2.0 rather 3.0 ports
  4. As your prior suggestion, change to a powered USB 3.0 hub

=> Thoughts?

The cable could definitely be the issue.
#3 MAY work but I prefer #2.

^
Ok. I have ordered a high quality USB 3.0 cable rated at 5Gbps. I will let you know the result when it arrives.

In the mean time, try the USB-2 port.
Datarate is very low.

An interesting post about Pi4 interference on USB ports here…

@OMR @Bruce_Osborne

The Pi4 specification says…

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

But the stick misidentifies itself as USB3.