Modbus failing after upgrade to 2023.9.0 #99784

34by151 · 2023-09-07T00:11:04Z

The problem

Upgraded from 2023.8.4 to 2023.9.0

After upgrade
Core connects to 2 modbus servers via rtuovertcp
After aprox 5mins all registers become unavailable

Modbus has been rock solid up to this version

Restored 2023.8.4 and modbus has returned to normal

What version of Home Assistant Core has the issue?

2023.9.0

What was the last working version of Home Assistant Core?

2023.8.4

What type of installation are you running?

Home Assistant Supervised

Integration causing the issue

modbustcp

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant · 2023-09-07T06:33:02Z

Hey there @adamchengtkc, @janiversen, @vzahradnik, 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.

_{^{(message by CodeOwnersMention)}}

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

janiversen · 2023-09-07T08:58:26Z

Please add debug log as pr documentation otherwise it is impossible to see what happens.

and of course configuration.yaml

we have seen issues earlier when timeout was too fast.

34by151 · 2023-09-07T10:22:47Z

Hey there @adamchengtkc, @janiversen, @vzahradnik, 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
(message by CodeOwnersMention)

modbus documentation modbus source (message by IssueLinks)

Debug logs lost when I restored the backup and reverted to 2023.8.4
I will clone vm and run in an isolated environment
After that I redo the upgrade and get the logs

Will see if I can get that done tomorrow and post the logs

sagitt · 2023-09-07T11:58:31Z

Same problem to me, i using it with alfa sinapsi and elmogway2

janiversen · 2023-09-07T12:05:06Z

And same response, please follow our guidelines, otherwise it makes no sense to open an issue.

FuL75 · 2023-09-07T12:59:22Z

Same here, looks like it wotks for one hour after reboot and then this:
2023-09-07 14:44:41.965 ERROR (SyncWorker_0) [homeassistant.components.modbus.modbus] Pymodbus: VMC_HUB: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)

FuL75 · 2023-09-07T15:10:56Z

my timeout was default one (5 secs), worked fine till 2023.8.4. Now I've tried to increase to 30 secs.
Let's see if it solves the issue.

janiversen · 2023-09-07T17:45:37Z

And none of you care follow the guidelines, and post a debug log. Without a debug log it is impossible to help.

"No response received" is often related to a too short timeout, but can be a number of other causes.

You need to make a small configuration.yaml, no custom components, run it with debug as pr modbus documentation, and post the configuration.yaml and the log here. Before that is posted no investigation will take place.

janiversen · 2023-09-07T18:28:36Z

And just for reference, my production system using tcp have been running for 24 hours without any error (I updated yesterday, hence 24 hours).

0xa51f · 2023-09-07T18:42:03Z

configuration yaml:

name: hub1
type: tcp
delay: 5
timeout: 5
host: 192.168.X.X
port: 502
sensors:
- name: Grid Power
  unit_of_measurement: "W"
  device_class: power
  data_type: int16
  slave: 30
  address: 2600
  lazy_error_count: 1

debug log:

home-assistant_2023-09-07T18-40-04.154Z.log

janiversen · 2023-09-07T18:54:27Z

@asifkassam you device stops responding, or something blocks the tcp/ip traffic:

2023-09-07 20:30:21.568 DEBUG (SyncWorker_2) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2023-09-07 20:30:21.568 ERROR (SyncWorker_2) [homeassistant.components.modbus.modbus] Pymodbus: hub1: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)

You have set lazy_error_count: 1, so of course this result in a termination. There are a couple of other parameters this might help, please read the documentation.

janiversen · 2023-09-07T18:54:57Z

@BluetriX the easiest is to read the modbus integration documentation.

0xa51f · 2023-09-07T19:00:30Z

@asifkassam you device stops responding, or something blocks the tcp/ip traffic:
2023-09-07 20:30:21.568 DEBUG (SyncWorker_2) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2023-09-07 20:30:21.568 ERROR (SyncWorker_2) [homeassistant.components.modbus.modbus] Pymodbus: hub1: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)
You have set lazy_error_count: 1, so of course this result in a termination. There are a couple of other parameters this might help, please read the documentation.

Thanks for reply - I will try it without lazy_error_count.

