MickMake / GoSungrow

GoLang implementation to access the iSolarCloud API updated by SunGrow inverters.
https://mickmake.com/
GNU General Public License v2.0
148 stars 42 forks source link

cannot install add-on #110

Open smpillai11 opened 3 months ago

smpillai11 commented 3 months ago

Failed to install add-on Unknown error, see supervisor logs

Logger: homeassistant.components.hassio Source: components/hassio/websocket_api.py:138 integration: Home Assistant Supervisor (documentation, issues) First occurred: 12:26:06 AM (2 occurrences) Last logged: 12:28:21 AM

Failed to to call /addons/ba22da74_gosungrow/install -

bbkinghun commented 2 months ago

Failed to install:

The command '/bin/ash -o pipefail -c chmod a+x /usr/local/bin/setup.sh && /usr/local/bin/setup.sh' returned a non-zero code: 1

Paraphraser commented 2 months ago

That's not really a lot to go on but, taking it at face value and making an educated guess, please see the screenshot.

IMG_2522

Is that GoSungrow: FAILED to install, please raise a GitHub issue. the message you actually saw?

If yes then, from the code, you can see that the checkExit() function is called after the two calls to apk. In my experience, the two most common reasons why apk running inside a Docker container fails is (a) a transient issue or (2) because of a DNS problem.

If it's transient then retrying may eventually solve the problem.

The situation is more complicated if it's the DNS. Containers running in non-host mode (like GoSungrow) are set up (by Docker) to use a resolver at 127.0.0.11 (a "magic" address claimed by Docker for the purpose) and, in effect, that tells the container to use the host's resolver which, in the case of HA, means the hassio_dns container. After that, I don't know but at some point, that hassio_dns container must learn which upstream DNS servers to use - presumably from DHCP when the HA host boots.

The most common arrangement for home networks is your router boots, connects to your ISP, and learns the IP addresses of your ISP's preferred DNS servers; and those get passed to LAN-side clients (like Home Assistant) in DHCP requests.

Where the problem seems to be is that the hassio_dns container issues recursive queries when trying to discover the IP address of the server(s) that can answer questions from apk. Many ISPs disallow incoming recursive queries. I've never understood why they do that. They just do. It's not just HA that has this problem. I've also seen it when PiHole is running in a container and is also the designated DNS server for the host on which PiHole is running - and it is triggered when Alpine-based containers like Mosquitto and Node-RED invoke apk.

The most reliable solution I've found is to override the router's DNS servers with the Google servers 8.8.8.8 and 8.8.4.4. Most routers have two places for configuring DNS servers: (1) the servers the router uses when issuing its own queries, and (2) the servers the router issues to clients in DHCP responses. It's best to make both use the Google servers.

I can't guarantee that I've either diagnosed your problem correctly or that using the Google servers will fix the problem in your situation. It's just something to try.

Hope this helps.