Lost Modbus Sensor after upgrade to Core 2024.3

phoinixgrr commented 8 months ago

The problem

Using Modbus, to control my Lg Therma Heat pump. After the update to Core 2024.3. I Seem to be experiencing some issues with reading specifically the following sensor:

      - name: "lg_therma_outlet_temp"
        unique_id: "lg_therma_outlet_temp"
        scan_interval: 10
        address: 3
        slave: 1
        input_type: input
        scale: 0.1
        device_class: temperature
        unit_of_measurement: "°C"
        precision: 1

Here is the whole configuration

 modbus:
  - name: "Heat Pump - LG Therma V"
    delay: 1
    timeout: 14
    message_wait_milliseconds: 200
    host: pump.home
    port: 8899
    type: tcp
    binary_sensors:
      - name: "lg_therma_heating_mode"
        address: 0
        scan_interval: 60
        slave: 1
        input_type: coil
      - name: "lg_therma_flow_too_low"
        address: 0
        scan_interval: 60
        slave: 1
        input_type: discrete_input
      - name: "lg_therma_pump_status"
        address: 1
        scan_interval: 10
        slave: 1
        input_type: discrete_input
        device_class: running
      - name: "lg_therma_compressor_status"
        address: 3
        scan_interval: 10
        slave: 1
        input_type: discrete_input
        device_class: running
      - name: "lg_therma_defrost_status"
        address: 4
        scan_interval: 60
        slave: 1
        input_type: discrete_input
        device_class: running
      - name: "lg_therma_dhw_status"
        address: 5
        scan_interval: 60
        slave: 1
        input_type: discrete_input
        device_class: running
      - name: "lg_therma_disinfect_status"
        address: 6
        scan_interval: 60
        slave: 1
        input_type: discrete_input
        device_class: running
      - name: "lg_therma_silent_status"
        address: 7
        scan_interval: 10
        slave: 1
        input_type: discrete_input
      - name: "lg_therma_error_status"
        address: 13
        scan_interval: 60
        slave: 1
        input_type: discrete_input
        device_class: problem
    sensors:
      - name: "lg_therma_outlet_temp"
        unique_id: "lg_therma_outlet_temp"
        scan_interval: 10
        address: 3
        slave: 1
        input_type: input
        scale: 0.1
        device_class: temperature
        unit_of_measurement: "°C"
        precision: 1
      - name: "lg_therma_inlet_temp"
        unique_id: "lg_therma_inlet_temp"
        scan_interval: 10
        address: 2
        slave: 1
        input_type: input
        scale: 0.1
        device_class: temperature
        unit_of_measurement: "°C"
        precision: 1
      - name: "lg_therma_flow_rate"
        unique_id: "lg_therma_flow_rate"
        scan_interval: 10
        address: 8
        slave: 1
        input_type: input
        scale: 0.1
        unit_of_measurement: "l/min"
        precision: 1
        zero_suppress: 5
      - name: "lg_therma_outdoor_air_temp"
        unique_id: "lg_therma_outdoor_air_temp"
        scan_interval: 10
        address: 12
        slave: 1
        input_type: input
        scale: 0.1
        device_class: temperature
        unit_of_measurement: "°C"
        precision: 1
      - name: "lg_therma_compressor_rpm"
        unique_id: "lg_therma_compressor_rpm"
        scale: 60
        precision: 0.1
        scan_interval: 10
        address: 24
        slave: 1
        unit_of_measurement: rpm
        input_type: input
      - name: "lg_therma_evaporator_pressure" # Dampfdruck Kondensator
        unique_id: "lg_therma_evaporator_pressure"
        address: 22
        scan_interval: 60
        unit_of_measurement: Bar
        slave: 1
        input_type: input
      - name: "lg_therma_compressor_pressure" # Dampfdruck Verdampfer
        unique_id: "lg_therma_compressor_pressure"
        address: 23
        scan_interval: 60
        unit_of_measurement: Bar
        slave: 1
        input_type: input

    switches:
      - name: "lg_therma_power"
        slave: 1
        address: 0
        write_type: coil
        command_on: 1
        command_off: 0
        verify:
          input_type: coil
          address: 0
          state_on: 1
          state_off: 0
      - name: "lg_therma_silent_mode"
        slave: 1
        address: 2
        write_type: coil
        command_on: 1
        command_off: 0
        verify:
          input_type: coil
          address: 2
          state_on: 1
          state_off: 0
    climates:
      - name: "lg_therma_climate_control"
        address: 3
        slave: 1
        input_type: input
        max_temp: 50
        min_temp: 15
        offset: 0
        precision: 1
        scale: 0.1
        target_temp_register: 2
        temp_step: 1
        temperature_unit: C
          #hvac_onoff_register: 0
        write_registers: true
        hvac_mode_register:
          address: 0
          values:
            state_cool: 0
            state_heat: 4

The entity lg_therma_outlet_temp is reported as Unavailable. No other changes introduced except upgrading to Core 2024.3.

What version of Home Assistant Core has the issue?

core-2024.3.0

What was the last working version of Home Assistant Core?

core-2024.2.5

What type of installation are you running?

Home Assistant OS

Integration causing the issue

modbus

Link to integration documentation on our website

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

Diagnostics information

