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…
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.
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.
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…
- 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
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…
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.
Does it? Physically the plug seems only to have four pins inside…
I intuitively always connect USB 2 devices to USB 2 ports and USB 3 devices to USB 3.
I replaced my USB extender cable with a new ‘high quality shielded’ USB 2.0 cable (with only 4 pins/cores and external shield), and plugged it into one of the Pi4 USB 2.0 ports.
From our discussions, I think this must be the best possible configuration for minimum interference (best shielding, lowest number of cores, lowest number of Pi4 USB busses touched, and lowest Pi4 touched bus clock rate). Unfortunately it does not solve my original (slowness) problem. So I guess the slowness is not due to interference after all.
My feeling is that the slowness is because the sensor’s ‘Z-Wave Instant’ transmissions are not getting through, so it is falling back to the ‘Z-Wave Polling’ transmissions instead; which obviously take longer.
I don’t see anything in the Configuration Parameters that may have changed in the migration from OH2 to OH3 relating to ‘Instant vs Polling’ transmissions. Did something change in the OH3 version of the binding that could be causing this?