Sluggish response times with Zooz 700 Series Controller when turning a device on and off quickly

[kris-anderson]

My Zooz 700 Series USB stick us running the latest 7.18.3 firmware.

I'm running the latest version of Z-Wave JS UI 8.11.0.598632a in a Docker container. That has Z-Wave JS version 10.12.0.

I've had a problem for a while now that I've never been able to accurately reproduce until tonight. There will be times that my network is sluggish, and when I activate something, it might take 3-20 seconds before the device responds.

I was reading tonight about 700 series sticks not handling many requests at the same time, and that got me thinking. Within the Z-Wave JS UI interface, if I turn a plug of mine on and off fairly quickly, within 4-8 cycles of turning it on and off, the device starts to get sluggish in it's response (going from activating nearly instantly, to taking 5-10 seconds to respond). In some cases, it won't respond at all. When that happens, I'll see a number of "Timeout Response" errors start appearing for that device in the GUI.

I'm happy that I can reproduce this now and I know that it's related to something like bandwidth with my stick... but where do I go from here?

Is this a known issue that would be resolved with a 500 series stick? If this isn't a known issue, and might be related to Z-Wave JS UI, is there some troubleshooting and logging I can do to help get this narrowed down and possibly fixed?

[robertsLando]

@kris-anderson Do you have an extension cable for your usb stick?

BTW I cannot help you so much with this problem, I know 700 series stick have some problems, @AlCalzone for sure can give you the answer you are looking for

[AlCalzone]

Please make a driver log, loglevel debug and attach it here as a file (drag & drop into the text field).

[kris-anderson]

I do have my USB stick on an extension cable and mounted away from the server.

My current log file is over 30MB in size. Can I force a log rotate to happen against the file so I can provide a clean sample of my logs of this event happening?

I tried to run logrotate within my docker container, but my container doesn't have logrotate installed. There's a zwavejs_logrotate.json file in my store/logs/ folder though, and I see compressed log files that have been rotated, so I know it happens :)

[AlCalzone]

My current log file is over 30MB in size. Can I force a log rotate to happen against the file so I can provide a clean sample of my logs of this event happening?

Driver logs are already rotated daily and kept for 7 days (by default). This is baked in and does not need external utilities.
You should have multiple files called zwavejs_<date> in your log folder. If they are all 30+ MB, there is either something spamming your network like crazy or you have too much auto-reporting going on - both of which would explain what you are experiencing.

Anyways, you can just delete the current file and it will start fresh.

[kris-anderson]

Here is a log file that I tried to keep as small as possible and reproduced the event by turning some plugs on and off repeatedly.
zwave-js-ui-store.zip

[AlCalzone]

Node 32 (the one you're switching) seems to have a very weak connection:
1st attempt, reached via direct connection after 1.6 seconds and 2 routing attempts (the failed one went through node 14). The ACK RSSI is -90 dBm, which is ~10-20 dBm above background noise. Some of your other nodes reach -49 to -28 dBm, which is MUCH MUCH better. Meanwhile, node 32 happily sends its meter reports, which arrive before the ACK of the outgoing command, and likely caused it to take that long. 3 of those are repeated, probably because the node didn't get the controller's ACK.

2nd attempt is now successfully routing through node 14 and "only" took 210 ms. The ACK from node 14 has a better RSSI of -70, but the ACK from node 32 to node 14 was -100 dBm - barely noticeable.

The next couple of attempts were the same but quicker.

Then, an attempt takes 4 routing attempts, ends up with a direct connection and 240ms, and again an ACK RSSI of -91 dBm. This time, only a single meter report (A) is received and the other (W) as well as command confirmation get lost.

[AlCalzone]

A 500 series controller can possibly help, but you might be able to improve the mesh and get the 700 series one working too:
Using health checks, work your way from the controller to the further away nodes, starting with the ones that are close. If any health check results are mediocre to bad, see if you can improve the results by changing the device location, or adding repeaters inbetween.