SetLED for ZEN32 unreliable

[youngbru]

I have a Webcore Piston that manages the LED color for a button of a Zooz ZEN32 scene controller. It has been working well for the last few weeks since I set it up, but it failed to set the LED properly last night and I am not sure why.
I am using a button 3 of the ZEN32 (Scenes is the device name, it is dev221 in logs, and it is referred to as Switch68 in the piston below) to turn of a group (Switch 41 in the piston - 'Head to Bed' in logs) with a bunch of devices. It basically turns off all the lights that may be on before I go to bed. A subset of those devices is also set up as a second group (Switch 7 in the piston - 'Basement Devices' in the logs). I am using Zooz Scene Controller (ZEN32) driver (v2.2.1 dated 12/4/2023) from Robert Morris @ bertabcd1234 for this device.

The idea is for the indicator to tell me if any lights in the 'Head to Bed' group are on by being white. Green indicates that only some lights in the basement are on, and blue tells me that all of the lights in the 'Head to Bed' group are off.

Last night, when I pushed the button, all lights were properly turned off, but the indicator stayed white. Looking at the piston log, it sent the proper command to turn the LED blue and I see the SetLED command in the device events but not in the hub logs. But the logs never seem to show that SetLED command even when I know the LED was changed.

Any ideas where the problem lies?
Piston seems to have worked properly, Hub thinks that the SetLED command was sent. But LED didn't change. Is there someplace else to look to see if the Z-Wave command was actually sent?

Here is the piston:

Here are the events from the Zen32 Events tab:

Note the I got impatient with the LED not changing and pushed the button a couple of additional times.

Here are the traces from Webcore:
2/3/2024, 11:23:49 PM +356ms
+4ms ╔Received event [Scenes].pushed/physical = 3 with a delay of 31ms, canQueue: true, calledMyself: false
+42ms ║Runtime (14022 bytes) initialized in 2ms (v0.3.114.20231008_HE)
+43ms ║╔Execution stage started
+60ms ║║Command optimization: Skipped execution of device command [Head to Bed].off() because it would make no change to the device. (1ms)
+86ms ║╚Execution stage complete. (42ms)
+92ms ╚Event processed successfully (89ms)
2/3/2024, 11:22:11 PM +232ms
+5ms ╔Received event [Scenes].pushed/physical = 3 with a delay of 30ms, canQueue: true, calledMyself: false
+229ms ║Runtime (14017 bytes) initialized in 2ms (v0.3.114.20231008_HE)
+230ms ║╔Execution stage started
+250ms ║║Command optimization: Skipped execution of device command [Head to Bed].off() because it would make no change to the device. (1ms)
+284ms ║╚Execution stage complete. (53ms)
+291ms ╚Event processed successfully (287ms)
2/3/2024, 11:22:08 PM +119ms
+2ms ╔Working queued event [Head to Bed].switch = off with a delay of 248ms, canQueue: false, calledMyself: true
+10ms ║Runtime (13978 bytes) initialized in 3ms (v0.3.114.20231008_HE)
+12ms ║╔Execution stage started
+216ms ║║Executed device command [Scenes].setLED(3.0,blue,60.0) (157ms)
+221ms ║╚Execution stage complete. (210ms)
+227ms ╚Event processed successfully (225ms)
2/3/2024, 11:22:07 PM +983ms
+3ms ╔Working queued event [Basement Devices].switch = off with a delay of 3687ms, canQueue: false, calledMyself: true
+10ms ║Runtime (13990 bytes) initialized in 3ms (v0.3.114.20231008_HE)
+11ms ║╔Execution stage started
+90ms ║║Executed device command [Scenes].setLED(3.0,blue,60.0) (28ms)
+97ms ║╚Execution stage complete. (85ms)
+104ms ╚Event processed successfully (102ms)
2/3/2024, 11:22:02 PM +89ms
+3ms ╔Received event [Scenes].pushed/physical = 3 with a delay of 131ms, canQueue: true, calledMyself: false

Note that some of the initial button push log fell off the bottom of the log by the time I copied it.

Hub Logs for the Scenes device (dev221):
dev:2212024-02-03 11:23:49.323 PMinfoScenes button 3 was pushed

dev:2212024-02-03 11:22:11.201 PMinfoScenes button 3 was pushed

dev:3542024-02-03 11:22:07.870 PMinfoHead to Bed switch was turned off

dev:2212024-02-03 11:22:01.957 PMinfoScenes button 3 was pushed

dev:3542024-02-03 12:15:59.801 AMinfoHead to Bed switch was turned off

dev:2212024-02-03 12:15:58.888 AMinfoScenes button 3 was pushed

[jtp10181]

I have a LED color change for the status of my locks, on two ZEN77 switches. I have issues with these some times also. I think possibly due to the rules stepping on each other but I have not looked that deep into it.

