Ah, you may be on to something, @coreystup !
Here are two downloadable packet dumps from wireshark (you’ll obviously need the wireshark application to open these): one for the traffic on the inovelli blue switch and one for the traffic on the GE/Jasco zigbee switch (acting somewhat as a control). Both experiments were run by binding each switch to the same single Hue bulb and pressing either up or down on the respective paddle and monitoring the traffic. Both of these dumps start with the initial packet being sent from the switch to the bulb and ends when the traffic tails off. The GE switch generates a total of 34 packets (none being of the broadcast type) over 0.1 seconds, while the Inovelli generates 213 (133 being broadcast) packets over 1.8 seconds.
I’m honestly unsure of exactly how to interpret all of these packets, but I can spot some differences between the GE vs Inovelli packets that may be worth noting:
Starting with the GE:
We can see it send a packet (two of the same actually- redundancy?) to the coordinator at .04s to tell it the new state of the switch (Off) with flags of: “acknowledge request” =
True and a “Disable Default Response” =
False.
Then, at .11s:
We can see the coordinator sending back a “ZCL: Default Response” of “Success”. Presumably letting the switch know that it received the packet and all is good.
Now, moving to the Inovelli:
We can see the same type of reporting packet sent to the coordinator at .05s with flags: “acknowledge request” = True, but (in contrast to the GE) with a “Disable Default Response” = True as well. Is this telling the coordinator that it’s expecting an acknowledgement, but at the same time telling it not to send a response? Looking through the rest of the packets, we never see the coordinator send back a “ZCL: Default Response” = “Success” message to the inovelli switch (it does send a few things to it that look like route discovery things, but never a “success” message as we saw with the GE switch).
The only odd thing about the “inovelli panics when it doesn’t get a response from the coordinator” hypothesis is that the inovelli only “waits” ~0.04s between sending the packet to the coordinator and then starting its flood of broadcast messages. Whereas the GE switch actually doesn’t even receive its response from the coordinator for about 0.06s after sending its packet to the coordinator.
Anyhow- is this helpful? Again, the technical aspects of zigbee are new to me so I’m grasping at straws a bit here, but just attempting to provide enough info to help troubleshoot this for the folks who are having these issues.
And just to note: these two dumps are not anomalies: this is consistent traffic behavior that I’ve always seen on both the GE switch as well as all of my inovelli switches. I strongly don’t think this has anything to do with a poor mesh/issues in communication. The switches and the Hue bulb in this experiment are all within ~6ft of the coordinator and each other and none of my installed switches are in the bad batches.
edit: oh, and these are the zigbee keys I have configured in wireshark for my networks to be able to see the fully decrypted packets:
“f0:8e:97:53:9c:05:ca:c5:f5:70:0c:28:93:ec:f8:dc”
“5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39”
“a38895d224d436924aba8cd7da4f4d9d”
“01030507090b0d0f00020406080a0c0d”