Add extra delay after a 'channel name request' command. The command can provoke a lot of answer packets. When the delay is not large enough to let the answer packets arrive, subsequent commands cause loss of answer packets.
I added an extra delay of 33 x SLEEP_TIMEOUT, this should be enough of the worst case scenario when VMBGPOD is replying with 33 * 3 answer packets. Maybe other newer modules send even more answer packets ? Not sure.
I suspect the answer packets get lost in the modules itself not able to put the packets on the bus while it is flooded with new commands.
After the update, users should clear the velbuscache to renew the readout of all modules.
Add extra delay after a 'channel name request' command. The command can provoke a lot of answer packets. When the delay is not large enough to let the answer packets arrive, subsequent commands cause loss of answer packets. I added an extra delay of 33 x SLEEP_TIMEOUT, this should be enough of the worst case scenario when VMBGPOD is replying with 33 * 3 answer packets. Maybe other newer modules send even more answer packets ? Not sure. I suspect the answer packets get lost in the modules itself not able to put the packets on the bus while it is flooded with new commands.
After the update, users should clear the velbuscache to renew the readout of all modules.