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

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.

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

1 Like

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?

Did you ever do any of my suggestions?

Sorry if I missed this but how many devices are we talking about here? Also, what is the range they are operating in? (one floor, two floors, just general distance for radios to operate in) How many mains powered devices, how many battery powered devices?
As I read this thread, I thought it isn’t any of this stuff with cables or ports. I think you have ghost nodes or something causing a lot of traffic. Could be a node that is reporting every few seconds swamping the network. Maybe the new stick caused a perimeter to be reset??? Guessing, but set log to debug and watch traffic. Supply info on above questions and we’ll figure it out

I did already try the trace logging on the z-wave binding but couldn’t see much to indicate potential problems. But to be honest I don’t know really what messages to search for ??

And I just tried ‘top’ and the biggest CPU consumer is the openhab process which is around 30% – so I guess that is not the problem?

Many thanks for the offer

  • not that many: 17 devices, of which 8 are battery powered
  • a regular house, 3 levels, brick construction, wood floors, ~15m corner to corner

Could you please explain what that even means?

There is one node in the stick that does not correspond to a physical device; and I don’t know how to remove it.

Ok. Will do.

Errr. Forgot to ask: what shall I look for?

^
PS let me add some more details…

  • On my OH2 system, I had most of the devices polling period set to their (fibaro & aeotec) default values of 24 hours, and I was relying on the ‘z-wave instant’ transmissions to get the data through. The response times where in the order of seconds.

  • On my OH3 system the ‘z-wave instant’ transmissions seem not to be that ‘instant’. The status does come through (and I don’t have to wait 24 hours for the poll). But takes ~10 minutes rather than just a few seconds.

  • Therefore on my OH3 system I am experimenting with reducing the polling period to 30 seconds (at least on the powered devices). That means that I do get the statuses in ~30 seconds again. But still slower than the several seconds I was used to…

I am getting trace logs at a rate of 80 MByte / hour :slight_smile:

Most likely this is the clue! I’ve had similar problems (with OH2). Removing dead nodes helped a lot.
Look here for instructions on how to do that with Aeotec Stick: Remove a ghost Z-Wave Node from HABmin - #8 by devTechi

I agree with Frank !!!

follow that link, or search this forum, there is software (zentools or something like that, runs on windows) if it can’t be done within OpenHAB (sorry don’t know OH3 very well yet)
A ghost node will bugger up everything and 99% of the time when folks are saying zwave worked great but now it is slow, it turns out to be a ghost node.

sorry, I miss spelled that, I meant parameters…
What I mean by that is that most zwave devices have various parameters, such as there reporting interval. I’ve seen where several devices have been set to have very short reporting intervals (like every 5 seconds or every 15 seconds) and the shear traffic they generate in a large system can swamp it. I thought maybe when you switched sticks, behaps such an interval got changed back to a default or something. Maybe just check them out and make sure nothing is to crazy
Anyhow, search and find the tools you need to get rid of the ghost node and I’m sure that will help. If you can’t find the software or a method, check back in here and I’ll dig around