With this kind of adaptor you don’t need that anyway.
This should do the trick.
Dear mbs38,
Output is same even, after setting flow controls
modbus:serial.onoffcmdstat.connection=COM4:19200:8:even:1:rtu:500:3000:rts/cts in:rts/cts out
modbus:serial.onoffcmdstat.id=1
modbus:serial.onoffcmdstat.type=discrete
modbus:serial.onoffcmdstat.start=0
modbus:serial.onoffcmdstat.length=2
Please check error logs logs
Regards
Hitesh Patel
You don’t need flow control.
Just this: modbus:serial.onoffcmdstat.connection=COM4:19200:8:even:1:rtu:500:3000
But, Sami had suggested so I configure it with flow control. I check with/without but result are same.
Interesting. I’ve got a strange feeling: has anyone ever tested the binding with even parity? I haven’t.
here’s an example
1 Like
Thx.
Any other ideas?
@hitesh.patel can you sniff the bus with another adaptor? It would be interesting to find out whether the requests actually appear on the line.
Working some suggests you don’t have anything fundamental wrong. Are you really sure you are using twisted pair for RS485 bus, really sure it is terminated properly?
He was able to poll data from the device with modpoll and radzio modbus master so hardware is probably not an issue here.
He is reportedly able to poll data with OH as well, albeit with some communication errors. It’s something marginal - timing or line quality. Crappy wiring really does show up in this kind of way.
Sami will tell us, but I don’t think the binding currently reports CRC errors, which could be helpful in this situation.
EDIT - thinking on it, in this case noisy data incoming would be more likely to give parity errors at the serial level.
Outgoing noisy data would return a NACK or simply nothing/timeout, depending what the slave feels like. A NACK could itself get garbled of course,
Actually, the CRC errors are reported in a different way, e.g. Modbus RTU Drexel & Weiss <> openHAB
The EOF exception in this thread means that the message could not be read fully, and the underlying serial library reported end-of-stream. Thus, the binding does not even check the CRC in this case…
How often does the read fail, and how often does it succeed?
Sami
Interesting note on the parity errors. I wonder if those could explain the EOF, why bother reading rest of the bytes if there is a parity error…
It looks like I might be able to log out parity errors, perhaps that could be good indication of serial line quality…
Best
Sami
That might well be very useful sometimes. i expect Windows and *nix environments might behave differently here.
Of course, many other serial users won’t use parity, but then we would get CRC errors.
Thanks for input
However, I have only one USB-Rs485 converter.