zwave-js / node-zwave-js

Z-Wave driver written entirely in JavaScript/TypeScript
https://zwave-js.github.io/node-zwave-js/
MIT License
741 stars 596 forks source link

ZWave Network stuck after wakeup of unknown node #7144

Closed miguent closed 1 week ago

miguent commented 2 weeks ago

Checklist

Deploy method

NPM

Z-Wave JS UI version

9.18.0

ZwaveJS version

12.13.1

Describe the bug

Hi all,

I have a strange issue with my ZWave network. I was using that for years now with OpenHAB. As I bough a new device (shelly qubino roller shutter) I needed to update the firmware of this item. As OpenHAB is not offering that, I decided to give zwaveJS a try. Running that on my raspberry pi was kind of smooth. But I have a strange issue: All my wired items are identified in the meantime. But everytime a battery device is waking up, the identification process takes place. ZwaveJS is then trying to send a command for identification, which is failing. Example:

2024-09-02 21:33:07.412 INFO Z-WAVE: [Node 021] Is now awake 2024-09-02 21:33:07.416 DEBUG MQTT: Publishing to zwave/nodeID_21/status: { time: 1725305587416, value: true, status: 'Awake', nodeId: 21 } with options { qos: 1, retain: true } 2024-09-02 21:33:07.435 DEBUG MQTT: Publishing to zwave/nodeID_21/lastActive: { time: 1725305587434, value: 1725305587434 } with options { qos: 1, retain: true } 2024-09-02 21:33:07.773 INFO Z-WAVE: [Node 021] Interview stage NODEINFO completed 2024-09-02 21:33:07.776 DEBUG MQTT: Publishing to zwave/nodeID_21/status: { time: 1725305587775, value: true, status: 'Awake', nodeId: 21 } with options { qos: 1, retain: true } 2024-09-02 21:33:09.043 ERROR Z-WAVE: [Node 021] Interview FAILED: Attempt 1/5 failed 2024-09-02 21:33:09.047 DEBUG MQTT: Publishing to zwave/nodeID_21/status: { time: 1725305589046, value: true, status: 'Awake', nodeId: 21 } with options { qos: 1, retain: true } 2024-09-02 21:33:15.344 ERROR Z-WAVE: [Node 021] Interview FAILED: Attempt 2/5 failed 2024-09-02 21:33:15.347 DEBUG MQTT: Publishing to zwave/nodeID_21/status: { time: 1725305595346, value: true, status: 'Awake', nodeId: 21 } with options { qos: 1, retain: true } 2024-09-02 21:33:26.623 ERROR Z-WAVE: [Node 021] Interview FAILED: Attempt 3/5 failed 2024-09-02 21:33:26.625 DEBUG MQTT: Publishing to zwave/nodeID_21/status: { time: 1725305606625, value: true, status: 'Awake', nodeId: 21 } with options { qos: 1, retain: true } 2024-09-02 21:33:42.912 ERROR Z-WAVE: [Node 021] Interview FAILED: Attempt 4/5 failed 2024-09-02 21:33:42.915 DEBUG MQTT: Publishing to zwave/nodeID_21/status: { time: 1725305622914, value: true, status: 'Awake', nodeId: 21 } with options { qos: 1, retain: true } 2024-09-02 21:34:04.209 ERROR Z-WAVE: [Node 021] Interview FAILED: Maximum interview attempts reached 2024-09-02 21:34:04.211 DEBUG MQTT: Publishing to zwave/nodeID_21/status: { time: 1725305644211, value: true, status: 'Awake', nodeId: 21 } with options { qos: 1, retain: true }

Please see the corresponding zwavejs log: zwavejs_2024-09-02.log

The log is telling me, that the queue is full. But the queue, according to executing the script driver.driverLog.sendQueue(driver.queue); is telling me that in the queue only requestnodeinfo (and equal) messages are waiting for a wakeup (which should be fine):

2024-09-02T19:34:04.217Z DRIVER all queues idle 2024-09-02T19:42:23.444Z DRIVER Send queue: (26 messages) · [REQ] SendData: ManufacturerSpecificCCGet [Node 18, Asleep] (P: WakeUp) · [REQ] SendData: ManufacturerSpecificCCGet [Node 30, Asleep] (P: WakeUp) · [REQ] SendData: ManufacturerSpecificCCGet [Node 27, Asleep] (P: WakeUp) · [REQ] SendData: ManufacturerSpecificCCGet [Node 24, Asleep] (P: WakeUp) · [REQ] SendData: ManufacturerSpecificCCGet [Node 26, Asleep] (P: WakeUp) · [REQ] SendData: ManufacturerSpecificCCGet [Node 19, Asleep] (P: WakeUp) · [REQ] SendData: ManufacturerSpecificCCGet [Node 23, Asleep] (P: WakeUp) · [REQ] SendData: ManufacturerSpecificCCGet [Node 44, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 20, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 3, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 4, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 6, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 7, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 9, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 14, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 17, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 22, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 25, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 28, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 29, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 40, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 43, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 46, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 48, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 49, Asleep] (P: WakeUp) · [REQ] RequestNodeInfo [Node 50, Asleep] (P: WakeUp)

But forcing a wakeup of one of the given nodes above in the requestnodeinfo status will break the network again.

After the error, the network does not accept any messages anymore and is completely stuck. I need to soft reset the controller to bring the network back online.

Do you have any idea what might be the issue here?

Thanks for any hint and best regards, Michael

To Reproduce

waking up a node which is waiting for protocolinfo.

Expected behavior

request information message should be accepted and not break the network.

Additional context

No response

AlCalzone commented 2 weeks ago

I can take a look at the logs later. In the meantime, which controller are you using?

miguent commented 2 weeks ago

Hi. Thanks a lot. I am using the zwave.me usb stick: Bus 001 Device 077: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB

AlCalzone commented 1 week ago

Transmission queue full

is an error from the controller. I haven't seen it before, except in a few circumstances where the communication with the controller went off the rails and put it in a really weird state.

To be honest, I don't know how to get around this. You could try unplugging the controller for a few seconds and see if that helps.

miguent commented 1 week ago

Hi,

I unplugged and plugged the stick in again several times. Always the same... I now ordered a new stick (same version) and backed up the old stick and pushed it to the new stick. So the network is transferred and the new stick now does not have these errors anymore. So I expect that the old stick was somehow corrupt. Hoping now that the new stick will just not start with these errors again in a few days...

Thanks a lot for your support.