Modbus Studer TCP Bridge not working after migration

Setup, Configuration and Use Migration
1

Hi, after reading nearly a day the forum up and down without success, i hope to find some help here and risk to ask some already asked question again).

My situation: i migrated about a month ago from openhab2 to 3 and now nearly everything is working again. What’s still causing issues is the modbus studer binding.

In the first run i moved my config from oh2 to oh3 (two different installations) and then found out, it’s not working. After some time in the forum i found, there is a new syntax for configuration needed and i switched.

Old config:

Bridge modbus:tcp:bridge [host="moxa-01.joessnitz.home", port=502, rtuEncoded=true]
Thing modbus:xtender:bridge:xtender1    "Xtender 1" (modbus:tcp:bridge) [ slaveAddress=11, refresh=5 ]

New config:

Bridge modbus:tcp:moxa-01 "Moxa-01" [host="192.168.5.15", port=502, rtuEncoded=true] {
        Bridge poller studer "StuderPoller" [ start=0, length=64, type="input" ] {
                Thing data xtender1     "Xtender 1" [ readStart="11", readValueType="int16" ]
        }
}

I also tried to remove the config, restart the system and redo it via the OH3-Webadmin interface.

Outcome: No matter if i do it via the web-ui or via modbus.things file, the only thing online is the tcp-bridge itself. Via things-file, the 2 attached things show “error:comm”/“error:bridge”, via the web-ui after adding the tcp-bridge, it does not show up as bridge-thing to parent the next item.

I am running a openhab 3.1.0, my plugins list as follows:

289 │ Active │  80 │ 3.1.0                 │ org.openhab.binding.modbus
290 │ Active │  80 │ 3.1.0                 │ org.openhab.binding.modbus.e3dc
291 │ Active │  80 │ 3.1.0                 │ org.openhab.binding.modbus.helioseasycontrols
292 │ Active │  80 │ 3.1.0                 │ org.openhab.binding.modbus.sbc
293 │ Active │  80 │ 3.1.0                 │ org.openhab.binding.modbus.stiebeleltron
294 │ Active │  80 │ 3.1.0                 │ org.openhab.binding.modbus.studer

Log is flooded by messages like:

2021-12-07 23:17:05.705 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_INPUT_REGISTERS, start=0, length=64, maxTries=3]). Aborting. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID c5af319e-c7ae-4407-9b24-36a0c807754e]

I am sure the studer equipment is working. If i reboot the old system and start the oh2-instance (2.5.12) there, it works immediately.

Any help is appreciated,

Thanks
Michael

2

Not really.

You used to use the Studer extension to the Modbus binding. I think perhaps you are keeping from us that there is a TCP gateway between openHAB and device?

You seem to now be trying to configure as generic Modbus instead. Why not continue to use Studer extension?

Your old config looks sensible

but it doesn’t work, so what’s changed?

How confident are you that your new installation can resolve the named address moxa-01.joessnitz.home ? Can you ping that from the console? What happens if you use the IP address of the gateway?

1 Like
3

Hi,

yes… i spared the hint, that between the RS485 and the openhab is a Moxa MGate MB3170I to translate from rs485 to ip.

I am not sure, when to use modbus and when it is studer. How can i select between the two of them? In the ui there is only the modbus binding itself.

Yes, moxa-01 is at least on OS-level resolvable. If it works within openhab, i am not sure. Even if i put a wrong hostname there, it replies with “online”. If i switch to ip, it makes no difference.

4

I don’t use the UI, if you want to use that somehow you must select a modbus:xtender: type Thing. (after creating a generic TCP bridge)
Or use xxx.things file like you used to.

Yes, TCP Bridge online does not mean the device even exists. It tells you the network is available, so we can try to connect. It’s the pathway that is online, not the destination.

If the Moxa responds to pings, you might try to set up a ping Thing from Network.

All we know so far is that there is no response to an OH TCP Modbus query.

5

I’d love to stick with config files. Imho, those are way faster. I now switched back to my original config (the working one from oh2.5).

I added network things and corresponding items. openhab recognized the moxa by name and ip as well as the serviceport 502 to be working. Can i debug modbus-tcp communication within openhab somehow?

6

You can use TRACE or DEBUG logging, I think modbus.transport will be the interesting module.

It’s not clear if you have network ping working on the ‘faulty’ OH3 setup. Don’t forget, network Thing “online” does NOT mean it works, you must link an Item for ping status.
I’m not convinced that you can ever ping port 502, shouldn’t that only speak Modbus-TCP?

