Darn serial, we always seem to go very low-level with this one Line level understanding would be probably the best insight into the topic. Is that what you meant with “old laptop as serial monitor”?
Based on javacomm serial library documentation (which is actually not used by OH but I guess the API is similar enough), we have “Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception.” – This is happening when we get “awaited 4 bytes, but received 2” log message. Does this give more hints?
I guess the socat suggestion might reveal something but then again it might hide the issues as socat would sit “between” the real serial port and openHAB.
I could try to make a special version of binding which tries to read bytes again if we timeout and not get all bytes at first time. It seems unlikely this would fix the issue though…
I don’t have a good enough understanding of what goes on between serial device and binding.
Something (the USB adaptor that I assume is in use) gets a byte at a time, something decides the bytes have stopped coming so “here’s a packet” and in our case it’s short.
A framing error pretty much means the stop bit was missed at the expected time, very low level error.
Poor bit timing by the transmitter or receiver can cause framing errors, and that could be sensitive to last data bit sent. That’d be the most significant bit, used as sign bit in signed integers…
I would expect bytes to be discarded at low level, but maybe not. That would leave the library to decide to pass along garbage or not, if it bothers checking for the framing error flag.
Can we tell if there really is a framing error at the hardware or do intervening libraries hide that?
Maybe @pete3 is able to try some read polls that include a larger proportion of bytes over hex80 value?
Hmm … can you make “programatically” inject the bytes from serialport, to see if openhab “alone” has similar behavior? That would also help isolating the problem.
One can then utilise diagslave (virtual modbus slave) and modpoll (modbus maste) to fill up the registers with the data you want to have. Pointing the openHAB to the other end of the null modem emulator allows you to read data from this local diagslave modbus serial slave
Many things are probably different to real slave and real serial communications… not sure how well it gives insights to the issues
EDIT: I tested this myself. Openhab can read the -10004=0xD8EC just fine over this “null modem emulator”, diagslave acting as modbus rtu slave. The issue can be something platform specific (I have 64bit linux x86_64) or related to something more lower level
It will not fix your issue but instead of DEBUG level log message ("awaited 4 bytes, but received 2") & issueing CRC errors, error more loudly logged about the missing bytes.
gnu.io refers to the serial support of openHAB. You can install it e.g. by feature:install openhab-transport-serial. I would expect then the modbus transport installation to work
Hi, just upgrade from 2.5.9 to 3 and now on snapshot to fix the locking problem (Thanks @ssalonen ) and am wondering if my CRC error issue is related to this subject. (On 2.5.9 had occasionally 1 of 3 try failed but never 2nd or 3rd).
Using a PI4, serial USB interface (Cheap Chinese), CAT5 cable with co-located 3xEastron SDM630, 2x SDM120 and about 10m away a WP8028ADAM. The SDM’s poll at 60,000ms and the WP8028 at 500ms. All ModBUS timings are OpenHAB default. The SDM630 & WP8028ADAM have zero errors. Both SDM120 however both have equal amount of excessive CRC resulting in approx. 100 OFFLINE (Est. 5% of the poll’s) events per 24hours with error as follows:
There are actually small differences in the data read in each message. Can’t read too much into that - may indicate noise on the line, may just be that source data has actually changed in a few milliseconds.
But it does allow for a noise problem, particularly as we’re obviously in amongst power cabling here. Different devices may be more or less sensitive about noise, different transfer lengths give more or less opportunity for noise or wandering bitrate timing. All boils down to “not easy to pin down.”
You’ve not mentioned termination. The USB adaptor probably has 120R built in, and the other devices none, that often suffices for short runs. Multi slaves and 10m runs is getting beyond “short” though, I would recommend a remote terminator as well.
Ultimately you might need to use shielded cable around power devices.
Or of course the SDM120 might just be pants. It’s not unheard of for any given design to be a bit ropy at a particular line speed, a change to another baud rate can help (but is a pain because everyone has to be changed)
The USB adapter has indeed a terminator, we tried with and without a 120R at the end but no difference. The cable is however unshielded so let’s see if we can improve that.
Did find one remark googling in regards to the SDM120 unrelated to OH where they changed to a SDM230 due to CRC errors so that would be an other option.
In any case thanks for your feedback and we go back to the cable to see if we can find some improvement there.
@ssalonen Hi, is this resolved in build 2447 snapshot 3.20? i have the same problems upgrading from 2.5 and tried also moving to snapshot tree, but keep having errors.
thanks
CP2102, SDM120 and 20 cm of cable.
I get excessive retry on modbus. I’ve only a SDM120 to reader in the same electrical panel. With OH 2.5 was good, with OH 3.2 snaphost (latest as I write) i had to cut the cable to 20 cm and slow to 2400 bps to no get the poller offline.
2021-04-05 12:48:31.983 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 4 out of 5 failed when executing request (ModbusReadRequestBlueprint [slaveId=6, functionCode=READ_MULTIPLE_REGISTERS, start=0, length=29, maxTries=5]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID e47020e4-e64a-4a16-96cd-149bb57e5f14]
(I took it from the first post because I can’t get it). But I didn’t see any message in the log telling about CRC error, only EOF errors.
Now, it works @2400bps with openhab snapshot 3.2 and I shortened (from 32 cm to about 15 cm) the cable and redoing the connections. Modbus termination is done on the transceiver side. The cable is not shielded due to be very short,
The previous connection worked without any problem with Open Hab 2.5
Thank you
If you are refering to me, i did send all available info.
(I have no news, since i am stuck for now on 3.1.M4, since another vital experimental binding for me (zmartify), hasnt yet been upgraded to OH3.1 (to changed dependensies)