[RENAMED] Mesh breakdown. Only 1-way communication with one of my devices

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.

Here's some examples of how I've been doing that:

def cmds = []
cmds << response(wave.indicatorV1.indicatorGet())

Here's another example:

		zwave.indicatorV1.indicatorSet(value: newValue).format(),
	], 300)

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


I wonder if this is related to a bug that was introduced in 2.2.0 which was fixed in an update 2.20.130

I’m on the latest update: Hadn’t seen that note before. Oddly, I didn’t have issues back then, but do now.

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.

try the following add a custom command:

def test() {
    return zwave.indicatorV1.indicatorGet().format()

BTW, the quickest way to get to the bottom of this is by sniffing the zwave frames.

Thanks for looking at this.

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.

Ok, I have results. I did 2 tests:

  1. 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().

  2. 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.

what works for me is:

sendHubCommand(new hubitat.device.HubMultiAction(delayBetween(cmds,500), hubitat.device.Protocol.ZWAVE))


sendHubCommand(new hubitat.device.HubAction(cmd), hubitat.device.Protocol.ZWAVE))

for single cmd

Yes, I have tried those too. And this was all working until the latest update.

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.

Have you tried:

sendHubCommand(new hubitat.device.HubAction(zwave.indicatorV1.indicatorGet().format()), hubitat.device.Protocol.ZWAVE))

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.

Thanks for the suggestions. I just tried out this method. Unfortunately, same result. Nothing comes back to parse().

I'm now assuming I'm going to have to sniff the z-wave frames, so I have ordered a dongle. So strange. This has been working well for over a year.

What device are you using?, if I have one I can test the get...

Cooper RFWC5

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.

I've updated the title of this thread to indicate that it's an issue with my mesh. Tonight I think I'm going to try to exclude and rejoin the device.

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.

1 Like

1 Like