Yes, I was hoping I could spare my poor SD-card all the logs, since the pymodbus log entries are caused by your integration and do contain a timestamp. Oh well, I have now enabled the logging, I think tomorrow morning I will know more.
Interestingly, your disconnection times are quite close to my own. Mine happen at around 1800 and 0400 plus or minus 10 minutes. I’ve actually created a few template sensors to “predict” when this is most likely to happen based on when it last happened.
I’ll be interested to see what comes up in your debug logs.
My inverters go offline at least once overnight, sometimes twice. They will refuse connection, eventually succeed on one of the retries and show status OFF, then go back to status SLEEPING.
Also, on timing, pymodbus itself has a 3 second timeout on connect. So there’s my retry timing and then there’s the pymodbus timeout on top of that. That is set in class ModbusDefaults in the same file.
Here are the results of my log-experiments. At the beginning of the experiment, around 00:30, I set the Storage Discharge limit of my battery to 0 - this also shows up in the logs:
2023-11-16 00:30:31.505 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.number] set SE10K-RWS48BEN4_7E062AB0_storage_discharge_limit to 0.0
This is also confirmed in the regular debug output:
2023-11-16 00:30:32.678 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Inverter 1: discharge_limit 0x0
At 4:19, the connection problems happen:
2023-11-16 04:19:02.937 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 10.8
2023-11-16 04:19:05.939 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-16 04:19:05.940 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Failed data refresh attempt #1
2023-11-16 04:19:05.940 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Waiting 1500 ms before data refresh attempt #2
2023-11-16 04:19:07.442 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 10.8
2023-11-16 04:19:10.445 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-16 04:19:10.446 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Failed data refresh attempt #2
2023-11-16 04:19:10.446 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Waiting 4500 ms before data refresh attempt #3
2023-11-16 04:19:14.948 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 10.8
2023-11-16 04:19:17.951 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-16 04:19:17.952 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Failed data refresh attempt #3
2023-11-16 04:19:17.952 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Waiting 13500 ms before data refresh attempt #4
2023-11-16 04:19:31.453 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 10.8
2023-11-16 04:19:31.456 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.178.28', 1502)
2023-11-16 04:19:31.457 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Failed data refresh attempt #4
2023-11-16 04:19:31.457 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Waiting 40500 ms before data refresh attempt #5
2023-11-16 04:20:11.959 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 10.8
2023-11-16 04:20:12.000 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] len rcount : 40 40
2023-11-16 04:20:12.028 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] len rcount : 4 4
2023-11-16 04:20:12.162 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] len rcount : 2 2
2023-11-16 04:20:12.181 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] len rcount : 4 4
2023-11-16 04:20:12.202 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] len rcount : 2 2
Interestingly and unexpectedly for me, pymodbus reports failure before the retry loop is even finished, no idea if this is expected behaviour. Connection is back at 4:20.
And of course, immediately afterwards in the first status message after the connection works again, my discharge settings are already gone:
2023-11-16 04:20:12.252 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Inverter 1: discharge_limit 0x459c4000
Just to make sure, I checked the last log before the connection failure - and it is still set to 0 before:
2023-11-16 04:18:33.105 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Inverter 1: discharge_limit 0x0
My hypothesis now: the inverter resets itself twice daily. During that time, the connection cannot be established, until the reset is finished. And: the inverter drops some settings that it considers non-essential to default settings (such as the discharge limit).
I talked to the Solaredge support today and they also confirmed that the inverter resets twice daily at those times - and that this is expected behaviour (even though I don’t trust this 100%, because I had asked the guy about my other problem before, which clearly went over his head and he was not capable to answer any Modbus-related questions - and was probably trying to get rid of me at this point).
Last finding: I had one more warning in the log afterwards that I had not seen before:
2023-11-16 05:00:42.677 WARNING (MainThread) [homeassistant.helpers.entity] Updating state for sensor.solaredge_b1_state_of_energy (<class 'custom_components.solaredge_modbus_multi.sensor.SolarEdgeBatterySOE'>) took 0.434 seconds. Please create a bug report at https://github.com/WillCodeForCats/solaredge-modbus-multi/issues
My working assumption: if my hypothesis is correct and the connection drops are caused by the inverter resetting, of course I can try fine-tuning connection-values all I want but the maximum I will be able to achieve is get rid of the error message in the logs. The loss of my discharge-setting is however caused by the inverter-reset and not by the loss of connection - and I would need to react accordingly in my automations, e.g. by trying to catch the reset in some kind of trigger that then resets the discharge-value to my desired values. Unless of course the integration could also somehow notice the reset (e.g. by finding out that its internal state of certain states and the values it gets from the inverter is no longer consistent - which appears to cause the last warning).
Thanks for listing to my TED-talk 
- and sorry for putting this in this thread, but it appears to be the most active thread for discussions on this Modbus-integration.
1 Like
I think it’s actually the reverse. The connection drops due to the inverter resetting.
That’s really interesting to read. I share your scepticism on this being expected behaviour, but as it is happening to more than just your inverter, it seems a plausible explanation. I have 2 inverters in my system and both reset at the same time twice a day.
I read through the Solaredge Power Control Open Protocol for Inverters document today to see if I could find any other indicators that might explain this behaviour. Based on my own observations from the logbook, all I could find in relation to Inverter Grid Control was this:
Power Control Block
This block enables the grid control functionality. The power control settings are operative only if the grid control functionality is enabled.
This functionality is disabled by default and should be set by your installer. This in itself is not earth-shatteringly important in determining the reason for inverter reset, but, the Power Control Block describes the range of settings in relation to inverter active power, reactive power, power factor and grid power frequency. In my own case, our grid voltage is quite high and ranges from 246V - 253V.
Grid frequency also fluctuates quite a bit
Finally, power factor also varies quite a bit
Now this might be perfectly normal behaviour, but I suspect these fluctuations might be the cause of the inverter reset. Of course, I have nothing to compare this against so I’d be interested to see how your grid supply behaves, if only to discount this from the investigation.
For now, I do exactly as you suggest above and try to pre-empt this behaviour by avoiding predicted reset times.
These are straight timeout failures; you can see they’re 3 seconds after the coordinator timeout is X message. The inverter is not responding at all so the connection attempt times out.
This is an active rejection of the TCP connection; it happens without delay after the coordinator timeout message. At this point the inverter is “up” but not accepting connections.
Last year I was having an issue where my inverter would reset (crash) every time a threshold was exceeded when I had set an export limit.
Some of these ‘advanced’ features don’t get broad usage so you can identify corner cases that slip through testing.
Anyway after a firmware upgrade the problem hasn’t reappeared for the last 12 months so it seemed to have fixed it, but of course nothing mentioned in the release notes.
You might want to try different firmware version?
1 Like
Worth a try I guess.
There’s another constant in class ModbusDefaults in const.py that anyone with write failures might want to try, although it will only work with “short” errors not the very long 60+ second inverter resets.
For values of ReconnectDelay:
ReconnectDelay = 0 # Minimum in seconds.milliseconds before reconnecting.
Try setting a value other than 0 such as ReconnectDelay = 0.1
However keep in mind that I disabled (set to 0) this feature of pymodbus because it didn’t work properly with Home Assistant async and so I’ve left it disabled ever since.
My inverter also “resets” twice a day, however it’s not always at the same time.
Today it was 4:33 AM and 6:27 PM
Yesterday night it was 3:26 AM at night. The log doesn’t let me go back further.
I got one idea for a “workaround”:
If you want to stop the Inverter from discharging the battery at night, you could simply set it to “Solar Power Only (Off)” after sunset with an Automation. But you have to change the Storage Command Mode AND the Storage Default Mode, because the Storage Default Mode will make sure, that it continues to stay on “Solar Power Only (Off)” after the reset(s). In the morning, when the sun rises, you could start an automation that changes it back to “Maximize Self Consumption” (Command & Default Mode) and set the Discharge Limit to Zero, until your Solar Power exceeds your Current Consumption.
This way - at least theoretically - you should be able to prevent the Battery from any Discharge at night. I’m currently testing this myself…
Apologies to jump into the middle of the thread but does anyone have an easy to understand (Non-YAML & Non-Solaredge Manual) explanation of each Modbus Multi Selector? ie Grid Control ‘on’ gives you control to set Export Limits etc, and ‘off’ means default which is ???
I’m assuming most Automatons I’m looking to build will be IF; energy price low at this time, then charge battery from grid if battery level is less than ? OR if battery level greater than ? and spot price is above X then discharge to grid. Otherwise, set solaredge solution to BAU.
There seems to be overlapping functions such as Export Limits and Active Power %. Or maybe not.
Happy to do the automation’s, but just don’t know what ‘Actions’ I should be doing to achieve control of the import / export, or indeed can I exceed my export rate etc, or anything else I should not be doing. Thanks in advance.
I think I have a working solution now for my winter mode (keep the BYD LVS battery at 39/40% SOC) without having major discharges. Now the inverter even goes to sleep at night (which saves some Energy).
If anyone is interested, I can post and explain my automations in the coming days.
Hi there, every time I’m using this integration I’m getting the following error one time:
This error originated from a custom integration.
Logger: custom_components.solaredge_modbus
Source: custom_components/solaredge_modbus/__init__.py:232
Integration: SolarEdge Modbus
First occurred: 17:47:49 (1 occurrences)
Last logged: 17:47:49
Error reading modbus data
Traceback (most recent call last):
File "/home/homeassistant/.homeassistant/custom_components/solaredge_modbus/__init__.py", line 232, in async_refresh_modbus_data
update_result = self.read_modbus_data()
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/homeassistant/.homeassistant/custom_components/solaredge_modbus/__init__.py", line 307, in read_modbus_data
self.read_modbus_data_inverter()
File "/home/homeassistant/.homeassistant/custom_components/solaredge_modbus/__init__.py", line 593, in read_modbus_data_inverter
inverter_data = self.read_holding_registers(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/homeassistant/.homeassistant/custom_components/solaredge_modbus/__init__.py", line 291, in read_holding_registers
return self._client.read_holding_registers(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/srv/homeassistant/lib/python3.11/site-packages/pymodbus/client/mixin.py", line 102, in read_holding_registers
return self.execute(
^^^^^^^^^^^^^
File "/srv/homeassistant/lib/python3.11/site-packages/pymodbus/client/base.py", line 177, in execute
if self.use_sync:
^^^^^^^
File "/srv/homeassistant/lib/python3.11/site-packages/pymodbus/transaction.py", line 168, in execute
response, last_exception = self._transact(
^^^^^^^^^^^^^^^
File "/srv/homeassistant/lib/python3.11/site-packages/pymodbus/transaction.py", line 313, in _transact
result = self._recv(response_length, full)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/srv/homeassistant/lib/python3.11/site-packages/pymodbus/transaction.py", line 343, in _recv
read_min = self.client.framer.recvPacket(min_size)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/srv/homeassistant/lib/python3.11/site-packages/pymodbus/framer/base.py", line 77, in recvPacket
return self.client.recv(size)
^^^^^^^^^^^^^^^^^^^^^^
File "/srv/homeassistant/lib/python3.11/site-packages/pymodbus/client/tcp.py", line 210, in recv
ready = select.select([self.socket], [], [], end - time_)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/srv/homeassistant/lib/python3.11/site-packages/pymodbus/client/tcp.py", line 257, in _handle_abrupt_socket_close
if data:
pymodbus.exceptions.ConnectionException: Modbus Error: [Connection] ModbusTcpClient(192.168.0.154:502): Connection unexpectedly closed 4.291534423828125e-05 seconds into read of 8 bytes without response from slave before it closed connection
Apart of that, it works fine. Is there anything I can do the elimiate this error?
Look a couple of posts above yours - e.g. to this one. Follow the answers down. I have a longer one with some logging-experiments here.
I have tried a couple of things like the author of this plugin suggests here. But have concluded in the end that my inverter likes to reset itself twice a day, which makes the connection fail - and there is nothing I can do about it, except work around the problem in my automations. I don’t mind the error-message particularily much - but the inverter also resets some internal states, which I then have to set again (e.g. battery discharge state). This is a bit of a pain, but you can work around that by reacting in your automations to the inverter posting its values again to the sensors.
1 Like
You actually aren’t using my integration. To avoid those errors I recommend trying my integration which is SolarEdge Modbus Multi.
1 Like
You are so right, I am sorry! I’m using
https://github.com/binsentsu/home-assistant-solaredge-modbus
and not your
https://github.com/WillCodeForCats/solaredge-modbus-multi
Let me change that! 
I see this dashboard approach uses the power values retrieved from Solaredge.
I have this running for more than a year, but the difference with the Solaredge app is quite big.
I am now trying to achieve the same by using the retrieved energy values. Did anybody already achieved this?
I am still struggling to calculate the real solar production.
My battery is sometimes charging from the grid, and that makes it difficult
1 Like