Connection pooling in modbus binding

LeXLuther422 · March 21, 2016, 6:30pm

new thread started here Modbus Transform

rossko57 · March 22, 2016, 8:55pm

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…

ssalonen · March 24, 2016, 6:36pm

@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

robiss · March 25, 2016, 7:24am

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.

ssalonen · March 25, 2016, 7:52am

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…

robiss · March 25, 2016, 8:12am

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

rossko57 · March 25, 2016, 10:38pm

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.

ssalonen · March 26, 2016, 7:23am

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!

mbs38 · March 27, 2016, 12:10am

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

ssalonen · March 27, 2016, 1:54pm

Thank you!

Good idea about the documentation. Added some comments to the PR.

Best,
Sami

sCythe · March 30, 2016, 1:56pm

Hello.
Please help to solve problem with Modbus protocol.

My config:

Arduino Pro mini with USB serial converter
Openhab 1.8.1

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

LeXLuther422 · March 30, 2016, 2:20pm

Just out of curiosity why are you reading the same start address as a coil then as a discrete? slave1 and slave2

sCythe · March 30, 2016, 3:04pm

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

ssalonen · March 30, 2016, 3:42pm

@sCythe,

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

sCythe · March 30, 2016, 5:02pm

Sami, thank for attention.
System automatically hide my messages, it think that it was an advertisement.
I do all you written above.
New logfile

ssalonen · March 30, 2016, 5:15pm

Thanks, this helps.

It can read something from the slave:
`19:21:52.888 [TRACE] [i.modbus.io.ModbusRTUTransport:127 ] - Managed to read at least one byte``
but when reading rest of the response, the serial library returns EOF immediately it seems (notice the same timestamp):

19:21:52.888 [ERROR] [i.modbus.io.ModbusRTUTransport:171  ] - Last request: 01 01 00 02 00 01 5c 0a
19:21:52.888 [ERROR] [i.modbus.io.ModbusRTUTransport:172  ] - failed to read: Error reading response (EOF)

Basically we would expect that the EOF error comes only after timeout has elapsed. The default timeout is 1500ms = 1.5 seconds:

19:21:52.898 [ERROR] [w.m.io.ModbusSerialTransaction:199 ] - execute try 1/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadCoilsRequest@511d78d1 (unit id 1 & transaction 1). Serial parameters: SerialParameters@102c4d88[portName=COM6,baudRate=38400,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=none,encoding=rtu,echo=false,receiveTimeoutMillis=1500]

I have a bad feeling that this issue might be platform dependent – not sure I know how the serial library openhab really works with different platforms.

Do you have the issue with other tools, such as modpoll?

sCythe · March 30, 2016, 6:07pm

I’m not test with modpol, but with PLC Simulator, it was no problem all work, logfile.

starting modpoll I have this result logfile

ssalonen · March 30, 2016, 8:05pm

Actually I meant that you would try to read data with modpull. Please keep openhab closed at this time.

If you could then paste the modpoll output, that would be most useful.

Their website has pretty good documentation on the usage but I’m happy to help if needed.

sCythe · March 31, 2016, 9:39am

Good day, ssalonen.

I test device with modpoll and received such a result:

modpoll -b 34800 -p none -m rtu -a 1 -r 1 -c 5 -t 0 COM4
modpoll 3.4 - FieldTalk™ Modbus(R) Master Simulator
Copyright (c) 2002-2013 proconX Pty Ltd
Visit http://www.modbusdriver.com for Modbus libraries and tools.

Protocol configuration: Modbus RTU
Slave configuration…: address = 1, start reference = 1, count = 5
Communication…: COM4, 34800, 8, 1, none, t/o 1.00 s, poll rate 1000 ms
Data type…: discrete output (coil)

– Polling slave… (Ctrl-C to stop)
Reply time-out!
– Polling slave… (Ctrl-C to stop)
Reply time-out!

Intresting result. First of all I test modpoll on my simulator program, be sure to select the correct settings of modpoll option.

with simulator

modpoll -b 34800 -p none -m rtu -a 1 -r 1 -c 5 -t 0 COM14
modpoll 3.4 - FieldTalk™ Modbus(R) Master Simulator
Copyright (c) 2002-2013 proconX Pty Ltd
Visit http://www.modbusdriver.com for Modbus libraries and tools.

Protocol configuration: Modbus RTU
Slave configuration…: address = 1, start reference = 1, count = 5
Communication…: COM14, 34800, 8, 1, none, t/o 1.00 s, poll rate 1000 ms
Data type…: discrete output (coil)

– Polling slave… (Ctrl-C to stop)
[1]: 0
[2]: 1
[3]: 1
[4]: 1
[5]: 0
– Polling slave… (Ctrl-C to stop)
[1]: 0
[2]: 1
[3]: 1
[4]: 1
[5]: 0

then I change programm in Arduino (other modbus library) and test device on modpol:

modpoll -b 38400 -p none -m rtu -a 1 -r 20 -c 5 -t 0 COM3

Protocol configuration: Modbus RTU
Slave configuration…: address = 1, start reference = 20, count = 5
Communication…: COM3, 38400, 8, 1, none, t/o 1.00 s, poll rate 1000 ms
Data type…: discrete output (coil)

– Polling slave… (Ctrl-C to stop)
[20]: 1
[21]: 0
[22]: 0
[23]: 0
[24]: 0

below you can see results with openhab:
my openhab.cfg

openhab.log in debug mode
I have response to switch on localhost page.

ssalonen · March 31, 2016, 2:33pm

I’m so sorry but I’m quite confused with the openhab logs you are pasting and the different devices you are trying out… If I understood correctly you have communication issue with modpoll as well as the openhab when communicating with real device.

If I understood correctly it seems to work with Arduino (COM3) but not real device (COM4)?