Hangs on 'asyncio.open_connection' #274
Comments
|
I updated my system to the the latest (b5b9ada) and see also problems:
|
|
I reverted back to d30089e which was the previous version that I was successfully running. Quick glance shows that now the integration created new entities (with _2 postfix). Need to investigate further. |
|
Hi @sofkaski, would you be willing to do the update to the latest, enabled debug logging, and restart HA w/ debug logging enabled and provide the log file? It would be very helpful! |
Here is the log for the first minute after restart. I hope this reveals already useful information. |
@davidrapan : Note that this is now the second time the new version is used since I reverted back after the first attempt. And the revert did not go well either. |
|
You should have remove and re-add back device so it clears out those duplicates. |
|
@realkibou, please I need you to enable debug logging then remove and re-add your device back. Wait until your sensors are 'unavailable', stop the debugging and attach the file here. Thank you. |
|
error_log-1.txt |
|
Whoa... 🤯 So you are saying that re-adding the device helps? And what about reload under that 3 dots menu? Could you also record the log w/ device remove and re-add back after that connections loss? |
|
Reloading it also helps. I have a suspicion that is becomes unavailable once I log into my inverter with the Deye app. But also that is inconsistent. |
|
What's the logger's firmware? |
|
Inverter: V0.2.0.1 3385-1515 0000-036B |
I have noticed that I get about once or twice a day no-socket-available errors and then timeout in connection, but solarman-ha recovers from that in the next update round nicely. My setup is such that the inverter is hybrid Deye SUN-8K-SG04P3-EU with a logger with firmware version LSW3_15_FFFF_1.0.9E. I have connected it also with Deye cloud. (which I would like to get rid of finally.) My understading is that Deye app does not talk directly to the logger, but the logger pushes data to the Deye cloud and app uses data from there. (Remote control operations might though talk with the logger directly 🤔 ). |
|
I now updated ha-solarman to 39732bd and everything went fine. Migrations were run. |
|
Yes that's what's proly happening but as you said it should recover. Why it does not work in @realkibou's case is really weird... Anyway, I'm glad it's good for you, @sofkaski. Thanks for the report, really appreciate it. 😉 |
|
I updated to the newest version of Solarman v24.12.02 and also my Deye inverter got an update to HMI: 0000-C372. The bug however persists. But one click on reload and it works for a bit |
|
Hello @githubDante! Me again! Any ideas? |
|
Hi @davidrapan , Something remains hidden here: but it looks like the logger is unavailable. Considering the timestamps probably a NoSocketAvailable error is raised in the call to @realkibou can you try to reach the logger IP address (ping/telnet to port 8899) in such moment, preferrably from the device where ha-solarman is running. |
|
Yes, No Sockat Available does occur once per ~ 5m or so in my case. This hang visible in the log is most likely in Asyncio’s open_connection as I’ve seen it happen but never in this unrecoverable form. Then there is 30s timeout triggered. It would be great if we could see traffic between HA and logger alongside the debug log. |
|
With the latest version 24.12.02 & Python 3.12 the NoSocketAvailable exception is definitely propagated to the log. But ... I managed to achieve the same result It's caused by a firewall dropping the packets to the destination address: in the ha container/machine/device is enough. |
Still the same bug :( |
|
I mean sure if you drop the packets I'd say it should timeout... but how could that happen in his case? Some HA's quirks? @realkibou, could you run a fresh HA installation aside and try it there? |
It could be a router, switch or anything that stands between the datalogger and the client. |
|
Yeah.. that's why I wanted to know if there is any chance that @realkibou heard anything about things like tcpdump and wireshark. 😆 |
|
The inverter is pingable. I just now made an automation that HA just reload the integration. Dirty, but it works. |
|
It's not about inverter but the path between HA and inverter. |
|
|
|
If you could run tcpdump in HA or on the device which hosts HA that would reveal way more. |
|
At 11:47:35 the inverter became unavailable. Here you go: ` ` |
|
192.168.101.3 is definitely not responding to ARP requests, making it unavailable. |
|
Yes it's clear it's not integration's fault. Something on your network is here to blame. Almost reminds me one issue I was experiencing w/ OpenWRT on AX3600, ARP table was not flushed when client reappeared on different network path and packets were still send to their old location. Which is really not the case here as I bet your inverter does not walk around the house, right? 😆 And I proly even know why reload of the integration helps, it's thanks to the discovery which sends broadcast packets at the start so I guess because inverter replies there is then small window for which it works. Anyway w/ the recent changes I implemented feature of rediscovery after every timeout. 😉 But still, I advise you to try to find the culprit! |
davidrapan
added
invalid
Description
The setup with my Deye Inverter SUN-5K-SG03LP1-EU works perfectly. All sensor data etc gets pulled. But after maybe 5 minutes everything switches to 'unavailable'.
Reproduction Steps
I can remove the device, add it again, then I get all the data, but again after 5 minutes or so, it is all 'unavailable' again.
Log
No log
Version
2024.11.3
The text was updated successfully, but these errors were encountered: