Just a suggestion, while “queuing” is being looked into. I’m developing a multi-slave Modbus application; don’t have enough hardware yet to help much with testing. But I am playing with configuration so far as I can.
I set up two TCP slaves in openhab.cfg and see the expected timeouts as they don’t yet exist. Monitoring the actual communication attempts shows batches of four attempts, as expected from 1 try + 3 retries.
My observation is that the retry mechanism fixates on each slave in turn, i.e. 4 tries at slaveA, followed by 4 tries at slaveB. This is not ideal as one missing/faulty slave would appear to prevent polling of any remaining working slaves for a long while (4 x timeout periods)? It would be better if retry attempts could be scheduled to the back of the queue, so that normal polling of other slaves could take place in between retries. poll SlaveA(timeout) - poll SlaveB - poll SlaveC - retry Slave A etc.
That might all be completely impractical of course!! just offering for consideration. It’s only a problem when some other error already exists, but would help make Modbus based systems more robust.