However, this has been working 100% for years and up to 2023.8.4 - rollback to 2023.8.4 and its stable on my production VM for 18+ hours including at the point where 2023.9.0 fails on a test VM (and it fails regularly on tes VM at 10/20/30 mins after restart)

These logs from a test VM on same hypervisor as production - no firewall and no other TCP/IP blocking or filtering - devices on same subnet.

janiversen · 2023-09-07T19:18:48Z

This release contains a new version of the library, which is likely to cause problems in custom_components, that have not been updated ! In 2023.10 there will be another library bump.

I did not say remove lazy_error_count, I personally use "lazy_error_count: 3" to avoid temporary problems on the net or in the device. I also have a higher timeout to give a device time to react.

BluetriX · 2023-09-07T19:27:33Z

Here is my log. My typical sensor looks like this:

name: Fox-PV
type: tcp
host: 192.168.1.7 # set to EW11 devices ip address
port: 8899
sensors:
- name: "Fox PV1-Voltage"
  unique_id: foxess_inv1_pv1_voltage
  scan_interval: 30
  slave: 247
  address: 31000
  state_class: measurement
  unit_of_measurement: "V"
  data_type: int16
  scale: 0.1
  precision: 1
  input_type: holding
  device_class: voltage

9_0_home-assistant_2023-09-07T19-17-00.740Z.log

I have not played around with lazy_error_count, timeout or retry_on_empty. This was not neccessary with 8.4.

Edit 1:
Here the 8.4 log:
8_4_home-assistant_2023-09-07T18-56-52.436Z.log

Edit 2:
I assume
2023-09-07 21:40:29.727 ERROR (SyncWorker_3) [homeassistant.components.modbus.modbus] Pymodbus: Fox-PV: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)
causes a disconnect with 9.0. - With 8.4 this was not the case.

I added close_comm_on_error: false to my config and now its running (10minutes till now)

New - working config:

- name: Fox-PV
  type: tcp
  host: 192.168.1.7 # set to EW11 devices ip address
  port: 8899
  close_comm_on_error: false # <<<<<<<<<<My change to work with 9.0 <<<<<<<<<<<<<<<<<<

  sensors:
    - name: "Fox PV1-Voltage"
      unique_id: foxess_inv1_pv1_voltage
      scan_interval: 30
      slave: 247
      address: 31000
      state_class: measurement
      unit_of_measurement: "V"
      data_type: int16
      scale: 0.1
      precision: 1
      input_type: holding
      device_class: voltage

janiversen · 2023-09-07T19:46:20Z

@BluetriX did you look at the log:

2023-09-07 21:12:04.942 ERROR (MainThread) [homeassistant.components.sensor] Error adding entities for domain sensor with platform modbus
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 591, in state
    numerical_value = float(value)  # type:ignore[arg-type]
                      ^^^^^^^^^^^^
ValueError: could not convert string to float: '\x00 \x00 \x00 \x00 \x00H\x003\x00-\x006\x00.\x000\x00-\x00E\x00 \x00 \x00 \x00 '

This is right at the beginning.

janiversen · 2023-09-07T19:47:51Z

next one is:

alueError: Sensor sensor.fox_inverter_model has device class 'None', state class 'measurement' unit 'None' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '� � � � �H�3�-�6�.�0�-�E� � � � ' (<class 'str'>

You also have a number of custom components active, which we suggest you disable before reporting an issue, since we have no idea which effect they might have.

janiversen · 2023-09-07T19:49:37Z

and finally:

2023-09-07 21:12:09.547 DEBUG (SyncWorker_2) [pymodbus.logging] Transaction failed. (Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received))

But as you can see it happens together with other errors, so it is more likely you have a network problem or something similar.

BluetriX · 2023-09-07T19:52:56Z

Yeah, you are right. This is my running (productive) HA at the moment. - with lots of custom stuff. - Just wanted to help (no one was posting debug logs but have issues with this release).

Ok I will have a look at my errors. Perhaps my workaround (close_comm_on_error) is not neccessary anymore.

0xa51f · 2023-09-07T20:00:59Z

This release contains a new version of the library, which is likely to cause problems in custom_components, that have not been updated ! In 2023.10 there will be another library bump.

I did not say remove lazy_error_count, I personally use "lazy_error_count: 3" to avoid temporary problems on the net or in the device. I also have a higher timeout to give a device time to react.

