Communication with Unvelvent VMC Domeo 450 with modbus

Add-ons Bindings
, ,
1

Hello,

I have a VMC from Unelvent with a modbus interface. On computer side, I use a FTDI USB modbus adpater.

I have a snipnet of python code working using pymodbus :slight_smile:

# cat test2.py 
#!/usr/bin/python

from pymodbus.client.sync import ModbusSerialClient
import pprint

pp = pprint.PrettyPrinter(indent=4)

client = ModbusSerialClient(method='rtu', port='/dev/ttyUSB0', baudrate=19200, bytesize=8, stopbits=1, parity='E')
client.connect()

result = client.read_input_registers(address=0x00, count=41, unit=0x01)
print "current airflow : ",result.registers[16]

# python test2.py 
current airflow :  4
#

Now, I would like to read this register from Openhab, here is the corresponding configuration in openhab.cfg :

modbus:poll=10000
modbus:serial.vmc.connection=/dev/ttyUSB0:19200:8:even:1:rtu
modbus:serial.vmc.id=1
modbus:serial.vmc.start=16
modbus:serial.vmc.length=1
modbus:serial.vmc.type=input
modbus:serial.vmc.valuetype=int16

Log :

11:44:33.840 [DEBUG] [o.b.m.internal.ModbusActivator:30   ] - Modbus binding has been started.
11:44:33.865 [DEBUG] [b.m.internal.ModbusSerialSlave:41   ] - overriding modbus port: null by: /dev/ttyUSB0but there is currently only one port supported
11:44:33.867 [DEBUG] [.modbus.internal.ModbusBinding:352  ] - config looked good, proceeding with slave-connections
11:44:33.867 [DEBUG] [b.m.internal.ModbusSerialSlave:117  ] - connection was null, going to create a new one
11:44:33.931 [INFO ] [.service.AbstractActiveService:169  ] - Modbus Polling Service has been started
11:44:33.964 [ERROR] [i.modbus.io.ModbusRTUTransport:166  ] - Last request: 01 04 00 10 00 01 30 0f
11:44:33.964 [ERROR] [i.modbus.io.ModbusRTUTransport:167  ] - failed to read: CRC Error in received frame: 0 bytes: 
11:44:33.967 [ERROR] [w.m.io.ModbusSerialTransaction:197  ] - execute try 1 error: I/O exception - failed to read
11:44:33.987 [ERROR] [i.modbus.io.ModbusRTUTransport:166  ] - Last request: 01 04 00 10 00 01 30 0f
11:44:33.988 [ERROR] [i.modbus.io.ModbusRTUTransport:167  ] - failed to read: CRC Error in received frame: 0 bytes: 
11:44:33.988 [ERROR] [w.m.io.ModbusSerialTransaction:197  ] - execute try 2 error: I/O exception - failed to read
11:44:33.995 [ERROR] [i.modbus.io.ModbusRTUTransport:166  ] - Last request: 01 04 00 10 00 01 30 0f
11:44:33.995 [ERROR] [i.modbus.io.ModbusRTUTransport:167  ] - failed to read: CRC Error in received frame: 0 bytes: 
11:44:33.996 [DEBUG] [.b.modbus.internal.ModbusSlave:342  ] - ModbusSlave:I/O exception - failed to read
11:44:34.001 [INFO ] [.b.modbus.internal.ModbusSlave:310  ] - ModbusSlave error getting responce from slave
...

I tried to read coils, discretes, holdings and input, I tried different type of parity (even if it works with EVEN with python lib), I tried differents typevalue without success.

If someone could help me, it would be very great !!!

Thanks

Denis

2

It is unusual to use any kind of parity used with serial RTU these days, I’d be reconfiguring to do away with that.

Most important to use an up to date Modbus binding, see

1 Like
3

Hello,

I just tried with 1.9.0 snaphsot :

4a670e02d33a466eaf6c8620d734df7b /opt/openhab/addons/org.openhab.binding.modbus-1.9.0-SNAPSHOT.jar

More debug but same error :

