Modbus COMMUNICATION_ERROR ModbusIOException

syntacrsc · May 2, 2023, 10:57am

Hello openhab community.
I’m facing some issues using the modbus binding and appreciate your assistence in pinning down the cause/finding a solution.
Here’s my setup:
Growatt SPH10000TL3 BH-UP solar inverter with RS-485 (twisted pair) interface connected to
RS-485 to ethernet converter ZLAN 5143D.
Openhab 3.4.3 on raspberyy pi 4b

Thing file:

Bridge modbus:tcp:SPH10000 "Modbus SPH10000" [ host="10.0.0.190", port=502, id=1, rtuEncoded=true ] 
{
	Bridge poller Batteriewerte "Modbus Batteriewerte" [ start=608, length=1, refresh=120000, type="holding", maxTries=2 ] 
	{ 
      //  Thing data BatterieSOC "SOC" [ readStart="608", readValueType="uint16" ]
    }
}

Looking at the things in UI I see this error on Thing “Modbus Batteriewerte”:

The log shows these messages:

When I try to poll register 608 using tools like “Simplify Modbus TCP Client” I do get a valid/successfull response:

Any ideas as to what I’m doing wrong here?

Any help is highly appreciated!

Thanks and kind regards,
Ralph…

Oggerschummer · May 2, 2023, 12:23pm

Maybe the address if off by 1 - Some use starting index 0, others 1.
Would give it a try, config looks fine to me.

syntacrsc · May 2, 2023, 12:53pm

Hi Thomas.

Thanks for the idea, unfortunately still the issue and the same messages in the log:

Oggerschummer · May 2, 2023, 1:06pm

Guess you understood me wrong, instructions unclear I guess
I see you set the salveID from 1 to 0, which is wrong.
What I meant is the register address, not the device.
Register 1 starts at 0, that might be the case here. Again, just a guess.

syntacrsc · May 2, 2023, 1:15pm

Ah, my mistake, sorry - changed the register to 607 but still no change.
I’ve also increase the log-level for the modbus binding - getting an additional message in the log (which is not helpful to me either).

Thanks again!

Oggerschummer · May 2, 2023, 2:12pm

Hmm, still I have the impression that the register address is not correct.

The description in the UI says:

Address of the first register, coil, or discrete input to poll.
Input as zero-based index number, e.g. in place of 400001 (first holding register), use the address 0.

Which register documentation did you follow? I found that one, but did not find the register you mentioned.

Maybe reading with your tool was a lucky punch - did you validate that the result value delivered did fit to the value you would have expected?
Did you succeed in reading any other device with the binding?
Sorry I was not able to help yet.

syntacrsc · May 2, 2023, 3:45pm

Hi Thomas.

Interesting point, I’ll do some research on this.

The value I receive in the tool makes sense, I’ve also changed the setting in the web-UI of the device and could read the adjusted value with the tool.

This is my source for the register addresses (plus some additional research):

Growatt modbus v3.05

Address 608 is not mentioned in the documentation but 88 is and I’ve the same problem with register 88 (as with any other). Unfortunately the Growatt inverter is my only modbus device so I cannot validate general functionality with anotjer device.

Kind regards,
Ralph…

Oggerschummer · May 2, 2023, 5:35pm

Corrected my link above, me bad. Seems that this documentation ist more recent, the one you mentioned is said to have many errors.
Page 56 mentions rwo registers for the SOC, try it with these.

One more question:Did you run the tool on the Raspi running OH or on your laptop? Timeout errors when connecting to the socket could point to general network issues as well.

syntacrsc · May 3, 2023, 5:57am

Hi Thomas.

Well, all versions of the growatt modbus specifications (v1.05, v1.20 and v3.05) mention holding register as the one showing the version of the modbus protocol in use by the device.

When querying holding register 88 with the tool I receive value 305 which - according to the spec - is the representation of the modbus protocol version 3.05 (see screen shot).

Given that, and the fact, that holding register 608 returns the value of the SOC set on my device (and changes when the setting is changed on the device) I’m pretty confident, that the modbus protocol version 3.05 is correct (even though the tech spec itself is very incomplete (e.g. 608 is missing) - but that’s true for all three versions).

Nevertheless I will dig into your idea of an offset possibly required to be applied to the specified addresses - not quite sure yet as to where to search though…

Kind regards,
Ralph…

syntacrsc · May 3, 2023, 6:19am

