I'm trying to wrap my head around what this means but I was watching the logs just now while I was tinkering with an unrelated LAN projector driver and this popped up.
This is odd because the response to a ConfigurationGet is a ConfigurationReport. But the driver wasn't receiving the "report." It was receiving the "get" and a lot of them. For reference the parse looks like this.
def parse(String description) {
logDebug "parse(description)"
logTrace "description: $description"
def result = []
def cmd = null
try {
cmd = zwave.parse(description, CommandClassVersions)
}
catch (e) {
log.error "zwave.parse(description) failed to parse description: ${description}"
}
if (cmd) {
result += zwaveEvent(cmd)
}
else {
log.warn "Unable to parse description: $description"
}
return result
}
Then there are, of course, many overloads of zwaveEvent like in many other drivers with different method signatures for different types of parsed commands. It hit the default where the command wasn't handled because there is no overload for ConfigurationGet.
Yeah, your device is sending a configurationGet command, and the driver isn't handling it.
In any event there's something up with the actual device, even if this command was of value, it shouldnt be sending that many of them that frequently...
If not this device maybe some other device. I tend to see this happen in my logs with on/off events on other devices. The thing is... they are very difficult to troubleshoot even with a Z-Wave sniffer. My sniffer doesn't have a good antenna and even if it did it doesn't pick up everything perfectly because it is not added to the mesh, it's not a Z-wave device so it doesn't get packets forwarded to it. It instead just tries to pull the unencrypted messages out of the air on its own by examining the air with a radio in the correct frequency.
I guess my point in bringing this up is that it would be nice to have some additional troubleshooting tools available to us. Maybe some simple analytics to help us find bad devices (like devices that should be repeating that aren't or have weak signal or duplicate messages. Or maybe a packet log of what the hub receives.
I did notice one thing for sure. When one of these duplicate log events occurs the hub is typically not an innocent bystander. The Z-Wave sniffers log goes crazy with events coming back out of the hub to all sorts of random devices and sometimes those random devices reply back with nonsense and make it worse (at least according to my sniffer). I tend to believe it as well because eventually even though I don't see anything in the logs for devices turning on or off if it goes on for a minute or two like that the log will get spammed with queue full exceptions.
It would be fantastic if I had a packet capture or packet log or something to go back to with the hope of finding the device that started the shenanigans. I have over the last two weeks really focused on stability by cutting power to two devices a day and observing if the behavior is better or worse. So far I haven't found it to help at all. The missing devices make the mesh worse and potentially compound the problem.
I'm almost 100% this is not a weak mesh problem either. I have around 100 Z-Wave devices in a confined area. It would be nice to see a node map without having to build it ourselves and also the RSSI associated to packet log or something.
If it takes me this long to track down an issue there are going to be a lot of people that never will track down their issues and give up.
