Testing in your situation would be very useful; it’s just possible that fixing OH to handle “proper” frag could mess up the current SMA workaround by throwing an error on a truncated message.
I did a randomly check on the Wireshark logfile and found that the delay between the response packet and the PUSH packet is approx 0.5 milliseconds.
Is this fix available in the OPENHAB 3.1 Milestone 3 ?
I have another PI available to do a fresh OPENHAB 3.1 Milestone 3 install.
Or should I test the fix on the OPENHAB 3.0 install ?
@sonave you can compare timestamps to know what is included in which milestone.
From github
@wborn wborn merged commit 2219705 into openhab:main 21 hours ago
Milestone 3 is 2 weeks old, and therefore does not contain these new fies.
You would have to install 3.1 snapshot of modbus transport bundle, probably you want snapshot of modbus binding as well to ensure compatibility.
It should be compatible with openhab 3.0 release to my knowledge.
@ssalonen
I have tried to test the updated transport bundle but I am not sure about my update procedure.
Here are the steps I carried out.
Step 1
A fresh install of OH 3.1.0 M3
Step 2
Before installing the MODBUS binding via Paper UI
openhab> bundle:list -s | grep transport.modbus
no instances found !
Step 3
Install MODBUS binding via Paper UI
openhab> bundle:list -s | grep transport.modbus
262 │ Active │ 80 │ 5.2.1 │ nrjavaserial
263 │ Active │ 80 │ 3.7.2 │ Apache Commons Net
264 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: Modbus Binding
265 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: E3DC Modbus Binding
266 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: HeliosEasyControls Binding
267 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: Modbus SBC Binding
268 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: StiebelEltron Bundle
269 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: Studer Binding
270 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: SunSpec Bundle
271 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery
272 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery for Linux using sysfs
273 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Configuration Serial
274 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Modbus Transport
275 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Serial Transport
276 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Serial Transport for RXTX
277 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Serial Transport for RFC2217
Step 4
Uninstall Modbus Transport Bundle
openhab> bundle:uninstall 274
openhab> bundle:list
264 │ Waiting │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: Modbus Binding
265 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: E3DC Modbus Binding
266 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: HeliosEasyControls Binding
267 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: Modbus SBC Binding
268 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: StiebelEltron Bundle
269 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: Studer Binding
270 │ Active │ 80 │ 3.1.0.M3 │ openHAB Add-ons :: Bundles :: SunSpec Bundle
271 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery
272 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery for Linux using sysf
273 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Configuration Serial
275 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Serial Transport
276 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Serial Transport for RXTX
277 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Serial Transport for RFC2217
Step 5
File org.openhab.core.io.transport.modbus-3.1.0-SNAPSHOT.jar copied to /usr/share/openhab/addons folder
sudo reboot
Step 6
On completion of the reboot
openhab> bundle:list
275 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Serial Transport
276 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Serial Transport for RXTX
277 │ Active │ 80 │ 3.1.0.M3 │ openHAB Core :: Bundles :: Serial Transport for RFC2217
278 │ Active │ 80 │ 3.1.0.202103161959 │ openHAB Core :: Bundles :: Modbus Transport
The ModbusTransport Bundle has been updated and is active
Step 7
Next I queried the SMA inverter (Current Power, register 30775, length=2, 32 bit signed integer)
Unfortunately the result is as before 
Where have I gone wrong ?
Hmm this is still too old,check the timestamp ( 20210316195)
Please try with jar from here Changed read to readFully in TCP transports to get rid of fragmented packets by denis-ftc-denisov · Pull Request #11 · openhab/jamod · GitHub
That’s the one I have used, I downloaded it one more time and repeated all steps.
Same time stamp, same test result
279 │ Active │ 80 │ 3.1.0.202103161959 │
Ah of course! It makes sense to have older timestamp as this self built by the developer who introduced the fix…
That’s a bummer then, it looks like the fix is not helping here 
Can you see the wrong bytes received if you enable verbose logging?
I had a look at the original fix again. It looks like while rtu-over-tcp has been fixed, a wrong method has been fixed with pure tcp… Additional fix needs to be introduced
Comment - bear in mind one of the objectives of testing was that any “fragmentation fix” does not mess up the existing SMA workaround of +2 registers (which relies on the binding handling a truncated message without complaint).
So far so good on that score.
Obviously better if the fix prevents truncation in the first place.
The fix will complain if we would not get all the bytes (truly truncated message).
However, the current behavior is quite unpredictable, it eagerly “gives up if” not all the bytes have not been buffered “all at once” by low level tcp handling (I would guess this is OS and java implementation specific). All unreceived bytes are simply assumed to be zero.
Seems like if the modbus response is splitted to multiple packets this is causing problems.
The fix is in fact simply calling the socket reading functions as any sane protocol handling: if we expect 5 bytes, we expect 5 bytes until we reach timeout.
It’s quite amazing that this has not come out with other devices / requests. I wonder if it is more likely to encounter issues if we have many registers polled with one request (large payload)
I think in most home environments no fragmentation will ever occur, or at least very infrequently.
It only gets noticed with SMA because it is consistently affecting a simple two-register read.
1 Like
@sonave can you please try again with this version of the modbus transport, download from Modbus TCP client to read full messages, even if fragmented/segmented by ssalonen · Pull Request #13 · openhab/jamod · GitHub
1 Like
Good news,
Based on a quick test I can confirm the problem has been fixed with latest patch.
Since my plant is not producing power at the moment I had to change my poller from current power (30775, length 2, 32 bits signed integer) to today’s yield (30517, length 4, 64 bits signed integer)
The value presented by my testsystem is 10288W, this is not a multiple of 256, which means that the LSByte is taken into account.
I will do additional testing tomorrow.
Today’s test: Query Current Power (Register 30775, length =2)
Result:
2021-04-21 14:35:19.394 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPowerSB2500_ValueasNumber' changed from 959 to 967
2021-04-21 14:35:29.614 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPowerSB2500_ValueasNumber' changed from 967 to 978
2021-04-21 14:35:39.855 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPowerSB2500_ValueasNumber' changed from 978 to 990
2021-04-21 14:35:50.030 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPowerSB2500_ValueasNumber' changed from 990 to 1002
My conclusion:
Lower byte now included in the result.
PM
If more evidence is required, let me know what additional testing should be done.
2 Likes
It’s very good to not only get to the bottom of “SMA are weird” but to get it working cleanly.
Additional test performed:
- On OH 3.1.0.M3 with Modbus Transport Bundle 3.1.0.202104201719 installed
- Query Current Power Register 30775, with length = 4 instead of 2 (The Current SMA workaround)
- Query Today Yield Register 30517, with length = 8 instead of 4 (The Current SMA workaround)
Result for Register 30775:
2021-04-25 14:18:22.979 [DEBUG] [ernal.handler.ModbusDataThingHandler] -
Thing modbus:data:POLL_SB2500_30775:CURRENT_POWER_SB2500 channels updated:
{modbus:data:POLL_SB2500_30775:CURRENT_POWER_SB2500:number=875}.
readValueType=int32, readIndex=Optional[30775], readSubIndex(or 0)=0, extractIndex=0 -> numeric value 875 and boolValue=true.
Registers ModbusRegisterArray(0000036B0000036B) for request ModbusReadRequestBlueprint [slaveId=3,
functionCode=READ_INPUT_REGISTERS, start=30775, length=4, maxTries=3]
Result for Register 30517:
2021-04-25 14:18:22.079 [DEBUG] [ernal.handler.ModbusDataThingHandler] -
Thing modbus:data:POLL_SB2500_30517:CURRENT_YIELD_SB2500 channels updated:
{modbus:data:POLL_SB2500_30517:CURRENT_YIELD_SB2500:number=3711}.
readValueType=int64, readIndex=Optional[30517], readSubIndex(or 0)=0, extractIndex=0 -> numeric value 3711 and boolValue=true.
Registers ModbusRegisterArray(0000000000000E7F00000000054E90DF) for requestModbusReadRequestBlueprint [slaveId=3,
functionCode=READ_INPUT_REGISTERS, start=30517, length=8, maxTries=3]