Entities are no longer available or jumping between available and unavailable
smartmatic opened this issue · comments
Before you create an issue, make sure to update to the current version of modbus_sungrow.yaml
Describe the bug:
Entities are no longer available or jumping from available to unavailable
Your Sungrow inverter:
-
Model: [e.g. SH-10.RT 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: [2024.4]
modbus_sungrow.yaml:
- Version/ time stamp : [2024-03-26] (see header of the file)
- 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:
- Go to '...'
- Click on '....'
- Scroll down to '....'
- See error
Expected behavior
Entities are available
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Logs:
`
Logger: homeassistant
Quelle: components/modbus/modbus.py:392
Erstmals aufgetreten: 08:31:14 (38 Vorkommnisse)
Zuletzt protokolliert: 08:39:36
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/modbus/sensor.py", line 113, in async_update
raw_result = await self._hub.async_pb_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/modbus/modbus.py", line 429, in async_pb_call
result = await self.low_level_pb_call(unit, address, value, use_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/modbus/modbus.py", line 392, in low_level_pb_call
result: ModbusResponse = await entry.func(address, value, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/pymodbus/client/base.py", line 167, in async_execute
self.send(packet)
File "/usr/local/lib/python3.12/site-packages/pymodbus/transport/transport.py", line 391, in send
self.transport.write(data) # type: ignore[attr-defined]
^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'write'
`
Logger: homeassistant.components.modbus.modbus
Quelle: components/modbus/modbus.py:318
Integration: Modbus (Dokumentation, Probleme)
Erstmals aufgetreten: 08:31:14 (89 Vorkommnisse)
Zuletzt protokolliert: 08:40:00
Pymodbus: SungrowSHx: Error: device: 1 address: 13019 -> Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 192.168.178.36:502]
Pymodbus: SungrowSHx: Error: device: 1 address: 5016 -> Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 192.168.178.36:502]
Pymodbus: SungrowSHx: Error: device: 1 address: 5604 -> Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 192.168.178.36:502]
Pymodbus: SungrowSHx: Error: device: 1 address: 5018 -> Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 192.168.178.36:502]
Pymodbus: SungrowSHx: Error: device: 1 address: 13009 -> Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 192.168.178.36:502]
Hatte das gleiche Problem mit der neuen yaml war das Problem behoben
Ich habe Modbus jetzt auf meiner Testinstanz deaktiviert und alles scheint wieder normal. Kann es sein, dass Modbus / HA Probleme damit hat, wenn zwei unterschiedliche Instanzen, die Daten Abfragen?
Ich habe das selbe Problem seit dem Core Update 2024.4 mit der aktuelle Yaml.
Nach einem Downgrade auf Core 2024.3.3 funktioniert alles einwandfrei.
War nur von kurzer Dauer bei mir wieder das gleiche Problem wie bei den anderen
Ich habe Modbus jetzt auf meiner Testinstanz deaktiviert und alles scheint wieder normal. Kann es sein, dass Modbus / HA Probleme damit hat, wenn zwei unterschiedliche Instanzen, die Daten Abfragen?
Yes, but is not an issue of HA, but the modbus server on the Sungrow inverter. For this you might want to use a modbus-proxy. The modbus-proxy is then the only instance querying the Sungrow and all others are querying the proxy.
Ich habe das selbe Problem seit dem Core Update 2024.4 mit der aktuelle Yaml. Nach einem Downgrade auf Core 2024.3.3 funktioniert alles einwandfrei.
Same on my installation. After a downgrade to 2024.3.3 everything's works fine again.
At least not a problem that everyone has. It works well for me on 2024.4.0 with latest modbus_sungrow.yaml with datestamp: 2024-03-26
At least not a problem that everyone has. It works well for me on 2024.4.0 with latest modbus_sungrow.yaml with datestamp: 2024-03-26
Same for me. Works with 2024.4.0
same issue for me. It is not working with 2024.4.0 and the new modbus_sungrow.yaml datestamp: 2024-03-26. After downgrade to 2024.3.3 it works fine
Same problem here, upgrade brings jumping values - new yaml doesnt solves the problem
For testing purposes, I installed a modbus proxy in HA, as often suggested.
It is really strange, even with modbus-proxy no sungrow data is displayed with installed Core 2024.4.0.
Downgrade to Core 2024.3.3 and the data is immediately available again, whether with or without modbus-proxy.
I hope there will soon be a solution for this, otherwise my only option is to use the Sungrow integration, which displays significantly less data.
I also have issues. Many sungrow values works fine (e.g DC power) while others (e.g Daily PV generation) don't since the upgrade. Others (e.g battery level) are changing forth and back to/from unavailable.
In the release notes for 2024.4 it is mentioned some breaking changes related to modbus but I don't yet understand if it is relevant.
After disconnecting my second HA instance requesting data from the inverter it works solid with HA 2024.4 and yaml 2024-3-26
I also have issues. Many sungrow values works fine (e.g DC power) while others (e.g Daily PV generation) don't since the upgrade. Others (e.g battery level) are changing forth and back to/from unavailable. In the release notes for 2024.4 it is mentioned some breaking changes related to modbus but I don't yet understand if it is relevant.
The "breaking change" is that modbus configurations without entities (only the device) are not allowed anymore. This is not causing this issues for you.
@ahd71 , @Ratfuzzy , @bennyrbg , @uwelklumpp, @hboltz , @Andrenato , can some of you also provide log files?
As for myself (and others as reported) this does not happen (or connection / entity unavailable issues are at least very rare).
Also please ensure that you use the second LAN port at the inverter (not WiNetS) and do not have any other instance reading the modbus from the the inverter (second HA instance or any other EMS) - if so, please describe your setup.
Hallo ich habe leider wieder Version 3.3 drauf weil damit läuft es ohne Probleme zu meinen Setup mostbus proxi 1.0.18 EVCC 0124.10 Home Assistent 2024.3.3 keine Probleme die neuste Sungrow Jaml von hier
mit der neuen Homeassistent Version stürzt es alle paar Stunden komplett ab so wie oben beschrieben wenn ich wieder Homeassistent neustarte funktioniert es wieder für ca 2 Stunden
Same issue here.
Which kind of logfile is needed? HA?
Pymodbus: SungrowSHx: Error: device: 1 address: 4999 -> Modbus Error: [Connection] Not connected[AsyncModbusTcpClient XXX.XXX.XXX.XXX:502]
Hands full at the moment but some observations:
I took an almost clean dev instance of HA and only added two modbus sensors into configuration - one that is working and one that is failing since upgrace in my prod instance.
Both worked in dev also after upgrading to 2024.4.
That leads me to think that some other used or unused register reads puts either modbus integration or the inverter in a state that gives subsequent problems.
I use WINET-S interface by the way with a slightly tweaked configuration to overcome that my inverter doesn't report state the way some of the other sensors expect but made calculations to get the same outcome.
Will collect logs and get back.
okay, some break through in troubleshooting / partial restored functionallity:
If removing the modbus sensors for the Monthly and Yearly statistics (45 of them!) the other sensors seems to again report correct values with the latest HA release.
I notice in my log the following error which I'm about to dive into further:
Logger: homeassistant
Källa: /usr/src/homeassistant/homeassistant/runner.py:146
Inträffade först: 11:05:18 (4 händelser)
Senast loggade: 11:05:27
Error doing job: Fatal error: protocol.data_received() call failed.
Traceback (most recent call last):
File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 1017, in _read_ready__data_received
self._protocol.data_received(data)
File "/usr/local/lib/python3.12/site-packages/pymodbus/transport/transport.py", line 303, in data_received
self.datagram_received(data, None)
File "/usr/local/lib/python3.12/site-packages/pymodbus/transport/transport.py", line 337, in datagram_received
cut = self.callback_data(self.recv_buffer, addr=addr)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/pymodbus/client/base.py", line 201, in callback_data
self.framer.processIncomingPacket(data, self._handle_response, slave=0)
File "/usr/local/lib/python3.12/site-packages/pymodbus/framer/base.py", line 139, in processIncomingPacket
self.frameProcessIncomingPacket(single, callback, slave, **kwargs)
File "/usr/local/lib/python3.12/site-packages/pymodbus/framer/socket_framer.py", line 106, in frameProcessIncomingPacket
raise ModbusIOException("Unable to decode request")
pymodbus.exceptions.ModbusIOException: Modbus Error: [Input/Output] Unable to decode request
This is some very weird behavior. I updated to 2024.4.0 and all of my sensors are still working, that is with the version 2023-12-31, but the only difference between the two is the battery level precision. I'm also requesting data slightly faster, which may cause a difference. All the 10 second registers are requested each second.
A year ago I also had similar issues, which is when I tried some things and ultimately decreased the scan_interval, which seems to work.
What did you set the battery level precision to?
fyi: The integration worked yesterday after updating to 2024.4 (with the old version from 2023-12-31).
It stopped some hours later, without any noticable reason.
Updating to 2024-03-26 did not change anything and now I fail to get it to work at all. I do not want to downgrade to 2024.3.3, so I will wait for a potential fix.
What did you set the battery level precision to?
It was the default. The precision was changed in the latest release. On mine, it currently isn't set, but that shouldn't make a difference.
Changed back to HA Core 2024.3.x - and it is running without problems with yaml of 31.12.2023...
Here is my attempt at rewriting the passage:
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.
Changed back to HA Core 2024.3.3 - and it is running without problems with yaml of 05.04.2024...
I need to cleanup all related threads a bit. This is a duplicate of #274 .In #274 there a some links to related HA issues. Please continue discussions there :)
The described behaviour is a result of HA internal changes (transitioning from sync to async calls). It does not look like this can somehow be fixed by rewriting stuff in this integration.
If you are affected, there is currently no other option than to downgrade to 2024.3 :/
In #274 there a some links to HA issues. Please continue discussions there :)