Connection pooling in modbus binding

openhab
modbus
binding
Tags: #<Tag:0x00007f1e5bea08c8> #<Tag:0x00007f1e5bea05f8> #<Tag:0x00007f1e5bea7ee8>
(Ssalonen) #156

@carzten2000, please find the late official 1.9.0 snapshot version here. I recommend using the above official development version instead of the custom build you are currently using (now that the new functionality is merged). I’m afraid that it’s unlikely that it works even there due to different baud rates.

So it works if you remove the slave having different baud rate, eg em23?

I believe there was discussion in this thread regarding the challenges of having different baud rates in the same line. I’m not sure you can really get that working reliably… But perhaps some one else has more information on this?

Technically speaking the binding currently configures (baud rate, parity etc) the serial port in the very beginning, and does not change it afterwards. That alone now causes issues for you as the baud rate would have to be reconfigured again and again to match the slave device requirements. This detail is easy to change though… We could try it out if you like?

0 Likes

(carzten2000) #157

Hi.

Yes, everything is working great when I remove the connection to the device em23.
So it is because of the differnet baud rates.

that would be greet if you want to change the binding so i can test it.

0 Likes

(Ssalonen) #158

@carzten2000 Please try out this version and report back please. Now this version re-configures the serial port after every transaction.

Best,
Sami

0 Likes

(carzten2000) #159

Hi.

I’am still getting the same error.