7

The things vs. items i realized. I added a thing+item with a broken dns record and another one to a closed port on the moxa too, to proove that “online” really means online. And to the moxa-01:502 a tcp-connect works (tested by telnet-client). I should probably mention, i created a servicedevice instead of a pingdevice.

About the Debug, i will try next and come back with more details.

8

DEBUG or TRACE on modbus.transport doesn’t bring up any additional messages. DEBUG on modbus itself kinda floods the logs.
On both (oh2.5 and oh3) there is for each modbus.studer thing a line like

2021-12-08 21:08:33.529 [DEBUG] [modbus.studer.internal.StuderHandler] - Initializing thing with configuration: Configuration[{key=slaveAddress; type=BigDecimal; value=61}, {key=refresh; type=BigDecimal; value=10}]
2021-12-08 21:08:33.529 [DEBUG] [modbus.studer.internal.StuderHandler] - Setting up regular polling

On oh2.5 after a few seconds there are lines like:

2021-12-08 21:09:45.943 [DEBUG] [rt.modbus.internal.ModbusManagerImpl] - Executing scheduled (5000ms) poll task BasicPollTask@1e53db29[request=ModbusReadRequestBlueprint@10942693[slaveId=42,functionCode=READ_INPUT_REGISTERS,start=2,length=2,maxTries=3],endpoint=ModbusTCPSlaveEndpoint@7ea5d58d[address=moxa-01.joessnitz.home,port=502],resultCallback=org.openhab.binding.modbus.studer.internal.StuderHandler$$Lambda$514/0x0000000100ce2840@5510e85b,failureCallback=org.openhab.binding.modbus.studer.internal.StuderHandler$$Lambda$515/0x0000000100ce2c40@10127c9d]. Current millis: 1638994185943
2021-12-08 21:09:46.014 [DEBUG] [rt.modbus.internal.ModbusManagerImpl] - Modbus operation ended, timing info: {total: 73 ms, connection: 12, transaction=45, callback=10} [operation ID 8939ab21-9ede-44a4-831e-5a81a4833e2a]

On oh3:

2021-12-08 21:08:37.491 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=272, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID ea85a320-5c1c-47a3-9811-cc582587a044]
2021-12-08 21:08:40.559 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=98, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 8f9d4990-53ae-4fbf-8c8f-7ae51889d992]
2021-12-08 21:08:43.624 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=22, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 9a3cf203-2e5a-4758-9216-8dd08a135f3a]
2021-12-08 21:08:46.689 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=24, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 395cce87-8b87-4356-8e61-15594eea33de]
2021-12-08 21:08:49.754 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=274, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 9e2a7abc-bf9d-408a-8342-f033d0b11510]
2021-12-08 21:08:52.819 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=272, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID ea85a320-5c1c-47a3-9811-cc582587a044]
2021-12-08 21:08:55.884 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=98, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 8f9d4990-53ae-4fbf-8c8f-7ae51889d992]
2021-12-08 21:08:58.950 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=22, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 9a3cf203-2e5a-4758-9216-8dd08a135f3a]
2021-12-08 21:09:02.015 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=24, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 395cce87-8b87-4356-8e61-15594eea33de]
2021-12-08 21:09:05.080 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=274, length=2, maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 9e2a7abc-bf9d-408a-8342-f033d0b11510]
2021-12-08 21:09:08.145 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=11, functionCode=READ_INPUT_REGISTERS, start=272, length=2, maxTries=3]). Aborting. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID ea85a320-5c1c-47a3-9811-cc582587a044]

The current log-config:

org.openhab.binding.modbus                         │ WARN
org.openhab.binding.modbus.studer                  │ TRACE
org.openhab.binding.modbus.transport               │ TRACE

Thanks for your help so far. I hope, you can get something from it.

9

It’s still not completely clear if you have run the network-ping tests on the ‘failing’ OH3 installation.

The OH3 installation gets no response to its queries. There’s not much else to say.

It tells you what it’s trying to do -

so you could try that from a 3rd party Modbus tool, like modpoll or radzio.

10

If i interpret this correctly, modpoll seems to work fine. If i add “-a” and one of the start addresses from the log, there is an “illegal data address” error every time. But, i do not know much about the modbus protocoll, so this is probably a mistake on my side.

