Zooz ZEN14 Gets Rarely Timeout Issue

[Sraw]

Checklist

• I have read and followed the above instructions

• I have checked the troubleshooting section and my problem is not described there.

• I have read the changelog and my problem was not mentioned there or the fix did not work.

Describe the issue

What is happening?

I am using the ZEN14 Outdoor Plugs to control two lights, basically turning the lights on when the sun sets. I do:

• Turn on light A.
• Wait for 2 seconds.
• Turn on light B.

Sometimes, very rarely, turning light B will silently fail. Means the light is not turned on, but in the UI it shows the value is "turned on", and even if I refresh the value, it still shows turned on.

And light A never failed.

What did you expect to happen instead?

I expect it can turn both lights on without any issue.

Steps to reproduce the behavior:

I use the HomeAssistant to control the lights. So just create a script that does the following:

• Turn on light A.
• Wait for 2 seconds. (It doesn't have to be 2 seconds, can be less, for example, 1 or 0.5)
• Turn on light B.

Anything else we should know?

None.

Software versions

Driver (node-zwave-js): 12.4.2

Z-Wave JS UI: I don't know, but as I am using docker, it is the version that contains 12.4.2 driver.

Home Assistant Z-Wave Integration: I don't know, the latest one.

Home Assistant Z-Wave JS Addon: None

ioBroker.zwave2 Adapter: None

If you are using something non-standard, tell us here: None

Device information

Manufacturer: Zooz
Model name: Zen14
Node ID: 0x027a 0x7000-0xb003

Checklist

• I made sure to provide a driver log on level debug.

• The log includes a re-interview of the problematic device (if applicable).

• The log includes the problematic interaction with the device (if applicable).

• I provided the node ID of the problematic device (if applicable).

Upload Logfile

zwavejs_current.log

The node ID is Node 013

[AlCalzone]

Did the problem you describe happen in that log? If so, when?

Z-Wave JS uses Supervision CC for these commands, which tells the device to tell us when it executed the command successfully (or when a command failed). During this log, every single command was reported to be successful. So if it did happen here, the device gave us wrong information.

[Sraw]

The issue starts at "2024-02-02T00:38:42.808Z".

I saw a few logs say:

2024-02-02T00:39:09.673Z CNTRLR   [Node 013] The node did not respond after 3 attempts, it is presumed dead
2024-02-02T00:39:09.678Z CNTRLR   [Node 013] The node is now dead.

I have built a very stable mesh network and the request shouldn't be timeout, not sure why the node goes dead.

Also seeing some logs like:

2024-02-02T00:39:20.317Z DRIVER « [Node 013] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -89 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Security2CC_CannotDecode
2024-02-02T00:39:20.317Z CNTRLR » [Node 013] Message authentication failed, cannot decode command. Requesting a 
                                  nonce...
2024-02-02T00:39:20.319Z CNTRLR » [Node 013] pinging the node...
2024-02-02T00:39:20.322Z DRIVER   all queues busy

I don't know if those are the root cause of the issue, or maybe the issue is as simple as the device doesn't work as expected.

If we can confirm that the issue is the device doesn't report the correct value, then I can raise a ticket to the Zooz support team.

[AlCalzone]

That first log is definitely a connectivity issue. Some of the working communication attempts (e.g. routing through node 17) show an RSSI value that is just barely above background noise levels (around -105 dBm):

ACK RSSI on repeaters:  -98 dBm

The same is true for some other communication attempts with other nodes. Honestly, I don't think the mesh is as solid as you think. Have you followed the guidelines in our troubleshooting docs?

• https://zwave-js.github.io/node-zwave-js/#/troubleshooting/connectivity-issues?id=general-troubleshooting
• https://zwave-js.github.io/node-zwave-js/#/troubleshooting/network-health?id=testing-the-connection-strength

The second is a resynchronization of the shared encryption state. Nothing to worry about, unless it happens all the time.

[TheKorn2]

@Sraw Just a little out-of-box thinking here... Do you actually need to separate the two devices turning on by a few seconds? The zen14 supports using one command to turn both outlets on/off at the same time. If you don't need them turned on separated in time might want to use that since it seems your first command always seems to work well. (Obviously doesn't address your underlying issue, but might be a workaround in the meantime!)

[Sraw]

@AlCalzone I will try to see if I can get the network better and check back.

@TheKorn2 Yeah thanks for it. I knew there is a command I could use for turning both on and off, but for some reason I could not tell it just isn't reliable enough. Anyway, I will give it a try again.

[AlCalzone]

If sending a single command to toggle the device isn't reliable enough, sending two will definitely be worse.