Open petrklus opened 9 years ago
Please see full log attached (it may be truncated as it's rotated daily due to being TRACE verbosity) zwave.log.zip | uploaded via ZenHub
Also, the Node 2 is the only one marked DEAD by the binding at this moment:
What’s happening is that the device isn’t responding to the message from the controller -: NODE 2: SendData Request. CallBack ID = 219, Status = Transmission complete, no ACK received(1) So, this causes the binding to do a heal.
If this is happening all the time, then it’s possible the item definition is incorrect. What is the device, and can you post the XML associated with node 2.
It's Fibaro Double Relay switch - and it still works absolutely fine, only sometimes commands get queued up because of the constant heal. Please find attached the node2.xml
It's Fibaro Double Relay switch - and it still works absolutely fine, only sometimes commands get queued up because of the constant heal. Please find attached the node2.xml
The question is why it’s doing the heal - the ultimate answer is because the device isn’t responding to messages (at least in the log you sent). This causes it to timeout and then there’s a heal. So, we need to find out why the device doesn’t respond. Either the item config is wrong (but probably not), or maybe the device is at the edge of reception? Is it always relay 2 that fails? or does relay 1 also fail occasionally? There’s no reason from a binding perspective why relay 2 is any different than relay 1...
No, it is quite close actually - probably just approx. 5m away from the stick, in between node 1 and the stick actually.
If I issue a command, it reacts immediately. For example, when I switch the lights ON, they respond immediately, but then the OFF may get delayed as I can see that after issuing ON, it starts pushing through the HEAL, which queues the OFF.
So, this node is not responding to any messages. Clearly it’s receiving them, but in the log you sent, we sent it a number of messages and they all timed out, so for some reason we’re not getting the response.
NODE 2: SendData Request. CallBack ID = 219, Status = Transmission complete, no ACK received(1)
@cdjackson Odd - I would be inclined to think that it was a transmission problem if the node was not so close. However, it seems to have fixed itself now - any ideas if it could be anything more than just interference?
It could be interference - I’m not sure. All we can say is that the device was obviously receiving the commands from the controller (since the light went on) but the controller wasn’t receiving the ACK from the device (since we got the NO ACK response). Other than that, I’m not sure - I’m pretty sure it’s not a binding issue though...
Hello,
I've noticed that switching dual-relay equipped lights can take surprisingly long amount of time. When looking at logs, I've noticed that every time I toggle a light (ON and then OFF), the binding is attempting a heal. I've switched the light ON, waited 1s and then switched it off. The ON command seems to go through, then after the OFF is issued the binding is attempting a heal. This happens every time and causes delay in command propagation
Please see below excerpt of the logs.