Modbus connection problem

Hi @Jereme_Guenther. Thanks for responding so quickly

As far as I know nothing good happens with two versions of the same binding, so any issues you get with that are not really important. I believe the system picks only one version.

What I meant by configuration is the openhab.cfg as described here. You can copy-paste only the modbus binding related configuration setting. If you have different configuration with you 1.7 setup, please paste that as well.

Can you please also enable debug level logging? This would help us to diagnose the issue better. You can use the start_debug script to do that.

When you paste the logs, can you provide more lines so any related error messages are pasted as well.

My configuration for modbus is the same between 1.7 and 1.8. I mentioned the two versions of the same binding because it was actually working like that.

Here is my configuration:

############################### Modbus Binding ########################################

sets refresh interval to Modbus polling service.

Value in milliseconds (optional, defaults to 200)

modbus:poll=2000

modbus:tcp.slave1.connection=192.168.1.31
modbus:tcp.slave1.type=coil
modbus:tcp.slave1.port=502
modbus:tcp.slave1.start=0
modbus:tcp.slave1.length=1

modbus:tcp.slave2.connection=192.168.1.31
modbus:tcp.slave2.type=coil
modbus:tcp.slave2.port=502
modbus:tcp.slave2.start=1
modbus:tcp.slave2.length=1

modbus:tcp.slave3.connection=192.168.1.31
modbus:tcp.slave3.type=coil
modbus:tcp.slave3.port=502
modbus:tcp.slave3.start=2
modbus:tcp.slave3.length=1

modbus:tcp.slave4.connection=192.168.1.31
modbus:tcp.slave4.type=coil
modbus:tcp.slave4.port=502
modbus:tcp.slave4.start=3
modbus:tcp.slave4.length=1

modbus:tcp.slave5.connection=192.168.1.31
modbus:tcp.slave5.type=coil
modbus:tcp.slave5.port=502
modbus:tcp.slave5.start=4
modbus:tcp.slave5.length=1

Why so complicated? That’s not the way it was meant to be used.
Try this:

openhab.cfg:
modbus:poll=2000
modbus:tcp.slave12345.connection=192.168.1.31
modbus:tcp.slave12345.type=coil
modbus:tcp.slave12345.port=502
modbus:tcp.slave12345.start=0
modbus:tcp.slave12345.length=5

in items:
Switch slave1 { modbus=“slave12345:0” }
Switch slave2 { modbus=“slave12345:1” }
Switch slave3 { modbus=“slave12345:2” }
Switch slave4 { modbus=“slave12345:3” }
Switch slave5 { modbus=“slave12345:4” }

Why so complicated? Because it was the first configuration I got to work and I just copied and pasted it for each port, and I haven’t had the time to try and clean it up correctly. Thank-you for making that easy for me.

I updated to your config and things are working perfectly with PR3819 now.

While I do agree your config is worlds better than mine. I am confused as to why mine was actually throwing errors. What is going to happen in the future when I do need to expand to using more than just a coil port on this device…

The Modbus binding is recognized to have difficulties handling multiple slave devices, for various reasons.
The changes to your config have made your device appear to the binding as a single slave with a few coils, instead of many slaves.with one coil each. It’s simpler for the binding to work with, as well as for you to look at and manage.

As you can tell by discussion of versions etc, this problem area is being looked into, chiefly by ssalonen

That must be the root of my problem then. I have finally tried to use the other half of my modbus device, the DO side. And now I am right back to my not connected issues with this config:

modbus:tcp.slave1.connection=192.168.1.31
modbus:tcp.slave1.type=coil
modbus:tcp.slave1.port=502
modbus:tcp.slave1.start=0
modbus:tcp.slave1.length=8

modbus:tcp.slave1a.connection=192.168.1.31
modbus:tcp.slave1a.type=coil
modbus:tcp.slave1a.port=502
modbus:tcp.slave1a.start=16
modbus:tcp.slave1a.length=8

I did get it to work once with a Switch for slave1a:<0:>0 and after that it died and isn’t working. I also tried combining the configs into one that started at 0 and had length 24, but since my modbus device does not actually have all those indexes I am guessing it was throwing errors.

Edit: I should go back and try this on version 1.7 since that version seemed to work for multiple modbus configs.

@Jereme_Guenther please see this post for the experimental version that might work for you.

Please note the additional (optional) parameter in connection string (not present in the official version), eg

modbus:tcp.slave1a.connection=192.168.1.31:502:100

The last number (100) is the delay between transactions in milliseconds.

The new binding makes sure that at most single connection is established, even when command is sent while polling. It seems that many modbus tcp devices can only accept single connection at a time. Furthermore connection is closed very aggressively, to avoid ‘reserving’ the server needlessly (similar was already implemented to the binding). The transaction delay seems to be necessary with some devices to give them some time to answer the connection request.

Edit: noted that you port parameter on a different line. I believe that is not supported anymore. Instead, you can configure it as above

edit 2: see the thread for serial modbus fixes. I think we close to improving the binding there as well

@ssalonen I reconfigured the port to the connection line, added the 100 default delay parameter, and the new version seems to be working perfectly.

Both slave configurations are accurately updating, and the second one is now correctly triggering my DO port without crashing the modbus plugin. Thank-you.

1 Like

@ssalonen very nice! Good job :+1:t2: