NO VALUE after Home Assistant >= 2024.04

[GolfOWL]

Before you create an issue, make sure to update to the current version of modbus_sungrow.yaml

Describe the bug:

After installing the new version of HA 2024.04 (yesterday) I miss the following values of the variables in the dashboard:

BATTERY
sensor.battery_charge
sensor.battery_charge_nominal
sensor.daily_battery_charge
sensor.daily_battery_discharge

sensor.battery_capacity
sensor.battery_state_of_health
sensor.daily_battery_charge_from_pv
sensor.daily_battery_charge
sensor.daily_battery_discharge
sensor.total_battery_charge_from_pv
sensor.total_battery_discharge
sensor.total_battery_charge

ENERGY
sensor.daily_pv_generation
sensor.daily_consumed_energy
sensor.daily_imported_energy
sensor.daily_exported_energy
sensor.total_consumed_energy

sensor.daily_pv_generation
sensor.daily_direct_energy_consumption
sensor.daily_exported_energy_from_pv
sensor.daily_battery_charge_from_pv
sensor.daily_battery_discharge
sensor.daily_exported_energy
sensor.daily_battery_charge
sensor.daily_imported_energy
sensor.total_pv_generation
sensor.total_direct_energy_consumption
sensor.total_exported_energy_from_pv
sensor.total_battery_charge_from_pv
sensor.total_battery_charge
sensor.total_battery_discharge
sensor.total_imported_energy
sensor.total_exported_energy

Your Sungrow inverter:

• Model: SH10RT-V112

• The inverter is connected via (mark one)

  • [] LAN (internal port)
  • [] WiNet-S (LAN)
  • WiNet-S (WLAN)

• Are you using a Modbus Proxy (mark one)

  • [] yes
  • [] no
  • I don't know what that is

Home Assistant version:

• Version: Core 2024.4.0, Supervisor 2024.03.1, Frontend 20240403.1

modbus_sungrow.yaml:

• Version/ time stamp : 2024-03-26
• [] I ensured to use the most recent version

** Inverter Firmware Status:**

• [] I made sure that the newest firmware is installed via the installers account

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
I would like to return to the previous state - the display of the values. :-)

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Thanks in advance

[umrath]

Related to/duplicate of #273

[GolfOWL]

Changed back to HA Core 2024.3.x - and it is running without problems...

[umrath]

Interesting change here!
After hopelessly trying to fiddle with everything I could possibly try, I noticed, that the modbus connection gets immediately closed when connecting via telnet to port 502.
This was unexpected.

A simple restart of my router (where the Sungrow is connected to) and a restart of the modbus-integration seem to have fixed it. At least for now.

[Throntorus]

Interesting change here! After hopelessly trying to fiddle with everything I could possibly try, I noticed, that the modbus connection gets immediately closed when connecting via telnet to port 502. This was unexpected.

A simple restart of my router (where the Sungrow is connected to) and a restart of the modbus-integration seem to have fixed it. At least for now.

Tried the same, unfortunatelly it can't help. Connection is still broken.

[sahnebar]

I experienced a similar issue with the new version 2024.4. I was able to resolve the problem by reverting to version 2024.3.x, which worked well again. I'm not sure what caused the issue in the newer version, but I'll wait and see if a fix becomes available.

[timkolloch]

After an update to 2024.4.1 it works for me again.

[mkaiser]

This is really odd..

I went through the HA changelog and the pymodbus changelogs and could not find any commits mentioning some relevant modbus changes (from 24.3 to 24.4.1)

For me it is still working using a modbus proxy (which is also based on pymodbus, so basically the same code base).

Did I miss any changes? I have no clue why it broke for many guys here

[Throntorus]

After an update to 2024.4.1 it works for me again.

I'm on 2024.4.1 (via docker on a Synology NAS) but still not working.

[githublakeware]

Same no value problem for me after Update to HA 2024.4.1 yesteday.

Home Assistant
Core 2024.4.1
Supervisor 2024.03.1
Operating System 12.1
Frontend 20240404.1

modbus_sungrow.yaml: 2024-04-05

No idea how everything is implemented.
Is there a Python incompatibility for modbus implementation after the last HA update?

Python 3.11 support has previously been deprecated and has now been removed.

home-assistant/core#114220

Modbus has problems: home-assistant/core#115039

[TCzerny]

The only thing I saw on 2024.4 regarding mid is was this:
home-assistant/core#113516

[Johnnyd1965]

I'm having the same problem. some values appear and then disappear..

[githublakeware]

Is that the problem?
home-assistant/core#115114 (comment)

[mkaiser]

Good catch! Thank you for the reference....

As it is most likely a HA internal issue, I guess we just need to wait.

I will consolidate all duplicate issues and discussions, soon and write some hints in the readme.md

[githublakeware]

Good catch! Thank you for the reference....

As it is most likely a HA internal issue, I guess we just need to wait.

I will consolidate all duplicate issues and discussions, soon and write some hints in the readme.md

The problem is on the problem tracker list now: home-assistant/core#115236

[githublakeware]

A fix was added to 2024.4.3 HA core milestone now.

[GolfOWL]

A fix was added to 2024.4.3 HA core milestone now.

Cool - good news. Many thanks...

[reesaroo74]

I was still having troubles with 2024.4.3 with one of my units, so also reverted to 2024.3.3 - working perfectly again

Terminal:
"has core update --version 2023.3.3"

[githublakeware]

Home Assistant Core Update 2024.4.3 has been released.
I installed it and it solved my problems unfortunately not yet.
Even a complete reboot of the system did not help.

Or am I too impatient and still have to wait for the hour?

This is for your information only, as this must be reported to home-assistant/core.

I have errors like:
Logger: homeassistant
Quelle: /usr/src/homeassistant/homeassistant/runner.py:146
Error doing job: Fatal error: protocol.data_received() call failed.

and

Logger: pymodbus.logging
Quelle: runner.py:189
General exception: index out of range

[Throntorus]

Home Assistant Core Update 2024.4.3 has been released. I installed it and it solved my problems unfortunately not yet. Even a complete reboot of the system did not help.

Or am I too impatient and still have to wait for the hour?

This is for your information only, as this must be reported to home-assistant/core.

I have errors like: Logger: homeassistant Quelle: /usr/src/homeassistant/homeassistant/runner.py:146 Error doing job: Fatal error: protocol.data_received() call failed.

and

Logger: pymodbus.logging Quelle: runner.py:189 General exception: index out of range

I can confirm this in exactly the same way. Unfortunately, no improvement after the update.

[InFlames82]

Home Assistant Core Update 2024.4.3 has been released. I installed it and it solved my problems unfortunately not yet. Even a complete reboot of the system did not help.
Or am I too impatient and still have to wait for the hour?
This is for your information only, as this must be reported to home-assistant/core.
I have errors like: Logger: homeassistant Quelle: /usr/src/homeassistant/homeassistant/runner.py:146 Error doing job: Fatal error: protocol.data_received() call failed.
and
Logger: pymodbus.logging Quelle: runner.py:189 General exception: index out of range

I can confirm this in exactly the same way. Unfortunately, no improvement after the update.

Same here

[mr-p666]

And in case the number of reports plays a role... unfortunately it doesn't work for me either!

[githublakeware]

Just opened: home-assistant/core#115489

[Andrenato]

Ich habe das Problem bei mir jetzt gelöst ich habe in der secret.yaml die ip Adresse vom Modbus proxy eingetragen seit dem habe ich keine Probleme mehr

Also die IP von Homeassistent

[Throntorus]

Ich habe das Problem bei mir jetzt gelöst ich habe in der secret.yaml die ip Adresse vom Modbus proxy eingetragen seit dem habe ich keine Probleme mehr

Also die IP von Homeassistent

Can you post how exactly you specified it?

[Andrenato]

Ich habe als addon mostbus Proxy dort ist die ip vom Sungrow Wechselrichter eingetragen unter Konfiguration

anschließend habe ich in der secret yaml die ip Adresse von homeassistent eingetragen Beispiel

der Sungrow Wchselrichter hat 192.168.0.75
Die Ip unter Modus Proxy bei Konfiguration eintragen

anschließend die ip Adresse in der secret.yaml von 192.168.0.75

auf die IP von homeassistent ändern

homeassistent Neustarten und dann sollte es funktionieren

[githublakeware]

I have now also switched to Modbus Proxy (https://github.com/Akulatraxas/ha-modbusproxy) in my environment, but it has not brought any improvement for me.
But doesn't that also make sense?
The proxy must also be based on the Modbus protocol. And if it is true that Sungrow is not comply witch the protocol (see home-assistant/core#115489 (comment)), then the proxy must also fail. Right?

[Andrenato]

Hast du die IP auch in der Secret yaml auf die IP von Homeassistent geändert?

[Gnarfoz]

I have now also switched to Modbus Proxy (https://github.com/Akulatraxas/ha-modbusproxy) in my environment, but it has not brought any improvement for me. But doesn't that also make sense? The proxy must also be based on the Modbus protocol. And if it is true that Sungrow is not comply witch the protocol (see home-assistant/core#115489 (comment)), then the proxy must also fail. Right?

People use modbus proxies for a different reason: some modbus implementations, like for example Sungrow's, react very badly to receiving multiple requests at the same time. On Sungrow SHxRT devices, it sometimes causes it to stop responding entirely until you power cycle the inverter (or unplug the network cable and reconnect it).
This is only relevant if you have more than one modbus client accessing the inverter. Forcing all modbus requests from multiple devices through a single proxy that can serialize possible overlapping requests avoids this problem. So indeed, if you only have one thing accessing the inverter, adding a modbus proxy shouldn't make a difference.

[Camp3r]

Sorry, but it is not working for me.

Did you reboot or restart your HA after update the modbus.yaml?

[githublakeware]

Sorry, but it is not working for me.

Did you reboot or restart your HA after update the modbus.yaml?

Yes, I updated the modbus_sungrow.yaml and then restartet HA. For some values, you have to wait for the full next hour to receive.

[githublakeware]

Sorry, but it is not working for me.

Did you reboot or restart your HA after update the modbus.yaml?

Yes, I updated the modbus_sungrow.yaml and then restartet HA. For some values, you have to wait for the full next hour to receive.

Sorry, the question was for jajaballard. I'm not really awake yet. :-)

[jajaballard]

Yes, I did a full restart. But this did not help.
I figured out my Sungrow changed the IP adresse, so I need to correct the value in secrets.yaml.
Now It works again!!!

Thanks for the workaround and your support!!

[bumperboy]

Home assistant 2024.4.4 installed and my Sungrow issue is fixed. thank you all for your help

[Uschinator]

Installed Home Assistant 2024.4.4 but still getting disconnected sometimes and then errors appear in the log:

`Logger: pymodbus.logging
Quelle: runner.py:189
Erstmals aufgetreten: 08:00:24 (9 Vorkommnisse)
Zuletzt protokolliert: 08:00:50

Failed to connect`

`Logger: homeassistant.components.modbus.modbus
Quelle: components/modbus/modbus.py:318
Integration: Modbus (Dokumentation, Probleme)
Erstmals aufgetreten: 07:49:47 (2 Vorkommnisse)
Zuletzt protokolliert: 08:00:22

Pymodbus: SungrowSHx: Error: device: 1 address: 5007 -> Modbus Error: [Input/Output] ERROR: No response received after 3 retries`

And an error for automation:
Error while executing automation automation.sungrow_inverter_update_battery_discharging_start_power_input_slider_update: expected float for dictionary value @ data['value']

This error happens to most of the sungrow automations.

[Uschinator]

And just now i got disconnected for 2 Minutes and every sensor or value displayed on the dashboard regarding sungrow was unavailable.
So this issue is still not fixed.

[AlexRitter]

Updated to 2024.4.4 and all Values are currently present.
Let´s see for a while what will happen....

[InFlames82]

Updated to 2024.4.4 and get this error log:

Logger: homeassistant.components.modbus.modbus
Quelle: components/modbus/modbus.py:318
Integration: Modbus (Dokumentation, Probleme)
Erstmals aufgetreten: 08:21:38 (66 Vorkommnisse)
Zuletzt protokolliert: 09:22:45

Pymodbus: SungrowSH10RT: Error: device: 1 address: 12999 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 13058 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 13099 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 33148 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 13049 -> pymodbus returned isError True

[githublakeware]

@ALL: Please report your errors to HA/core.

[githublakeware]

I have now added all devices/entities to modbus_sungrow.yaml again, so I am using the original mkaiser yaml again. I currently get all values with HA/core 2024.4.4.

[githublakeware]

Updated to 2024.4.4 and get this error log:

Logger: homeassistant.components.modbus.modbus
Quelle: components/modbus/modbus.py:318
Integration: Modbus (Dokumentation, Probleme)
Erstmals aufgetreten: 08:21:38 (66 Vorkommnisse)
Zuletzt protokolliert: 09:22:45

Pymodbus: SungrowSH10RT: Error: device: 1 address: 12999 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 13058 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 13099 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 33148 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 13049 -> pymodbus returned isError True

Are these values that are not yet available or that your inverter does not supply? For example, if no battery is connected?

[Uschinator]

It is working now.
After setting the Sync Intervall from 10 seconds down to 1 second no more errors and disconnects happened so far.
Tried 5 Seconds but then disconnects happening. Seems like my SH10RT_V112 is bored by the long intervall of more than 1 second and is closing the connection.

[AlexRitter]

It is working now. After setting the Sync Intervall from 10 seconds down to 1 second no more errors and disconnects happened so far. Tried 5 Seconds but then disconnects happening. Seems like my SH10RT_V112 is bored by the long intervall of more than 1 second and is closing the connection.

Tried to update the Firmware on the Sungrow Device ?
Are you using the internal LAN or the Dongle ?

I had a similar issue last year before i updated the Firmware on Inverter and Dongle...

[Uschinator]

Tried to update the Firmware on the Sungrow Device ? Are you using the internal LAN or the Dongle ?

I had a similar issue last year before i updated the Firmware on Inverter and Dongle...

I am using the internal LAN (modbus). The Firmware was updated last week during the installation. The installer did it.

[AlexRitter]

Tried to update the Firmware on the Sungrow Device ? Are you using the internal LAN or the Dongle ?
I had a similar issue last year before i updated the Firmware on Inverter and Dongle...

I am using the internal LAN (modbus). The Firmware was updated last week during the installation. The installer did it.

Has the installer rebootet the entire device ?
Sometimes they dont.... (Powering down entiry Power Plant, DC, AC, Battery) ?
Just to shure it is not a local issue.

I´m running 2024.4.4 with latest Sungrow.yml and today i had zero issues (I was able to reproduce the issues with 2024.4.1 - 3)
I´m using SH6.0RT-V112 - nearly the same device...

[Uschinator]

It is working now. Maybe on the weekend i will try to reboot the device. I would loose the Power to the Backup Circuits during reboot/shutdown so not on a workday.

[AlexRitter]

It is working now. Maybe on the weekend i will try to reboot the device. I would loose the Power to the Backup Circuits during reboot/shutdown so not on a workday.

Makes sense.
Think about requesting your own Installer Account at Sungrow.
Makes Live much easier for Updates und Troubleshooting ;-)

[Uschinator]

Thanks for the tip. I have already an installer account created. My installer is not that familiar and the setup was mainly done by me on his phone...
But the system is not yet finished and therefore i do not mess with it until it is finished and the handover is done.

[mastameista]

I have updated to 2024.4.4 in the early morning today and it works like a charm. I have a SH10RT_V112 inverter and the latest modbus_sungrow.yaml. Also I am on the latest sungrow firmwares. So for me the issue seems to fixed. :)

[InFlames82]

Updated to 2024.4.4 and get this error log:

Logger: homeassistant.components.modbus.modbus
Quelle: components/modbus/modbus.py:318
Integration: Modbus (Dokumentation, Probleme)
Erstmals aufgetreten: 08:21:38 (66 Vorkommnisse)
Zuletzt protokolliert: 09:22:45

Pymodbus: SungrowSH10RT: Error: device: 1 address: 12999 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 13058 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 13099 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 33148 -> pymodbus returned isError True
Pymodbus: SungrowSH10RT: Error: device: 1 address: 13049 -> pymodbus returned isError True

Are these values that are not yet available or that your inverter does not supply? For example, if no battery is connected?

All of these values are available before 2024.4.

[playcom-de]

I am using a USB2Serial (RS485) adapter to get data from an energy meter, what has worked well for months. After Updating HA-Core from 2024.3.3 to 2024.4.3, I can’t connect my USB2Serial-Adapter. Everything in HA looks fine, as far as I can see, but I get the following error:

Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:318
integration: Modbus (documentation, issues)
First occurred: 15:16:56 (2 occurrences)
Last logged: 15:18:57

Pymodbus: EM_Heizung: Error: device: 0 address: 1024 -> Modbus Error: [Input/Output] ERROR: No response received after 3 retries
Pymodbus: EM_Heizung: Error: device: 0 address: 1056 -> Modbus Error: [Input/Output] ERROR: No response received after 3 retries

I have tried to change from USB0 to USB1, also different baudrates, nothing works.

Even 2024.4.4 did not fix the issue. Going back to 2024.3.3 fixes the issue.

[tkahn]

I'm running Home Assistant on this setup:

Core: 2024.5.1
Supervisor: 2024.04.4
Operating System: 12.2
Frontend: 20240501.0

Inverter: Sungrow SH10RT
Connected via: LAN (internal port)
modbus_sungrow.yam: 2024-04-05

I have been using this solution for getting data from my inverter for a couple of months now and everything has been working fine. I did have to change the IP in secrets.yaml a couple of times since my router decided to give it a new IP (DHCP) but other than that there have been no issues. Since then I've assigned it a static lease in the router.

A couple of weeks ago it stopped working though and I have spent several days looking over all settings in HA, integrations, router, inverter and network configuration but come up empty handed.

Using QModMaster I can contact the inverter on the IP-address and get data with the standard settings:

IP: 192.168.1.75
TCP port: 502
Slave address: 1

As you can see I receive packets and there are no errors. I can also ping the inverter on the IP from the terminal in Home Assistant without any problems:

I found this thread and decided it might be related to the problems I'm experiencing. I'm happy to assist if you want me to check anything in particular. As for now I'm stuck and don't know how to get things up and running again.

Thanks for an awesome integration by the way @mkaiser!

[mkaiser]

the original issue is fixed now, so I will close this thread.

@ tkahn
I have no clue at the moment. I would (desperately) try a modbus proxy (see wiki).

Can you try the proxy and when it is not working open a new, separate issue?

[playcom-de]

Not at all! I have just upgraded to version 2024.5.1 and still get the following error message.

Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:331
integration: Modbus ([documentation](https://www.home-assistant.io/integrations/modbus), [issues](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+modbus%22))
First occurred: 10:57:13 (1 occurrences)
Last logged: 10:57:13
Pymodbus: EM_Heizung: Error: device: 0 address: 1024 -> Modbus Error: [Input/Output] ERROR: No response received after 3 retries

Values are now delivered irregularly, but some entities change to "unavailable". I also have the following entry in the logs:

Logger: homeassistant.bootstrap
Source: bootstrap.py:1010
First occurred: 10:59:19 (1 occurrences)
Last logged: 10:59:19
Setup timed out for bootstrap waiting on {<Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>, <Task pending name='call_later 0.1' coro=<ModbusRegisterSensor.async_update() running at /usr/src/homeassistant/homeassistant/components/modbus/sensor.py:113> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[set.remove()]>} - moving forward

I think I'll go back to 2024.3.3 for the time being, since modbus is stable.

[Gnarfoz]

Your error message is referring to a heating entity, so it's probably out of scope for this Sungrow project.

That's something best tracked at the home assistant bug tracker.

Actually, even if it was referring to something this project provides, the actual Modbus communication is done by Home Assistant itself. This project is really only a sophisticated configuration file for the Home Assistant Modbus integration.

[playcom-de]

Your error message is referring to a heating entity, so it's probably out of scope for this Sungrow project.

You are right, my bug is not directly related to the Sungrow integration, but I think the problem is the same. The problem are changes to the Modbus integration that have been introduced with version 2024.4.x.

I am referring to an energy meter for a heating device. The energy meter is conected to HA by a USB2Serial (RS485) adapter to get data from the energy meter via modbus. In this respect, my problem has little to do with a heating entity.

My integration is very similar to Sungrow's, but uses rtu and not tcp.

´´´
modbus:

• name: EM_Heizung
  type: serial
  port: /dev/ttyUSB1
  baudrate: 115200
  bytesize: 8
  method: rtu
  parity: N
  stopbits: 1
  delay: 0
  message_wait_milliseconds: 60
  timeout: 50
  sensors:

  • name: EM L1 Voltage
    unique_id: em_l1_voltage
    unit_of_measurement: V
    address: 0x0400
    data_type: uint32
    scale: 0.001
    precision: 3
    state_class: measurement
    scan_interval: 30

  ...

  • name: EM L1 Power
    unique_id: em_l1_power
    unit_of_measurement: W
    address: 0x041A
    data_type: uint32
    scan_interval: 10
    ´´´

If the problems for the Sungrow integration have been fixed with the latest version, then I'm glad for everyone who uses it. I had thought or hoped that I had the same problem and didn't want to open a separate case. Maybe I'll have to do that now anyway.

[Uschinator]

• scan_interval: 10

You can try to set the scan_interval to 1
That did the trick for me. No more errors after a restart of HA.

[tkahn]

the original issue is fixed now, so I will close this thread.

@ tkahn I have no clue at the moment. I would (desperately) try a modbus proxy (see wiki).

Can you try the proxy and when it is not working open a new, separate issue?

I solved the problem and it had nothing to do with this integration, which was working fine all along. Made a comment about it and the solution in this issue: #291 (comment)

Sorry for the false alarm and thanks again for the work you've put into this integration.