Sure, I’ll look into that.
1 Like
I am also seeing this repair notification a lot more than I used to and I was looking at another Home Assistant instance and they commented that they were also seeing this repair a lot more often as well.
The repair used to check on a polling basis the failure condition and self correct if connectivity was restored. It feels like this polling check isn’t occuring so the repair never self repairs it seems to always waits until the user manually presses the repair button.
1 Like
I’m also getting this plus it seems to be struggling to connect, only in the last day since some updates.
If you are using a proxy and the proxy doesn’t start before HA starts, the repair issue will be raised when integration set up/start up fails becasue it can’t communicate.
Any start up communications failure will raise the repair issue. I haven’t seen this personally and there have been no changes to how repair issues are handled.
For info - mine isn’t running through a proxy, but in the last few days it’s been unable to connect. Seems to be after recent updates, but difficult to pin down which.
I’m getting the following in the logs:
2024-02-10 19:21:45.806 ERROR (MainThread) [custom_components.solaredge_modbus_multi] Timeout fetching SolarEdge Coordinator data
2024-02-10 19:21:45.807 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 8.403 seconds (success: False)
2024-02-10 19:22:15.405 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 8.4
2024-02-10 19:22:18.684 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 40 40
2024-02-10 19:22:21.742 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 4 4
2024-02-10 19:22:23.807 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 8.402 seconds (success: False)
Had been fine until late on 8th Feb, which appears to be when I updated to core_2024.1.6. Currently running ver 2.4.10-pre.4 of the integration.
Starting with Release v2.4.10-pre.5 repair issues from HA startup will be automatically cleared.
2 Likes
This appears to be something is causing a slowdown which in turn causes the update it to reach the 8.4 second coordinator timeout (this value is calculated depending on what the integration detects).
Turn on pymodbus debugging to see if there’s a reason the reads are slow.
In configuration.yaml:
logger:
logs:
pymodbus: debug
Ok, I’ve put that in the config. I’ll post anything I find.
You shouldn’t be getting 3 seconds between reads. They should be sub-second in normal conditions.
Thanks! It has not yet been released for HACS installation, has it?
Hello,
Can I somehow change Solaredge’s default SoC? I have a SE10K-RWS with 4x Pylontech US5000 which works really flawlessly with the LV 14 profile. Unfortunately, Solaredge has specified a minimum SoC of 15%, which means my memory discharge ends as soon as 15% is reached. However, the Pylontechs could easily be discharged to 5%.
Is there somehow a way to minimize the preset SE value or increase the real SoC by 10% so that the discharge can continue? I’m grateful for every hint.
My SE-10K RWS Allows me to discharge the BYD batteries up to 10%…
I not know if is a different firware version, or maybe there is a specific discharge based on the battery connected
All pre-releases are on HACS immediately. You might have to manually refresh if it doesn’t show up automatically (assuming beta versions is turned on in HACS).
1 Like
I set up debugging in the logs - I’ll sent you a private message with a link.
It looks like it works for a while and then seems to struggle. I can’t see anything obvious, but then again I’m not the expert!
I see some of the failures are because it sends requests but doesn’t get any response.
Some have a message that shouldn’t be possible in a single connection setup Unrequested message: ReadHoldingRegistersResponse (4). This means that that it got a response that it didn’t ask for. If you were running a proxy I would say that was because the proxy send the wrong response to the wrong client. Or it did ask earlier, gave up, and the response is extremely delayed.
The first thing I would suggest is to try turning off “keep modbus open” option. I’m going to look at the code and do something that would force the connection to close and retry if timeout is reached.
OK - thanks for the quick response. I’ve turned off the “keep modbus open” for now. I’ll see how that goes.
So far seems to have done the trick, it’s definitely been connected for longer.
You can try Release v2.4.11-pre.1 with keep modbus open option. This version will force a disconnect if there are timeout errors.
OK - will do.
Sorry to say, keep Modbus open didn’t work with the new version. Seems to be holding up with this off at present but as I write this it’s struggling again.