@watou Argh – too fast response from me. I meant that the PR 3684 is about fixing that assumption. Current implementation assumes that state is not changed by external party between polls. But perhaps this discussion is better continued in the actual pull request.
@watou @walter @paolo_denti New issue #3818 made for this. Corresponding pull request #3819 made to fix the issue.
I would appreciate if you would take the time to review the solution. @walter: can you test the new version? I uploaded the PR 3819 version online.
Hi @ssalonen I’m testing it and all now is working again.
Thanks a lot for the fix.
@watou Can you provide to approve the fix?
Walter
I have marked both the issue and PR for the 1.8.1 milestone. Does it need to be merged sooner than that, or would it instead make sense for @ssalonen to provide a link on the forum to a “hotfix” JAR until then?
A “hotfix” JAR I think it’s a very nice idea!
Yes I actually pasted hot fix jar above already 
I agree with the trend here. version 1.7 worked great. In version 1.8 modbus started throwing errors saying “ModbusSlave not connected”. It acts very much like modbus isn’t closing connections behind itself, which us causing all sorts of issues in my system.
I tried PR 3819 version, but I am still getting the errors. Has anyone else been successful with this new version of the jar?
After some more testing I do not think this is my issue at all. It sounds like everyone else here is able to use their modbus device just fine with openhab, just not other software at the same time. In my case openhab starts out reading the values from the modbus device, but quickly begins failing with the mentioned error; occasionally it will recover briefly and read values again before returning to the errors.
It’s not the modbus device as the old 1.7 configuration still works great.
Hi Jereme, I have a lot of modbus devices that I read from openhab and also from other sw at the same time.
Where I start to use OH I used 1.8 snapshot and modbus doesn’t work fine, the connection not closed was a big problem for me. Now I’m using PR 3819 from @ssalonen and all is fine, no problem.
P.S.
I’m using only modbus TCP using a Moxa Gw to convert modbus RTU in TCP. In new modbus version I see some changes on serial connection, but I don’t use it and I can’t test it becouse I use a VM.
@Jereme_Guenther can you provide more details? I think you are using modbus TCP?
If 1.7 worked great, then I’m afraid the connection closing introduced originally in the PR 3228 by paolodenti and later re-introduced (to fixup my other PR) in my PR 3819 might be causing the issue. Looking at the issue milestones, I believe that in 1.7 there was no connection closing after modbus read/write transaction.
If you can give more information on your configuration we can try troubleshoot from there…
thanks
Yes, I am using modbus TCP, the device is an Adam 6052 module.
I currently have two configurations of openhab as I try and make the transition from 1.7 to 1.8. Fortunately I am pretty new to this software so I do not have much in the way of configuration to copy over. The 1.7 configuration continues to function perfectly.
--------The Error-----------------
2016-02-09 20:14:12.879 [INFO ] [.b.modbus.internal.ModbusSlave] - ModbusSlave not connected
I did discover something very interesting. While both the 1.8 modbus jar file, and the PR 3819 jar files individually don’t work. (the 1.7 version results in nothing, while both 1.8 versions have that error.) But, if I use both the 1.7 and PR 3819 jar files together then things work perfectly. This was very unexpected and an unintentional discovery. I would have expected some method conflict error or something similar from this.
Unfortunately, when I tried to verify these findings by recreating each set of errors in turn it did not work a second time. Now when I include both jar files I get the original error and this:
-----------Error----------------
2016-02-09 20:20:45.130 [WARN ] [i.internal.GenericItemProvider] - Attempted to register a second BindingConfigReader of type ‘modbus’. The primaraly reader will remain active!
Edit: (but then a few minutes later with the new files it did indeed start working correctly again. So I have been able to re-create it.)
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
