Modbus Error: [Input/Output] Unable to decode request

[MrWaloo]

Hi,

In the Jeedom plugin for a modbus implementation, a user encounters a problem with his setup. He has a serial communication behind a gateway (serial/TCP) and when a request is send (all the previous log are irrelevant) the log looks like this and repeats itself .

[2024-11-23 22:40:54][DEBUG] : Adding transaction 1
[2024-11-23 22:40:54][DEBUG] : send: 0x0 0x1 0x0 0x0 0x0 0x6 0xa 0x4 0x0 0x12 0x0 0x1
[2024-11-23 22:40:55][DEBUG] : recv: 0x0 0x1 0x0 0x0 0x0 0x8 0xa 0x4 0x2 0x0 0xdc 0x1d 0x68 0x0 old_data:  addr=None
[2024-11-23 22:40:55][DEBUG] : Processing: 0x0 0x1 0x0 0x0 0x0 0x8 0xa 0x4 0x2 0x0 0xdc 0x1d 0x68 0x0
[2024-11-23 22:40:55][DEBUG] : decode PDU for 4
[2024-11-23 22:40:55][WARNING] : Unable to decode frame Modbus Error: [Input/Output] Invalid response b'\x02\x00\xdc\x1dh\x00' has byte count of 2
[2024-11-23 22:40:55][ERROR] : Fatal error: protocol.data_received() call failed.
protocol: <pymodbus.client.modbusclientprotocol.ModbusClientProtocol object at 0xffffa160f550>
transport: <_SelectorSocketTransport fd=8 read=polling write=<idle, bufsize=0>>
Traceback (most recent call last):
  File "/opt/pyenv/versions/3.11.10/lib/python3.11/asyncio/selector_events.py", line 1013, in _read_ready__data_received
    self._protocol.data_received(data)
  File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/transport/transport.py", line 297, in data_received
    self.datagram_received(data, None)
  File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/transport/transport.py", line 331, in datagram_received
    cut = self.callback_data(self.recv_buffer, addr=addr)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/client/modbusclientprotocol.py", line 71, in callback_data
    used_len, pdu = self.framer.processIncomingFrame(data)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/framer/base.py", line 77, in processIncomingFrame
    data_len, pdu = self._processIncomingFrame(data[used_len:])
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/framer/base.py", line 99, in _processIncomingFrame
    raise ModbusIOException("Unable to decode request")
pymodbus.exceptions.ModbusIOException: Modbus Error: [Input/Output] Unable to decode request
[2024-11-23 22:40:55][DEBUG] : Connection lost Chaudière due to Modbus Error: [Input/Output] Unable to decode request
[2024-11-23 22:40:55][DEBUG] : callback_disconnected called: Modbus Error: [Input/Output] Unable to decode request
[2024-11-23 22:40:55][DEBUG] : Wait Chaudière 100.0 ms before reconnecting.
[2024-11-23 22:40:55][DEBUG] : Chaudière: 'on_connect_callback' called with connected = False
[2024-11-23 22:40:55][DEBUG] : Connecting Chaudière
[2024-11-23 22:40:55][DEBUG] : Connected to Chaudière
[2024-11-23 22:40:55][DEBUG] : Chaudière: 'on_connect_callback' called with connected = True

"Chaudière" is the equipment name in Jeedom.

It appears that the gateway, and maybe the device too, sends too many bytes :
recv: 0x0 0x1 0x0 0x0 0x0 0x8 0xa 0x4 0x2 0x0 0xdc 0x1d 0x68 0x0

• 0x0 0x1 : Transaction Identifier (0x0001)
• 0x0 0x0 : Protocol Identifier (0x0000)
• 0x0 0x8 : Length : 8 bytes but 5 would have been enough because the by count indicates 2 bytes
• 0x0a : Unit Identifier : 10
• 0x04 : Function Code : 4, "Read Input Registers"
• 0x02 : Byte Count 2 <-- So only 2 bytes are relevent... !
• 0x00 0xdc : Data : 0xdc = 220
• 0x1d 0x68 0x00 : Why?

The error occurs before any decoding has been done according to the logs. In my program, in the decoding part, logs are written but these logs don't appear here.
So the error occurs when receiving the answer.

It is obvious that the device sends something wrong, this does not make any doubt, but would it be possible to avoid the error? Any idea?
Could it be RFC 2117 implementation?

[janiversen]

You do not write which version of pymodbus you use, nor whether is sync/async and which call you are using ?

The Send

send: 0x0 0x1 0x0 0x0 0x0 0x6 0xa 0x4 0x0 0x12 0x0 0x1

Looks like a tcp/socket connection.
Length is 6,
Slave is 10
Function code is read input registers
address is 12
count is 1

So that is all correct.
The device responds with:

0x0 0x1 0x0 0x0 0x0 0x8 0xa 0x4 0x2 0x0 0xdc 0x1d 0x68 0x0

Length is 8,
Slave is 10
Function code is read input registers
byte count is 2
BUT the there are 5 data bytes, which is WRONG, first of all data are a multiple of 2, and byte count must correspond with that.

This is the reason the packet cannot be decoded.

I have no idea, why it repeats itself, it is something outside pymodbus !! Pymodbus raises pymodbus.exceptions.ModbusIOException, and waits for a new request.

pymodbus do not accept illegal packets, the simple reason being that it is impossible. The simplest way is to use the trace_recv_packet method, which receives the byte stream and allows modifications. The new version of the trace methods are available on dev, and will be part of v3.8.0

[MrWaloo]

Of course, sorry...
pymodbus V3.7.4 / async

Thank you for your answer.

So in the received packet, there are 8 bytes of data (5 would have been enough for "standart" response) and after the 2 bytes data, there are 3 bytes more. The 3 more bytes should/could be ignored and only the byte count (in this example 2 bytes = 1 register) should be used.

Somehow, the response is well formed : the data length is 2 bytes (1 register). The response length is odd, but the count is ok.

He is still making some tests. He may deactivate the RFC 2117 feature, it may help.

[janiversen]

The response is NOT well formed, the byte count field is wrong ! But knowing the request, the MBAP length is wrong and the message contain too many bytes.

The RFC 2117 is normally with frameType.RTU and not with frameType.SOCKET.

[MrWaloo]

The gateway may introduce the error in the frame after a conversion (RTU->socket). It may have some option to disable such stuff. I will tell him to look in this direction.

Thank you again!