I agree with that in general.
There are RARE times when there is little choice (like why there is a dedup option on the generic motion sensor driver), but in general the driver should be reporting what it receives.
Simply an appeasement for what should be considered faulty device firmware...
I tried at least 10 switches/dimmers, even the 1 GE model I have and all exhibited the same issue.
I mean if there is more I can do to figure this out I do not mind, please point me in the correct direction and I will diagnose this more.
No argument from my side. 
1 Like
Yet with the same firmware (latest version) on these devices this issue did not occur in the past....
I hear ya. Still doesn't mean it isn't the device, a bad route, interference, etc. Or it could 100% be the hub radio firmware, hub software, a driver, a faulty C-7 hub (rare, but could theoretically happen), etc.
If you want to know for 100% sure, you have to get a zwave sniffer and put in the time analyzing the logs.
We are all just guessing at this point as there is no data. Issues like this are very hard to troubleshoot without low level tools.
I do have a Z-stick can that be used as a Z-wave sniffer?
Not sure. While I have a z-stick (sitting right in front of me, actually), I have used a UZB stick for sniffing for years. Typically you have to flash special firmware on the stick to get it to relay/cough up all messages it hears.
There are a few threads on here about zniffer / sniffer (same thing). Could probably ask in one of them.
Would you be able to point me to one of these threads, if you don't mind. I mean I can search if you don't have any saved.
Here's one for Zigbee:
2 Likes
Somebody did this for this exact problem a while back. Concluded that the hub was sending a lot of "get" commands. See Z-Wave storms - looks like HE Hub's fault?
2 Likes
Exactly. Markus is amazing and he discovered at least one other "issue" with zigbee on HE. Mike is aware
1 Like
Yes, but you will also note in that thread that there was no agreement in the end that this was a hub "bug". Might be, might not be, depends on how you look at it I guess. There was no conclusion in that thread at all, actually - it quickly diverged to other matters altogether.
It would be interesting if someone could show that the same thing happens on the C-7 where the queued command behavior is supposedly different than it is on the C-5.
I'll run my sniffer for a while and see if I can catch one of my events on my C-7. Not optimistic, though, as in general my system seems to be running as expected. Just got to factory reset one of my surface pro's 1st so I can put it by the hub.
I upgraded to 2.2 firmware and turned down/off all reports and they finally STFU. Man they were chatty
I posted about similar issues yesterday. Something totally went haywire in the Z-Wave mesh and/or hub. Mesh froze for some devices (dimmers), other devices (motion sensors) showing multiple logs per second. Stock drivers, nothing recently changed.
1 Like
Yes, I need to but it's like armageddon around here when the internet goes down. I'll get to it eventually.
@JasonJoel, @mike.maxwell - Maybe you will understand this Zniffer output. I have a simple Central Scene capable Dimmer (device 27). Z-Wave details shows its routed to the Hub along the path 01 -> 0D -> 1B. So that's 1 - > 13- > 27 in decimal. From the Hubitat web interface, with the switch already off, I click the "Off" control button on the web interface. Lines 1-15 show the captured the Zniffer output below. Note how the Source for a number of entries is "2" (see, e.g., lines 1, 5, 6, 10, 13) - this strikes me as very odd as the Z-Wave interface is device "1". This exchange starts with the Hub and it seems to me that the Hub, from the very beginning of this transaction, is sending the wrong "source" information in the packet sent to the dimmer which would be a Hub error. The dimmer then responds to that same source #2. I noticed in other Zniffer post from others, the Hub does seem to be device #1.
Further, if I generate the "off" from the physical dimmer itself rather than the Hub, it shows communication to the Hub as node "1", not "2" which is what I would expect. This is shown as lines 16-30 of the Zniffer capture.
Perhaps this is a clue to the problem of multiple events. If I'm reading this right, it looks like there is a packet formatting problem for packets originating from the hub with the wrong source address being inserted.
This is on a C7 hub with firmware 2.2.3.145. The device is joined non-secure.
Everything's fine until we get to the multi level reports.
It's sent from 27 to 13, then 13 to 1, 13 doesn't get an ack from the hub so it sends it again.
It looks like the sniffer is closer to the endpoint devices than the hub, so it's hard to tell if the hub sent the first ack or not, but in any event 13 didn't get it.
Node Id 2 is a virtual node used by the hub.
I guess I'm happy / sad on that one. Happy that nothing wrong is shown. Sad that this wasn't a clue to the problem with the multiple event flood that I and others have been having.
PS - the Zniffer PC was about a foot away from the hub, but maybe the hub just has a better antenna / receiver.
Just for reference I restored back to FW version 2.2.2.129 and here is the results from one of my dimmers. This is two actions turning on the switch and then off.
Here is the same procedure but on FW version 2.2.3.148.
The 2.2.3 version seems to be doubling up the events, or at least it appears that way. Both dimmers were turned on from the web UI.
Also I noticed on 2.2.2.129 that the physical and digital events are displayed correctly, at least for the generic driver.
1 Like