2016-07-12 09:27:15.321 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - Last request: 01 04 00 0c 00 03 70 08
2016-07-12 09:27:15.323 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - failed to read: Error reading response (EOF)
2016-07-12 09:27:15.327 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute try 1/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@392119 (unit id 1 & transaction 3). Serial parameters: SerialParameters@38130d[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
2016-07-12 09:27:17.195 [INFO ] [marthome.event.ItemStateChangedEvent] - room08_room_temp changed from 22.60 to 22.50
2016-07-12 09:27:17.841 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - Last request: 01 04 00 0c 00 03 70 08
2016-07-12 09:27:17.848 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - failed to read: Error reading response (EOF)
2016-07-12 09:27:17.850 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute try 2/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@392119 (unit id 1 & transaction 3). Serial parameters: SerialParameters@38130d[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
2016-07-12 09:27:20.361 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - Last request: 01 04 00 0c 00 03 70 08
2016-07-12 09:27:20.362 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - failed to read: Error reading response (EOF)
2016-07-12 09:27:20.364 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute try 3/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@392119 (unit id 1 & transaction 3). Serial parameters: SerialParameters@38130d[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
2016-07-12 09:27:20.365 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute reached max tries 3, throwing last error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@392119. Serial parameters: SerialParameters@38130d[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
2016-07-12 09:27:20.367 [ERROR] [.binding.modbus.internal.ModbusSlave] - ModbusSlave (em23): Error getting modbus data for request net.wimpi.modbus.msg.ReadInputRegistersRequest@392119. Error: I/O exception - failed to read. Endpoint ModbusSerialSlaveEndpoint@1b70321[portName=/dev/ttyUSB0]. Connection: SerialConnection@6c8b5f[portName=/dev/ttyUSB0,port=/dev/ttyUSB0]

It does not look like the baud rate is changing.

0 Likes

(Ssalonen) #160

If I remember correctly, the binding prints summary of parsed slaves in the beginning . That should make it clear what baud etc will be used.

Can you repeat the test with debug level logging and paste the relevant log snippet here? you can find instructions to logging configuration from the modbus binding wiki page

Best
Sami

0 Likes

(Rossko57) #161

The whole idea of mixing speed/parity modes etc. down a single wire seems a bit perilous. In theory, the timing of RTU inter-message gaps and suchlike is set by linespeed. Even if cleverness could be worked into the binding to make safe allowances at the master end, you can’t predict how the slaves are going to cope.

The Modbus RTU specification states
"The transmission mode (and serial port parameters) must be the same for all devices on a MODBUS Serial Line."
which means that slave designers need not handle the case in any sensible way.
Reminder - it is possible the particular problem being attacked here is slave-based i.e. one of the devices is entering error recovery when it sees “gibberish” intended for another slave.

Also think that trying to get the binding to cope with it is essentially wasted effort for non-compliant cases. Personally I wouldn’t like to guess how well different hardware and operating system hosts would handle rapid reconfiguring of serial ports to make it feasible anyway.

The “correct” solution here is to set up two serial buses (would that just be a second USB<>RS485 adaptor in this case?)

1 Like

(carzten2000) #162

@ssalonen

After reading the reply from @rossko57 I thing that best solution would be to just ad another usb<>rs485.
I going to test this next week, and I will report back with the result.

0 Likes

(Rossko57) #163

I didn’t mean to sound snippy about it, like “you can’t do that” !

I’m sure it would work in many cases. The difficulty is that in cases where it doesn’t work properly, the problem may lie in some ‘Black Box’ (Operating system, serial adaptor, modbus slave) outside of your control. No-one will be interested in fixing those because they won’t be seen as broken - “That is not the way to use them”. Note that fully-featured modbus slaves would be counting up more errors than good transfers.
Worse case, you get it working - but then later some small change in host or slave breaks it. Me, I just wouldn’t risk that.

Please do let us all know if multiple serial buses works for you - that may be an untested case (so far) for the OH binding.

0 Likes

(Ssalonen) #164

Really good that you brought this up! Indeed from the perspective of the rtu slave it is really bad situation if there are many baud rates on the same line.

Therefore will leave the binding as is and looking forward to hear the feedback from the test.

0 Likes

(carzten2000) #165

Hi @rossko57 and @ssalonen

I have now tried with an extra usb <> rs485 device.
And it is working :slight_smile:

Thanks :slight_smile:

This is the configration:

poll=10000
writemultipleregisters=true

# Read kWh & kW from EM23 El Meter
serial.em23.connection=/dev/ttyUSB1:9600:8:none:1:rtu:1000
serial.em23.id=1
serial.em23.start=12
serial.em23.length=3
serial.em23.type=input

# Read Nilan Temp
serial.nilan.connection=/dev/ttyUSB0:19200:8:even:1:rtu:1000
serial.nilan.id=30
serial.nilan.valuetype=int16
serial.nilan.start=203
serial.nilan.length=6
serial.nilan.type=input

# Read Nilan RH
serial.nilan2.connection=/dev/ttyUSB0:19200:8:even:1:rtu:1000
serial.nilan2.id=30
serial.nilan2.valuetype=int16
serial.nilan2.start=221
serial.nilan2.length=1
serial.nilan2.type=input

# Read Nilan AlarmState
serial.nilan3.connection=/dev/ttyUSB0:19200:8:even:1:rtu:1000
serial.nilan3.id=30
serial.nilan3.valuetype=int16
serial.nilan3.start=400
serial.nilan3.length=10
serial.nilan3.type=input

# Read/Write Nilan ControlSet
serial.nilan4.connection=/dev/ttyUSB0:19200:8:even:1:rtu:1000
serial.nilan4.id=30
serial.nilan4.start=1001
serial.nilan4.length=4
serial.nilan4.type=holding

# Read/Write Nilan Speed
serial.nilan5.connection=/dev/ttyUSB0:19200:8:even:1:rtu:1000
serial.nilan5.id=30
serial.nilan5.start=200
serial.nilan5.length=2
serial.nilan5.type=holding
0 Likes

(Ssalonen) #166

Thank you for reporting back. Great to hear it is working!

Clarified this bit in the wiki

0 Likes

(lgeorgiev) #167

Is it possible to restric modbus.net.TCPMasterConnection to make only one connection per IP:port
As many slaves addet behind one IP the connections become many. Most of the Gateways support one connection.
No debug information about the address of the failed slave. ( ModbusSlave: Error connecting to master: Connection timed out)

0 Likes

(Ssalonen) #168

Hi @igeorgiev

What version of modbus binding you are using? The latest development version includes this feature, and it is actually the only mode of operation.

Best
Sami

0 Likes

(lgeorgiev) #169

Hi Sami,
I’m using the last stable version openHAB runtime (v1.8.3).
When I start the OH, I see:
2016-08-01 19:54:14.055 [DEBUG] [o.b.m.internal.ModbusActivator] - Modbus binding has been started.
2016-08-01 19:54:14.129 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘FF_Service_PWM’ instanciated
2016-08-01 19:54:14.137 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Garden_TRh’ instanciated
2016-08-01 19:54:14.139 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Garden_TRh_Relay’ instanciated
2016-08-01 19:54:14.141 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘GF_Office_PWM1’ instanciated
2016-08-01 19:54:14.143 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘GF_Office_PWM2’ instanciated
2016-08-01 19:54:14.144 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘GF_Showroom’ instanciated
2016-08-01 19:54:14.146 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘GF_Warehouse’ instanciated
2016-08-01 19:54:14.148 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Office_TRh’ instanciated
2016-08-01 19:54:14.149 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Office_TRh_Relay’ instanciated
2016-08-01 19:54:14.151 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Printer_TRh’ instanciated
2016-08-01 19:54:14.153 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Printer_TRh_Relay’ instanciated
2016-08-01 19:54:14.154 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘RackRoom_TRh’ instanciated
2016-08-01 19:54:14.156 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘RackRoom_TRh_Relay’ instanciated
2016-08-01 19:54:14.157 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Service_TRh’ instanciated
2016-08-01 19:54:14.158 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Showroom_TRh’ instanciated
2016-08-01 19:54:14.159 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Showroom_TRh_Relay’ instanciated
2016-08-01 19:54:14.161 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Warehouse_TRh’ instanciated
2016-08-01 19:54:14.162 [DEBUG] [.modbus.internal.ModbusBinding] - modbusSlave ‘Warehouse_TRh_Relay’ instanciated
2016-08-01 19:54:14.163 [DEBUG] [.modbus.internal.ModbusBinding] - config looked good, proceeding with slave-connections
2016-08-01 19:54:14.168 [DEBUG] [modbus.net.TCPMasterConnection] - connect()
2016-08-01 19:54:14.192 [DEBUG] [modbus.net.TCPMasterConnection] - connect()
2016-08-01 19:56:21.497 [DEBUG] [modbus.internal.ModbusTcpSlave] - ModbusSlave: Error connecting to master: Connection timed out
2016-08-01 19:56:21.498 [DEBUG] [modbus.net.TCPMasterConnection] - connect()
2016-08-01 19:58:28.856 [DEBUG] [modbus.internal.ModbusTcpSlave] - ModbusSlave: Error connecting to master: Connection timed out
2016-08-01 19:58:28.857 [DEBUG] [modbus.net.TCPMasterConnection] - connect()

and from linux console I see the folloing connections:
netstat | grep 237
tcp6 0 0 192.168.74.235:49395 192.168.74.237:502 ESTABLISHED
tcp6 0 1 192.168.74.235:49396 192.168.74.237:502 SYN_SENT

All Slaves are on one IP address (…74.237) with different IDs

0 Likes

(Ssalonen) #170

Hi

Unfortunately you cannot use the latest stable version to get the new behavior. You need to download the latest development version from here. Please remove the older version before installing the new one.

Please report how it works with the new version. I would recommend using pastebin.com for the logs, makes the thread more readable.

0 Likes

(Matheus Botura Pimenta) #171

Hi Sami,

I have two slaves (tcp) configured. If one of them is off it takes about 20 seconds to poll the one that is working.
Is there anyway to avoid this situation?

I´m running OH 1.8.3 with Modbus binding 1.9.0 on Windows 10.

OH log:
http://pastebin.com/nivQsdgW

0 Likes

(Matheus Botura Pimenta) #172

I don´t have enough knowledge, but I think “modbus.net.TCPMasterConnection” is taking to long to return an error connection…

http://pastebin.com/UDtKgcht

0 Likes

(Ssalonen) #173

Hi @Botura, can you please paste your modbus configuration please. Which of the slaves return connection timeout.

It seems that connection timeout is 3 seconds by default. Further wait might be introduced by the connection string parameters (see the wiki for details).

Best
Sami

0 Likes

(Matheus Botura Pimenta) #174

Here is my configuration, the slave that is returning timeout is 192.168.0.12.

The timeout seens to be 21 seconds… I´ve tried with the default parameters, ie, just setting host = “modbus:tcp.IOR12.connection=192.168.0.12” but the behavior was the same, except by the retries times.

As I could understand reading the wiki, there is no timeout parameter for modbus tcp slaves, the timeout is used only with serial slaves.

http://pastebin.com/rxZRwh9u

0 Likes

(Ssalonen) #175

Hi,

you are correct that there is no way to modify the timeout – in fact, there never has been :frowning: Nevertheless, I’m still a bit confused why the default 3s timeout is not respected and you are observing much larger timeout period.

Before jumping to any fixes etc, can you please do these steps

  1. Make sure you are using the modbus binding version linked above (just to be sure)
  2. Use simplified config with one modbus slave only, e.g. IOR11. Use 0 for reconnectAfterMillis, interConnectDelayMillis and 1 for connectMaxTries (this you have already). Keep the poll period of 500 (ms) and interTransactionDelayMillis of 60 (ms).
  3. enable debug logging, instructions are in the wiki
  4. Use pastebin to paste 1) configuration and 2) logs

Best,
Sami

0 Likes