what about the RTU setting could that have thrown it off?
Ah I didn’t even notice that error in the config! Yes that apparently crashes some part of openhab itself (likely better error handling would be in order in core as well).
I have to improve the error handling.
Note that the binding handles the situation that two openhab modbus slaves have the same ip. Actually, that is the whole point the of this “connection pooling”.
Not sure what you are trying to achieve by setting ip and “rtu” – RTU is supported only with serial connections, not TCP connections. Or was it a pure typo?
The binding fails to parse “rtu” as number (as it should represent inter transaction delay in millis), and apparently makes openhab stuck…
I think it was left there when I was first started messing with modbus tcp and openhab. and I never know it was an error because the previous bindings must have ignored it.
It is true that they used to ignore additional parameters since previously you could only input host and port with TCP slaves. I believe you might get the old binding crash with 192.168.100.1:ThisIsInvalidPort since ThisIsInvalidPort is not a number…
Seems to work. No errors.
1200 Baud => 8.3ms/Character => 3.5*8,3ms = 29.05ms
=> 35ms should be ok for every application
What’s way more important anyway is the value of readTimeout where 280ms is actually quite low. The spec says:
Typically the Response time-out is from 1s to several second at 9600 bps
Although most devices are a lot faster we shouldn’t make something as low as 280ms the default - or at least suggest sth like 1.5s for debugging purposes.
Of course all I’m saying applies to serial lines only. I’ve got no real clue about ModBus TCP 
1 Like
Excellent feedback @mbs38! I agree that it makes sense to have large read time out, since I expect the 280ms to become tight if reading many many registers.
I shall go with the 35ms and 1.5s with serial slaves. For TCP I shall use 50ms inter transaction delay since it was required at least for my (pretty hefty, but with default settings) PLC.
I am playing with my settings and trying to get it to run smooth.
I am in a old and quite network heavy building at my company monitoring various devices around the plant.
Using wireshark with the filter set to “mbtcp” I can watch all the trafic go by one thing I noticed is when a device stops communicateing it brings the updates down to a snails pace as it retries the connection.
I am setting mine up as
modbus:poll=1000
# (IP)
# | (PORT)
# | | (interTransactionDelayMillis)
# | | | (reconnectAfterMillis)
# | | | | (interConnectDelayMillis)
# | | | | | (connectMaxTries)
# | | | | | |
modbus:tcp.slave1.connection=192.168.1.200:502:50:500:100:2
What I would like to achieve is every second it polls the 10 modbus devices with minimum delay between devices then essentially rest till the next second
Hi
Do you need all the parameters?
You could lower connection rtries (1), inter transaction delay (as low as your device can go), and inter connect delay (0ms)
With these settings it would try to connect only once, and if the slave is down it goes to next.
Edit : please note that with unreliable slaves the write commands will vanish if the retries are not enough…
I don’t know. can I skip parameters by having two colons next to each other?
modbus:tcp.slave1.connection=192.168.1.200::50::0:1
Oh sorry yeah that’s not possible. I was thinking that now some of the settings are more conservative than the defaults but I realized that defaults of these new settings are naturally not documented anywhere yet. 
Please try out the parameters I suggested and see if the performance is feasible for you.
Thanks
ok well I have come up with another fun modbus config question I am trying to JS transform a number I am receiving but it’s not working 
I have tried two different ways. The number is 6.10HZ the register returns 61 so I am dividing it by 10 the multiplying it by 60 to get RPM. When I have the JS inside the quotation marks it kicks an error when I have it outside the quotation marks it does nothing and I see the raw number.
HZ_RPM.js
(function(i){ return Math.round(i / 10 * 60); })(input)
Number Fan1RPM_H "Compressor Exaust Fan RPM [%d]" (modbus_raw,modbus) {modbus="slave5:0":JS(HZ_RPM.js)}
Number Fan1RPM_H "Compressor Exaust Fan RPM [%d]" (modbus_raw,modbus) {modbus="slave5:0:JS(HZ_RPM.js)"}
here is the error
org.openhab.model.item.binding.BindingConfigParseException: Register references should be either :X or :<X:>Y
at org.openhab.binding.modbus.internal.ModbusGenericBindingProvider$ModbusBindingConfig.<init>(ModbusGenericBindingProvider.java:207) ~[na:na]
at org.openhab.binding.modbus.internal.ModbusGenericBindingProvider.parseBindingConfig(ModbusGenericBindingProvider.java:108) ~[na:na]
at org.openhab.binding.modbus.internal.ModbusGenericBindingProvider.processBindingConfiguration(ModbusGenericBindingProvider.java:91) ~[na:na]
at org.openhab.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:348) [org.openhab.model.item_1.8.1.jar:na]
at org.openhab.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:324) [org.openhab.model.item_1.8.1.jar:na]
at org.openhab.model.item.internal.GenericItemProvider.processBindingConfigsFromModel(GenericItemProvider.java:171) [org.openhab.model.item_1.8.1.jar:na]
at org.openhab.model.item.internal.GenericItemProvider.modelChanged(GenericItemProvider.java:390) [org.openhab.model.item_1.8.1.jar:na]
at org.openhab.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:159) [org.openhab.model.core_1.8.1.jar:na]
at org.openhab.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:100) [org.openhab.model.core_1.8.1.jar:na]
at org.openhab.model.core.internal.folder.FolderObserver.checkFolder(FolderObserver.java:142) [org.openhab.model.core_1.8.1.jar:na]
at org.openhab.model.core.internal.folder.FolderObserver.run(FolderObserver.java:99) [org.openhab.model.core_1.8.1.jar:na]
Hi
Do you mind opening a separate thread about this as it is unrelated to this topic. Let’s continue the discussion on transformations there
Did you manage to configure modbus for sufficient performance? How did it perform with my configuration advice?
Best
Sami
The reason I kept it here is I believe that the binding needs to be setup to allow transform.
I agree that is quire relevant discussion but I try to keep this topic focused on the new version of the binding and especially the connection related and multi slave enchantments it include.
It just makes it easier to follow later on when I eventually submit a pull request for all the changes. I’m afraid it would otherwise be too easy to connect the error messages with this new version of the binding… I hope you understand!
I actually have something you could try with the transforms… Let me know when you have made the new thread and Let’s continue it there
Might be dumb question, but should these new parameters only be available as colon-style : appendages to the basic connection data, or is there value in making them (also) individually accessible (so that defaults for other things can be left as-is)? Or does it already happen that way?
Trivial example
modbus:tcp.slave2.connection=192.168.6.180:502
already has an alternative format as
modbus:tcp.slave2.connection=192.168.6.180
modbus:tcp.slave2.port=502
and of course ‘port’ can be defaulted simply by
modbus:tcp.slave2.connection=192.168.6.180
It’d be a lot clearer to read and understand, rather than
modbus:tcp.slave1.connection=192.168.1.200:502:50:500:100:2
when revisiting a config many months later…
@rossko57, I think you have a very good point. Indeed, the configuration is pretty hard to read currently.
However, please note that your example is deprecated and alternative format with port is not supported any more. I do not know the exact history of the binding but I believe the support was dropped when connection was introduced (to replace port and host). This is really one of the bad sides of introducing new configuration, the old just lives on even though it might not be even supported anymore.
As you might remember we discussed possible configuration options in the beginning of the thread. My last proposal was presented in this post. There you had configuration parameters similar to your example.
As the new binding does not have a concept of different “endpoint parameters” (that is, inter transaction wait millis (serial+tcp), reconnectAfterMillis (tcp), interConnectDelayMillis (tcp), connectMaxTries (tcp)) for different openhab modbus slaves, it would make sense to separate connection configuration from the actual “register/item definitions”.
I would like to keep the configuration changes conservative, and not introduce new format if not considered absolutely necessary. I do hope that we can figure defaults (as discussed with mbs38 here) that work for 90% of people. For those who need extra performance, would deep dive into configurations – perhaps with pre-made examples in the openhab.cfg as comments.
Just had an other idea as well, could we have nice comments in openhab.cfg, similar to @LeXLuther422’s example:
# (IP)
# | (PORT)
# | | (interTransactionDelayMillis)
# | | | (reconnectAfterMillis)
# | | | | (interConnectDelayMillis)
# | | | | | (connectMaxTries)
# | | | | | |
modbus:tcp.slave1.connection=192.168.1.200:502:50:500:100:2
Would you find this usable as a starting point?
Best,
Sami
Hi,
I would also agree with rossko57 about configuration. Ip port looks ok, as it is already kind of a standart:
modbus:tcp.slave2.connection=192.168.6.180:502
But timeouts should be on separate line, as it is to hard to remember. In couple of weeks you will need to check manual to see which one means what.
Btw, thanks for good work, have not check yet how it works, but nice to see a progress.
Thanks for the comment @robiss. I would appreciate if you could test the latest version and get your feedback how it works.
I will think how the separation of parameters would make sense…
Will try to test it ASAP, i guess in a matter of month, since installation/setup in not quite there yet. Currently I`m building a new house and made a decision to go with rpi + openHab instead of loxone, as it looks like this setup gives more freedom and project makes a lot of progress
1 Like