Error fetching SolarEdge Coordinator data

[DeimicUser]

Before reporting a bug, make sure your configuration is correct, your LAN is working, and you have read about the "Known Issues" in the wiki:
https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki

Describe the bug
A clear and concise description of what the bug is.

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots of the problem and/or configuration.

Logs
Copy any logs in Home Assistant from "custom_components.solaredge_modbus".
Logger: custom_components.solaredge_modbus_multi
Source: helpers/update_coordinator.py:182
Integration: SolarEdge Modbus Multi Device (documentation, issues)
First occurred: 18:25:56 (1 occurrences)
Last logged: 18:25:56

Error fetching SolarEdge Coordinator data: Connection failed: Modbus Error: [Connection] ModbusTcpClient: Connection unexpectedly closed 0.00010848045349121094 seconds into read of 8 bytes without response from unit before it closed connection

Debug Logs
Debug logs are not always necessary, but may be required for more complex issues. You can enable debug logs by adding the following to your configuration.yaml file and restarting Home Assistant.

logger:
    default: warning
    logs:
        custom_components.solaredge_modbus_multi: debug

Debug logging will generate a large amount of data: it is recommended to configure it, collect the data needed, then remove debug logging during normal operation.

Home Assistant (please complete the following information):

• Home Assistant Core Version: 2023.2.1
• solaredge-modbus-multi Version: 2.2.11

Additional context
Add any other context about the problem here.

[WillCodeForCats]

Connection errors are not usually a bug or integration problem.

Check your network and if you're using any kind of wireless try changing to a wired connection.

[DeimicUser]

Hi
Yes, SolarEdge is connected via LAN cable directly with main router. I don't know if this is an error to raise the issue but I received many of that same error since the beginig of connection SolarEdge with HA around Nov-2022. If you claims that it is not related with integration then yes you can close this case.

[WillCodeForCats]

If it only happens sometimes then it's probably an issue with the inverter resetting the connection (and I'll never know why). You can try turning on the keep modbus connection open option to see if that changes anything.

[tonywheeler60]

Hello,

I'm also seeing these errors showing in my logs. On the my dashboard I've got gauges and basic information displays that shows values drawn directly from this integration and they display errors due to the lost data. I too use a wired LAN connection and I've checked the network and it is fine. Maybe it's the inverter but it does distract from what is otherwise an excellent integration - thank you.

My log summary shows:

Logger: custom_components.solaredge_modbus_multi
Source: helpers/update_coordinator.py:182
Integration: SolarEdge Modbus Multi Device (documentation, issues)
First occurred: 13:10:51 (10 occurrences)
Last logged: 13:27:50

Error fetching SolarEdge Coordinator data: Update failed: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)
Error fetching SolarEdge Coordinator data: Update failed: No response from inverter ID 1

[WillCodeForCats]

I use a 30 second polling interval with LAN connection and get occasional no responses too, so while it could be a problem with the pymodbus library it's probably just the inverter doesn't respond sometimes.

[tonywheeler60]

It seems that more failures are showing for me. That's a subjective assessment but I am seeing periods or around 10 minutes when no data can be displayed from this integration. If it is some aspect of the SolarEdge system failing is there anything that we can do to reduce the problem in some way? I am using a 10 sec refresh - could all these hits of the server be causing such problems? If so what would you recommend? I've already dropped the refresh rate down to 30 secs - should I keep the connection live or could this be a cause of issues too?

This log entry seems slightly different.

Logger: custom_components.solaredge_modbus_multi
Source: helpers/update_coordinator.py:182
Integration: SolarEdge Modbus Multi Device (documentation, issues)
First occurred: 5 February 2023 at 13:10:51 (32 occurrences)
Last logged: 13:28:06

Error fetching SolarEdge Coordinator data: Update failed: No response from inverter ID 1
Error fetching SolarEdge Coordinator data: Update failed: Meter read error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)
Error fetching SolarEdge Coordinator data: Connection failed: Modbus Error: [Connection] ModbusTcpClient(192.168.0.132:1502): Connection unexpectedly closed 9.632110595703125e-05 seconds into read of 8 bytes without response from unit before it closed connection
Error fetching SolarEdge Coordinator data: Update failed: Battery read error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)
Error fetching SolarEdge Coordinator data: Connection failed: Modbus Error: [Connection] ModbusTcpClient(192.168.0.132:1502): Connection unexpectedly closed 0.00010919570922851562 seconds into read of 8 bytes without response from unit before it closed connection

[tonywheeler60]

Just FYI, Will. I'm seeing these connection problems quite often (multiple times each day) and when they occur the gauges and information derived from the integration remain failed for over 5 mins (at least).
I've found that restarting the HA server seems to resolve the issue - as soon as the server has restarted the information is there. I know this is a somewhat sledgehammer solution but, unless quite coincidental, this means the issue of an initial loss Comms is not being automatically rectified as soon as it maybe. I appreciate this is not completely objective but it may help. I've just seen this today and I'll try to get more factual information information to report.

[tonywheeler60]