Same problem with this config using a lazy_error_count of 3 and an increased timeout:

name: hub1
type: tcp
delay: 5
timeout: 15
host: 192.168.88.9
port: 502
sensors:
- name: Grid Power
  unit_of_measurement: "W"
  device_class: power
  data_type: int16
  slave: 30
  address: 2600
  lazy_error_count: 3

attached log:

home-assistant_2023-09-07T19-55-48.695Z.log

Meanwhile the production VM running 2023.8.4 running over the same network fabric is not having any issues communicating with the device

BluetriX · 2023-09-07T20:18:47Z

@asifkassam

You have the same issue that I have:

2023-09-07 21:51:22.971 DEBUG (SyncWorker_0) [pymodbus.logging] Transaction failed. (Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)) 
2023-09-07 21:51:22.971 DEBUG (SyncWorker_0) [pymodbus.logging] Processing: 
2023-09-07 21:51:22.971 DEBUG (SyncWorker_0) [pymodbus.logging] Getting transaction 86
2023-09-07 21:51:22.971 DEBUG (SyncWorker_0) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2023-09-07 21:51:22.971 ERROR (SyncWorker_0) [homeassistant.components.modbus.modbus] Pymodbus: hub1: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)
2023-09-07 21:51:23.968 DEBUG (SyncWorker_3) [homeassistant.components.modbus.modbus] Pymodbus: hub1: Modbus Error: [Connection] Failed to connect[ModbusTcpClient(192.168.88.9:502)]

So I don't think it's a "physical" network issue. Possibly the start of HomeAssistant is causing this.

Btw:
@janiversen In the meantime I could fix my first two errors (Error adding entities, fox_inverter_model has device class 'None',) but the third (Transaction failed. (Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)) ) still applies

0xa51f · 2023-09-07T20:21:46Z

So I don't think it's a "physical" network issue. Possibly the start of HomeAssistant is causing this.

@BluetriX
the error presents ~20-30mins after start of Home Assistant for me, consistently

BluetriX · 2023-09-07T20:39:00Z

@asifkassam ok - so this is a different behaviour then. My error occours right at the start and repeats every while and then.

But I think something doesn't fit. I will try to find out why the error comes sometimes.

With me it is always the string
0x* 0x* 0x0 0x0 0x6 0x0 0x3 0x79 0x21 0x0 0x1
that fails. So probably it queries something invalid or something. I need to understand what the fields are. Haven't really dealt with Modbus or RS485 before.

To the original problem:
With 9.0 the error behavior seems to have changed. Presumably it is now correct (disconnect after error) and before (8.4) this did not happen and it was more "error tolerant".
So probably all have problems who have configured or query anything incorrectly.

