I have a driver I maintain that just recently stopped working:
By putting in debug logging statements, I've narrowed it down to that it's not able to send IndicatorSet or IndicatorGet commands out to the device anymore, and it no longer receives IndicatorReports.
Up until just recently (I think the latest update, but I just noticed the issue today), shortly after sending these, I would get a string back to my parse() method that could be parsed into an IndicatorReport. Now, parse() never gets called after sending out an indicatorGet. And the device doesn't update its lights after sending an indicatorSet.
(Unfortunately, that's as far as I can debug. I don't know if HE is not sending out the indicatorGet, or if the device is getting it but not sending back the indicatorReport. However, one additional clue is that the indicatorSet command is not having any effect on the device either, so maybe nothing is getting sent out.)
The device DOES send back parseable reports for when I push buttons on it. Those do get back to my parse() method.
Nothing has changed in the code, and this has been working for over a year with multiple devices and just stopped. Any ideas? CC @bravenel
It's similar to this earlier issue that @mike.maxwell helped me with:
However, for that one, parse() was called and I needed to explicity tell it what version of z-wave command to parse. For this new issue, parse() isn't getting called at all. Any ideas @mike.maxwell? Thanks!
which means the device isn't sending anything, perhaps because it's not receiving the indicatorGet?
The first example you provided shouldn't work at all since the class starts off with wave, instead of zwave.
That first "wave" was a typo from transcribing it. It's correct in the driver.
Yes, I think the device is not receiving the indicatorGet or indicatorSet commands. It is sending back other commands to parse() though. (Such as BasicSet and SceneActivationSet.)
I will try out the custom command and get back to you.
First, I added a custom test command like yours into a driver for a z-wave bulb. Switched the command to be one to turn the bulb on. I wanted to make sure I was hooking up the test command correctly. The bulb did turn on, and the bulb sent a message back to parse().
I did the same thing sending an indicatorGet to my RFWC5. parse() never gets called. I think the hub is not sending out the indicatorGet command.
To sniff zwave frames, does that require buying test hardware?
It requires a ZWave controller that can be reprogrammed with ZNiffer firmware. You may or may not be able to restore it to it's original use, therefore it's advised to purchase one specifically for this purpose. $30-40
I find that returning commands from functions only works for functions expected to return a command like "updated", the ones defined by capabilities and as command in preferences.
Simply returning zwave commands from functions (if they are not cases mentioned above) or using sendHubCommand(cmd) (this is SmartThings thing) does not work.
I notice that you use response(...) in the driver afaik this does not work with Hubitat. Maybe they are changing something with it but it never worked for me. The functions above expect cmds to be in .format() form as far as I know.
[edit]
Also I noticed that you clear association groups. I'm not sure which group is the main one for this device (it's group 1 for modern devices, last group for older ones) but if you remove hub from the main association group the device will probably not respond to you. I assume this is not an issue since you mentioned that it worked before but just one more thing I noticed.
Curiouser and curiouser... Well, I don't think it's a hub issue anymore. It's either that device or my z-wave mesh.
I installed a second RFWC5 in my house, and it's working perfectly.
So that means the symptom list is now:
The hub IS sending out commands.
The device is not receiving (or if it is, it's not responding to) any commands.
But if the device sends messages back to the hub, they DO get there.
I'm not sure why the device would be able to route back to the hub, but the hub couldn't route to the device. I have a UZB3 on the way, so I can try out the zniffing thing.
Well, chalk one up for "it's almost always a mesh problem." I excluded and reincluded the device and now it's working perfectly. I do wish I knew how the mesh got messed up, but I'm back in working order now.