Closed miguent closed 1 week ago
I can take a look at the logs later. In the meantime, which controller are you using?
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
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.
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.
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