On average, sure. That gives you capacity to deal with motion sensors triggering and turning on light and having that be subsecond. Can you have more traffic sure. When does it break? Don’t know exactly.
I too have some of the ZEN15s that @madbrain does, and I have previously throttled the reporting way down, but not to the point you had recommended. In an hour I was getting 2k+ Rx messages. I just made some changes and am curious if I will notice an improvement.
I ran both Firefox and Chrome at the same time on my PC.
I was able to see the issue with no devices showing in the ZUI control panel in Firefox, and at the exact same time, all devices were present in the ZUI control panel in the Chrome window.
It looks like there has been a regression between ZUI and Firefox.
This is unrelated to the Z-wave device connectivity issues, as you pointed out, though.
Thanks. As it turns out, on Wednesday, the Z-wave stick fell on the floor for about one hour. The double side tape keeping it on the wall no longer held. I put an anchor between it and the USB cable. The errors dropped to a more reasonable level after that.
Here is what the controller statistics are now showing :
The dropped RX commands are now only about 3%.
Dropped RX messages are negligible.
Did you mean that you had no TX errors ? I also have none.
I do still have some timeout ACK.
I started looking at the diagnostic sensors for my devices. I have 68 nodes, and it takes a very long time to enable 7 diagnostic sensors for each, one at a time. That’s 476 sensors to enable, and it takes multiple clicks for each.
Anyway, I have seen wild variance between devices. For example 2 ZEN76 switches 5 ft apart, in separate wall boxes, can have 100ms and 500ms round trip times respectively.
An HC620 lock in the downstairs bedroom has 1500ms round trip time.
A Zen76 located inches from it has 60ms RTT.
A First Alert alarm in the same room has only 31ms RTT.
Another HC620 is at 1400ms. Another at 900ms, 900ms.
The ZEN76s in the home theater are at 270ms, 100ms, 74ms. All 3 in the same wall box.
The HC620 near my hot tub, the most distant from the controller, has an RTT of 3500ms. That is the longest of all devices I have enabled the sensors for. I still have about 35 nodes to enable them for.
If you go into the entities dashboard under settings, you can sort by disabled entities and also search by entity name, then multi select and enable many at once.
You may want to consider recalculating routes one by one for line powered devices starting with the ones physically closest to the stick.
I have no dropped RX or TX, I get a few timeouts a week from the same devices - aoetec multisensor 7 and aoetec smart switch.
Here’s how it looks after 45 hours. You’ll see that basement sensor has a very high RTT with one TX. That’s is zwavejs reading the lux sensor and it takes 500ms for it to respond 
But yes, high RTT are generally not good.
RTT do vary. The way I read this, is the device changed routes and so now it takes longer. Most devices seem to behave like this. So I’ve learned not to worry about it.
Thanks ! That was extremely helpful.
Could you please explain to me how you created your dashboard with all the devices and various columns ?
My skills at creating dashboards, like most things graphical, are minimal at best. Especially now with the macular degeneration. It’s been 3 years that I have been using HA and my dashboards mostly use the Entities card. I have not figured out how to do tabs the way you have, either.
I’d like to do the same tracing for my Wifi devices (Wiz bulbs) which also have serious latency and signal strength problems.
How would I do that ?
I can easily live with RTT for 500ms. It’s the ones >1s and with commands that randomly don’t come through that bother me.
Sometimes, I’ll flip a bunch of switches in my dashboard, and I get 1 or 2 errors, but I have no idea which switch the errors are for, unfortunately, which is frustrating.
FYI, this is the message count for my 3 ZEN15 yesterday.
JP@HIGGS MSYS /c/Scripts
$ grep -i "Node 086" /d/Downloads/zwavejs_2025-03-14.log | wc -l
224
JP@HIGGS MSYS /c/Scripts
$ grep -i "Node 135" /d/Downloads/zwavejs_2025-03-14.log | wc -l
6743
JP@HIGGS MSYS /c/Scripts
$ grep -i "Node 024" /d/Downloads/zwavejs_2025-03-14.log | wc -l
157
Clearly, the parameters did not work for Node 135. I really don’t know why. All 3 units are on the same firmware v1.6, and had the same Z-Wave parameters.
I’m going to exclude and re-include the offending one.
The dashboard wasn’t easy. Basically I have a CSV file (aka excel) with all my zwave devices in it and various parameters (like are they battery powered), then I hit the go fast button and it generates the displays, packages and automations needed to monitor the devices - this gets pushed into HA and then I have the dashboard. Glad to share it, it’s done with shell scripts.
If you are running zwavejsui open up a device, select advanced, select rebuild routes. This will rebuild the route for a single device. Somewhere there is an option to “rebuild all routes” - do not do this, it’s problematic and not recommended by the experts in this forum.
Maybe this is really rudimentary, but I did not set the same parameters for my ZEN15’s. I varied the numbers by the device and its history. For example, the ZEN15 that my server runs through, I set this:
151: 40w
152: 10%
171: 300 seconds
172: 3000 seconds
173: Disabled
174: Disabled
And the ZEN15 that my dishwasher runs through:
151: 3w
152: 10%
171: 300 seconds
172: 3000 seconds
173: Disabled
174: Disabled
I did that because I care if the dishwasher changed 3 watts, but I don’t really care if my server changes 40 watts.
If you’re still getting a ton of messages on 135, check what you have on 151 and 152 vs what the power usage is.
Thanks !
I’d love to see the scripts you used to get your dashboard.
I have been writing this sort of scripts also for keeping track of devices, but so far not for Z-wave devices in HA - for IP devices with pfSense and smokeping. And I’m planning on extending my scripts to Unifi. And maybe synchronize with HA device names too, some day. My scripts are not ready for public consumption yet, though. It helps that pfSense / smokeping / Unifi all have a GUI already, or I would never be able to present the data properly.
I guess I should have made it clear that I use the ZEN15 strictly as on/off switches. I don’t rely on the power/voltage/current reports. The reason for that is that the Z-Wave bandwidth is just too low.
I have a lot of plug-in devices that I monitor, including non-smart appliances such as my trusty 15 year old Miele dishwasher. I settled on TP-Link Kasa KP125 Wifi smart plugs with energy monitoring. At some point, these could be had from Target and Best buy for about $15/piece. I have a little over 50 of them. Not all of them are currently in use. They work perfectly for the “appliance has finished” blueprint, which I have been using for years. The main downside of the KP125 is that you need internet access to initially set them up. If you live in a cabin, you won’t be able to set them up on local Wifi. Once you are past the initial setup, though, they work fine locally without an ISP. I really wish that wasn’t the case.
I use the Z-wave smartplugs mainly for network devices, such as my pfsense wired router, cable modem, unmanaged ethernet switches, Wifi access points. Obviously I can’t use Wifi smartplugs for those devices. So, I bought the ZEN15.
2 of the ZEN15 are behaving just fine. The third just isn’t. It insists on sending unwanted power reports even though I disabled everything.
This is after node 135 was excluded, the device factory reset, and the device re-included as node 173 :
$ grep -i "Node 173" /d/Downloads/zwavejs_2025-03-15.log | wc -l
6005
I guess this part of the thread needs to be redirected to Zooz support.
1 Like
Try setting those high, like 100 watts, may help while you get it sorted out with Zooz.
Thanks. I’ll give it a shot.
Meanwhile, I started running diagnostics (health checks) on various nodes. First, the nodes closest to the controller. I found this one particularly disturbing. This is a ZSE18 motion sensor. It is powered via USB, not batteries. It’s located on a wall, 5ft from the ZST39 controller, with a direct line of sight. The route shown in ZUI is direct to the controller - no repeaters.
Yet, it gets a 3/10 rating.
I really don’t know what to make of it. Is this a problem with the motion sensor ? The stick ? RF signal interference ? Or overloaded Z-wave bus from other malfunctioning device(s) ?
I can temporarily unplug all the plug-in and battery Z-Wave devices, but it’s a bit of a shot in the dark, and there are a lot of nodes to go through. My HAOS host being a beefy PC won’t last long on UPS if I want to debug without the hardwired switches.