I finally got a chance install the latest update a few minutes ago and it is working fine so far. I will try to report back after it has run for several hours.
1 Like
Thank you @pewu78!
Yes I think this should do it ā I introduced a precise āworkaroundā in the binding to resolve the specific problem witness by all of you in this thread.
It looks like the actual bug is in a 3rd party library but unfortunately I could not figure it out to fix it in upstream. As your reports have shown, it is quite hard to reproduce and requires very specific conditions to trigger. I suspect that the issue was possible with previous binding versions but these exact conditions did not just occur.
Thank you all, would have not been possible without your testing! I pushed fix for the official binding, should hopefully get to the next release.
I am sorry about being a little slow getting this update installed, my wifeās mother fell this week and was hurt pretty bad so there has been a lot going on here.
I did get the update installed last night, or perhaps more accurately early this morning and am very pleased to report that the Modbus binding has been running for over nine hours, which I have not seen at anytime previously unless I had extra logging on.
I am still reading a single holding register as I have been pretty much throughout this testing process. During this current test I have been polling at 250ms and have the extra logging turned off. I have not seen any errors since starting openhab the last time. The āopenhab.logā has not had any entries since shortly after startup and the only entries in the āevents.logā
(except for a couple of 0 values mentioned below) have been the expected āItemStateChangedEventā entries whenever I operate a discrete input (a light switch) which causes a change in the register value.
I did see a couple of odd entries over an 9 hour or so time period where the log reported a value of 0 from my register and it was between 1 and 5 minutes later before the log reported the register returning to the expected value. If this persists I may have to look into this but I donāt want to muddy things here since it is unrelated to this topic and may simply be a quirk on my end.
I want to thank you for your patience, especially in the early time when I seemed to be the only one reporting this issue (on another thread) and we both were probably convinced that I (a new user) was just making a stupid mistake somewhere or there was possibly something with my specific installation or hardware especially since I was running on Windows. I was almost relieved when a few other users started reporting similar issues.
Again I applaud you for your patience with all of this, I know it had to be tough, especially since you (as far as I know) were unable to reproduce the issue on your openhab install.
I also want to thank all the others that have tried to help with this issue.
Things are looking much better here so I guess this issue can be marked as resolved whenever you thing it to be appropriate to do so.
Now maybe I can see if I can do something in openhab, I guess my first project will be getting things set up for writing bits to modbus registers in order to fire my outputs once I get the jython stuff set up again for rules.
Thanks again for all the help.
1 Like
Yes I can also report back that the polling is running without any problems since the 2.5.9 binding install.
Thank you @ssalonen for your help, really appreciate your work. Your the MVP.
Thank you once again. I can also confirm that the fix is in for 2.5.9 release.
So at that point should we install the Modbus binding using the PaperUI and nothing else needed?
As far as you know will the Modbus binding be ready to go for openhab 3?
1 Like
Just installed the latest version.
Changed my thing back to:
Bridge modbus:tcp:SE7K [ host="10.0.0.34", port=502, id=1, timeBetweenTransactionsMillis=100,
timeBetweenReconnectMillis=1000, connectMaxTries=3, reconnectAfterMillis=1000, connectTimeoutMillis=2500 /*, updateUnchangedValuesEveryMillis=60000*/ ] {
Will let you know what the outcome is.
I think itās commented out, but reminder that parameter does not belong to a Bridge type Thing.
The other settings here will hammer your slave device with TCP reconnect cycles, which is no bad thing for testing. You might want to review for efficiency later.
1 Like
Yes @BHall, fixes will be included part of 2.5.9.
All openhab2 bindings will be ready for openhab3, modbus included 
2 Likes
So far everything is still running without an error. Seems like you fixed it.
Many thank youās to everybody involved in fixing this!
2 Likes
Same hereā¦ No issue at all.
IĀ“ll let it run for now, and probably skip 2.5.9 update.
1 Like
Yesterday evening, Iāve updated to 2.5.9 Daily 225-1 and the modbus binding is still working well 
1 Like
It has been running for almost 3 weeks without errors. I consider it definitely fixed.
2 Likes
Hello
I have the same problem on openHAB 3.0.0.RC1.
After a few hours modbus seral stops polling, but in the setting page it is al online.
does anyone use modbus serial connection on OH3 ?
thank you
Hi. Any news regarding this issue? I switched to OH3 and I use connection through serial. Binding seems to stop working after some time.
Hi . I just jumped back to OH 2 . Waiting for better news on serial modbus in OH3.
I wonder is this reported problem with unreliable CommPortIdentifier.getPortIdentifiers() is related
run into the same issue in OH3
the serial rtu modbus connection is not stable and the binding stops working after failing reconnect.
I guess this is up to the openhab core to fix this , right?
This is the understanding indeed, bundled serial library should be fixed in core.
I switched to OH3 this month without any issues regarding the modbus binding.