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
It certainly does make sense to keep these new, rather obscure, settings normally “out of sight”. (Obviously, assuming a sensible set of defaults exists, which shouldn’t be a problem)
I think the ascii-art style guide added to the config file is perfectly adequate for deciphering the parameters.
I think you are saying e.g. retries is generally applied across all slaves - so it is more like the “poll” parameter, applying to the whole binding, not the connection. So that putting these new parameters on the connection configs is perhaps not the right thing. Maybe it is more appropriate as part of the “poll” parameter (particularly the timing stuff)
It does all get a bit tricky without introducing the concept of a connection, from which multiple slaves could hang. With OH2 looming, it isn’t the time for such restructuring.
Yeah I think you got my point. Indeed it’s somewhat similar to poll but like you said it might affect only some slaves (for example certain slow modbus tcp slave, or all serial slaves but not the tcp slaves).
Let’s go with the simple approach and iterate on top of that if needed. I would like to get this out in the wild as now many are suffering with current version of the binding.
Not really familiar with OH2 but I’ve seen some examples of hiearchial configuration where this would fit much more nicely. Perhaps something to look at when OH2 is closer.
EDIT: Pull request submitted. Let’s see how it goes!
Well done.
Could you post some further documentation about the configuration syntax in openhab.cfg so those reviewing the PR dont’t need to skim through the whole thread to piece things together?
And thx again for the great work. You really have transformed the thing from almost useless to pretty decent.
Best,
Max
Thank you!
Good idea about the documentation. Added some comments to the PR.
Best,
Sami
Hello.
Please help to solve problem with Modbus protocol.
My config:
when i use modbus simulator it always work, both the device and the program. when its work directly i don’t have stable transaction, it receives a signal or not.
I experimented with different version of SNAPSHOT, It does not help
openhab.cfg
modbus:poll=5
modbus:serial.slave1.connection=COM6:38400:8:none:1:rtu:280:100
modbus:serial.slave1.type=coil
modbus:serial.slave1.id=1
modbus:serial.slave1.start=2
modbus:serial.slave1.length=1
modbus:serial.slave2.connection=COM6:38400:8:none:1:rtu:280:100
modbus:serial.slave2.id=1
modbus:serial.slave2.start=2
modbus:serial.slave2.length=1
modbus:serial.slave2.type=discrete
modbus:serial.slave4.connection=COM6:38400:8:none:1:rtu:280:100
modbus:serial.slave4.id=1
modbus:serial.slave4.start=1
modbus:serial.slave4.length=1
modbus:serial.slave4.type=holding
openhab.log in normal mode 2016-03-30 16:25:22.334 [INFO ] [.o.core.internal.CoreActivator] - openHAB r - Pastebin.com
openhab.log in debug mode 16:30:14.471 [DEBUG] [.s.internal.SchedulerActivator:36 ] - Scheduler has been - Pastebin.com
Just out of curiosity why are you reading the same start address as a coil then as a discrete? slave1 and slave2
it’s my mistake while writing code. coil - switch led, dicrete - contact. it’s necessary to change address of discrete.
modbus:serial.slave1.connection=COM6:38400:8:none:1:rtu:280:100
modbus:serial.slave1.type=coil
modbus:serial.slave1.id=1
modbus:serial.slave1.start=2
modbus:serial.slave1.length=1
modbus:serial.slave2.connection=COM6:38400:8:none:1:rtu:280:100
modbus:serial.slave2.id=1
modbus:serial.slave2.start=3
modbus:serial.slave2.length=1
modbus:serial.slave2.type=discrete
modbus:serial.slave4.connection=COM6:38400:8:none:1:rtu:280:100
modbus:serial.slave4.id=1
modbus:serial.slave4.start=1
modbus:serial.slave4.length=1
modbus:serial.slave4.type=holding
normal 2016-03-30 17:55:58.640 [INFO ] [.o.core.internal.CoreActivator] - openHAB runti - Pastebin.com
debug 17:58:34.399 [DEBUG] [.s.internal.SchedulerActivator:36 ] - Scheduler has been - Pastebin.com
unfortunately its not working also
in experiment I use only coil register, but have same trouble
could you please try with latest of the latest version, available in the pull request.
Please note the changed configuration compared to previous snapshot versions, as discussed in the pull request. To keep things as simple as possible, please use this configuration
modbus:serial.slave1.connection=COM6:38400:8:none:1:rtu
modbus:serial.slave1.type=coil
modbus:serial.slave1.id=1
modbus:serial.slave1.start=2
modbus:serial.slave1.length=1
You probably need to comment out items referring to slaves.
I would also need to have higher level of logging. See this post on the details how to edit the logback_debug.xml.
After these changes, please start openhab using start_debug
Best
Sami
Sami, thank for attention.
System automatically hide my messages, it think that it was an advertisement.
I do all you written above.
New logfile