This won’t make it better, possibly worse. Properly set up Modbus error recovery adds delay to any remaining working parts of your modbus system, extending transaction queues.
If want to think about this properly, please see guide -
But in truth with one Modbus slave as you have shown us, I would leave retry settings at default
Messing with this will not fix your problem.
Get rid of modbus.cfg. It’s neither use nor ornament. Make very sure that you do not have v1 binding installed alongside v2.
Okay, so you have one slave, a half dozen pollers at fairly high poll rates, and many tens of Item? I am guessing all those data Things are linked to Items?
This is asking a lot of an RPi3. It’s not too much at all - but there are big performance traps set for you. (Especially if you are running your slave on the same RPi). There is not enough performance to allow you to be careless here.
Modbus binding defaults are suited for unfamiliar users to get a simple project going, you’ve moved beyond that and should take steps to tune your system.. All those Items updating every half second is stressing out the rest of your system - are some/all persisted?
I recommend to read and implement here -
Reviewing the performance guide, I feel should add a additional section about TCP behaviour. Again, the defaults get you started but need proper consideration in a limited resource environment - which can include the target Modbus slaves, not just the openHAB host.
This is probably the cause of your logged TCP errors, but has likely nothing at all to do with system issues.
I’ll add this when I’ve thought about it, but you’ve got plenty to get on with and I think that is more relevant.
And yes, v2 binding has different potential stress points and different settings to deal with them … because it’s different.