Modbus - NO 'transaction identifier' - OH3 modbus tcp thing causing modbus device to crash (Sailer FRIWASTA)

Add-ons Bindings
, ,
1

Hi there!
I am working on a strange problem. Things and items defined. Config, OH3 and modbus device are working fine - as long as I use just “input” register. At some point I picked a “holding” register from the list and liked to work with that value.
tried a lot. No way to read that holding as 32-bit signed big-endian. start is 230 and length is 2:

Bridge poller holding1 "sailer holding poller 1" [ start=230, length=2, refresh=10000, type="holding" ] {

        Thing data water_volume "sailer water-volume (l/min)" [ readStart="230", readValueType="int32" ]
}

activated TRACE:
2023-02-28 18:29:01.335 [TRACE] [rt.modbus.internal.ModbusManagerImpl] - Going execute transaction with request request (FC=READ_MULTIPLE_REGISTERS): 00 00 00 00 00 06 01 03 00 e8 00 02 [operation ID 866e23e6-4691-450f-a9f4-a52993e0af36]

What is a bit irritating:
there is no “transaction identifier” in that data package:
00 00 00 00 00 06 01 03 00 e8 00 02

I used Rapid SCADA Modbus Parser to get more information on that package. I don’t know, if a “transaction identifier” is mandantory for that device.

Using “Modbus poller” with same register everything works perfect for hours. thousands of requests and proper answers.

I also tried “holding” register 232. The same. Not working with openHAB. After some time the modbus device is not responding anymore regarding the input registers. Power cycled that device and then it is working again with the other/input registers.

All logs from the tool “Modbus Poll” show an increasing “transaction identifier”.

Within TRACE of the log there is an “Read timed out”-error:
2023-02-28 18:28:59.329 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_MULTIPLE_REGISTERS, start=232, length=2, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 866e23e6-4691-450f-a9f4-a52993e0af36]

At this point I would assume, that the device is not answering due to the missing “transaction identifier”. All other information is the same (compared the modbus tcp packages)

I would be very glad if someone could give me an hint how to solve this? Did anyone ever used the modbus tcp binding with a “Sailer FRIWASTA” (‘fresh water station’)?

Thanks,
Dirk

1 Like
2

Looks like modbus implementation issue on device end. Was you able to obtain interesting data using other tool?

3

With the tool “Modbus Poll” I was able to collect data from “holding” 230 (+231) and 232 (+233) more than 2.000 times and working fine for hours. The only difference regarding the modbus tcp package I found until yet was that “transaction identifier”. openHAB modbus does not use the “transaction identifier”. It is always 0x0000. The “Modbus Poll” tool does use that “transaction identifier” and it receives the same “transaction identifier” within the reply from that modbus device.

4

How do you know? Did you make a wireshark record?
Do you have a modbus specification (modbus table) form the device that you can post here?

Can you also post your complete modbus configuration (=Slave, Poller, Data)?
What is the unitID of the device?

5

the “transaction identifier” seems to be mandatory for tcp connections.

here a link to the modbus implementation guide

it says:

4.2 TCP CONNECTION MANAGEMENT

Implementation Rules:

  1. Several MODBUS transactions can be activated simultaneously on the same TCP
    Connection.

Remark: If this is done then the MODBUS transaction identifier must be used to
uniquely identify the matching requests and responses.

Does anyone knows how to get in contact with the maintainer(s) of that openHAB modbus binding?

6

I compared the ‘dumped’ tcp packages. I activated TRACE-level on openHAB:

log:set TRACE wimpi.modbus.net
log:set TRACE org.openhab.core.io.transport.modbus
log:set TRACE org.openhab.binding.modbus

Since I am on a remote site and openHAB is running on a RaspberryPi wireshark would be hard to get. I trusted the logs.

“Modbus Poll” has a log where outgoing and incoming tcp pakets are displayed as raw hex data. Both include ‘transaction identifier(s)’. The tcp modbus answer from the modbus device has the same ID as the request from the “Modbus Poller” application.