Thank you. Nothing else calling the modbus connection. My network connection seems sound and I've seen the HA integration in a failed state for some minutes whilst the SolarEdge server-based app is still showing almost realtime data - clearly using the very same network, albeit one local and the other via the LAN to the Internet. This seems to support the idea that it's either a uniquely modbus issue or a problem with the integration.

[WillCodeForCats]

From my end if the inverter doesn't respond there's nothing I can do to force it to respond.

[Ashpork]

Thank you. Nothing else calling the modbus connection. My network connection seems sound and I've seen the HA integration in a failed state for some minutes whilst the SolarEdge server-based app is still showing almost realtime data - clearly using the very same network, albeit one local and the other via the LAN to the Internet. This seems to support the idea that it's either a uniquely modbus issue or a problem with the integration.

To be fair, the SolarEdge app is very forgiving to poor network connections. How is your inverter connected to your router?

I used to have lots of connectivity issues whilst my inverter was connected to a powerline network connection, but the solaredge app "looked" perfect giving you the impressions there were no local problems. The Homeassistant logs however contained patchy messages of " Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)", and my history full of patchy data

Wiring my inverter directly to my router massively helped the resilience. You could argue that this integration could make another attempt to get data from the router when it receives garbage, but that would just be masking the root problem.

[WillCodeForCats]

The other major difference is that the integration is "pull" and the solaredge monitoring platform is "push".

The inverter knows if it failed to push data upstream to the monitoring platform and can buffer failed intervals until they can be batch uploaded when there is a successful connection. This way no data is lost due to bad connection, especially for cellular connected inverters. It also hides low quality connections.

When we pull data and there's no response at the moment the pull is requested it's just that: a request was sent and nothing came back. There's no way for the integration to know why. I just have to trust the pymodbus library when it says "no response". There's also no going back in time and filling in missing intervals on pulls.

[WillCodeForCats]

Release v2.3.0-pre.1 adds a new retry capability that may help with unstable connections.

[tonywheeler60]

I'm also using a power line adapter but I've seen clearly live data on the app when the integration shows nothing. I've got a live (separate) electricity smart meter in home display (Hildebrand Glow) and confirms the almost live data from the SolarEdge app. This proves beyond doubt that my network is sound, at least good enough for the SolarEdge servers.

[Ashpork]

A sound network would be one without packet loss, as mentioned what you're seeing is the solaredge app being a little more consumer friendly and smoothing out the rough associated with all sorts of connectivity issues within LAN and WAN environments.

I had similar symptoms to you, see my image below. My integration is set to refresh every 10 seconds, but with the powerline connection I would get drop outs for about 4 minutes.

I then moved the powerline connection at the router end to the same circuit as the powerline connection next to the inverter, and it happened less frequently, but would still occasionally occur, causing me troubles with sending commands to my inverter to charge, switch off etc.

I then went to a wired connection and all the problems went.

Whilst i don't disagree that perhaps the app could be more resilient to connection issues (i don't know if those changes would need to be in this integration or the underlying modbus component), it doesn't hide that fact that your network is likely to be dropping packets.

Are you able to experiment in a similar way?

[WillCodeForCats]

The solaredge monitoring platform is not proof of a stable connection: see my other response on push vs pull.

[WillCodeForCats]

The solaredge monitoring platform "push" upload is absolutely more resilient to lower quality connections.

Modbus is an older protocol, it's very simple, but also not as resilient. It was originally used with a serial bus. There's no handshake in modbus so neither side knows if the messages it sent were actually received. The inverter could very well be sending responses out and we don't get them or the inverter never gets our requests. You could use wireshark to find out but that wouldn't fix anything. I'm just using the pymodbus defaults which are to resend packets 3 times with 0.3 second delay between each resend and an ultimate 3 second response timeout.

Even if other things appear to work modbus is not an exceptionally resilient protocol so I recommend going back to basics with a direct Ethernet connection. No powerline adapters, no wifi bridges, no wifi connected Home Assistant host. Then work from there adding in things one at a time to find which one causes the problem. Remember that powerline adapters are just another type of "wireless" bridge using RF methods and are subject to interference just like any other radio or wireless connection.

[tonywheeler60]

An update - I've now confirmed that the apparent modbus issues (loss of data) are quite often rectified by doing a quick YAML reload (the Dev restart option short of a full restart). I've found that a system YAML reload will often bring the SolarEdge data straight back up. This would indicate that the integration code might at least handle the problem better regardless of cause?
If I leave the system to recover on its own it may take many minutes but the reload YAML will bring data back in seconds.
Maybe you might error trap this and, in such data loss cases, simply attempt a relevant YAML reload?

[WillCodeForCats]

My only supported answer is going to be to fix the network: I can't make the integration try to account for an infinite number of unknown combinations of everyone's idea of networking.

Create an automation to do a reload. The only thing you're doing with a reload is starting the polling interval timer back at zero. You can easily do that by reloading only the integration too.

[WillCodeForCats]

PR #295 may help some instances by making retry attempts before giving up on an update cycle.

It's not yet in a pre-release (I'm letting it run on my dev platform for a while first) but it will be soon.

[WillCodeForCats]

Release v2.3.0-pre.1 adds a new retry capability that may help with unstable connections.

[tonywheeler60]

Thank you, look forward to trying it when released.