Edit1:
Identified my issue (with help of https://rapidscada.net/modbus/ ) and now everything is working fine without any workaround (close_comm_on_error). Thanks @janiversen for pointing on the issues! <3

34by151 · 2023-09-07T21:21:13Z

home-assistant - Copy.log

34by151 · 2023-09-07T21:23:36Z

Tried using an isolated VM
Everything working
Performed upgrade from 2023.8.4 to 2023.9.0

After stating up modbus working fine
After a few minutes all the modbus sensors fail

I have 2 modbus servers with 4 energy meters (2 on each)
Modbus fails on both

If I reload the modbus config the cycle repeats

Reverted to 2023.8.4 VM, no issues

Log above

janiversen · 2023-09-09T11:56:53Z

Please ask that question in the integration you are using, we have no way of knowing how they might or might not have changed the parameters

Paulholloway · 2023-09-09T12:17:53Z

I'll put the question there too, but I suspect the main issue lies in the HA update and what it has changed.

As an example of one of the sensors:

- name: "solis"
  type: tcp
  host: !secret solis_ip
  port: 502   # for S2-WL-ST sticks
  # port: 8899  # for DLS-L sticks

  sensors:
    - name: Solis Temperature
      slave: 1
      address: 33093
      count: 1
      scale: 0.1
      input_type: input
      data_type: uint16
      lazy_error_count: 5
      scan_interval: 60
      device_class: temperature
      state_class: measurement
      unit_of_measurement: °C

janiversen · 2023-09-09T12:34:11Z

You are probably correct, but here we do not consider custom components.

fboundy · 2023-09-09T13:43:10Z

It’s not an integration, just a set of scripts that call the standard HA ModBus service. I haven’t seen the problem myself but I haven’t updated to the version mentioned.

…

On 9 Sep 2023 at 13:34 +0100, jan iversen ***@***.***>, wrote: You are probably correct, but here we do not consider custom components. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

Zollman94 · 2023-09-09T14:20:34Z

Same problem here. Modbus sensors showing Unavailable after update to 2023.9.0. Reverted to 2023.8.0 solved issue and working as before.

Wolfir77 · 2023-09-09T16:42:34Z

I have the same problem

HKUser1 · 2023-09-09T18:02:52Z

Same here ...sungrow Sensors are not available again

fboundy · 2023-09-09T18:28:05Z

Just to reiterate that the OP is not using a custom integration. The repo that I put together (and which he mistakenly calls an integration) simply has config (or registers assigned to entities) and scripts to use core HA ModBus with Solis inverters. Unless this issue is being addressed elsewhere I think it has been Closed prematurely.

…

On 9 Sep 2023 at 19:03 +0100, HKUser1 ***@***.***>, wrote: Same here ...sungrow Sensors are not available again — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

legomind · 2023-09-09T18:46:16Z

Everyone just be patient and wait for 2023.9.2 so we can see if upgrading to pymodbus 3.5.2 fixes the issue. It seems very likely it will. See here: https://github.com/pymodbus-dev/pymodbus/releases/tag/v3.5.2

34by151 · 2023-09-09T20:13:26Z

Tested 2023.9.1 last night
2023.9.1 has the same issue

Ill wait for and test 2023.9.2

pbix · 2023-09-10T01:26:01Z

Is the below a breaking change in pymodbus 3.5.0?

My component uses "Endian.Big" which worked before. Do I have to change them all to "Endian.BIG" now or an exception will be thrown? If so, how would I support some folks using older HA versions and folks using 2023.9.0 and later?

34by151 · 2023-09-13T03:33:10Z

Just upgraded to 2023.9.2
Been running 2023.9.2 for just over an hour without an issue

Seems to have resolved the issue but will conform after a few hours of uptime

daza67 · 2023-09-13T04:13:32Z

Same here, seems solid again with 2023.9.2.

HarrisonPace · 2023-09-13T10:41:37Z

It didn't fix the issue for me, upgraded to 2023.9.2 and it's broken still, downgraded back to 2023.9.0 and it works again.

dienavarrete · 2023-09-13T15:11:49Z

This new update (2023.9.2) fixed the problem for me.

vandersson888 · 2023-09-13T15:52:34Z

2023.9.2 is running flawless for me as well! Great work!

dolenec · 2023-09-13T16:09:17Z

Please close task as completed.

p4r4ll4x · 2023-09-16T06:39:25Z

2023.9.2 does not fix it for me, it feels more stable, but the issue sill occurs.
I have an automation that restarts modbus when items become unavailable and it still triggers.
I have 64 modbus switches configured.

Pymodbus: wago_beneden: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)
00:32:58 – (ERROR) Modbus - message first occurred at September 13, 2023 at 18:11:15 and shows up 6 times

modbus wago_beneden communication closed
00:32:46 – (WARNING) Modbus - message first occurred at September 13, 2023 at 18:11:18 and shows up 9 times

ilMartiniano · 2023-10-07T20:35:12Z

2023.10.1 and alpha sinapsi sensor, no fix It for me.

sagitt · 2023-10-08T07:53:14Z

2023.10.1 and alpha sinapsi sensor, no fix It for me.

Remove count: from sensors

cagnulein · 2023-10-13T10:00:39Z

I had a similar issue with my Alfa sensor.
I had this configuration https://www.alfabysinapsi.it/wp-content/uploads/2021/12/configuration.yaml and it worked well till the 2023.10 of HASS.
I replaced it with:

modbus:
  - name: Alfa
    type: tcp
    host: 192.168.0.57
    port: 502
    sensors:
        - name: Potenza Attiva Prelevata Istantanea
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 2
        - name: Potenza Attiva Immessa Istantanea
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 12
        - name: Potenza Attiva Prodotta Istantanea
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 921
        - name: Energia Attiva Prelevata Totale
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 5
        - name: Energia Attiva Immessa Totale
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 15
        - name: Energia Attiva Prodotta Totale
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 924
        - name: Pot Att Prel Quart Media
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 9
        - name: Pot Att Imm Quart Media
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 19
        - name: Tot Energ Att Prel Giorno-1 F1
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 30
        - name: Tot Energ Att Prel Giorno-1 F2
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 32
        - name: Tot Energ Att Prel Giorno-1 F3
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 34
        - name: Tot Energ Att Prel Giorno-1 F4
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 36
        - name: Tot Energ Att Prel Giorno-1 F5
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 38
        - name: Tot Energ Att Prel Giorno-1 F6
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 40
        - name: Tot Energ Att Imm Giorno-1 F1
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 54
        - name: Tot Energ Att Imm Giorno-1 F2
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 56
        - name: Tot Energ Att Imm Giorno-1 F3
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 58
        - name: Tot Energ Att Imm Giorno-1 F4
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 60
        - name: Tot Energ Att Imm Giorno-1 F5
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 62
        - name: Tot Energ Att Imm Giorno-1 F6
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 64
        - name: Fascia oraria corrente
          data_type: uint16
          address: 203
        - name: Data evento
          data_type: uint32
          address: 780
        - name: Tempo residuo distacco
          data_type: uint16
          address: 782

I hope it will be useful for someone (I just removed the count fields)

ciottomate · 2023-10-14T18:31:10Z

Yet it is !! Thanks

In summary just remove the COUNT command on each row where it's present.

Ciao ! :-)

I had a similar issue with my Alfa sensor. I had this configuration https://www.alfabysinapsi.it/wp-content/uploads/2021/12/configuration.yaml and it worked well till the 2023.10 of HASS. I replaced it with:

modbus:
  - name: Alfa
    type: tcp
    host: 192.168.0.57
    port: 502
    sensors:
        - name: Potenza Attiva Prelevata Istantanea
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 2
        - name: Potenza Attiva Immessa Istantanea
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 12
        - name: Potenza Attiva Prodotta Istantanea
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 921
        - name: Energia Attiva Prelevata Totale
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 5
        - name: Energia Attiva Immessa Totale
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 15
        - name: Energia Attiva Prodotta Totale
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 924
        - name: Pot Att Prel Quart Media
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 9
        - name: Pot Att Imm Quart Media
          device_class: power
          unit_of_measurement: W
          state_class: measurement
          data_type: uint16
          address: 19
        - name: Tot Energ Att Prel Giorno-1 F1
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 30
        - name: Tot Energ Att Prel Giorno-1 F2
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 32
        - name: Tot Energ Att Prel Giorno-1 F3
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 34
        - name: Tot Energ Att Prel Giorno-1 F4
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 36
        - name: Tot Energ Att Prel Giorno-1 F5
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 38
        - name: Tot Energ Att Prel Giorno-1 F6
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 40
        - name: Tot Energ Att Imm Giorno-1 F1
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 54
        - name: Tot Energ Att Imm Giorno-1 F2
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 56
        - name: Tot Energ Att Imm Giorno-1 F3
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 58
        - name: Tot Energ Att Imm Giorno-1 F4
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 60
        - name: Tot Energ Att Imm Giorno-1 F5
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 62
        - name: Tot Energ Att Imm Giorno-1 F6
          device_class: energy
          unit_of_measurement: Wh
          state_class: total_increasing
          data_type: uint32
          address: 64
        - name: Fascia oraria corrente
          data_type: uint16
          address: 203
        - name: Data evento
          data_type: uint32
          address: 780
        - name: Tempo residuo distacco
          data_type: uint16
          address: 782

I hope it will be useful for someone (I just removed the count fields)

epenet added the integration: modbus label Sep 7, 2023

home-assistant bot assigned janiversen Sep 7, 2023

janiversen mentioned this issue Sep 7, 2023

Make modbus retry fast on read errors #99576

Merged

20 tasks

pbix mentioned this issue Sep 7, 2023

Latest HA 2023.9.0 breaks SolArk Integration pbix/HA-solark-PV#40

Closed

veista mentioned this issue Sep 7, 2023