Since the modbus device is a “modbus tcp” implenmentation (network on device) and the device has at least THREE modbus units (‘0’ and ‘247’ for configuration and ‘1’ for the modbus polling of data (input, coils, holding). At the moment I would asume, that the management implementation uses (and needs) those ‘transaction identifiers’ to assign the reply to the original request. Because the device crashes on a communication without ‘transaction identifiers’

Maybe it also internally organizes the communication relying on that info - hard to say. Nevertheless the documentation is clearly. ‘transaction identifier’ must be used

Why? In my case it is by design, that the condition applies ‘several MODBUS transactions are activated simultaneously’ - due to the fact that there needs to be different openHAB modbus tcp things with same tcp IP and port but different unitIDs.
:502 with modbus UnitID ‘247’ for the configuration device - even to set password to access the device ‘1’
:502 with modbus UnitID ‘1’ for the polling device (read and write coils, input and holding register)

I got an excel with a huge list of registers and also examples of tcp packages when reading those regsters. I will post a link to a screenshot regarding that register 230 example.

Thanks, Dirk

7

here a screenshot from the log provided by a tool named “Modbus Poll”:

That tool uses ‘transaction identifier’. The modbus device is answering properly and providing the holding register data thousands of times and for hours.

8

here a screenshot of the modbus table regarding holding register 230 & 232.

As you can see, there are examples regarding the raw tcp hex data for reading the holding regsiters.
“Variable 115” called “Brauchwasserfluss” is stored in register 230 (variable * 2 = 115 * 2 = 230) with the length of 2 registers (int32 = 4 byte)

modbus tcp package payload to read that register (and regsiter 231 also) should be:
03 00 E6 00 02

03 => read holding register(s) function code
E6 => decimal 230
02 => length of 2 registers (=> 4 byte)

Exacly what openHAB and “modbus Poller” did. Therefore I am sure, that my things, pollers and data things are correctly defined regarding the UnitID, FC, register number and length.

The only difference I can see at trace level is that openHAB does not provide the “transaction identifier” within that modbus tcp package.

I havn’t found any profile to add a ‘provide transaction identifier’-configuration flag to my modbus tcp thing or to change the config in any other way to make it work…

The Manufacturer of that modbus unit insists that the implementation is correct and refers to the working “Modbus Poll” tool

1 Like
9

Hi Łukasz!
sorry, but at the moment for me it looks like a bad implementation on the openHAB side. Please see my reply to @Tuny

10

Hi @ssalonen!

On my exploration to get things working and understanding openHAB modbus implementation I took a look at:

In line 204 there is the code responsible for the log output I am investigating on.

line 204:
logger.trace(“Going execute transaction with request request (FC={}): {} [operation ID {}]”,
request.getFunctionCode(), libRequest.getHexMessage(), operationId);

my log:
2023-03-01 10:42:57.258 [TRACE] [rt.modbus.internal.ModbusManagerImpl] - Going execute transaction with request request (FC=READ_MULTIPLE_REGISTERS): 00 00 00 00 00 06 01 03 00 e6 00 02 [operation ID cb474887-6a39-4476-9801-a29b1e518732]

libRequest.getHexMessage() deliveres the hex-dump of that package beeing sent? Is that right?

From that payload “00 00 00 00 00 06 01 03 00 e6 00 02” I am assuming, that the openHAB modbus tcp implementation does not provide any modbus ‘transaction identifier’. It seems to provide 0x0000 as identifier in each and every package. Could you please check and confirm that point?

Since I am not able to get a wireshark at the moment (remote site) and not receiving any help from the manufacturer of that modbus device at the moment this is my only conclusion. Since the modbus device is crashing and not accessible after a few requests from openHAB a solution is really urgent for us.

I definied two modbus tcp things for that modbus unit in openHAB (3.4.2). The modbus unit has an network interface and provides three modbus units through modbus tcp protocol. UnitID 0,1 and 247. I need at least two (247 and 1). UnitID 247 for configuration and to provide a password via modbus to access UnitID 1. Therefore there are at least two modbus connections open and running at the same time.

Reading the ‘modbus implementation guide’ on 4.2.4 (see earlier post) I have to assume, that there should be an uniquely defined ‘transaction identifier’ - therefore not 0x0000 in each package.

I would be very happy if you could answer this point and join the discussion above. I’ve been working on an implementation for many days now, but unfortunately I can’t get any further.

Thanks,
Dirk

11

Im pretty sure transaction identifier is there, since its part of frame and communication protocol. It is a base to correlate slave response with request sent by modbus master. Transaction id normally is being incremented. Not sure why it stays at 0 for you. Out of curiosity - does other tool you use start with transaction id at 0 or 1?

12

Hi @splatch

I checked it. The other tool starts from “0” and there is an increase on each telegramm.

log from “Modbus Poller” tool:
Tx:000000-12:05:42.093-00 00 00 00 00 06 01 03 00 E6 00 02
Rx:000001-12:05:42.108-00 00 00 00 00 07 01 03 04 00 00 00 89
Tx:000002-12:05:47.112-00 01 00 00 00 06 01 03 00 E6 00 02
Rx:000003-12:05:47.127-00 01 00 00 00 07 01 03 04 00 00 00 88

I saw ‘older’ sources (=> “jamod” fork) increasing the ID understandable within code:

ModbusTCPTransaction.java line 201:

 m_Request.setTransactionID(c_TransactionID.increment());

Maybe this happens also in actual code but within other called functions - but I am not sure. again: I am very sorry, that I do not have wireshark. That would be much more effective. I am just relying on the logs (txt, debug, trace) from the different tools.

13

Hi @splatch!

You are right! There is an transaction ID - but it is not shown in the trace of that request -block. It is visible in the trace of a successful response. Since these successful communication traces do not happen so often I havn’t realized them yet…

So I activated other modbus things again and used that filter in frontail and got several modbus responses:

2023-03-01 12:42:33.391 [TRACE] [rt.modbus.internal.ModbusManagerImpl] - Response for read request (FC=3, transaction ID=33420): 82 8c 00 00 00 07 01 03 04 00 00 00 00 [operation ID 6211eda2-8c8a-4742-a0f5-867145ff8736]

2023-03-01 12:42:43.442 [TRACE] [rt.modbus.internal.ModbusManagerImpl] - Response for read request (FC=3, transaction ID=33421): 82 8d 00 00 00 07 01 03 04 00 00 00 00 [operation ID 566db8b2-4204-443f-b2e2-3d7fdc30bb97]

2023-03-01 12:42:53.493 [TRACE] [rt.modbus.internal.ModbusManagerImpl] - Response for read request (FC=3, transaction ID=33422): 82 8e 00 00 00 07 01 03 04 00 00 00 00 [operation ID 6a0fdef6-f8fb-452a-bf79-7e20dc2bd470]

2023-03-01 12:43:03.535 [TRACE] [rt.modbus.internal.ModbusManagerImpl] - Response for read request (FC=3, transaction ID=33423): 82 8f 00 00 00 07 01 03 04 00 00 00 00 [operation ID 195e19f2-705c-4aa0-820c-9eedf673a80a]

And this info is telling me, that there is an transaction ID within that package and it is increased!

hex:
=> 82 8c => 82 8d => 82 8e => 82 8f

decimal:
=> 33420 => 33421 => 33422 => 33423

@ssalonen
Therefore it is quite obvious, that there is an increasing transaction ID! Sorry to bother you all!

The problem must be caused by some other reason :frowning:

1 Like
14

If you are on remote site try termshark. It will save you ton of time on figuring out tcpdump options.

15

You could also install OpenHAB on your Windows machine, were you have the modbus poller tool installed.
On this machine you can trace the communication with wireshark and compare what is different between OpenHAB and the tool.
I am confident that you will get this to work with openHAB.

16

Hello DirkSander

I am also the owner of a Friwasta Plus.

Do you know if this Modbus table is public?
I could also make very good use of it

17

Hi @DirkSander,
just wondering what was the final outcome of your story? Also, would you be willing to post the modbus table or link to the source here? My electrician hooked up my Friwasta with Sailer Manager unit today and I really want to take a look at it’s modbus capabilities in the next few days.
Cheers!

1 Like