Cannot use Modbus-RTU with rs485 device

Development Add-ons
,
1

Hello,

I am trying to access a Modbus device with RS485 interface, but I cannot make it work. I am using both official Modbus binding, and my own one. I am using OpenHAB 2.5.0-M3 build.

I have seen many similar issues here, like ARM board and MODBUS rs485 converter, but I have not seen any solution (but using a RTU-TCP proxy).

Here is the error:

2019-10-09 19:12:51.605 [ERROR] [impi.modbus.io.ModbusSerialTransport] - Transmit Echo not received
2019-10-09 19:12:51.657 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute try 1/1 error: I/O failed to write. Request: net.wimpi.modbus.msg.ReadMultipleRegistersRequest@53d9fc5a (unit id 1 & transaction 1). Serial parameters: SerialParameters@3a7d9ca3[portName=/dev/ttyS1,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=none,encoding=rtu,echo=true,receiveTimeoutMillis=1500]

I am sure that the system is able to reach the device, as this piece of code works fine (uses libmodbus):

ctx = modbus_new_rtu(dev, B19200, 'N', 8, 1);
modbus_set_slave(ctx, slave_id);
modbus_connect(ctx);
sz = modbus_read_registers(ctx, 0x5000, HOLDING_SZ, (uint16_t *) buf);

Any help greatly appreciated!

Hardware: Axon M205 - https://www.unipi.technology/unipi-axon-m205-p180?categoryId=20
System: Debian 9.11
OpenHAB: 2.5.0-M3

Thanks!
Bubuche

2

I have found a first issue:

In the bridge-serial.xml file, in org.openhab.binding.modbus bundle, the flowControlIn and flowControlOut parameters are not correct:

<!-- values here match SerialPort.FLOWCONTROL_* constants -->
<options>
  <option value="none">None</option>
  <option value="xon/xoff in">RTS/CTS</option>
  <option value="rts/cts in">XON/XOFF</option>
</options>

Some errors disappear if I pick “XON/XOFF” to get “rts/cts in”.
I’ll made more test later.

3

Well spotted. You should raise an issue on github for that.
Many modbus users use xxx.things file method to configure, it won’t crop up there and may have been overlooked so far. Many serial users select flow control “none”, so again it wouldn’t matter.

Your original message looks mor to do with echo parameter.

4

The error related to the echo parameter was one of my X attempts to make it work.

I finally performed a system upgrade yesterday, with packages/drivers from my hardware vendor. Since then everything seems to work as expected (none of the control flow parameter ever worked before)!

Sorry for the inconvenience, and thanks for the github issue!

1 Like