Just migrating to OH2.4 and while performing some initial tests “on the bench” with power plugs I experienced very long delays ( > 10 seconds ) when swithing on a lamp.
After observing the log, noticed it occurs after sending a command to a node which is not present. The binding first performs a number of retries on the node which is not present before sending the command to switch on the lamp.
Is this a limitation of the binding or the dongle that transactions are processed sequentially, or is it just a bug ?
I expect the behaviour is the same if a node which is absent is part of a group and a command is sent to the group. Is this assumption correct ?
Is there any option to improve this behaviour (e.g. reduce the time to sending the command) ?
As you can see, node 5 is timing out and this is the source of the problem. The binding will normally prioritise traffic, and since you have sent a high priority command (ie a command to set a dimmer) to a device, the binding is trying to deliver this. The fact that the device is not responding is the source of the delay.
Firstly, there is a limitation with ZWave - it can only handle a single transaction at one - so yes, there is a sequential processing of transactions limited by the controller, but it’s not a bug.
Yes - if you are sending commands to devices that do not exist, then the binding will try and deliver those commands. I think this is reasonable, and I think you should look to remove devices that are not there - or at least don’t send them commands.
I suggest to remove devices that don’t exist - or as above, don’t send them commands at least. There is no real option for improving this - we could look at not sending retries, but we tried that for a while and it caused other problems (and retries are recommended by ZWA).
Thanks for your quick reply It explains a least a couple of issues I had in the past. Frankly speaking I would have never expected this limitation with ZWave (basically any decent communication protocol)
I do not know the zensys protocol, but what is considered a “transaction” ? e.g. it is not possible to send a TX request to the Z-stick after the first RX ack at 16:31:13.028 ?
Tha ACK timeout of 6 seconds is quite long, especially for a small network with a few hops. Is there any way to configure this ?
Agreed! I’m hopeful that with the upcoming changes, we will see this removed, but let’s see…
There can be only a single outstanding SendData request at once. I have tried to work around this, but it causes all sorts of problems.
The problem is that ZWave does a bunch of things to find routes - it first tries the existing route, then (from memory) it tries a backup route, then as a last resort it sends out the explorer frames to go searching to the node. This all takes time, and the recommended timeout from ZWave is 5 seconds. The controller can cancel the transaction earlier if it wants, and the binding will then move on quicker.
Really, I would strongly suggest to remove devices that don’t work. Anything else is likely to cause you other problems - eg reducing the timeout will just cause problems for other devices in the network as the routes will not be able to be discovered.
I do agree that the ZWave protocol is not great here. With the move to Silabs, I expect good changes, but I can’t really say a lot at the moment as I am under an NDA with them.
It explains a least a couple of issues I had in the past. Frankly speaking I would have never expected this limitation with ZWave (basically any decent communication protocol)