I think you did a great assesment there @rossko57. I would also agree that this kind of restructuring fits nicely into openhab2 changes… For now I would indeed go for the approach where retries are minimized. Still, I do understand the delay you will eventually see if there are many openhab slaves pointing to the same physical modbus slave.
Indeed there are many approaches of handling this nicely and in a flexible manner (user has control) but still with reasonable defaults (good performance by default). Would it help if the modbus requests are grouped by endpoint (e.g. ip/port), and then executed. If request would fail due to connection error or IO error, the other requests pointing to the same endpoints would not be tried out before next poll cycle.
I have tried to get feedback on the openhab2 implementation of modbus in the somehwat old pull request but so far no luck. We try to get to a situation where both openhab versions can be maintained with relative ease. There are plans on splitting the modbus binding to usable “transport” bundles, that other bindings could use. This would mean that other bindings could re-use basic modbus protocol to implement “higher level protocols”. Currently people are forced to fork the modbus binding to implement some manufacturer specific edition of modbus (I have seen examples of this in the forum). Unfortunately this kind of split requires quite much planning and expertise and certainly might affect these “robustness/performance requirements” we are discussing here.
Can we detect a broken slave via an OH rule?
Yes, actually now we can now. I’ve implemented the feature request from @mbs38:
So you can react to Undefined states in rules – basically telling there is something wrong with the slave. Please consult the wiki for details.
This got me thinking something quite hackish… what if we would use Config Admin Binding to modify the modbus configuration automatically in case of slave errors? Perhaps that would solve your immediate need?