Modbus TCP sporadically assinging Response value to wrong sensor

[oeidfhlsk]

The problem

When polling Holding Registers, response values get Randomly assigned to another slave entity of the same Modbus Client.

The Sensor is always sending 0, the Peaks in the graph are exactly the numbers previously read from another slave.

Note the right sequence number but with wrong slave address and data in the Debug output:

send: 0x18 0xe0 0x0 0x0 0x0 0x6 **0x12** 0x3 0x1 0xe 0x0 0x2
recv:  0x18 0xe0 0x0 0x0 0x0 0x7 **0xd** 0x3 0x4 0x0 0x0 0x0 0x0

Data on the Network looks fine according to Wireshark. This Issue seems to sit deep in the parser before the debug output.
Even if such packets were to be sent from a TCP client, they should be discarded because of the mismatch in the slave address.

I tried to dig in the Modbus Parser Code, but Several layers with Asynchronous execution are a little overwhelming for me at the moment. But I am happily providing as much info as neccessary.

What version of Home Assistant Core has the issue?

core-2024.11.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Supervised

Integration causing the issue

Modbus

Link to integration documentation on our website

https://www.home-assistant.io/integrations/modbus/

Diagnostics information

No response

Example YAML snippet

modbus:
  - name: modbus_hub
    type: tcp
    host: 192.168.12.160
    port: 8888
    delay: 60
    timeout: 5
    sensors:
      - name: E_S5_P11_W_S1
        slave: 18
        address: 0x104
        input_type: holding
        unit_of_measurement: W
        device_class: power
        state_class: measurement
        scale: 1
        offset: 0
        precision: 0
        data_type: int32
        scan_interval: 60      
      - name: E_S5_P12_A_S2
        slave: 13
        address: 0x102
        input_type: holding
        unit_of_measurement: A
        device_class: current
        state_class: measurement
        scale: 0.001
        offset: 0
        precision: 3
        data_type: int32
        scan_interval: 60

Anything in the logs that might be useful for us?

2024-11-17 06:36:19.815 DEBUG (MainThread) [pymodbus.logging] Adding transaction 6368
2024-11-17 06:36:19.815 DEBUG (MainThread) [pymodbus.logging] Resetting frame - Current Frame in buffer - 
2024-11-17 06:36:19.815 DEBUG (MainThread) [pymodbus.logging] send: 0x18 0xe0 0x0 0x0 0x0 0x6 0x12 0x3 0x1 0xe 0x0 0x2
2024-11-17 06:36:19.931 DEBUG (MainThread) [pymodbus.logging] recv: 0x18 0xe0 0x0 0x0 0x0 0x7 0xd 0x3 0x4 0x0 0x0 0x0 0x0 old_data:  addr=None
2024-11-17 06:36:19.931 DEBUG (MainThread) [pymodbus.logging] Processing: 0x18 0xe0 0x0 0x0 0x0 0x7 0xd 0x3 0x4 0x0 0x0 0x0 0x0
2024-11-17 06:36:19.931 DEBUG (MainThread) [pymodbus.logging] Factory Response[ReadHoldingRegistersResponse': 3]
2024-11-17 06:36:19.931 DEBUG (MainThread) [pymodbus.logging] Getting transaction 6368
2024-11-17 06:36:19.931 DEBUG (MainThread) [pymodbus.logging] Very short frame (NO MBAP):  wait for more data

Additional information

Possibly related to several previous unsolved Modbus outlier issues such as
#119649
mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant#299
binsentsu/home-assistant-solaredge-modbus#126
#87876

[home-assistant]

modbus documentation
modbus source

[oeidfhlsk]

I was able to stop the peaks from showing up by messing with the timing and mode on the TCP Server device.
I still think there are issues with the Sequence numbering and Responses with slave address mismatch should get discarded and retried.

[bdraco]

If you can come up with a reliable way to reproduce the issue, I'd recommend opening an issue with pymodbus as it seems based on the report that the problem lies there.