2024.2 modbus entities unavailable until first change

[juhanjuku]

The problem

After updating to 2024.2 modbus entities show 'unavailable' until they change state. After restoring to 2024.1.6 modbus works correctly again. (tried 3 times)

No errors in log

What version of Home Assistant Core has the issue?

2024.2.3

What was the last working version of Home Assistant Core?

2024.1.6

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

home-assistant.log

Example YAML snippet

´´´
modbus:
  # Kodu_anal-1
  - type: tcp
    host: 192.168.1.20
    port: 502
    name: hub20
    delay: 0
    message_wait_milliseconds: 30
    timeout: 5

    sensors:
      - name: Modbus 20-0 # Analog20-0    Vent. niiskus
        unit_of_measurement: "%" # 0..100 % scale=100/65536
        address: 0
        data_type: uint16
        precision: 1
        scale: 0.001526

      - name: Modbus 20-1 # Analog20-1    Vent. temp.
        unit_of_measurement: °C # 0..50 % scale=50/65536
        address: 1
        data_type: uint16
        precision: 1
        scale: 0.000763

      - name: Modbus 20-2 # Analog20-2    Maakütte tase
        unit_of_measurement: "%" # -50..150 % scale=200/65536=0,00305
        address: 2
        data_type: uint16
        precision: 1
        scale: 0.00305
        offset: -50

      - name: Modbus 20-3 # Analog20-3    MK Boileri temp
        unit_of_measurement: °C # 0..100 'C' scale=100/65536=0,00153
        address: 3
        data_type: uint16
        precision: 1
        scale: 0.00153

  # Kodu_digi-1
  - type: tcp
    host: 192.168.1.21
    port: 502
    name: hub21
    delay: 0
    message_wait_milliseconds: 30
    timeout: 5

    binary_sensors:
      - name: Modbus 21-0 # Sensor1-0     Siim PK-olek
        slave: 1
        address: 0
        device_class: heat
      - name: Modbus 21-1 # Sensor1-1     Kabinet PK-olek
        slave: 1
        address: 1
        device_class: heat
      - name: Modbus 21-2 # Sensor1-2     Magamistuba PK-olek
        slave: 1
        address: 2
        device_class: heat
      - name: Modbus 21-3 # Sensor1-3     Duss PK-olek
        slave: 1
        address: 3
        device_class: heat
´´´

Anything in the logs that might be useful for us?

No errors in log.

Additional information

No response

[home-assistant[bot]]

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]

the behavior in the current version correspond to the actual situation, as long as as entity have not responded it is "unavailable".

It is correct that older versions had different behaviors, but that was wrong, because an entity could show a wrong value for a long time.

[juhanjuku]

Problem seems to be, why modbus gets no response for entity until first state change. This must be simple registry reading and this works in 2024.1.6

[janiversen]

It is not unavailable until the first state change! it is unavailable until the first Read which normally happens very fast, unless there is a device problem. Please remember Modbus is a polled protocol not a push protocol.

But even "very fast' means a short time "unavailable", the same happens if e.g. your device reboots.

[juhanjuku]

Sorry, but I don't understand why history graph shows unavailable until first state change, when entity is polled shortly after restart and gets its current state. Something has been changed with 2024.2 update.

[janiversen]

I cannot help you with that, the sequence is clear:

1) modbus startup 2) set all entities to "unavailable" 3) schedule reading of all entities apart from switch 3) as modbus receives responses update the status of the entities.

The sequence is tested and works, the modbus integration do NOT listen for changes, but reads the entities according to the scan_interval.

[janiversen]

I cannot help you with any analysis, as you have not added a debug log as pr modbus integration documentation, so I cannot see when specific entities are read.

[juhanjuku]

Sorry if I misunderstood which log file to include. I included home-assistant.log file, with log options: homeassistant.components.modbus: debug pymodbus: debug as guided at the end of modbus documentation page. If you advise me how to make better logs, I gladly provide them

[janiversen]

The log you provided have as the very first lines:

2024-02-25 18:15:07.598 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration garbage_collection which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant

You have not done that.....but apart from that, everything is normal, there are no abnormal messages in the modbus communication, and data are returned as expected.

[juhanjuku]

Do you mean, I must remove all custom integrations from my HA and make new log file? Or is the log file wrong? I included complete log file how it starts after restart. I also can't see any errors in log file, but I have no idea where to look. I'm not programmer so I can't analyze code. I just see that when I revert to 2024.1.6 history graph starts showing states right after system start, but after update to 2024.2 graphs are showing unavailable until first state change. (no changes in my modbus yaml) I suspected History graph Card, but this behavior concerns only modbus entities. Zigbee entities are displayed correctly.

[janiversen]

Remove custom_components is a demand for filing an issue, but in your case, there are no need....as the modbus communication is normal, and as I explained earlier restarting modbus will result in a short time where the entities are unavailable (which is correct). Also as stated earlier the modbus protocol is independent of state changes it updates the entities with each read cycle.

[juhanjuku]

Thank you, I try to make some more tests, to see if this is connected with History graph Card.

[juhanjuku]

It seems to be History graph Card related issue. If I look 'unavailable' entities with Developer tools / States, they show actual values, not unavailable. Also same entities in Entities card show correct values. Mystery is, why all other tags, except modbus, behave normally on History graph?

Correction: History shows also 'unavailable' since restart

Can it be that after restart, history is saving modbus entities states to database before first pull gets actual values and 'unavailable' stays in database until next state change?

[juhanjuku]

2024.2.4 fixed the issue :)

[juhanjuku]

Unfortunately, few days later issue game back. If it's related to modbus startup later than first data save to database, theb I don't know where to report issue.

[janiversen]

Well there is nothing to report as this is the behavior we want, because it reflects what is actually happening.

[juhanjuku]

I can't be agree with you that what I see reflects what is actually happening. I made two views to show my modbus entities. History card reads data from database and entities card shows latest states for same entities with last updated time. I made restart 30 minutes ago. You can see that slowly changing entities keep showing unavailable on graph card but entities card shows received status shortly after restart. If I check 'unavailable' entities with developer tools/states, they show on or off, not unavailable. So, I'm saying, all modbus entities get correct states shortly after restart, but history shows 'unavailable' until next state change. So history is not reflecting what is actually happening.

[janiversen]

You are free to have your opinion of course, and from your explanation I am not even sure it's a modbus integration problem.

But please do not expect us to make any changes. If you want the code to work differently pull requests are welcome.

[juhanjuku]

I'm not saying, this is modbus integration problem. After restart modbus entities sates are written to database before modbus actually gets first response from device. It can be database write sequence what is changed with 2024.2 Seems to be pointless to continue discussion here when you are just defending your area, not trying help.

[janiversen]

Your title says it is a modbus problem !

This is not a support forum, "issues" are used to report bugs, and I have being trying to see if there was a bug in the modbus integration, not defending myself nor trying to help you.

If you need help, then please use the user forums.