0.32.2 asleep / awake loop

[jparchem]

Version

Checklist:

• [x] I am not using Home Assistant. Or: a developer has told me to come here.
• [x] I have checked the troubleshooting section and my problem is not described there.
• [x] I have read the changelog and my problem is not mentioned there.

Build/Run method

• [x] Docker
• [ ] PKG
• [ ] Snap package
• [ ] Manually built (git clone - yarn install - yarn run build )

Zwavejs2Mqtt version: 0.32.2 Z-Wave JS version: Driver Version: 8.9.0-beta.1 / Server Version: 1.13.0

Describe the bug

Copied from original bug report HERE by @acburnett

After updating to 0.32.2, my zwave network stopped working. The logs show an awake / asleep loop for a smoke detector that is definitely asleep. Its a first alert zcombo and they rarely wakeup. I have 5 of them and only the one is logged in the loop, rolling back to 0.32.1 fixed the issue.

To Reproduce

Steps to reproduce the behavior:

Im not sure, hopefully im not the only one that had the issue and someone much smarter than me could chime in.

Expected behavior

Going back to 0.32.1 fixed it for me

Additional context

Add any other context about the problem here.

[kpine]

Most likely a duplicate of https://github.com/zwave-js/node-zwave-js/issues/3959. Fixed in driver version 8.9.2.

[kpine]

Also, manually waking up the device should fix the problem for now.

[dadcoachengineer]

Most likely a duplicate of zwave-js/node-zwave-js#3959. Fixed in driver version 8.9.2.

The issue @acburnett and I observed effected ALL z-wave devices not only battery powered or ZCOMBO smoke/CO monitors. I have a slew of GE/Jasco switches, Aeotec devices, and ZCOMBO alarms and all were unresponsive over the z-wave network when running 0.32.2. All of them became responsive when going back to 0.32.1

[kpine]

The issue you observed is the awake / sleep loop, same thing I reported. Waking up the device, or upgrading the driver will fix that. I would make a guess that solving the problem also fixes your unresponsive network.

EDIT: Actually, I don't have to guess. Another user in the HA discord had the same problem, and it was fixed by manually waking up the ZCOMBO, which is why I added that comment here.

[dadcoachengineer]

Cool. I was just stating it wasn't limited to battery powered devices and manually triggering/waking the device did not cause it to respond to network commands.

I am crossing my fingers that the root cause is the same 👍

[kpine]

Well, the problem is specific to the old ZCOMBO smoke alarms, or any other battery device that doesn't wake up on its own. You need to manually wake these up by removing the batteries, holding down the test button and re-inserting the batteries. They don't wake up any other way.

The unresponsive network is just a symptom of awake / sleep loop. The driver is stuck handling those messages so nothing else will get handled.

[jparchem]

I also have 5 of them. I can confirm that waking them using the battery removal / reinsert procedure previously mentioned works. As I manually wake up each one, I can watch the loop get stuck on the next successor until that one is reset, and so on until all 5 have been reset at which time everything starts working again for me.

[Photo64]

I am having the same problem. I have 3 of the older zcombo smoke alarms. However I woke them up yesterday and it worked for awhile but started the loop again and stops me from controlling any of my zwave devices. I woke them up again today but once again after a short while the loop begins and prevents usage of the zwave devices. Hopefully the driver update (8,9,2) gets pushed out soon as I understand that is supposed to fix it.

[kpine]

Are you sure you're waking them up properly? Once woken and the route assignment command is issued, the setting that causes the loop is persisted into the node-zwave-js cache files. It shouldn't need to do anything again from that point.

[Photo64]

I thought it was pulling the batteries out reinserting while holding the test button, is that not correct? Also, rolling back to 0.32.1 did not work for me.

[kpine]

That's the correct procedure. Maybe try again? It doesn't make sense to me that rolling back to 0.32.1 does not work. The code that causes this loop is not present in that driver version.

If you have CLI access you can verify that waking up the device was effective or not. Here I'm grepping for node 10 and the hasSUCReturnRoute field. It should show true if it has been updated. (Mine's false because I'm using 8.9.2).

