Runtime panic and shutdown

[isaacss98]

I have just installed GoSungrow on HA 2025.2.4 core, supervisor 2025.02.1

This is a new install, I have never had this working before. When starting the service discovers the devices but then shuts down with a panic:

2025/02/20 04:17:25 INFO: Connecting to MQTT HASSIO Service...
2025/02/20 04:17:25 INFO: Connecting to SunGrow...
2025/02/20 04:17:25 INFO: Found SunGrow 2 devices
2025/02/20 04:17:25 INFO: Caching Sungrow metadata...
2025/02/20 04:17:25 INFO: Cached 434 Sungrow data points...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc8 pc=0x8c633f]

I don't know what to do from here.

Thanks

[phatz]

Having the same issue here. First time installation of GoSungrow (and Home Assistant in general).

HA Version installed:
Core 2025.4.1
Supervisor 2025.03.4

Error as reported in the log:

[14:28:38] INFO: Syncing data from gateway https://gateway.isolarcloud.eu ...
2025/04/05 14:28:39 INFO: Connecting to MQTT HASSIO Service...
2025/04/05 14:28:39 INFO: Connecting to SunGrow...
2025/04/05 14:28:39 INFO: Found SunGrow 3 devices
2025/04/05 14:28:39 INFO: Option[homeassistant/select/GoSungrow/GoSungrow-option-mqtt_loglevel/cmd] set to 'enabled'
2025/04/05 14:28:39 Unknown log level, setting to default.
2025/04/05 14:28:39 INFO: Caching Sungrow metadata...
2025/04/05 14:28:39 INFO: Cached 496 Sungrow data points...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc8 pc=0x8c55f3]

Thanks.

[Paraphraser]

I'm running Core 2025.4.1 Supervisor 2025.03.4 Operating System 15.1 Frontend 20250404.0 without issues. Can I ask if you are sure that you followed all of the steps in gist part 2?

[phatz]

I'm running Core 2025.4.1 Supervisor 2025.03.4 Operating System 15.1 Frontend 20250404.0 without issues. Can I ask if you are sure that you followed all of the steps in gist part 2?

Thank you for your reply.

I hadn't gone through the steps in gist part 2 initially, but I did so after you mentioned it, and still getting the same error.

~ # docker images | grep -e REPOSITORY -e gosungrow
REPOSITORY TAG IMAGE ID CREATED SIZE
ba22da74/amd64-addon-gosungrow 3.0.7-backup 5ead80174d6a 19 hours ago 118MB
ba22da74/amd64-addon-gosungrow 3.0.7 f2cbc9418287 16 months ago 161MB
triamazikamno/amd64-addon-gosungrow 3.0.7 f2cbc9418287 16 months ago 161MB
~ #

Restarting the add-on within the web browser, I see the following docker image running, which is the correct one (patched):
CONTAINER ID IMAGE
7fa2f6a982a4 ba22da74/amd64-addon-gosungrow:3.0.7

Running software versions:
Core 2025.4.1
Supervisor 2025.03.4
Operating System 15.1
Frontend 20250404.0

Log file of the error:

Token File: /data/.GoSungrow/AppService_login.json
[06:13:05] INFO: Syncing data from gateway https://gateway.isolarcloud.eu ...
2025/04/06 06:13:05 INFO: Connecting to MQTT HASSIO Service...
2025/04/06 06:13:05 INFO: Connecting to SunGrow...
2025/04/06 06:13:05 INFO: Found SunGrow 3 devices
2025/04/06 06:13:05 INFO: Option[homeassistant/select/GoSungrow/GoSungrow-option-mqtt_loglevel/cmd] set to 'enabled'
2025/04/06 06:13:05 Unknown log level, setting to default.
2025/04/06 06:13:05 INFO: Caching Sungrow metadata...
2025/04/06 06:13:05 INFO: Cached 496 Sungrow data points...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc8 pc=0x8dad53]
.
.
.
[truncated output]

I can't seem to figure out what's going on. I'll try and find out the actual commands HA add-on is using so I can run them outside HA using the patched binary, and if that fails, I'll try reinstalling a fresh HA instance and try the add-on installation from the beginning.

Any ideas are welcome, thanks.

[Paraphraser]

Sorry but I can't really help with this. MickMake (the repo owner) has been silent for a very long time. Unless someone with the requisite Go skills, the time and motivation steps up and forks the repo, I doubt that problems like this will ever get solved.

My guess (and it is no more than that) is that something about your Sungrow hardware is sufficiently different from mine as to cause the GoSungrow code to follow a different path, the result being that yours crashes while mine doesn't.

My usage of the HA container is minimal. I have only gone far enough to write that gist I pointed you at before. And the only reason I did that was because my own non-HA usage also broke. The way I use GoSungrow is explained here. Whether that approach would help you...