2024-03-07 14:57:35.015 DEBUG (SyncWorker_9) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:35.016 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:35.104 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:35.104 DEBUG (SyncWorker_9) [pymodbus.logging] RECV: 0x2 0x8b 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:57:35.105 DEBUG (SyncWorker_9) [pymodbus.logging] Processing: 0x2 0x8b 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:57:35.105 DEBUG (SyncWorker_9) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:57:35.105 DEBUG (SyncWorker_9) [pymodbus.logging] Adding transaction 651
2024-03-07 14:57:35.106 DEBUG (SyncWorker_9) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:35.106 DEBUG (SyncWorker_9) [pymodbus.logging] Getting transaction 651
2024-03-07 14:57:35.106 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:35.311 DEBUG (SyncWorker_11) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:35.311 DEBUG (SyncWorker_11) [pymodbus.logging] Running transaction 652
2024-03-07 14:57:35.311 DEBUG (SyncWorker_11) [pymodbus.logging] SEND: 0x2 0x8c 0x0 0x0 0x0 0x6 0x1 0x4 0x0 0x2 0x0 0x1
2024-03-07 14:57:35.312 DEBUG (SyncWorker_11) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:35.312 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:35.385 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:35.385 DEBUG (SyncWorker_11) [pymodbus.logging] RECV: 0x2 0x8c 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xbf
2024-03-07 14:57:35.385 DEBUG (SyncWorker_11) [pymodbus.logging] Processing: 0x2 0x8c 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xbf
2024-03-07 14:57:35.386 DEBUG (SyncWorker_11) [pymodbus.logging] Factory Response[ReadInputRegistersResponse': 4]
2024-03-07 14:57:35.386 DEBUG (SyncWorker_11) [pymodbus.logging] Adding transaction 652
2024-03-07 14:57:35.386 DEBUG (SyncWorker_11) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:35.386 DEBUG (SyncWorker_11) [pymodbus.logging] Getting transaction 652
2024-03-07 14:57:35.387 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:35.590 DEBUG (SyncWorker_16) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:35.590 DEBUG (SyncWorker_16) [pymodbus.logging] Running transaction 653
2024-03-07 14:57:35.591 DEBUG (SyncWorker_16) [pymodbus.logging] SEND: 0x2 0x8d 0x0 0x0 0x0 0x6 0x1 0x4 0x0 0x8 0x0 0x1
2024-03-07 14:57:35.591 DEBUG (SyncWorker_16) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:35.592 DEBUG (SyncWorker_16) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:35.664 DEBUG (SyncWorker_16) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:35.665 DEBUG (SyncWorker_16) [pymodbus.logging] RECV: 0x2 0x8d 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0x32
2024-03-07 14:57:35.666 DEBUG (SyncWorker_16) [pymodbus.logging] Processing: 0x2 0x8d 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0x32
2024-03-07 14:57:35.667 DEBUG (SyncWorker_16) [pymodbus.logging] Factory Response[ReadInputRegistersResponse': 4]
2024-03-07 14:57:35.667 DEBUG (SyncWorker_16) [pymodbus.logging] Adding transaction 653
2024-03-07 14:57:35.667 DEBUG (SyncWorker_16) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:35.667 DEBUG (SyncWorker_16) [pymodbus.logging] Getting transaction 653
2024-03-07 14:57:35.668 DEBUG (SyncWorker_16) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:35.889 DEBUG (SyncWorker_1) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:35.889 DEBUG (SyncWorker_1) [pymodbus.logging] Running transaction 654
2024-03-07 14:57:35.890 DEBUG (SyncWorker_1) [pymodbus.logging] SEND: 0x2 0x8e 0x0 0x0 0x0 0x6 0x1 0x4 0x0 0xc 0x0 0x1
2024-03-07 14:57:35.890 DEBUG (SyncWorker_1) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:35.890 DEBUG (SyncWorker_1) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:35.964 DEBUG (SyncWorker_1) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:35.964 DEBUG (SyncWorker_1) [pymodbus.logging] RECV: 0x2 0x8e 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xb9
2024-03-07 14:57:35.965 DEBUG (SyncWorker_1) [pymodbus.logging] Processing: 0x2 0x8e 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xb9
2024-03-07 14:57:35.965 DEBUG (SyncWorker_1) [pymodbus.logging] Factory Response[ReadInputRegistersResponse': 4]
2024-03-07 14:57:35.965 DEBUG (SyncWorker_1) [pymodbus.logging] Adding transaction 654
2024-03-07 14:57:35.966 DEBUG (SyncWorker_1) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:35.966 DEBUG (SyncWorker_1) [pymodbus.logging] Getting transaction 654
2024-03-07 14:57:35.966 DEBUG (SyncWorker_1) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:36.169 DEBUG (SyncWorker_20) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:36.170 DEBUG (SyncWorker_20) [pymodbus.logging] Running transaction 655
2024-03-07 14:57:36.170 DEBUG (SyncWorker_20) [pymodbus.logging] SEND: 0x2 0x8f 0x0 0x0 0x0 0x6 0x1 0x4 0x0 0x18 0x0 0x1
2024-03-07 14:57:36.170 DEBUG (SyncWorker_20) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:36.171 DEBUG (SyncWorker_20) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:36.244 DEBUG (SyncWorker_20) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:36.244 DEBUG (SyncWorker_20) [pymodbus.logging] RECV: 0x2 0x8f 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0x0
2024-03-07 14:57:36.245 DEBUG (SyncWorker_20) [pymodbus.logging] Processing: 0x2 0x8f 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0x0
2024-03-07 14:57:36.245 DEBUG (SyncWorker_20) [pymodbus.logging] Factory Response[ReadInputRegistersResponse': 4]
2024-03-07 14:57:36.245 DEBUG (SyncWorker_20) [pymodbus.logging] Adding transaction 655
2024-03-07 14:57:36.246 DEBUG (SyncWorker_20) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:36.246 DEBUG (SyncWorker_20) [pymodbus.logging] Getting transaction 655
2024-03-07 14:57:36.246 DEBUG (SyncWorker_20) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:36.452 DEBUG (SyncWorker_7) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:36.452 DEBUG (SyncWorker_7) [pymodbus.logging] Running transaction 656
2024-03-07 14:57:36.452 DEBUG (SyncWorker_7) [pymodbus.logging] SEND: 0x2 0x90 0x0 0x0 0x0 0x6 0x1 0x4 0x0 0x3 0x0 0x1
2024-03-07 14:57:36.453 DEBUG (SyncWorker_7) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:36.453 DEBUG (SyncWorker_7) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:36.534 DEBUG (SyncWorker_7) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:36.535 DEBUG (SyncWorker_7) [pymodbus.logging] RECV: 0x2 0x90 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xbf
2024-03-07 14:57:36.535 DEBUG (SyncWorker_7) [pymodbus.logging] Processing: 0x2 0x90 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xbf
2024-03-07 14:57:36.536 DEBUG (SyncWorker_7) [pymodbus.logging] Factory Response[ReadInputRegistersResponse': 4]
2024-03-07 14:57:36.536 DEBUG (SyncWorker_7) [pymodbus.logging] Adding transaction 656
2024-03-07 14:57:36.536 DEBUG (SyncWorker_7) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:36.537 DEBUG (SyncWorker_7) [pymodbus.logging] Getting transaction 656
2024-03-07 14:57:36.537 DEBUG (SyncWorker_7) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:36.741 DEBUG (SyncWorker_5) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:36.742 DEBUG (SyncWorker_5) [pymodbus.logging] Running transaction 657
2024-03-07 14:57:36.742 DEBUG (SyncWorker_5) [pymodbus.logging] SEND: 0x2 0x91 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x0 0x0 0x1
2024-03-07 14:57:36.742 DEBUG (SyncWorker_5) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:36.743 DEBUG (SyncWorker_5) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:36.814 DEBUG (SyncWorker_5) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:36.815 DEBUG (SyncWorker_5) [pymodbus.logging] RECV: 0x2 0x91 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x4
2024-03-07 14:57:36.815 DEBUG (SyncWorker_5) [pymodbus.logging] Processing: 0x2 0x91 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x4
2024-03-07 14:57:36.815 DEBUG (SyncWorker_5) [pymodbus.logging] Factory Response[ReadHoldingRegistersResponse': 3]
2024-03-07 14:57:36.816 DEBUG (SyncWorker_5) [pymodbus.logging] Adding transaction 657
2024-03-07 14:57:36.816 DEBUG (SyncWorker_5) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:36.816 DEBUG (SyncWorker_5) [pymodbus.logging] Getting transaction 657
2024-03-07 14:57:36.816 DEBUG (SyncWorker_5) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:43.737 DEBUG (SyncWorker_3) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:43.737 DEBUG (SyncWorker_3) [pymodbus.logging] Running transaction 658
2024-03-07 14:57:43.737 DEBUG (SyncWorker_3) [pymodbus.logging] SEND: 0x2 0x92 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x1 0x0 0x1
2024-03-07 14:57:43.738 DEBUG (SyncWorker_3) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:43.738 DEBUG (SyncWorker_3) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:43.814 DEBUG (SyncWorker_3) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:43.815 DEBUG (SyncWorker_3) [pymodbus.logging] RECV: 0x2 0x92 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:57:43.815 DEBUG (SyncWorker_3) [pymodbus.logging] Processing: 0x2 0x92 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:57:43.816 DEBUG (SyncWorker_3) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:57:43.816 DEBUG (SyncWorker_3) [pymodbus.logging] Adding transaction 658
2024-03-07 14:57:43.816 DEBUG (SyncWorker_3) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:43.816 DEBUG (SyncWorker_3) [pymodbus.logging] Getting transaction 658
2024-03-07 14:57:43.816 DEBUG (SyncWorker_3) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:44.023 DEBUG (SyncWorker_6) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:44.023 DEBUG (SyncWorker_6) [pymodbus.logging] Running transaction 659
2024-03-07 14:57:44.024 DEBUG (SyncWorker_6) [pymodbus.logging] SEND: 0x2 0x93 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x3 0x0 0x1
2024-03-07 14:57:44.024 DEBUG (SyncWorker_6) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:44.024 DEBUG (SyncWorker_6) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:44.094 DEBUG (SyncWorker_6) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:44.095 DEBUG (SyncWorker_6) [pymodbus.logging] RECV: 0x2 0x93 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:57:44.095 DEBUG (SyncWorker_6) [pymodbus.logging] Processing: 0x2 0x93 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:57:44.095 DEBUG (SyncWorker_6) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:57:44.095 DEBUG (SyncWorker_6) [pymodbus.logging] Adding transaction 659
2024-03-07 14:57:44.096 DEBUG (SyncWorker_6) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:44.096 DEBUG (SyncWorker_6) [pymodbus.logging] Getting transaction 659
2024-03-07 14:57:44.096 DEBUG (SyncWorker_6) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:44.300 DEBUG (SyncWorker_17) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:44.301 DEBUG (SyncWorker_17) [pymodbus.logging] Running transaction 660
2024-03-07 14:57:44.301 DEBUG (SyncWorker_17) [pymodbus.logging] SEND: 0x2 0x94 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x7 0x0 0x1
2024-03-07 14:57:44.301 DEBUG (SyncWorker_17) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:44.302 DEBUG (SyncWorker_17) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:44.374 DEBUG (SyncWorker_17) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:44.375 DEBUG (SyncWorker_17) [pymodbus.logging] RECV: 0x2 0x94 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:57:44.375 DEBUG (SyncWorker_17) [pymodbus.logging] Processing: 0x2 0x94 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:57:44.375 DEBUG (SyncWorker_17) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:57:44.376 DEBUG (SyncWorker_17) [pymodbus.logging] Adding transaction 660
2024-03-07 14:57:44.376 DEBUG (SyncWorker_17) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:44.376 DEBUG (SyncWorker_17) [pymodbus.logging] Getting transaction 660
2024-03-07 14:57:44.376 DEBUG (SyncWorker_17) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:44.582 DEBUG (SyncWorker_2) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:44.583 DEBUG (SyncWorker_2) [pymodbus.logging] Running transaction 661
2024-03-07 14:57:44.583 DEBUG (SyncWorker_2) [pymodbus.logging] SEND: 0x2 0x95 0x0 0x0 0x0 0x6 0x1 0x4 0x0 0x2 0x0 0x1
2024-03-07 14:57:44.583 DEBUG (SyncWorker_2) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:44.584 DEBUG (SyncWorker_2) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:44.654 DEBUG (SyncWorker_2) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:44.655 DEBUG (SyncWorker_2) [pymodbus.logging] RECV: 0x2 0x95 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xbf
2024-03-07 14:57:44.655 DEBUG (SyncWorker_2) [pymodbus.logging] Processing: 0x2 0x95 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xbf
2024-03-07 14:57:44.655 DEBUG (SyncWorker_2) [pymodbus.logging] Factory Response[ReadInputRegistersResponse': 4]
2024-03-07 14:57:44.656 DEBUG (SyncWorker_2) [pymodbus.logging] Adding transaction 661
2024-03-07 14:57:44.656 DEBUG (SyncWorker_2) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:44.656 DEBUG (SyncWorker_2) [pymodbus.logging] Getting transaction 661
2024-03-07 14:57:44.656 DEBUG (SyncWorker_2) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:44.862 DEBUG (SyncWorker_9) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:44.862 DEBUG (SyncWorker_9) [pymodbus.logging] Running transaction 662
2024-03-07 14:57:44.863 DEBUG (SyncWorker_9) [pymodbus.logging] SEND: 0x2 0x96 0x0 0x0 0x0 0x6 0x1 0x4 0x0 0x8 0x0 0x1
2024-03-07 14:57:44.863 DEBUG (SyncWorker_9) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:44.863 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:44.934 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:44.935 DEBUG (SyncWorker_9) [pymodbus.logging] RECV: 0x2 0x96 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0x32
2024-03-07 14:57:44.935 DEBUG (SyncWorker_9) [pymodbus.logging] Processing: 0x2 0x96 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0x32
2024-03-07 14:57:44.935 DEBUG (SyncWorker_9) [pymodbus.logging] Factory Response[ReadInputRegistersResponse': 4]
2024-03-07 14:57:44.935 DEBUG (SyncWorker_9) [pymodbus.logging] Adding transaction 662
2024-03-07 14:57:44.936 DEBUG (SyncWorker_9) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:44.936 DEBUG (SyncWorker_9) [pymodbus.logging] Getting transaction 662
2024-03-07 14:57:44.936 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:45.140 DEBUG (SyncWorker_11) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:45.141 DEBUG (SyncWorker_11) [pymodbus.logging] Running transaction 663
2024-03-07 14:57:45.141 DEBUG (SyncWorker_11) [pymodbus.logging] SEND: 0x2 0x97 0x0 0x0 0x0 0x6 0x1 0x4 0x0 0xc 0x0 0x1
2024-03-07 14:57:45.142 DEBUG (SyncWorker_11) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:45.144 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:45.224 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:45.225 DEBUG (SyncWorker_11) [pymodbus.logging] RECV: 0x2 0x97 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xb9
2024-03-07 14:57:45.226 DEBUG (SyncWorker_11) [pymodbus.logging] Processing: 0x2 0x97 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0xb9
2024-03-07 14:57:45.226 DEBUG (SyncWorker_11) [pymodbus.logging] Factory Response[ReadInputRegistersResponse': 4]
2024-03-07 14:57:45.226 DEBUG (SyncWorker_11) [pymodbus.logging] Adding transaction 663
2024-03-07 14:57:45.226 DEBUG (SyncWorker_11) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:45.227 DEBUG (SyncWorker_11) [pymodbus.logging] Getting transaction 663
2024-03-07 14:57:45.228 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:57:45.434 DEBUG (SyncWorker_16) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:57:45.435 DEBUG (SyncWorker_16) [pymodbus.logging] Running transaction 664
2024-03-07 14:57:45.435 DEBUG (SyncWorker_16) [pymodbus.logging] SEND: 0x2 0x98 0x0 0x0 0x0 0x6 0x1 0x4 0x0 0x18 0x0 0x1
2024-03-07 14:57:45.436 DEBUG (SyncWorker_16) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:57:45.438 DEBUG (SyncWorker_16) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:57:45.526 DEBUG (SyncWorker_16) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:57:45.526 DEBUG (SyncWorker_16) [pymodbus.logging] RECV: 0x2 0x98 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0x0
2024-03-07 14:57:45.527 DEBUG (SyncWorker_16) [pymodbus.logging] Processing: 0x2 0x98 0x0 0x0 0x0 0x5 0x1 0x4 0x2 0x0 0x0
2024-03-07 14:57:45.527 DEBUG (SyncWorker_16) [pymodbus.logging] Factory Response[ReadInputRegistersResponse': 4]
2024-03-07 14:57:45.527 DEBUG (SyncWorker_16) [pymodbus.logging] Adding transaction 664
2024-03-07 14:57:45.528 DEBUG (SyncWorker_16) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:57:45.528 DEBUG (SyncWorker_16) [pymodbus.logging] Getting transaction 664
2024-03-07 14:57:45.528 DEBUG (SyncWorker_16) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 8 months ago

Hey there @janiversen, mind taking a look at this issue as it has been labeled with an integration (modbus) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `modbus` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign modbus` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

modbus documentation modbus source _{^{(message by IssueLinks)}}

janiversen commented 8 months ago

The debug is fine, but you have cut away the interesting part in the beginning, we need to see the change from OK messages to faulty ones....

janiversen commented 8 months ago

Please make a configuration only containing the faulty sensor and one good, make a debug log of that, and lets see the whole log.

phoinixgrr commented 8 months ago

The debug is fine, but you have cut away the interesting part in the beginning, we need to see the change from OK messages to faulty ones....

Thanks for the quick response @janiversen

I am currently performing a downgrade to to 2024.2.5 to confirm the assumption that the upgrade to 2024.3.0 is the cause of it.

core-ssh config]$ ha core update --version 2024.2.5
⣟ Processing...

Will update this accordingly with my findings. Also with the requested logs.

phoinixgrr commented 8 months ago

Confirmed. Downgrading to 2024.2.5 fixes the issue.

Log from the 2024.3.0

2024-03-07 14:48:05.750 DEBUG (SyncWorker_12) [pymodbus.logging] Connection to Modbus server established. Socket ('192.168.101.12', 56172)
2024-03-07 14:48:10.037 DEBUG (SyncWorker_8) [pymodbus.logging] Current transaction state - IDLE
2024-03-07 14:48:10.037 DEBUG (SyncWorker_8) [pymodbus.logging] Running transaction 1
2024-03-07 14:48:10.038 DEBUG (SyncWorker_8) [pymodbus.logging] SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x1 0x0 0x0 0x0 0x1
2024-03-07 14:48:10.038 DEBUG (SyncWorker_8) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:10.042 DEBUG (SyncWorker_8) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:10.120 DEBUG (SyncWorker_8) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:10.121 DEBUG (SyncWorker_8) [pymodbus.logging] RECV: 0x0 0x1 0x0 0x0 0x0 0x4 0x1 0x1 0x1 0x0
2024-03-07 14:48:10.121 DEBUG (SyncWorker_8) [pymodbus.logging] Processing: 0x0 0x1 0x0 0x0 0x0 0x4 0x1 0x1 0x1 0x0
2024-03-07 14:48:10.121 DEBUG (SyncWorker_8) [pymodbus.logging] Factory Response[ReadCoilsResponse': 1]
2024-03-07 14:48:10.122 DEBUG (SyncWorker_8) [pymodbus.logging] Adding transaction 1
2024-03-07 14:48:10.122 DEBUG (SyncWorker_8) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:10.122 DEBUG (SyncWorker_8) [pymodbus.logging] Getting transaction 1
2024-03-07 14:48:10.122 DEBUG (SyncWorker_8) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:11.524 DEBUG (SyncWorker_3) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:11.524 DEBUG (SyncWorker_3) [pymodbus.logging] Running transaction 2
2024-03-07 14:48:11.524 DEBUG (SyncWorker_3) [pymodbus.logging] SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x0 0x0 0x1
2024-03-07 14:48:11.525 DEBUG (SyncWorker_3) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:11.529 DEBUG (SyncWorker_3) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:11.621 DEBUG (SyncWorker_3) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:11.621 DEBUG (SyncWorker_3) [pymodbus.logging] RECV: 0x0 0x2 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:11.622 DEBUG (SyncWorker_3) [pymodbus.logging] Processing: 0x0 0x2 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:11.622 DEBUG (SyncWorker_3) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:48:11.622 DEBUG (SyncWorker_3) [pymodbus.logging] Adding transaction 2
2024-03-07 14:48:11.623 DEBUG (SyncWorker_3) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:11.623 DEBUG (SyncWorker_3) [pymodbus.logging] Getting transaction 2
2024-03-07 14:48:11.623 DEBUG (SyncWorker_3) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:33.562 DEBUG (SyncWorker_5) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:33.563 DEBUG (SyncWorker_5) [pymodbus.logging] Running transaction 3
2024-03-07 14:48:33.563 DEBUG (SyncWorker_5) [pymodbus.logging] SEND: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x1 0x0 0x1
2024-03-07 14:48:33.563 DEBUG (SyncWorker_5) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:33.566 DEBUG (SyncWorker_5) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:33.677 DEBUG (SyncWorker_5) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:33.678 DEBUG (SyncWorker_5) [pymodbus.logging] RECV: 0x0 0x3 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:33.678 DEBUG (SyncWorker_5) [pymodbus.logging] Processing: 0x0 0x3 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Adding transaction 3
2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Getting transaction 3
2024-03-07 14:48:33.680 DEBUG (SyncWorker_5) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:35.881 DEBUG (SyncWorker_15) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:35.882 DEBUG (SyncWorker_15) [pymodbus.logging] Running transaction 4
2024-03-07 14:48:35.882 DEBUG (SyncWorker_15) [pymodbus.logging] SEND: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x3 0x0 0x1
2024-03-07 14:48:35.883 DEBUG (SyncWorker_15) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:35.886 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:35.955 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:35.956 DEBUG (SyncWorker_15) [pymodbus.logging] RECV: 0x0 0x4 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:35.956 DEBUG (SyncWorker_15) [pymodbus.logging] Processing: 0x0 0x4 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:35.956 DEBUG (SyncWorker_15) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:48:35.957 DEBUG (SyncWorker_15) [pymodbus.logging] Adding transaction 4
2024-03-07 14:48:35.957 DEBUG (SyncWorker_15) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:35.957 DEBUG (SyncWorker_15) [pymodbus.logging] Getting transaction 4
2024-03-07 14:48:35.958 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:36.197 DEBUG (SyncWorker_1) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:36.197 DEBUG (SyncWorker_1) [pymodbus.logging] Running transaction 5
2024-03-07 14:48:36.198 DEBUG (SyncWorker_1) [pymodbus.logging] SEND: 0x0 0x5 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x4 0x0 0x1
2024-03-07 14:48:36.198 DEBUG (SyncWorker_1) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:36.202 DEBUG (SyncWorker_1) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:36.273 DEBUG (SyncWorker_1) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:36.273 DEBUG (SyncWorker_1) [pymodbus.logging] RECV: 0x0 0x5 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:36.273 DEBUG (SyncWorker_1) [pymodbus.logging] Processing: 0x0 0x5 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:36.274 DEBUG (SyncWorker_1) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:48:36.274 DEBUG (SyncWorker_1) [pymodbus.logging] Adding transaction 5
2024-03-07 14:48:36.274 DEBUG (SyncWorker_1) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:36.274 DEBUG (SyncWorker_1) [pymodbus.logging] Getting transaction 5
2024-03-07 14:48:36.275 DEBUG (SyncWorker_1) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:36.479 DEBUG (SyncWorker_6) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:36.479 DEBUG (SyncWorker_6) [pymodbus.logging] Running transaction 6
2024-03-07 14:48:36.480 DEBUG (SyncWorker_6) [pymodbus.logging] SEND: 0x0 0x6 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x5 0x0 0x1
2024-03-07 14:48:36.480 DEBUG (SyncWorker_6) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:36.483 DEBUG (SyncWorker_6) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:36.552 DEBUG (SyncWorker_6) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:36.553 DEBUG (SyncWorker_6) [pymodbus.logging] RECV: 0x0 0x6 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:36.553 DEBUG (SyncWorker_6) [pymodbus.logging] Processing: 0x0 0x6 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:36.554 DEBUG (SyncWorker_6) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]

Log from the downgraded "healthy" 2024.2.5 :

2024-03-07 15:09:47.171 DEBUG (SyncWorker_0) [pymodbus.logging] Connection to Modbus server established. Socket ('192.168.101.12', 45324)
2024-03-07 15:10:01.175 DEBUG (SyncWorker_15) [pymodbus.logging] Current transaction state - IDLE
2024-03-07 15:10:01.176 DEBUG (SyncWorker_15) [pymodbus.logging] Running transaction 1
2024-03-07 15:10:01.176 DEBUG (SyncWorker_15) [pymodbus.logging] SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x1 0x0 0x0 0x0 0x1
2024-03-07 15:10:01.177 DEBUG (SyncWorker_15) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:01.196 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:01.255 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:01.255 DEBUG (SyncWorker_15) [pymodbus.logging] RECV: 0x0 0x1 0x0 0x0 0x0 0x4 0x1 0x1 0x1 0x0
2024-03-07 15:10:01.256 DEBUG (SyncWorker_15) [pymodbus.logging] Processing: 0x0 0x1 0x0 0x0 0x0 0x4 0x1 0x1 0x1 0x0
2024-03-07 15:10:01.256 DEBUG (SyncWorker_15) [pymodbus.logging] Factory Response[ReadCoilsResponse': 1]
2024-03-07 15:10:01.256 DEBUG (SyncWorker_15) [pymodbus.logging] Adding transaction 1
2024-03-07 15:10:01.257 DEBUG (SyncWorker_15) [pymodbus.logging] Getting transaction 1
2024-03-07 15:10:01.257 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:03.247 DEBUG (SyncWorker_4) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:03.248 DEBUG (SyncWorker_4) [pymodbus.logging] Running transaction 2
2024-03-07 15:10:03.248 DEBUG (SyncWorker_4) [pymodbus.logging] SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x0 0x0 0x1
2024-03-07 15:10:03.248 DEBUG (SyncWorker_4) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:03.249 DEBUG (SyncWorker_4) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:03.328 DEBUG (SyncWorker_4) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:03.329 DEBUG (SyncWorker_4) [pymodbus.logging] RECV: 0x0 0x2 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:03.329 DEBUG (SyncWorker_4) [pymodbus.logging] Processing: 0x0 0x2 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:03.330 DEBUG (SyncWorker_4) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:03.330 DEBUG (SyncWorker_4) [pymodbus.logging] Adding transaction 2
2024-03-07 15:10:03.330 DEBUG (SyncWorker_4) [pymodbus.logging] Getting transaction 2
2024-03-07 15:10:03.331 DEBUG (SyncWorker_4) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:03.886 DEBUG (SyncWorker_9) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:03.886 DEBUG (SyncWorker_9) [pymodbus.logging] Running transaction 3
2024-03-07 15:10:03.887 DEBUG (SyncWorker_9) [pymodbus.logging] SEND: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x1 0x0 0x1
2024-03-07 15:10:03.887 DEBUG (SyncWorker_9) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:03.896 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:03.960 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:03.961 DEBUG (SyncWorker_9) [pymodbus.logging] RECV: 0x0 0x3 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:03.961 DEBUG (SyncWorker_9) [pymodbus.logging] Processing: 0x0 0x3 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:03.962 DEBUG (SyncWorker_9) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:03.962 DEBUG (SyncWorker_9) [pymodbus.logging] Adding transaction 3
2024-03-07 15:10:03.962 DEBUG (SyncWorker_9) [pymodbus.logging] Getting transaction 3
2024-03-07 15:10:03.963 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:04.191 DEBUG (SyncWorker_10) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:04.191 DEBUG (SyncWorker_10) [pymodbus.logging] Running transaction 4
2024-03-07 15:10:04.192 DEBUG (SyncWorker_10) [pymodbus.logging] SEND: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x3 0x0 0x1
2024-03-07 15:10:04.192 DEBUG (SyncWorker_10) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:04.195 DEBUG (SyncWorker_10) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:04.271 DEBUG (SyncWorker_10) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:04.271 DEBUG (SyncWorker_10) [pymodbus.logging] RECV: 0x0 0x4 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.272 DEBUG (SyncWorker_10) [pymodbus.logging] Processing: 0x0 0x4 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.272 DEBUG (SyncWorker_10) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:04.272 DEBUG (SyncWorker_10) [pymodbus.logging] Adding transaction 4
2024-03-07 15:10:04.272 DEBUG (SyncWorker_10) [pymodbus.logging] Getting transaction 4
2024-03-07 15:10:04.273 DEBUG (SyncWorker_10) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:04.519 DEBUG (SyncWorker_12) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:04.520 DEBUG (SyncWorker_12) [pymodbus.logging] Running transaction 5
2024-03-07 15:10:04.520 DEBUG (SyncWorker_12) [pymodbus.logging] SEND: 0x0 0x5 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x4 0x0 0x1
2024-03-07 15:10:04.520 DEBUG (SyncWorker_12) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:04.521 DEBUG (SyncWorker_12) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:04.620 DEBUG (SyncWorker_12) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:04.620 DEBUG (SyncWorker_12) [pymodbus.logging] RECV: 0x0 0x5 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.621 DEBUG (SyncWorker_12) [pymodbus.logging] Processing: 0x0 0x5 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.621 DEBUG (SyncWorker_12) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:04.621 DEBUG (SyncWorker_12) [pymodbus.logging] Adding transaction 5
2024-03-07 15:10:04.622 DEBUG (SyncWorker_12) [pymodbus.logging] Getting transaction 5
2024-03-07 15:10:04.622 DEBUG (SyncWorker_12) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:04.891 DEBUG (SyncWorker_11) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:04.891 DEBUG (SyncWorker_11) [pymodbus.logging] Running transaction 6
2024-03-07 15:10:04.891 DEBUG (SyncWorker_11) [pymodbus.logging] SEND: 0x0 0x6 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x5 0x0 0x1
2024-03-07 15:10:04.892 DEBUG (SyncWorker_11) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:04.892 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:04.968 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:04.969 DEBUG (SyncWorker_11) [pymodbus.logging] RECV: 0x0 0x6 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.969 DEBUG (SyncWorker_11) [pymodbus.logging] Processing: 0x0 0x6 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.970 DEBUG (SyncWorker_11) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:04.971 DEBUG (SyncWorker_11) [pymodbus.logging] Adding transaction 6
2024-03-07 15:10:04.972 DEBUG (SyncWorker_11) [pymodbus.logging] Getting transaction 6
2024-03-07 15:10:04.972 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:05.270 DEBUG (SyncWorker_14) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:05.271 DEBUG (SyncWorker_14) [pymodbus.logging] Running transaction 7
2024-03-07 15:10:05.271 DEBUG (SyncWorker_14) [pymodbus.logging] SEND: 0x0 0x7 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x6 0x0 0x1
2024-03-07 15:10:05.271 DEBUG (SyncWorker_14) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:05.283 DEBUG (SyncWorker_14) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:05.360 DEBUG (SyncWorker_14) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"

Not an expert on Modbus. I see the following difference

2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Frame check failed, ignoring!!

This message keeps repeating Let me know how can I further help

janiversen commented 8 months ago

Thanks for the log, but now I am confused...you originally said you had 1 faulty sensor...and now it is multiple. Actually it looks as if the faulty sensor is now responding.

janiversen commented 8 months ago

A short look on the log, it seems the message is ok, so no idea why frame check fails...I need to run this in our simulator, which will take a little while.

phoinixgrr commented 8 months ago

homeassistant reports only one sensor does not work (at least from GUI). The "lg_therma_outlet_temp" . Specifically it is reporting as unavailable. This happens with 2024.3.0

Reverting to 2024.2.5 the only sensor not working "lg_therma_outlet_temp" starts working again.

PimDoos commented 8 months ago

Based on your configuration, I believe some sensors are ignored due to duplicate addresses:

 climates:
      - name: "lg_therma_climate_control"
        address: 3
# ... #

 sensors:
      - name: "lg_therma_outlet_temp"
        unique_id: "lg_therma_outlet_temp"
        scan_interval: 10
        address: 3
# ... #

I see the same thing on my instance with the following log messages:

Modbus pi01/Ecodan Zone 1 room temperature address pi0194_holding_4 is duplicate, second entry not loaded!

phoinixgrr commented 8 months ago

Correct .This sensor is also used in the climates: section.

In the above picture, the same sensor is used and reported in the climate "19.1 degrees"

It is a common configuration, used for LG Therma . Example: https://rodmcbain.com/mastering-modbus-heat-pump-integration-with-home-assistant/

Not sure if the above example is problematic, and never bothered to validate it, since it worked fine, and it only stopped working when updating to 2024.3.0

PimDoos commented 8 months ago

@janiversen I also use both a climate and sensor entity monitoring the same address, since climate entities do not generate long-term statistics. Would it make sense to allow duplicate entities across different entity domains?

phoinixgrr commented 8 months ago

I can confirm. I also get this error:

2024-03-07 14:48:00.313 WARNING (MainThread) [homeassistant.components.modbus.validators] Modbus Heat Pump - LG Therma V/lg_therma_outlet_temp address Heat Pump - LG Therma V3_input_1 is duplicate, second entry not loaded!

janiversen commented 8 months ago

The address is duplicate, but with different types (coil/input) so we do not remove the entry. But you really should correct that...a register in modbus cannot have 2 different types.

However I am still puzzled as to why you get frame_check failed, that is at a different level, and I will investigate.

No it would not make sense, or it would make the same sense not to have any checks at all. Defining the same address multiple times, means more polling of your device, different values in HA (because the 2 entities are not read simultaneously), the latter is the reason we added the check (there was an issue showing the statistics was wrong).

janiversen commented 8 months ago

Now I see you get the duplicate error, you would have saved me some investigation had you told the whole story in the beginning.

phoinixgrr commented 8 months ago

Now I see you get the duplicate error, you would have saved me some investigation had you told the whole story in the beginning.

Apologies for being unable to review 50,000 lines of an unfamiliar log format without clarity on what I'm searching for.

wc -l home-assistant.log
58294 home-assistant.log

I hope that downgrading and confirming the issue with 2024.3.0 at least provided some assistance.

phoinixgrr commented 8 months ago

Seems to be related to the changes introduced here: https://github.com/home-assistant/core/pull/108906

Tom-Bom-badil commented 8 months ago

Seems to be related to the changes introduced here: #108906

Oh wait - I was wondering why after yesterday's update I got the "is lower than 5 seconds, which may cause Home Assistant stability issues" on 4 of my sensors. Those sensors had scan_interval: 0 to be read in only once during startup of HA (e.g. device serial #, hardware revision etc - those NEVER change, so no need to poll them regularly). Changed it to 3600s, error gone.

Was '0' a misinterpretation / misconfiguration from my end (which is likely), or is this a faulty behaviour and related to those changes?

/tom

janiversen commented 8 months ago

@Tom-Bom-badil that is another problem, and a real bug, please file a separate issue. "scan_interval: 0" is valid !

janiversen commented 8 months ago

As for the issue at hand, duplicate addresses are causing multitude of problems, and a number of filed issues, that is the reason for the check.

That being said, the "frame_check failed" is still open, that is something that should not happen.

janiversen commented 8 months ago

For those who want to use the same register for multiple entities, you need to add an automation that makes the duplication.

PimDoos commented 8 months ago

Changed my sensor using the same address as the thermostat to use a different address which supplies the same value. Solved for me.

phoinixgrr commented 8 months ago

As for the issue at hand, duplicate addresses are causing multitude of problems, and a number of filed issues, that is the reason for the check.

For those who want to use the same register for multiple entities, you need to add an automation that makes the duplication.

I'm not suggesting that this approach is incorrect.

However, it's crucial to recognize that this is a breaking change, which will have an impact on the majority of users utilizing LG Therma heatpumps (maybe other heatpumps also since most probably are utilizing also climates configuration ) with modbus for homeassistant integration. Given that many users simply copy and paste existing configurations, this change must be approached with caution.

janiversen commented 8 months ago

No it is not a breaking change, it detects a configuration that may lead to and probably will lead to problems.

But it is all history the release is out, with the release notes.

phoinixgrr commented 8 months ago

Wouldn't a sensor unexpectedly reporting as "unavailable" be regarded as a breaking change?

This is not reported in HA UI logs, nor any warning/message is appeared. The duplicate address, just becomes unavailable. You need to go through ssh console, search through several lines of logs, to identify the issue. (Not sure if also the logging level for modbus needs to be elevated for this to be reported)

janiversen commented 8 months ago

it is reported in homeasssistant.log, as noted earlier in this issue! this log is available in the UI.

The discussion about "breaking change" does not seem productive, I made a choice when I made the pull request, the reviewer agreed with me and thus it got merged. If you see it differently then please review the pull request before they are merged, where they can be changed, instead of afterwards, where there are nothing to change.

janiversen commented 8 months ago

The "frame check failed" is not an error as such, but a misplaced log statement in the underlying library.

phoinixgrr commented 8 months ago

So, if there is no alternate available adress to pull the information of the address that is also used on the climate control, how does one take that information to use it somewhere else in home assistant?

I am just investigating for a workaround here. Not a home assistant expert here, so I most probably maybe missing something.

If i get this correctly if modbus address is used in climate control, then it can be considered as good as dead. It cannot be used anywhere else.

janiversen commented 8 months ago

use automation.

phoinixgrr commented 8 months ago

use automation.

@janiversen

Could you please offer an example of this? I'm finding it challenging to grasp how automations are useful here, given that automations in HA are typically designed to initiate actions in response to events. How does this apply in this situation?

janiversen commented 8 months ago

This is not a support channel, issues are for reporting bugs, please use the user forums.

vuk1980 commented 8 months ago

I have the same problem here. I am having hard time to understand why should I use automation to read same register defined under sensor and under climate entitis in modbus config. for something which should be very simple. My configuration in modbus is very simple (that's why I initially start using this) Also it is very clear how climate in modbus shoud access temp input register so I really don't understand what this change brings to anyone.

janiversen commented 8 months ago

Well you might not understand it, possibly because you did not read the explanation given several times. It is needed in order to ensure consistency. Without it 2 entities, which refers to the same modbus register, would have different values, depending on the update frequency.

You have the entity available in HA, so no need to read it a second time !!!

Others have been complaining about the different values, and they are correct.

And please do not forget, open source is the place where doers decide what happens, so if you want changes get active and submit pull requests, instead of just complaining.

vuk1980 commented 8 months ago

Thank you for your answer. My intentions are not to complain rather to understand if instruction for modbus are the same as before. Meaning, from now on, if we use climate definition in modbus where we must have defined input_type (with address and slave) we cannot use additional sensor to have that value as separate entity? Or wiseverse If I define sensor for (in this case) outlet temp how I can use that sensor in modbus climate definition? That's all what I am trying to understand, what this change brings in overall for modbus usage and instructions (limitation). I cannot find these things here. Thanks! I understand how community works. For now I will stay on previous HA version.

phoinixgrr commented 8 months ago

For now I will stay on previous HA version.

So you are opting for not receiving additional ha updates for ever?

I can understand your furstration @vuk1980 . I am at the same state. It's a breaking change —it used to function, but now it doesn't. The entire community using LG Heat Pumps with Modbus is impacted, and users are already feeling the effects.

Are you familiar with the automation mentioned here? My goal is simply to utilize Climate control and have the flexibility to use the same address elsewhere

janiversen commented 8 months ago

It is fair you want to understand how to configure modbus, the instructions have not changed, it was never advised to have the same register being used in different entities, difference is that now it is being checked.

This channel "issues" is about reporting bugs, not providing support.

And I repeat if you use the climate control, the entity IS available in HA and can be used, without adding a second entity.

phoinixgrr commented 8 months ago

it was never advised to have the same register being used in different entities, difference is that now it is being checked.

It was never discouraged also. 🤷‍♂️

phoinixgrr commented 8 months ago

@vuk1980 There are some recommendations from the community here: https://community.home-assistant.io/t/modbus-issue-after-update-2024-3-cannot-access-same-input-register-twice/700893/4

So it seems that instead of "automation" a " template sensor." can be used to workaround it. Hope that helps

phoinixgrr commented 8 months ago

For anyone searching for a workaround:

This can replace the address used in the modbus climate control.

sensor:
  - platform: template
    sensors:
      lg_therma_outlet_temp:
        friendly_name: "Lg Therma V Outlet Temperature"
        unit_of_measurement: "°C"
        value_template: "{{ state_attr('climate.lg_therma_climate_control', 'current_temperature') }}"

Where climate.lg_therma_climate_control the name of your climate control

phoinixgrr commented 8 months ago

Thank you @janiversen for your awesome work on the Modbus Integration 👍

max-mayorov commented 8 months ago

I have the same problems here. I also use the same address in 2 different domains, but I cannot understand why is that a problem... And it is definitively a breaking change.

janiversen commented 8 months ago

You cannot use the same address with 2 different entities, because the register in your device represent 1 entity.

janiversen commented 8 months ago

You might consider it a breaking change, to me (being the maintainer) the old behavior was a real bug (that was reported in several issues) so we fixed it.

Any change is a breaking change for someone, because the behavior changes.

max-mayorov commented 8 months ago

Any change is a breaking change for someone, because the behavior changes.

I totally understand the reasoning behind the change. That's definitively a good thing that this is fixed, but when behavior changes drastically, like in this case (due to a bugfix or not) - that's a breaking change. A breaking change is a modification in the API that will require API users (in this case me) to update the application/configuration to prevent disruptions. Better communication on breaking changes leads to swifter upgrades.

But nevertheless, thanks for the maintaing the modbus integration, it is awesome!

max-mayorov commented 8 months ago

@janiversen , sorry to come back to this again, but why duplicated names are also not allowed? For other integrations this is not a problem...

modbus:
  name: logo
  type: tcp
  host: x.x.x.x
  port: yyy
  binary_sensors:
    - name: "Storage"
      input_type: coil
      address: 8203
      scan_interval: 1
      unique_id: logo.binary_sensor.q12
  switches:
    - name: "Storage"
      write_type: coil
      scan_interval: 1
      address: 40
      # V5.0
      verify:
      unique_id: logo.switch.storage

With the above config it logs a warning:

Modbus logo/Storage is duplicate, second entry not loaded!

janiversen commented 8 months ago

That is a bug, which is solved in 2024.3.1

max-mayorov commented 8 months ago

Great, thanks a lot!

vwtuner commented 8 months ago

Ändern Sie Slave von 1 auf 2 für die zweite Entität

janiversen commented 8 months ago

That will not work unless you want to change device.

vwtuner commented 8 months ago

It works great.

janiversen commented 8 months ago

Well changing slave means the request goes to another device, and that is normally not what you want.

And especially randomly changing slave:1 to slave:2 will typically not work, except for the case where you have 2 devices with address 1 and 2.

home-assistant / core