core: Modbus sensors with datatype 'string' are unavailable with 2023.10.0

The problem

Modbus sensors with datatype ‘string’ are unavailable with 2023.10.0. Numeric sensors are working as expected. There are no modbus-related error messages in the log.

What version of Home Assistant Core has the issue?

core-2023.10.0

What was the last working version of Home Assistant Core?

core-2023.9.3

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/#configuring-sensor-entities

Diagnostics information

No response

Example YAML snippet

- name: Mennekes Amtron Professional
  type: tcp
  host: ###########
  port: ###
  sensors:

    ## General system information
    - name: Amtron Firmware
      unique_id: 7ac5d621-81b6-4b29-b72b-6824db6e8622
      address: 100
      slave: 1
      count: 2
      input_type: holding
      data_type: string
      scan_interval: 86400

Anything in the logs that might be useful for us?

No response

Additional information

No response

About this issue

  • Original URL
  • State: closed
  • Created 9 months ago
  • Comments: 27 (11 by maintainers)

Most upvoted comments

Thanks to the suggestion from @mschulze46 I can confirm there is a bug in the modbus integration.

I hope to fix it later today and will then add it to next patch version, sorry for the inconvenience.

@mschulze46 you actually might be on to something !

the request is for address 40019, but the length is 1, that looks wrong when I compare with the configuration, let me take a deeper look in the code.

I’m not into the details of the Modbus protocol but this section of the log might contain the problem:

2023-10-06 09:35:08.997 DEBUG (SyncWorker_0) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2023-10-06 09:35:08.997 DEBUG (SyncWorker_0) [pymodbus.logging] Running transaction 3
2023-10-06 09:35:08.997 DEBUG (SyncWorker_0) [pymodbus.logging] SEND: 0x0 0x3 0x0 0x0 0x0 0x6 0x0 0x3 0x9c 0x53 0x0 0x1
2023-10-06 09:35:08.997 DEBUG (SyncWorker_0) [pymodbus.logging] New Transaction state "SENDING"
2023-10-06 09:35:08.997 DEBUG (SyncWorker_0) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2023-10-06 09:35:09.002 DEBUG (SyncWorker_0) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2023-10-06 09:35:09.002 DEBUG (SyncWorker_0) [pymodbus.logging] RECV: 0x0 0x3 0x0 0x0 0x0 0x5 0x0 0x3 0x2 0x53 0x31 <<<==========
2023-10-06 09:35:09.002 DEBUG (SyncWorker_0) [pymodbus.logging] Processing: 0x0 0x3 0x0 0x0 0x0 0x5 0x0 0x3 0x2 0x53 0x31
2023-10-06 09:35:09.002 DEBUG (SyncWorker_0) [pymodbus.logging] Factory Response[ReadHoldingRegistersResponse': 3]
2023-10-06 09:35:09.002 DEBUG (SyncWorker_0) [pymodbus.logging] Adding transaction 3
2023-10-06 09:35:09.002 DEBUG (SyncWorker_0) [pymodbus.logging] Getting transaction 3
2023-10-06 09:35:09.002 DEBUG (SyncWorker_0) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"

The response ends with the bytes 0x53 0x31 (ASCII => S1). These are the first 2 characters of the model string.

    - name: "E3DC Model"
      unique_id: e3dc_model
      address: 40019
      data_type: string
      count: 16 <<<==========
      scan_interval: 3600

Since I specified to read a count of 16 I assume the response to be truncated after 2 characters of the payload.

Read the documentation! and read the log:

count: 2 cannot be combined with data_type: int32

That is your issue.