Multiple drops of communication #210
Comments
|
When you say entire system unresponsive, do you mean home assistant becomes unresponsive and won't let you interact with it? If yes then that's exactly what I have noticed too. I just got the inverter, installed the integration and my system started to lag/fail to connect/etc Removing the integration gets rid of this. I unfortunately don't have logs right now. I'll try to post something tomorrow if I can get it. |
|
I'm experiencing the same issue. 2023-12-03 13:21:34.999 WARNING (SyncWorker_2) [homeassistant.loader] We found a custom integration solaredge_modbus which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant |
|
the logs from the topic opener seem to be a network issue: This is the Error logged for Modbus: But there are also similar issues for other integrations: There is also the question:
--> You can get the information when using the Core-Integration (connected to the Web API) - they are provided as attributes within the "Inverters" Sensor: 
That's pretty sure either a network issue, or something with the inverter (Firmware) - but not a general issue with the integration itself. |
|
This is my inverter:
|
|
So you are connected via WiFi... At least, that would rule Out one possible source |
|
Unfortunately I can not. Inverter and router are separated by a wall, without doors or windows, and I have no way to pass an ethernet cable, except through the pipes where the electrical cables pass, and in that case the operation would be complex |
|
The Problem is, that there were issues in the past where the Inverter caused disconnects when it was connected via WiFi. Such disconnects are hard to identify - at least, it's unlikely that they are caused by the Integration itself. You might also get in contact with the Solar Edge Support to Check this from the Inverter Side. |
|
Yes, I confirm - there is a serious issue with these hiccups. Whole HA Core becomes unavailable for 30 seconds. It makes whole HA installation very unstable... I started to monitor this unstability with Uptime Kuma, and sensor loads HA webpage. Here's how it looks like on a fresh HA installation (Docker container) with only SolarEdge Modbus integration installed (nothing else at all): 
Those vertical red lines are the moments when HA is unavailable. And here's as a contrary example fully loaded HA instance with no SolarEdge Modbus integration: 
I've spent last couple of that trying to filter out which integration causes such instability... Of course ping to HA host works all the time, only 'homeassistant' container is blocker and freezes. |
|
I think the reason is that the sensor values are currently updated within the main HA thread. As long as there is a quick and stable connection towards the inverter this does not pose a problem. But if connecting/getting the values takes a considerable amount of time, the HA main thread is occupied long enough so it becomes visible through for example unresponsive UI. I'll check if the updating can be offloaded to a HA executor job |
|
Upgrading from 2023.8.4. to 2023.12.3 makes HA slow in responding. Same messages in log as descibed by Mauriziosacca. Doubt if it has anything to do with the network, given that all other integrations work as designed and I don't see any wierd network behaviour. Re-installing the plug-in doesn't solve the problem. The moment you disable the plug-in, the issues dissapear. Making the interval period longer gives some releave but problems don't dissapear. |
I've got the same problem here, for now i've just disabled the integration for now. |
|
This is the log file from my homeassistant instance. And this is another behavior, it acts like it works, but drop the connection after 1s |
|
Could you try version V1.10.2 if it's any better? |
|
@binsentsu I think it would be wise to wait a bit for a final result, it's been only few hours since I updated to v1.10.2 but it already looks so much BETTER. Take a look at screen below to see how whole HA web gui (and main core at the same time) stabilizes after update. I will let you know in a day or two the result in longer period of time. The spike at 4:51 was just before updating (couldn't sleep at night ;-) - after that the graph is flat and this is what we are looking for!). 
|
|
The change probably properly fixes #100 |
Yes, 100% sure it should - what I'm measuring exactly is UI responsiveness (this sensor loads HA login webpage, so it comes from main 'homeassistant' container). State for now, the fix relieved UI in 100%. I've updated this integration around 5 am, and until now 24h average response time is improving dramatically toward positive side (was 32ms, is already 21ms, it should be completely flat tomorrow morning): 
|
|
There is a clear improvement. I have the update running now for 7 Hours and only have 5 missed communications where I had 35 before so 7* better. It is still not zero let’s see how it evolves.
Oscar H.M. De Vries
***@***.***
… Op 4 jan. 2024 om 18:01 heeft TroLoos ***@***.***> het volgende geschreven:
The change probably properly fixes #100
Yes, 100% sure it should - what I'm measuring exactly is UI responsiveness (this sensor loads HA login webpage, so it comes from main 'homeassistant' container).
State for now, the fix relieved UI in 100%. I've updated this integration around 5 am, and until now 24h average response time is improving dramatically toward positive side (was 32ms, is already 21ms, it should be completely flat tomorrow morning):
Screenshot.2024-01-04.at.17.58.05.png (view on web)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
|
Yes, definitely now it works as expected:
Avg. Response for 24-hour time period went down from initial 142ms (2 weeks ago) to 7ms (full day after upgrade to newest version). Since working thread is now a separate from core HA, perhaps it would be a good idea to give SolarEdge a little bit more time to answer the call? This integration still generates quite a lot of warning/error related to connectivity issues. I think it is not really a matter of device availability on WiFi network (ping works 100% of the time) but rather exclusive access to TCP port 1502. Even if I setup to poll SolarEdge every 30s (or every 5s) - it doesn't make a difference, errors and warnings still appear in a pretty much same amount. I guess it is a matter of handling TCP connection. |
|
@TroLoos Can you share latest logging with connection errors? |
|
@binsentsu actually, turns out that my WiFi link to inverter isn't that solid as I thought... and I guess this is a problem showing up in my logs. I will change the antenna to something better and see if it help. For now - I think this issue has been successfully resolved. Thank you for your support! |
Hello I am using the Solar edge integration now for 4 weeks and found it to be a good integration. It dos however create multiple errors in my log and I have not got proof but it seems to make the total system unstable. 172.116.0.114 is my Soloar edge controller.
Here is a copy of part of the log which I see regularly:
File "/usr/local/lib/python3.11/site-packages/pymodbus/client/tcp.py", line 262, in _handle_abrupt_socket_close
raise ConnectionException(msg)
pymodbus.exceptions.ConnectionException: Modbus Error: [Connection] ModbusTcpClient(172.116.0.114:1502): Connection unexpectedly closed 0.00030922889709472656 seconds into read of 8 bytes without response from slave before it closed connection
2023-10-27 20:20:05.767 ERROR (MainThread) [pymodbus.logging] Connection to (172.116.0.114, 1502) failed: [Errno 113] Host is unreachable
2023-10-27 20:20:05.768 WARNING (MainThread) [custom_components.solaredge_modbus] not able to connect to 172.116.0.114:1502
2023-10-27 20:21:01.766 ERROR (MainThread) [pymodbus.logging] Connection to (172.116.0.114, 1502) failed: timed out
2023-10-27 20:21:01.769 WARNING (MainThread) [custom_components.solaredge_modbus] not able to connect to 172.116.0.114:1502
2023-10-27 20:21:18.219 WARNING (MainThread) [haffmpeg.core] Timeout while waiting of FFmpeg
2023-10-27 20:32:29.353 WARNING (MainThread) [homeassistant.components.websocket_api.http.connection] [140293215605440] from 172.116.0.102 (Home Assistant/2023.7 (io.robbie.HomeAssistant; build:2023.471; iPadOS 15.8.0)): Disconnected: Did not receive auth message within 10 seconds
2023-10-27 21:59:04.269 WARNING (MainThread) [homeassistant.components.sonos.speaker] No recent activity and cannot reach Woonkamer, marking unavailable
2023-10-27 21:59:45.612 WARNING (Thread-5) [pychromecast.socket_client] [Huiskamer(172.116.0.11):8009] Heartbeat timeout, resetting connection
2023-10-27 22:00:15.624 ERROR (Thread-5) [pychromecast.socket_client] [Huiskamer(172.116.0.11):8009] Failed to connect to service ServiceInfo(type='host', data=('172.116.0.11', 8009)), retrying in 5.0s
2023-10-28 06:20:13.652 ERROR (MainThread) [custom_components.solaredge_modbus] Error reading modbus data
Traceback (most recent call last):
File "/config/custom_components/solaredge_modbus/init.py", line 232, in async_refresh_modbus_data
update_result = self.read_modbus_data()
What can it be?
The text was updated successfully, but these errors were encountered: