Having some trouble with my black series dimmers. They seem to be flooding the zwave network with duplicate messages causing massive delays or simply failed actions.
Zooz 700 series S2 zwave stick
running zwavejs2mqtt hooked into homeassistant with the zwavejs integration.
I have 3 black series dimmers. 2 of them are connected to 2 separate loads (nodes 4 & 8), one of them is not (node 12). I created a zwave association group so the one that is NOT connected to any sort of load will control the other 2. This works fairly well, however i am not sure it is 100% the correct way.
Next problem comes in with trying to control these lights from homeassistant. since it seems like association groups only work when using local control and not through the network i created a “light group” in home assistant and aded nodes 4 & 8 to it. However, anytime that gets turned on/off in homeassistant the zwave logs get flooded with duplicate messages. the number of duplicates vary and it doesn’t happen every single time, but i would say about 80% of the time it simply does not work. Toggling the lights seems more reliable that trying to dim them but both ways run in to issues. Log below
2021-07-04 00:17:33.519 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 99 => 67
2021-07-04 00:17:36.672 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 67 => 67
2021-07-04 00:17:53.185 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 67 => 54
2021-07-04 00:17:56.334 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 54 => 54
2021-07-04 00:18:06.873 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 54 => 99
2021-07-04 00:18:09.408 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 99 => 99
2021-07-04 00:18:23.407 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 99 => 0
2021-07-04 00:18:26.496 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:18:36.359 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 0 => 99
2021-07-04 00:18:48.549 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 99 => 50
2021-07-04 00:18:51.595 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 50 => 50
2021-07-04 00:18:56.028 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 50 => 99
2021-07-04 00:18:59.005 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 99 => 99
2021-07-04 00:19:09.565 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 52
2021-07-04 00:19:09.987 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 99 => 52
2021-07-04 00:19:12.689 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 52 => 52
2021-07-04 00:19:12.946 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 52 => 52
2021-07-04 00:19:19.795 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 52 => 99
2021-07-04 00:19:20.012 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 52 => 99
2021-07-04 00:19:22.879 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 99 => 99
2021-07-04 00:19:23.139 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 99 => 99
2021-07-04 00:19:30.792 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 99 => 0
2021-07-04 00:19:33.942 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:34.031 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:34.115 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:35.085 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:35.728 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:36.057 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:36.569 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:36.757 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:36.788 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:36.873 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:36.957 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:36.987 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:37.021 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:37.089 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:37.331 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:37.355 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:37.514 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:37.817 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:37.859 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:37.960 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:38.040 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:39.084 INFO ZWAVE: Node 4: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:19:59.272 INFO ZWAVE: Node 5: value updated: 32-0-currentValue 0 => 255
2021-07-04 00:19:59.288 INFO ZWAVE: Node 5: value updated: 113-0-Home Security-Motion sensor status 0 => 8
2021-07-04 00:20:11.706 INFO ZWAVE: Node 5: value updated: 32-0-currentValue 255 => 0
2021-07-04 00:20:11.720 INFO ZWAVE: Node 5: value updated: 113-0-Home Security-Motion sensor status 8 => 0
2021-07-04 00:20:11.937 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 99 => 0
2021-07-04 00:20:12.202 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:20:15.298 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 0 => 0
2021-07-04 00:20:28.567 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 0 => 99
2021-07-04 00:20:32.484 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 99 => 0
2021-07-04 00:20:35.511 INFO ZWAVE: Node 8: value updated: 38-0-currentValue 0 => 0
First part is me controlling them from home assistant one at a time, not so bad. Then i turned on the light group, which worked. Then i turned the light group OFF at 00:19:30.792. One light did manage to turn off pretty quickly, but then 40 seconds later at 00:20:11.937 you can see the other one finally turned off. Kind of at a loss here, first venture into the zwave world but if i can’t get this performance ironed out. Node 4 is two hops from controller (node 4 - multiple neighbors - hub). The other 2 nodes here are direct to the hub. I am posting here as i am not noticing the same problem with other zwave switches i have that are controlled from homeassistant. Only these black series dimmers are giving me problems.
When you set up Node 12 to control Nodes 4 and 8, did you also set up either Node 4 or 8 to control Node 12? If so, and you did not properly set parameter 12, you may have created an infinite loop (which would flood the zwave network).
Is your goal to have 3 switches grouped together as part of a virtual 4-way setup (so any of the 3 dimmers controls all 3), or are you trying to do something else?
It’s a pseudo 4 way. As in if I operate either node 4 or node 8 independently I do not want them controlling the other switches. Only node 12 has associations to 4 and 8. I did not configure any associations on the others. Local control seems to be working. The real struggle is toggling/dimming the light group from home assistant. Where home assistant has a group that essentially creates a new single light containing nodes 4 and 8.
I feel like I could have a workaround but associations don’t work when controlled from home assistant/remotely. I see the config parameter for it but it stays set to [-1] Custom. If I disable it, [0] disabled, that sticks, but if I choose enable it just goes back to [-1] Custom. Then if I toggle node12 remotely it doesn’t trigger the associations. I feel like it should though as they function is present in other brand switches. Does that feature require the red series or something?
If you havent already, I recommend both power-cycling the dimmers by pulling the air-gap, and then reinterviewing the nodes in zwavejs2mqtt (you dont need to exclude/include, just a reinterview).
Paramater 12 should look like this in zwavejs2mqtt (I dont have any black series dimmers, so my screenshot is from a red series. It should look similar though)
If everything works fine locally , I wouldnt think the config parameters are the issue though. Have you double-checked to make sure you dont have any automations that could be causing issues?
This is a bug in the display of partial parameters on the LZW31/LZW31-SN in recent releases that you can safely ignore – anytime you see -1 for one of these you can just read it as 1. I’ve been meaning to file a bug, but haven’t gotten to it yet.
From my experience it is not just a display bug as the associations only work locally and not through zwave hub. If it was just a display bug i should still be able to toggle node12 remotely and have it also toggle its associated nodes, 4 and 8.
everything has been restarted/rebooted multiple times. home assistant and zwavejs2mqtt are both current/up-to-date versions. Firmware on dimmers is latest stable. Healed the network to make sure things were correctly routing.
it does happen with turning them on individually from homeassistant, however not nearly as frequently nor does it send quite as many messages. Whereas turning on the group either the on or the off is almost guaranteed to send the flood of duplicate messages
I haven’t experienced any change in behavior beyond the UI incorrectly showing the wrong sign for these values, but if you want to know for sure what is actually getting set for the parameter, turn on debug logging and check the logs.
You can also use the ‘Custom Configuration’ option at the bottom of the config tab to get/set the raw value and bypass the partial parameters entirely if you want.
I actually have experienced this quite a lot recently, among other performance issues on my Z-Wave network and have spent literally weeks trying to understand the root cause. I actually shared some very similar logs in an issue on the Z-Wave JS GitHub here.
I’ve since rebuilt my network multiple times over, moved from a 500 series to 700 series stick and also gotten a ‘zniffer’ stick setup. Unfortunately, none of these have been a complete fix, though I have managed to make incremental improvements in the overall performance.
IMO, what you are experiencing is not directly related the associations or the use of groups within Home Assistant, but is something you can likely reproduce anytime there is a significant amount of traffic being routed on your Z-Wave network.
Here’s an example from my own network of toggling 4 nodes (no associations) via the HA UI:
Z-Wave JS Log (Debug only for Node 15)
2021-07-05T01:39:51.366Z SERIAL » 0x011300a9010f076c01b103260100250000000037a6 (21 bytes)
2021-07-05T01:39:51.371Z DRIVER » [Node 015] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ route: 0, 0, 0, 0
│ callback id: 55
└─[SupervisionCCGet]
│ session id: 49
│ request updates: true
└─[MultilevelSwitchCCSet]
target value: 0
2021-07-05T01:39:51.380Z SERIAL « [ACK] (0x06)
2021-07-05T01:39:51.382Z SERIAL « 0x010401a90152 (6 bytes)
2021-07-05T01:39:51.384Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.386Z DRIVER « [RES] [SendDataBridge]
was sent: true
2021-07-05T01:39:51.399Z SERIAL « 0x011d00a93700000100ab7f7f7f7f00000300000000030100007f7f7f7f7fa8 (31 bytes)
2021-07-05T01:39:51.401Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.404Z DRIVER « [REQ] [SendDataBridge]
callback id: 55
transmit status: OK
2021-07-05T01:39:51.414Z SERIAL « 0x010e00a800010f056c0231ff0000ab59 (16 bytes)
2021-07-05T01:39:51.415Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.417Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
└─[SupervisionCCReport]
session id: 49
more updates follow: false
status: Success
duration: 0s
2021-07-05T01:39:51.420Z CNTRLR [Node 015] [~] [Multilevel Switch] currentValue: 1 => 0 [Endpoint 0]
2021-07-04 21:39:51.421 INFO ZWAVE: Node 15: value updated: 38-0-currentValue 1 => 0
2021-07-05T01:39:51.441Z SERIAL » 0x011300a90110076c01b203260100250000000038b5 (21 bytes)
2021-07-05T01:39:51.449Z SERIAL « [ACK] (0x06)
2021-07-05T01:39:51.452Z SERIAL « 0x010401a90152 (6 bytes)
2021-07-05T01:39:51.454Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.456Z DRIVER « [RES] [SendDataBridge]
was sent: true
2021-07-05T01:39:51.468Z SERIAL « 0x011d00a93800000100a57f7f7f7f00000300000000030100007f7f7f7f7fa9 (31 bytes)
2021-07-05T01:39:51.469Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.473Z DRIVER « [REQ] [SendDataBridge]
callback id: 56
transmit status: OK
2021-07-05T01:39:51.485Z SERIAL « 0x010e00a8000110056c0232ff0000a54b (16 bytes)
2021-07-05T01:39:51.487Z SERIAL » [ACK] (0x06)
2021-07-04 21:39:51.492 INFO ZWAVE: Node 16: value updated: 38-0-currentValue 1 => 0
2021-07-05T01:39:51.500Z SERIAL « 0x010e00a800010f056c0231ff0000ab59 (16 bytes)
2021-07-05T01:39:51.501Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.503Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
└─[SupervisionCCReport]
session id: 49
more updates follow: false
status: Success
duration: 0s
2021-07-05T01:39:51.520Z SERIAL » 0x011300a90111076c01b303260100250000000039b4 (21 bytes)
2021-07-05T01:39:51.528Z SERIAL « [ACK] (0x06)
2021-07-05T01:39:51.534Z SERIAL « 0x010401a90152 (6 bytes)
2021-07-05T01:39:51.535Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.537Z DRIVER « [RES] [SendDataBridge]
was sent: true
2021-07-05T01:39:51.546Z SERIAL « 0x011d00a93900000100ae7f7f7f7f00000300000000030100007f7f7f7f7fa3 (31 bytes)
2021-07-05T01:39:51.548Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.551Z DRIVER « [REQ] [SendDataBridge]
callback id: 57
transmit status: OK
2021-07-05T01:39:51.562Z SERIAL « 0x010e00a8000111056c0233ff0000ae40 (16 bytes)
2021-07-05T01:39:51.563Z SERIAL » [ACK] (0x06)
2021-07-04 21:39:51.569 INFO ZWAVE: Node 17: value updated: 38-0-currentValue 1 => 0
2021-07-05T01:39:51.577Z SERIAL « 0x010e00a800010f056c0231ff0000aa58 (16 bytes)
2021-07-05T01:39:51.578Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.581Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
└─[SupervisionCCReport]
session id: 49
more updates follow: false
status: Success
duration: 0s
2021-07-05T01:39:51.601Z SERIAL » 0x011300a9012d076c01b40326010025000000003a8c (21 bytes)
2021-07-05T01:39:51.609Z SERIAL « [ACK] (0x06)
2021-07-05T01:39:51.611Z SERIAL « 0x010401a90152 (6 bytes)
2021-07-05T01:39:51.613Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.615Z DRIVER « [RES] [SendDataBridge]
was sent: true
2021-07-05T01:39:51.625Z SERIAL « 0x010e00a8000110056c0232ff0000ca24 (16 bytes)
2021-07-05T01:39:51.626Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.633Z SERIAL « 0x011d00a93a00000100a07f7f7f7f00000300000000030100007f7f7f7f7fae (31 bytes)
2021-07-05T01:39:51.635Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.637Z DRIVER « [REQ] [SendDataBridge]
callback id: 58
transmit status: OK
2021-07-05T01:39:51.698Z SERIAL « 0x010e00a8000111056c0233ff0000b25c (16 bytes)
2021-07-05T01:39:51.700Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.744Z SERIAL « 0x010e00a800010f056c0231ff0000b143 (16 bytes)
2021-07-05T01:39:51.745Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.747Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
└─[SupervisionCCReport]
session id: 49
more updates follow: false
status: Success
duration: 0s
2021-07-05T01:39:51.787Z SERIAL « 0x010e00a800010f056c0231ff0000c032 (16 bytes)
2021-07-05T01:39:51.789Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.791Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
└─[SupervisionCCReport]
session id: 49
more updates follow: false
status: Success
duration: 0s
2021-07-05T01:39:51.837Z SERIAL « 0x010e00a800010f056c0231ff0000c032 (16 bytes)
2021-07-05T01:39:51.839Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:51.841Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
└─[SupervisionCCReport]
session id: 49
more updates follow: false
status: Success
duration: 0s
2021-07-05T01:39:51.952Z SERIAL « 0x010e00a800012d056c0234ff0000ca1f (16 bytes)
2021-07-05T01:39:51.956Z SERIAL » [ACK] (0x06)
2021-07-04 21:39:51.966 INFO ZWAVE: Node 45: value updated: 38-0-currentValue 1 => 0
2021-07-05T01:39:52.588Z SERIAL « 0x010c00a800010f0326030000c0b3 (14 bytes)
2021-07-05T01:39:52.592Z CNTRLR [Node 015] [~] [Multilevel Switch] currentValue: 0 => 0 [Endpoint 0]
2021-07-04 21:39:52.594 INFO ZWAVE: Node 15: value updated: 38-0-currentValue 0 => 0
2021-07-05T01:39:52.597Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:52.601Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
└─[MultilevelSwitchCCReport]
current value: 0
2021-07-05T01:39:52.645Z SERIAL « 0x010c00a80001100326030000caa6 (14 bytes)
2021-07-04 21:39:52.647 INFO ZWAVE: Node 16: value updated: 38-0-currentValue 0 => 0
2021-07-05T01:39:52.649Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:52.660Z SERIAL « 0x010c00a80001110326030000b2df (14 bytes)
2021-07-04 21:39:52.662 INFO ZWAVE: Node 17: value updated: 38-0-currentValue 0 => 0
2021-07-05T01:39:52.664Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:52.781Z SERIAL « 0x010c00a800012d0326030000ca9b (14 bytes)
2021-07-04 21:39:52.785 INFO ZWAVE: Node 45: value updated: 38-0-currentValue 0 => 0
2021-07-05T01:39:52.789Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:54.924Z SERIAL « 0x011300a800010f0a3202213400000000000000c0a5 (21 bytes)
2021-07-05T01:39:54.929Z CNTRLR [Node 015] [~] [Meter] value[66049]: 1.6 => 0 [Endpoint 0]
2021-07-04 21:39:54.931 INFO ZWAVE: Node 15: value updated: 50-0-value-66049 1.6 => 0
2021-07-05T01:39:54.934Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:54.939Z DRIVER « [Node 015] [REQ] [BridgeApplicationCommand]
└─[MeterCCReport]
type: Electric
scale: W
rate type: Consumed
value: 0
time delta: 0 seconds
2021-07-05T01:39:54.979Z SERIAL « 0x011300a80001100a3202213400000000000000cab0 (21 bytes)
2021-07-04 21:39:54.981 INFO ZWAVE: Node 16: value updated: 50-0-value-66049 1.6 => 0
2021-07-05T01:39:54.983Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:54.990Z SERIAL « 0x011300a80001110a3202213400000000000000b1ca (21 bytes)
2021-07-04 21:39:54.992 INFO ZWAVE: Node 17: value updated: 50-0-value-66049 1.6 => 0
2021-07-05T01:39:54.994Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:55.104Z SERIAL « 0x011300a800012d0a3202213400000000000000ca8d (21 bytes)
2021-07-04 21:39:55.109 INFO ZWAVE: Node 45: value updated: 50-0-value-66049 1.6 => 0
2021-07-05T01:39:55.112Z SERIAL » [ACK] (0x06)
2021-07-05T01:39:56.536Z SERIAL « 0x011300a80001130a3202213400000010000000a4cd (21 bytes)
2021-07-04 21:39:56.541 INFO ZWAVE: Node 19: value updated: 50-0-value-66049 1.6 => 1.6
2021-07-05T01:39:56.544Z SERIAL » [ACK] (0x06)
read your github issue and yes it does sound just like what i am experiencing. Thanks for that info, however all of this seems to be way over my head for debugging zwave network issues for the time being at least. Was trying to move away from my wifi switches but those have been extremely reliable and might just need to go back to them.
I did test this with both the Aoetec Zstick Gen5, as well as my current stick, the Zooz ZST10-700, neither made a difference. For the time being i will try and avoid using groups in homeassistant to change the lights but that is going to be a little prohibitive and might end up just putting my old switches back in.
Here’s an even better example of this behavior which I was able to capture while simply toggling the state of one node on it’s own. This looks to me like evidence of a firmware bug.
@EricM_Inovelli could you please take a look at this thread and in particular the GitHub Gist I’ve linked above?
Some additional details:
Node 01: Silicon Labs UZB-7 (firmware v7.15.4)
Node 02: Aeotec Network ZW189-C15 (firmware v1.3)
Node 17: Inovelli LZW31-SN (firmware v1.56)
All three of these nodes are in the same room and within ~20ft of each other and have a direct line of sight between them.
I have only seen this issue before on the Hubitat C7 running the 700 series chip. What we have had explained by our engineer is that the controller on the hub is not responding in time with ACK and the switch is sending duplicate messages (believing that the initial ones have been lost). This looks very similar but I am not sure if it is the same.
I am running a 700 series hub, however, i tested with a 500 series hub and was getting the same results. Novice when it comes to zwave still but if there is anything more i can provide to assist let me know how to go about doing so.
I am using a 700 series stick (Silcon Lab’s reference design SLUSB001A with firmware included in the 7.15.4 SDK. I was able to reproduce this with a HUSBZB-1, which is a 500 series stick.
The delay until the first ACK was only 10ms and only 5ms for the second. What is the actual timeout before retrying?
I’m also seeing this issue using an Aeotec Z-Stick Gen5+. It definitely causes pretty significant slowdowns when controlling a large number of switches.
For me this is most noticeable when traffic is high on my zwave network. For example, when triggering my goodnight scene that turns off ~20 Inovelli Red switches and dimmers, my network is unresponsive for 30-45 seconds after triggering the scene due to repeated messages. In some cases I see as many as 15-20 repeat value reports per node!
I’ve managed to improve things a bit using multicast through zwave_js (at least now the lights turn off quickly), but the network congestion caused by this is still an issue.