Most likely situation for you is the Zwave mesh was overwhelmed and the command never made it to the device. Happens sometimes unfortunately. A fully functional "supervision" implementation on the driver could eliminate this by retrying command the device did not respond to. Unfortunately it is not that easy to implement properly. Would be a lot easier if the hub had some built in methods for it but all the code is left to the driver.

[youngbru]

Thanks for the reply. So if it is just Z-Wave traffic, if I turned on device optimization (most times I use it, there are only a few lights that actually need to be turned off) that would reduce the number of commands sent, and if I turn on metering, that would spread out the traffic. Do I have the right?

Long term, I may bite the bullet and go through my Z-Wave devices one-by-one and exclude and re-include without S2 security. I built my network with S2 Security turned on for almost all of my devices (Almost all Zooz) but from what I have read since then, I would probably be better off without using security. I think you have been one of the proponents of that to increase network speed and reliability.

Back to the setLED command, if I come back and check say 10 seconds after I try to set the LED, to see if the LED is actually the correct color, will the hub actually query the device for the LED color setting, or will it just use an internally-tracked device state which may not represent reality?

[jtp10181]

@youngbru

if I turned on device optimization (most times I use it, there are only a few lights that actually need to be turned off) that would reduce the number of commands sent, and if I turn on metering, that would spread out the traffic. Do I have the right?

Yes and Yes

I would Keep S2. If I ever get around to rebuilding my mesh I am going to go back to all S2.

@youngbru

Back to the setLED command, if I come back and check say 10 seconds after I try to set the LED, to see if the LED is actually the correct color, will the hub actually query the device for the LED color setting, or will it just use an internally-tracked device state which may not represent reality?

Thats going to greatly depend on the driver. I don't think the community driver tracks the color at all, it just a send it and forget it type of thing.

[youngbru]

OK, thanks. I thought I remembered seeing you post that you thought removing S2 made your network more reliable and faster. Did I remember wrong? Why do you want to go back to S2?

On a different note, why do the SetLED commands not show up in the log even though they are shown as an event for the device? Is there anywhere one can look to see each and every command sent/received over the Z-Wave network?

[hydro311]

FWIW, about a year ago (maybe 2? who knows anymore ) I moved everything I could over to S2 -- for me, that's currently 28 out of 30 ZW devices.

It's been a definitive win for me -- my mesh has never been better. The only gotcha is that the built-in ZW firmware updater doesn't work for S2 devices, but these update steps work great instead.

[youngbru]

I have 88 Z-Wave devices in my network, 65 of them use S2. I sometimes get long delays and I was under the impression from reading other threads that removing S2 made things faster and more robust, albeit at the potential risk of an outside device snooping and/or spoofing. But at least in my environment, the risk of that is very small. And the risk should that happen is mere annoyance, not actual harm.

[jtp10181]

@youngbru

I thought I remembered seeing you post that you thought removing S2 made your network more reliable and faster. Did I remember wrong? Why do you want to go back to S2?

That was on the C7 before it got Zwave firmware updates. Zwave was very broken on the C7 initially. I mainly just want to rebuild my mesh which got messed up slightly on the C7 at one point. When I do rebuild it I will join everything with Smart Start using S2.

@youngbru

On a different note, why do the SetLED commands not show up in the log even though they are shown as an event for the device? Is there anywhere one can look to see each and every command sent/received over the Z-Wave network?

Logging is determined by the driver. Sometimes debug logging will show you more. The Zwave logs show some info, I think it is pretty much useless though.

[bertabcd1234]

@youngbru

On a different note, why do the SetLED commands not show up in the log even though they are shown as an event for the device?

Are you using my driver? If so, it will log commands sent if you have "Enable debug logging" enabled. (Keep in mind that this auto-disables after 30 minutes, per Hubitat convention -- driven by the fact that it's normally only useful for troubleshooting. You can delete the scheduled job if you really don't want it to.) Some built-in drivers do this, too, though it's not a convention and depends on the author's preferences (many newer ones do).

In any case, what's showing up on "Events" is probably just the fact that the command was sent, not that an event was generated. Contrary to its name, this page shows both (as of a few firmware versions ago) -- a great help for troubleshooting since you don't need to rely on the driver to log anything, though you'll normally get more information (like any parameters) if it does. But as mentioned above, the two are not related in any way; this is just information known to the platform and is an authoritative source, whereas logging depends on your driver and its options.

Some of my Z-Wave drivers also attempt retries if Z-Wave Supervision suggests a failure, but I don't think I ever added that to this driver. It also doesn't always help (if it failed once, trying again in a few seconds might also fail). But in any case, that's only available with secure inclusion.

[youngbru]

Yes, using your driver. I may play with the debug logging sometime. Thanks for the reply.