'ModbusHub' object has no attribute 'async_pymodbus_call' 2023.9 veista/nilan#80

Closed

ndurchx mentioned this issue Sep 9, 2023

Exceptions since HA 2023.9.0 mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant#158

Closed

Paulholloway mentioned this issue Sep 9, 2023

Modbus failing after upgrade to HA 2023.9 fboundy/ha_solis_modbus#14

Closed

janiversen mentioned this issue Sep 9, 2023

Bump pymodbus to v3.5.2 #99988

Merged

20 tasks

janiversen closed this as completed Sep 9, 2023

HarrisonPace mentioned this issue Sep 11, 2023

TCP modbus connection not restored after device restarted #100063

Closed

This was referenced Nov 7, 2023

Modbus RTU over Serial on RS485 Unreliable data captured #101927

Closed

Modbus RTU over Serial on RS485 Unreliable data captured #103601

Closed

github-actions bot locked and limited conversation to collaborators Nov 13, 2023

Modbus failing after upgrade to 2023.9.0 #99784

Modbus failing after upgrade to 2023.9.0 #99784

Comments

34by151 commented Sep 7, 2023

The problem

What version of Home Assistant Core has the issue?

What was the last working version of Home Assistant Core?

What type of installation are you running?

Integration causing the issue

Link to integration documentation on our website

Diagnostics information

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

home-assistant bot commented Sep 7, 2023

janiversen commented Sep 7, 2023 • edited Loading

34by151 commented Sep 7, 2023

sagitt commented Sep 7, 2023

janiversen commented Sep 7, 2023

FuL75 commented Sep 7, 2023

FuL75 commented Sep 7, 2023

janiversen commented Sep 7, 2023 • edited Loading

janiversen commented Sep 7, 2023

0xa51f commented Sep 7, 2023

janiversen commented Sep 7, 2023

janiversen commented Sep 7, 2023

0xa51f commented Sep 7, 2023 • edited Loading

janiversen commented Sep 7, 2023 • edited Loading

BluetriX commented Sep 7, 2023 • edited Loading

janiversen commented Sep 7, 2023

janiversen commented Sep 7, 2023

janiversen commented Sep 7, 2023

BluetriX commented Sep 7, 2023

0xa51f commented Sep 7, 2023

BluetriX commented Sep 7, 2023 • edited Loading

0xa51f commented Sep 7, 2023 • edited Loading

BluetriX commented Sep 7, 2023 • edited Loading

34by151 commented Sep 7, 2023

34by151 commented Sep 7, 2023 • edited Loading

janiversen commented Sep 9, 2023

Paulholloway commented Sep 9, 2023

janiversen commented Sep 9, 2023

fboundy commented Sep 9, 2023 via email

Zollman94 commented Sep 9, 2023

Wolfir77 commented Sep 9, 2023

HKUser1 commented Sep 9, 2023

fboundy commented Sep 9, 2023 via email

legomind commented Sep 9, 2023

34by151 commented Sep 9, 2023

pbix commented Sep 10, 2023

34by151 commented Sep 13, 2023

daza67 commented Sep 13, 2023

HarrisonPace commented Sep 13, 2023

dienavarrete commented Sep 13, 2023

vandersson888 commented Sep 13, 2023

dolenec commented Sep 13, 2023

p4r4ll4x commented Sep 16, 2023 • edited Loading

ilMartiniano commented Oct 7, 2023

sagitt commented Oct 8, 2023

cagnulein commented Oct 13, 2023

ciottomate commented Oct 14, 2023 • edited Loading

janiversen commented Sep 7, 2023 •

edited

Loading

janiversen commented Sep 7, 2023 •

edited

Loading

0xa51f commented Sep 7, 2023 •

edited

Loading

janiversen commented Sep 7, 2023 •

edited

Loading

BluetriX commented Sep 7, 2023 •

edited

Loading

BluetriX commented Sep 7, 2023 •

edited

Loading

0xa51f commented Sep 7, 2023 •

edited

Loading

BluetriX commented Sep 7, 2023 •

edited

Loading

34by151 commented Sep 7, 2023 •

edited

Loading

p4r4ll4x commented Sep 16, 2023 •

edited

Loading

ciottomate commented Oct 14, 2023 •

edited

Loading