Nooo … it’s case of looking over what you have, thinking about what you’re doing and why, and fine tuning by adjustment.
Example; are you persisting on every update or every change? Why? (There might be good reasons for some, but not others)
If you are persisting everything you’ve almost certainly not yet thought it through.
“But it’s a Modbus problem!” - well Modbus is an industrial scale protocol that will happily stress all the other parts of the system that you’ve linked it’s data too.
I believe the whole system is stressed. Its an Rpi3A running way above its capabilities. Fine tuning modbus may help a little. But I still believe his system is highly stressed.
Next thing may be, that its running on a bad (slow and old) SD card. That would be the top argument 
More than you might expect. This is about adjusting the water tap to control the flow into the leaky bucket. There’s nothing wrong with the tap, but it is capable of making the bucket brim over. By default, the tap is turned fully on.
You may be right. I´ve only got two modbus devices. So I´m not suffering from the same issue, yet.
Sage point and going through it all now.
‘With great persistence comes great responsibility.’ Spider-man. 
thx
ps. new updated oh2.5 system and setup now running no errors 60+ hrs 
Well spotted … I think this is our main issue … as OH doesn’t seem to support rpi3A?
It works from our rpi3B burn image and the rpi3a has tons of cpu resources etc available but seems like there is a disconnect eventually causing a crash?
If this is true … any plans for OH to do img for the rpi3A range … it has better small form factor, lower cost and similar cpu spec to rpi3b range.
cheers
I really wonder how many have thoughts about the Rpi3A. As mentioned, I didn´t even know it was exsisting. But it would be interesting to know, howcome it crashes and Rpi3B doesnt.
Okay, I doubt that has anything to do with 2.4 → 2.5
Did you address update rates, persistence, etc? I am convinced most issues like this are about pouring data into an openHAB design not optimized for this kind of business, resulting in i/o bottlenecks on sluggish hardware. Persistence, logging, Grafana, all queuing and competing for same resources.
Of course it shouldn’t crash, but at least one of these moving parts (including the OS and Java) can be expected to have bugs under stress.
I’m reminded I owe a blurb about Modbus-TCP tweaking, separate business but closely related. I started, but must finish that 
I have added some “TCP tuning” info to the Modbus Performance tutorial thread referenced earlier.
This will likely make little difference at the oipenHAB end, but every little helps.
Thanks for this TCP update.
The system has been running constantly for 100+ hrs with not.one single.error.log 
As previous, pretty sure the issue looks to have been an incompatibility of the OH/ionware system with the new rpi A range SBC.
The new combined OH2.5 and ionware Plug&Play SD card image c/w iHome Smart Home softlogic control algorithm free download now available here …
Free sample(s) to test of the ionC1 control board to any educators out there. 
enjoy!
From original version of our ionware rpi0 system c/w Grafana/influx … the cpu was running 100%+ … it worked well but was overburdened.
Our latest version uses rrd4j and Chart item …
Not as pretty as Grafana … but it’ll do. 
And cpu load <90% … so all good.
laters
I really dont fancy the rrd4j and chart, to be honest. But if it works for you, then all is fine, and great you got it sorted
