I noticed that the side effect to PR #2049 is that it introduces an at least 1 second delay before the message is re-transmitted, and could potentially be much worse if there is more activity on the network, as each unsolicited message resets the timer again.
This is a simple change to use a much shorter timeout after a CAN or NAK message from the controller, so we can get on with clearing the message queue sooner, while still allowing any queued incoming messages to be processed first, in the spirit of the original PR.
This makes a big difference for me when setting scenes with multiple Z-Wave devices. I have been seeing delays of 2-3 seconds appearing due to the chatty devices responding to requests with multiple unsolicited updates on the lifeline association group.
I noticed that the side effect to PR #2049 is that it introduces an at least 1 second delay before the message is re-transmitted, and could potentially be much worse if there is more activity on the network, as each unsolicited message resets the timer again.
This is a simple change to use a much shorter timeout after a CAN or NAK message from the controller, so we can get on with clearing the message queue sooner, while still allowing any queued incoming messages to be processed first, in the spirit of the original PR.
This makes a big difference for me when setting scenes with multiple Z-Wave devices. I have been seeing delays of 2-3 seconds appearing due to the chatty devices responding to requests with multiple unsolicited updates on the lifeline association group.