13:40:32.537 [ERROR] [i.modbus.io.ModbusRTUTransport:171  ] - Last request: 01 04 00 10 00 01 30 0f
13:40:32.537 [ERROR] [i.modbus.io.ModbusRTUTransport:172  ] - failed to read: CRC Error in received frame: 0 bytes: 
13:40:32.537 [ERROR] [w.m.io.ModbusSerialTransaction:199  ] - execute try 3/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@197be2ec (unit id 1 & transaction 4). Serial parameters: SerialParameters@e89c2d9[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
13:40:32.538 [ERROR] [w.m.io.ModbusSerialTransaction:204  ] - execute reached max tries 3, throwing last error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@197be2ec. Serial parameters: SerialParameters@e89c2d9[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
13:40:32.538 [ERROR] [.b.modbus.internal.ModbusSlave:505  ] - ModbusSlave (vmc): Error getting modbus data for request net.wimpi.modbus.msg.ReadInputRegistersRequest@197be2ec. Error: I/O exception - failed to read. Endpoint ModbusSerialSlaveEndpoint@54547df6[portName=/dev/ttyUSB0]. Connection: SerialConnection@53f9a2f3[portName=/dev/ttyUSB0,port=/dev/ttyUSB0]

What I understsood when I read your post is the binding doesn’t support parity at the moment ? Is right ?

Concerning the post you pointed me, it seems it is not the same error and setup as me.

Best regards

Denis Sacchet

4

Not at all, I just said parity isn’t used often.

That’s right, but it allowed you to find the updated binding.

I’m not sure how the CRC message can arise with no apparent response content (rather than a timeout). It does suggest the poll is getting out and provoking a response, eliminating permissions issues. Are you able to hookup say a laptop with another RS485 adaptor to monitor the line?

5

Hi

Could you please repeat that with verbose logging enabled?

See https://github.com/openhab/openhab/wiki/Modbus-Binding#enable-verbose-debug-logging

Best
Sami

6

Hello,

here is the trace :

15:31:40.273 [DEBUG] [o.b.m.internal.ModbusActivator:31   ] - Modbus binding has been started.
15:31:40.335 [DEBUG] [.modbus.internal.ModbusBinding:494  ] - modbusSlave 'vmc' instanciated
15:31:40.361 [DEBUG] [.modbus.internal.ModbusBinding:646  ] - Parsed the following slave->endpoint configurations: {vmc=EndpointPoolConfiguration@6b4ec3d5[passivateBorrowMinMillis=35,interConnectDelayMillis=0,connectMaxTries=3,reconnectAfterMillis=-1,connectTimeoutMillis=0]}. If the endpoint is same, connections are shared between the instances.
15:31:40.362 [DEBUG] [.modbus.internal.ModbusBinding:648  ] - Parsed the following pool configurations: {ModbusSerialSlaveEndpoint@26aedba0[portName=/dev/ttyUSB0]=EndpointPoolConfiguration@6b4ec3d5[passivateBorrowMinMillis=35,interConnectDelayMillis=0,connectMaxTries=3,reconnectAfterMillis=-1,connectTimeoutMillis=0]}
15:31:40.363 [DEBUG] [.modbus.internal.ModbusBinding:649  ] - config looked good
15:31:40.364 [INFO ] [.service.AbstractActiveService:169  ] - Modbus Polling Service has been started
15:31:40.407 [TRACE] [dbusSlaveConnectionFactoryImpl:86   ] - Created connection SerialConnection@256e99d0[portName=/dev/ttyUSB0,port=<null>] for endpoint ModbusSerialSlaveEndpoint@26aedba0[portName=/dev/ttyUSB0]
15:31:40.430 [TRACE] [pi.modbus.net.SerialConnection:128  ] - Got Port Identifier
15:31:40.441 [TRACE] [pi.modbus.net.SerialConnection:138  ] - Got Serial Port
15:31:40.449 [TRACE] [pi.modbus.net.SerialConnection:174  ] - i/o Streams prepared
15:31:40.450 [TRACE] [dbusSlaveConnectionFactoryImpl:182  ] - Validating endpoint ModbusSerialSlaveEndpoint@26aedba0[portName=/dev/ttyUSB0] connection SerialConnection@256e99d0[portName=/dev/ttyUSB0,port=/dev/ttyUSB0] -> true
15:31:40.452 [TRACE] [.b.modbus.internal.ModbusSlave:358  ] - ModbusSlave (vmc): borrowing connection (got SerialConnection@256e99d0[portName=/dev/ttyUSB0,port=/dev/ttyUSB0]) for endpoint ModbusSerialSlaveEndpoint@26aedba0[portName=/dev/ttyUSB0] took 70 ms
15:31:40.459 [DEBUG] [i.modbus.io.ModbusRTUTransport:77   ] - Sent: 01 04 00 10 00 01 30 0f
15:31:40.478 [TRACE] [i.modbus.io.ModbusRTUTransport:127  ] - Managed to read at least one byte
15:31:40.481 [DEBUG] [i.modbus.io.ModbusRTUTransport:145  ] - Response: 00 00
15:31:40.482 [ERROR] [i.modbus.io.ModbusRTUTransport:171  ] - Last request: 01 04 00 10 00 01 30 0f
15:31:40.485 [ERROR] [i.modbus.io.ModbusRTUTransport:172  ] - failed to read: CRC Error in received frame: 0 bytes:
15:31:40.486 [ERROR] [w.m.io.ModbusSerialTransaction:199  ] - execute try 1/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@1cb5a7de (unit id 1 & transaction 1). Serial parameters: SerialParameters@60320dce[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
15:31:40.491 [INFO ] [b.k.i.connection.KNXConnection:212  ] - Established connection to KNX bus on 192.168.1.26:3671 in mode TUNNEL.
15:31:40.522 [DEBUG] [i.modbus.io.ModbusRTUTransport:109  ] - Clear input: 00 00 00 b8 f3
15:31:40.527 [DEBUG] [i.modbus.io.ModbusRTUTransport:77   ] - Sent: 01 04 00 10 00 01 30 0f
15:31:40.546 [TRACE] [i.modbus.io.ModbusRTUTransport:127  ] - Managed to read at least one byte
15:31:40.546 [DEBUG] [i.modbus.io.ModbusRTUTransport:145  ] - Response: 00 00
15:31:40.547 [ERROR] [i.modbus.io.ModbusRTUTransport:171  ] - Last request: 01 04 00 10 00 01 30 0f
15:31:40.547 [ERROR] [i.modbus.io.ModbusRTUTransport:172  ] - failed to read: CRC Error in received frame: 0 bytes:
15:31:40.547 [ERROR] [w.m.io.ModbusSerialTransaction:199  ] - execute try 2/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@1cb5a7de (unit id 1 & transaction 1). Serial parameters: SerialParameters@60320dce[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
15:31:40.583 [DEBUG] [i.modbus.io.ModbusRTUTransport:109  ] - Clear input: 00 00 00 b8 f3
15:31:40.587 [DEBUG] [i.modbus.io.ModbusRTUTransport:77   ] - Sent: 01 04 00 10 00 01 30 0f
15:31:40.605 [TRACE] [i.modbus.io.ModbusRTUTransport:127  ] - Managed to read at least one byte
15:31:40.606 [DEBUG] [i.modbus.io.ModbusRTUTransport:145  ] - Response: 00 00
15:31:40.607 [ERROR] [i.modbus.io.ModbusRTUTransport:171  ] - Last request: 01 04 00 10 00 01 30 0f
15:31:40.607 [ERROR] [i.modbus.io.ModbusRTUTransport:172  ] - failed to read: CRC Error in received frame: 0 bytes:
15:31:40.607 [ERROR] [w.m.io.ModbusSerialTransaction:199  ] - execute try 3/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@1cb5a7de (unit id 1 & transaction 1). Serial parameters: SerialParameters@60320dce[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
15:31:40.608 [ERROR] [w.m.io.ModbusSerialTransaction:204  ] - execute reached max tries 3, throwing last error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadInputRegistersRequest@1cb5a7de. Serial parameters: SerialParameters@60320dce[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
15:31:40.608 [ERROR] [.b.modbus.internal.ModbusSlave:505  ] - ModbusSlave (vmc): Error getting modbus data for request net.wimpi.modbus.msg.ReadInputRegistersRequest@1cb5a7de. Error: I/O exception - failed to read. Endpoint ModbusSerialSlaveEndpoint@26aedba0[portName=/dev/ttyUSB0]. Connection: SerialConnection@256e99d0[portName=/dev/ttyUSB0,port=/dev/ttyUSB0]

Best regards

Denis Sacchet

7

Re,

I took a tcpdump capture with usbmon, I see traffic on the line, but it is difficult to interpret. If you want, I can upload this capture.

I validate the good working of the adapter with a python program. I can read and write data on the VMC, so I think the problem is more related to the configuration of OpenHAB.

In the meantime, I also looked to jamod library. There is the net.wimpi.modbus.cmd.SerialAITest class which can test communication with a slave, but for example, the parity is hardcoded, and unfortunately, my knowledge in java is very limited. My idea is to achieve to read and write data with the low level library like with my python script to eliminate a problem with the lib and concentrate on OpenHAB.

And this lastpoint, if you can provide me with a very simple java program using jamod library outside of OpenHAB, it should be a good starting point (and also a very good tool to debug modbus connection for other users).

Best regards

Denis Sacchet

8

Really great that you got it working with python!

It certainly gives hope that same hardware works with different software.

We have had really positive experiences with 1.9.0 with serial but obviously depending on hardware (?) it does work as well as it could.

I’ll come back to this hopefully this weekend.

Best
Sami

9

Hello,

just for information, I commit the code for python here

Best regards

Denis Sacchet

10

OK, so a bit of history here (perhaps useful for other developers as well)

java modbus libraries

As far as I can tell, openhab incorporates a forked version of jamod library. Jamod is not developed anymore but there forked versions of that, e.g. j2mod and j2mod by steveohara.

The second j2mod fork seems have gone through quite an overhaul, there are tests and the serial library has been switched:

The main driver for doing this work is to get away from the RxTxComm library and to use something that brings it’s own native implementations and is actively supported.

The weapon of choice is the jSerialComm library which is extremely well supported by Will Hedgecock and is actively developed.

The underlying communication is done using a serial library, nrjavaserial, in openhab, shared by all the bindings (as far as I understand bundled in org.openhab.io.transport). Note that nrjavaserial seems to use RXTXComm, something that was dropped in the second j2mod library.

For openhab, switching the serial library might not trivial as we want to support many architectures, and all the java serial libraries include a “native” precompiled libraries.

openhab modbus binding changes

The modbus binding (especially the serial side) received quite many changes during 1.9.0 development, in pull request #4226 from me. Improvements were enabled huge help from the community. I could not the serial functionality at all myself since I do not have a serial modbus slave available.

Eventually we managed to get constant serial throughput with @mbs38 , although that was with higher baud rates than you have.

In openhab fork, changes include

  • logging to use a logging library
  • error handling improvements, consistent retry (PR #4226)
  • new functionality to enable easier testing, for example, the server component are used in the integration tests (PR #4226)
  • some serial line parameters (PR #4226)

Critical part to get the RTU serial communication working was to introduce a silent period before sending a new request. This is due to the fact that in Modbus/RTU, silence splits up the sentences.

The testing revealed different serial behaviour windows, something that I considered a bug in the nrjavaserial library. On windows it seemed that the serial data read calls were not blocking, returning EOF immediately. On nix the serial library waited the timeout before returning EOF.

differences between java libraries

You can compare the differences between implementation of these different modbus java libraries:

  • jamod, uses setReceiveThreshold to do blocking read (not retries) link
  • openhab jamod, similar to original jamod, although we call setReceiveThreshold now even with one byte reads: link
  • original j2mod, has a retry to get all the bits, link
  • steveohara j2mod, jSerialComm seems to handle the blocking/non-blocking details, modbus library code is simple, link

summary

From the development with the serial devices (and the fact that we still have issues) I got the impression that one of the following is true

  • jamod part of the modbus binding uses the serial library (nrjavaserial / RXTXComm) in “non-robust” way, losing bits in the process
  • the serial library is buggy / unreliable / platform dependent

The fact that the modbus libraries have so different way of reading the data support my theory, I think. But who knows, it might be something simple really…

how to proceed

I like your idea of having a test program. I think it should be possible to have the test command line application as part of the binding.

During the coming weeks, I think I can provide you two different versions, one with the logic the openhab-jamod currently implements, and one with the original j2mod (read retry mechanism to get all the bits).

If these do not work, we might be facing a dead-end. The development of the binding is really unrewarding and slow without a test slave to work with…

In the meanwhile you might want to try out higher baud rate if you have the possibility to change the slave baud rate.

Best,
Sami

11

Hi Sami,

thanks for your feedback. Do you want a remote access to my system to have a slave for your test ? I can provide you with a SSH account on a box with a serial connection through a FTDI USB adapter to my VMC.

My Java skills are really limited, else it would be a pleasure to give a hand.

Regards

Denis