OK, so a bit of history here (perhaps useful for other developers as well)
java modbus libraries
As far as I can tell, openhab incorporates a forked version of jamod library. Jamod is not developed anymore but there forked versions of that, e.g. j2mod and j2mod by steveohara.
The second j2mod fork seems have gone through quite an overhaul, there are tests and the serial library has been switched:
The main driver for doing this work is to get away from the RxTxComm library and to use something that brings it’s own native implementations and is actively supported.
The weapon of choice is the jSerialComm library which is extremely well supported by Will Hedgecock and is actively developed.
The underlying communication is done using a serial library, nrjavaserial, in openhab, shared by all the bindings (as far as I understand bundled in org.openhab.io.transport). Note that nrjavaserial seems to use RXTXComm, something that was dropped in the second j2mod library.
For openhab, switching the serial library might not trivial as we want to support many architectures, and all the java serial libraries include a “native” precompiled libraries.
openhab modbus binding changes
The modbus binding (especially the serial side) received quite many changes during 1.9.0 development, in pull request #4226 from me. Improvements were enabled huge help from the community. I could not the serial functionality at all myself since I do not have a serial modbus slave available.
Eventually we managed to get constant serial throughput with @mbs38 , although that was with higher baud rates than you have.
In openhab fork, changes include
- logging to use a logging library
- error handling improvements, consistent retry (PR #4226)
- new functionality to enable easier testing, for example, the server component are used in the integration tests (PR #4226)
- some serial line parameters (PR #4226)
Critical part to get the RTU serial communication working was to introduce a silent period before sending a new request. This is due to the fact that in Modbus/RTU, silence splits up the sentences.
The testing revealed different serial behaviour windows, something that I considered a bug in the nrjavaserial library. On windows it seemed that the serial data read calls were not blocking, returning EOF immediately. On nix the serial library waited the timeout before returning EOF.
differences between java libraries
You can compare the differences between implementation of these different modbus java libraries:
- jamod, uses setReceiveThreshold to do blocking read (not retries) link
- openhab jamod, similar to original jamod, although we call setReceiveThreshold now even with one byte reads: link
- original j2mod, has a retry to get all the bits, link
- steveohara j2mod, jSerialComm seems to handle the blocking/non-blocking details, modbus library code is simple, link
summary
From the development with the serial devices (and the fact that we still have issues) I got the impression that one of the following is true
- jamod part of the modbus binding uses the serial library (nrjavaserial / RXTXComm) in “non-robust” way, losing bits in the process
- the serial library is buggy / unreliable / platform dependent
The fact that the modbus libraries have so different way of reading the data support my theory, I think. But who knows, it might be something simple really…
how to proceed
I like your idea of having a test program. I think it should be possible to have the test command line application as part of the binding.
During the coming weeks, I think I can provide you two different versions, one with the logic the openhab-jamod currently implements, and one with the original j2mod (read retry mechanism to get all the bits).
If these do not work, we might be facing a dead-end. The development of the binding is really unrewarding and slow without a test slave to work with…
In the meanwhile you might want to try out higher baud rate if you have the possibility to change the slave baud rate.
Best,
Sami