openhab01:~$ mbpoll moxa-01 -a 11 -c 2
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [11]
                        start reference = 1, count = 2
Communication.........: moxa-01, port 502, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, output (holding) register table

-- Polling slave 11... Ctrl-C to stop)
[1]:    32704
[2]:    0
-- Polling slave 11... Ctrl-C to stop)
[1]:    32704
[2]:    0
^C--- moxa-01 poll statistics ---
2 frames transmitted, 2 received, 0 errors, 0.0% frame loss
11

openHAB is not trying to read OUTPUT type, nor address 1

In Modbus, Input and Holding types are two distinctly different sets of registers.

12

It starts getting complicated. :stuck_out_tongue:

If i add “-t 3” it reads input-register-table and by “-r 27?” the following:

For 272 (as in the log)

mbpoll moxa-01 -a 11 -c 2 -t 3 -r 272 -1
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [11]
                        start reference = 272, count = 2
Communication.........: moxa-01, port 502, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, input register table

-- Polling slave 11...
Read input register failed: Illegal data address

OR:

mbpoll moxa-01 -a 11 -c 2 -t 3 -r 273 -1
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [11]
                        start reference = 273, count = 2
Communication.........: moxa-01, port 502, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, input register table

-- Polling slave 11...
[273]:  16036
[274]:  23069

For all start codes i checked, it works when i increment by 1. So, how do i shift addresses by 1? And why is it working on the oh2-instance? :confused:

13

You don’t. mbpoll uses register numbers, where register number 1 has address 0. openHAB uses register addresses, starting at 0 (mirrors what is actually sent in the protocol).
It’s all frequent confusion with Modbus, I’d forgotten mbpoll does that.

End result is -

That is working good, and exactly mimics what openHAB is trying to do.

Now you’ve got to work out what is different between the environment mbpoll runs in, and the environment openHAB3 runs in. I can’t imagine it’s any permissions issue for TCP/IP. Docker? Multiple network ports?

14

Sorry for delay. Needed to clean up and filter a little bit.

I have installed both of the openhab-systems (2.5 and 3) in a proxmox environment. The mbpoll runs also on the same server, where oh3 is running. To reduce risk of incorrect permissions, i tried to run mbpoll as openhab-users, it still works.

To see, what is different, i tcpdumped an oh request as well as one via mbpoll. Wireshark knows about modbus, so it was quite easy to see. Only issue. It’s only there via mbpoll. If i trigger it while openhab is running, there is no modbus-request visible except in the openhab-log. So, it seems, as if openhab simply does not trigger the request. Only traffic i see from openhab is the network thing.

15

I guess that’s blocking TCP/IP traffic somehow. Maybe you need to permit non-HTTP or something.

1 Like
16

Additional question from my part. Are you now using the studer binding or the generic modbus binding (using poller and data things)?

The initial post is also confusing… I think there was no rtu-over-tcp support (rtuEncoded parameter) in openhab 2. This was added in openHAB 3.1.0 Milestone 1 Releases · openhab/openhab-distro · GitHub

Also, if I understand correctly, the moxa device acts as plain modbus tcp server, so you should not need the rtuEncoded parameter.

Nevertheless rtu or not, you would expect to see the network traffic in the wireshark, so there might be a lower level issue here…

1 Like
17

proxmox isn’t filtering or blocking traffic. At least about that i am quite sure, as both oh-vm’s are running on the same system and even mbpoll is installed on the oh3-system, what also works fine. The line between working and nonworking is only within the oh3-environment.

18

I moved back to the old config since i got hinted, this is studer and the new one is only generic modbus.
About the rtu-param i am not sure. It is there already in the 2.5 config. However, i will try to remove it to see, if that makes any difference. I just checked the 2.5 documentation (Studer - Bindings | openHAB), there it is already, however, in another syntax than i have it.

As openhab runs as VM, the moxa is reachable by tcp only and is working as a gateway to the modbus world. As stated, i will try to remove it. Maybe openhab did not send the requests as oh3 is confused about the rtu parameter.

19

:slight_smile: That’s it. I removed the rtu, what was followed by some java exceptions in the oh log. So, i restarted and the items went online immediate.
Solution:
Bridge modbus:tcp:bridge [host="moxa-01.joessnitz.home", port=502]

Thanks a lot to both of you for guiding me there and explaining loads of details about the modbus protocol.

(As openhab still does not offer an option, to write (e.g. battery reserve power) back to modbus, maybe this could be done via some command line tool.)