Is there any way to show the full modbus request and response frames that are beeing sent/received by the binding?

According to the log there’s a CRC error in the received frame:
“Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException CRC Error in received frame: 6 bytes: 21 01 03 04 01 31 [operation ID 1422d2ab-6f8a-4c22-8a10-82ebbc062428]”

So there is communication going back and forth - seeing the details might give some clues on the cause of the error!?

As to my limited knowledge:
the request (for holding reg 88) should look like that:
01 03 00 58 00 01 05 D9
the response (with a value of 305) should look like that:
01 03 02 01 31 78 00

syntacrsc · May 3, 2023, 6:45am

Ha! I changed the logging level of org.openhab.core.io.transport.modbus to TRACE and can now see the request message/frame being sent from the openhab binding- and that is (as to my limited understanding of modbus) totally off!

Request for holding register 88 being sent:
00 00 00 00 00 06 01 03 00 58 00 01

Should be like that (at least this request is working when being sent by tool Simply Modbus TCP Client):
01 03 00 58 00 01 05 D9

Looks like Modbus binding is sending plain modbus TCP requests and not Modbus RTU requests even though rtuEncoded = true is set in the thing file.
Changing the rtuEncoded setting is not affecting anything in regards to the message/frame being sent - looks like a bug to me.

Is there anyone using modbus tcp binding with rtuEncoded = true ???

I’ve created a seperate post for the rtuEncoded issue with the modbus binding - see Mobus binding with “rtuEncoded=true” not working

Oggerschummer · May 3, 2023, 7:20am

Seems you’re getting closer.
Just tried with my Growatt 600 through the web interface and can confirm register 88 is working, response is 305.

Regarding the RTU-encoding:

Your interface is talking RTU to your Growatt on the twisted pair cable, fine.
But in the TCP-Direction, what is the setting in the interface? RTU over TCP ?
My meters are connected the same way, but over TCP I do not use RTU but plain ModBus TCP. This works.
Try disabling the RTU over TCP in the interface and use plain ModBus TCP, then remove the RTU-flag in openHAB and give it a try.

syntacrsc · May 3, 2023, 7:41am

Just had the same idea but I’m failing most likely due to a lack of understanding of my ZLAN 5143D interface settings:

I’ve tried all these various modes but it seems these settings do not change the frame format from RTU to be plain TCP (not sure if this setting has an effect at all - might be a prblem of the “cheap” interface device?).

Using the Simply modbus TCP tool the only frame format working (for all the above modes) is “RTU over TCP” (plain TCP requests do fail).

syntacrsc · May 5, 2023, 10:01am

Short update:

Thanks to an idea by Marcus (@MaWe222222) I did test a modbus serial connection with rtu encoding enabled to my device - that works like a charm!

To me it really looks like there’s a problem within the modbus binding for modbus TCP with RTU encoding enabled.

Any help on Modbus TCP with RTU encoding enabled is still highly appreciated!

Oggerschummer · May 8, 2023, 7:26am

Hi Ralph,

I had a similar issue (the timeout message I saw you get in your first post) when connecting my Protoss PW-21 gateway to some DDM18SD meters this week and I nearly collapsed figuring out the reason,
so I’m leaving this here for the record in case someone struggles with the same problem.
In my case the request was send to the ModBus, but there was no response on the bus itself, which caused the timeout.

Things I did:

The meter is connected correctly, no terminators used due to short cable length within the cabinet, polarity is fine, so no issue here.
Tried using the wireless interface, no succcess
Same for wired Ethernet.
RTU encode on / off, no effect (as I guessed)
Reset the interface, power on power off, nothing helped

This morning I was successful.
The meters uses a not really common scheme of even parity, not 8N1 but 8E1. On the display it shows 8N1, so guess why I was wrong.
Reconfiguring the serial interface in the Modbus Interface did the trick, values are coming like a charm.
No need for RTU over TCP.

When you tried with the serial usb interface:
Did you have different settings for the serial port than in the RS485 ethernet gateway? Maybe something there is fishy and the interface is sending to the bus but not receiving the proper response or no response at all.

I’d suggest to remove the RTU over TCP flag - the gateway itself does to transformation from RTU to TCP. Then check your serial port settings in the interface and that they match the device you are connecting to.
My Growatt is currently offline as I’m moving the panels to another location, so I was not able to test it.

Or did you succeed in the meantime?

Regards
Thomas