dietpi@rpi2:/srv/apps/z2m/data$ grep 'nodeId.*:10.*hasSUC' *.json*
d73ecdff.values.jsonl:{"k":"{\"nodeId\":10,\"commandClass\":-1,\"endpoint\":0,\"property\":\"hasSUCReturnRoute\"}","v":false}

[Photo64]

I just went and replaced the batteries in all 3 of my zcombo smoke alarms and I am still unable to control any of my zwave devices. I am still on 0.32.2. Should I roll back now? I also tried running your grep example but got a "no such file or directory" return

[kpine]

I just went and replaced the batteries in all 3 of my zcombo smoke alarms and I am still unable to control any of my zwave devices.

Are you still seeing the awake / asleep messages? I think you might need to wake them up in order, as @jparchem described. The log message will complain about one of the nodes, you need to wake that one up first. When it is handled, it will complain about a different node, then wake that one up, etc.

If you aren't seeing the asleep / awake loop, then you have a different issue.

I also tried running your grep example but got a "no such file or directory" return

That's because you copied and pasted the output of my command. You only want the grep command on the first line. And you need to run it from the z2m store directory, not your home directory.

[Photo64]

I rolled back to 0.32.1 and then saw this in the logs (see below). I was afraid it had woke then went back to sleep and looping again. However I restarted HA and now I have control again of my zwave devices but not sure if it will last. It seems like it's only this node that is causing an issue.

2021-12-29 22:10:22.346 INFO ZWAVE: Node 51 is now asleep 2021-12-29 22:10:25.994 INFO ZWAVE: Node 51 is now awake 2021-12-29 22:10:26.681 INFO ZWAVE: Node 51 is now asleep 2021-12-29 22:10:31.665 INFO ZWAVE: Node 51 is now awake 2021-12-29 22:10:33.835 INFO ZWAVE: Node 51 is now asleep 2021-12-29 22:10:42.561 INFO ZWAVE: Node 51 is now awake 2021-12-29 22:10:53.486 INFO ZWAVE: Node 51: value updated: 113-0-alarmType 13 => 13 2021-12-29 22:10:53.495 INFO ZWAVE: Node 51: value updated: 113-0-alarmLevel 255 => 255 2021-12-29 22:10:53.836 INFO ZWAVE: Node 51: value updated: 113-0-alarmType 13 => 13 2021-12-29 22:10:53.846 INFO ZWAVE: Node 51: value updated: 113-0-alarmLevel 255 => 255 2021-12-29 22:10:56.870 INFO ZWAVE: Node 57: value updated: 113-0-alarmType 13 => 13 2021-12-29 22:10:58.064 INFO ZWAVE: Node 57: value updated: 113-0-alarmLevel 255 => 255 2021-12-29 22:10:58.382 INFO ZWAVE: Node 57: value updated: 113-0-alarmType 13 => 13 2021-12-29 22:10:58.383 INFO ZWAVE: Node 57: value updated: 113-0-alarmLevel 255 => 255 2021-12-29 22:11:19.501 INFO ZWAVE: Node 51 is now asleep 2021-12-29 22:11:27.046 INFO ZWAVE: Node 51 is now awake 2021-12-29 22:11:29.373 INFO ZWAVE: Node 51 is now asleep

[kpine]

Those are excessive, but not as extreme as this issue. There's even a gap of almost 30 seconds where it says it's awake. I would say this is something else, but it's hard to tell without driver debug logs. We already know 0.32.1 is a bad release though.

[Photo64]

I've been running for quite awhile without any issues until this recent update and it since it's affecting the same zcombo smoke alarms that others are reporting I am assuming it is similar. 0.32.2 doesn't seem to work for me and 0.32.1 appears to work sporadically, at least so far. Hopefully a new push comes soon.

[jparchem]

@Photo64 I'll keep an eye out for how long the manual reset of my 5 zcombos keeps things working under 0.32.2, but I will say that for me reverting back to 0.32.1 always works (in my case without any restarts) and I've gone back and forth between the two versions at least half a dozen times while testing things.

[AlCalzone]

@robertsLando I think we can close this. This was caused by the broken driver beta and should be fixed by now.