Paraphraser/Compiling GoSungrow.md

Last active March 18, 2026 00:42

Star (19) You must be signed in to star a gist
Fork (1) You must be signed in to fork a gist

Select an option

Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/Paraphraser/cad3b0aa6428c58ee87bc835ac12ed37.js"></script>
Save Paraphraser/cad3b0aa6428c58ee87bc835ac12ed37 to your computer and use it in GitHub Desktop.

Download ZIP

Compiling GoSungrow

Raw

Compiling GoSungrow.md

Updating GoSungrow

This gist is intended to help you deal with the following error conditions:

Error: appkey is incorrect 'er_invalid_appkey
Error: unknown error 'Request is not encrypted'
nil pointer exceptions while fetching battery information
missing device_type arguments

Home Assistant log errors with wording like:

 The configuration uses the deprecated option object_id to set the default entity id. Replace with default_entity_id

This gist has a number of parts which, because of the way in which this gist has grown over time, are not necessarily in a logical order.

The instructions you should follow depend on what you want to do:

Part	Explains how to
Part 1	recompile GoSungrow from its source code. This includes the patches that solve all the error conditions listed above.
Part 2	removed - this approach will stop working in Home Assistant Core 2026.4.
Part 3	use a pre-compiled patched binary outside of Home Assistant. This lets you run GoSungrow from your Terminal command line.
Part 4	use a pre-built Docker image outside of Home Assistant.
Part 5	patch the broken Docker add-on for use in Home Assistant.

Parts 2, 3 and 4 are independent do not require you to follow the steps in Part 1 and recompile GoSungrow yourself. The instructions in these parts assume you are using one of the triamazikamno images as your starting point. However, the final result only deals with the "appkey is incorrect" and "request is not encrypted" errors.

Part 5 depends on you first recompiling GoSungrow yourself by following the steps in Part 1. Part 5 then explains how to construct a new add-on image for Home Assistant which includes the recompiled binary. The result deals with all four error conditions listed above.

about this gist

The reason this gist has a multi-part structure is historical.

The first version of this gist answered the question, "how do I recompile GoSungrow from its source code?" That material became Part 1.

Part 2 went through several revisions including using a Dockerfile plus the results of recompiling as per Part 1 to produce a new local image for Home Assistant. When triamazikamno provided patched Docker images, Part 2 was replaced with simpler (!) instructions.

Part 3 was added following a suggestion by xpufx which further leverages the work done by triamazikamno and avoids the need for recompiling GoSungrow from its source code.

Part 4 was added following a comment by Lmecano which identified a use-case for deploying the Docker images outside of the confines of Home Assistant.

Part 1 was amended to explain how to include pull requests 108, 137 and 138, alongside the fixes from the triamazikamno encryption branch.

Part 5 was added so that the "fully patched" binary could be used in Home Assistant, effectively replacing Part 2.

So long as you do not encounter either the nil pointer exceptions while fetching battery information or missing device_type arguments problems, Parts 2, 3 and 4 remain valid.

Part 1 — Compiling GoSungrow

These instructions have been tested on macOS (Darwin) and Raspberry Pi OS (Debian). The Go compiler can be installed on Windows but I don't have any way of testing that.

Assumptions

git is installed.
wget is installed.

Using your Home Assistant instance to recompile GoSungrow

If you are recompiling GoSungrow so that you can then proceed to Part 5 and rebuild the Home Assistant GoSungrow add-on, you can follow these Part 1 instructions on either a support host (Linux, macOS, Windows), or your Home Assistant instance using the Advanced SSH & Web Terminal.

The advantages of compiling on your HA instance are:

the Go compiler will compile for the correct hardware architecture automatically. You will not have to worry about cross-compiling to account for any differences between your support host and the hardware on which your Home Assistant instance is running; and
the compiled binary will already be on your HA instance so there will be no need to try to figure out how to copy the binary from your support host onto your HA instance.

The disadvantages are:

the specs for support hosts tend to be "big and beefy" whereas Home Assistant is typically deployed on Watts-conserving hardware. This means that compilation will be fairly slow (minutes); and
the "scaffolding" you put in place (the Go compiler and the GoSungrow source tree) will disappear the next time the Advanced SSH & Web Terminal add-on is re-created.

Given that you are unlikely to be doing this every day, the advantages may well outweigh the disadvantages. It's up to you to decide.

Prepare your system (Linux+macOS)

Create the "go" sub-directory in your home directory:
```
$ mkdir -p ~/go
```
Add the following lines to your ~/.bashrc or ~/.profile as is your preference:
```
#=======================================================================
# Senses if the go compiler is installed
#=======================================================================

GO_BIN=/usr/local/go/bin
if [ -x "$GO_BIN/go" ] ; then
   export GOPATH="$HOME/go"
   export PATH="$PATH:$GO_BIN:$GOPATH/bin"
fi
unset GO_BIN
```
Tips:
- If you copy/paste into a Windows text editor, make sure your editor saves with Unix (␊ : 0x0A) line endings, rather than Windows (␍␊ 0x0D 0x0A). Alternatively, use a tool like dos2unix to post-process the file.
- If you are doing all this on your Home Assistant instance, you must use ~/.profile.

Install/Update Go compiler

Linux (including your Home Assistant instance)

Open your browser at the Go downloads page.

Choose an appropriate image. Example:

$ URL=https://go.dev/dl/go1.26.1.linux-amd64.tar.gz
$ TARGZ=$(basename $URL)

Also make a note of the SHA256 checksum and assign it to a variable. Example:
```
$ HASH=031f088e5d955bab8657ede27ad4e3bc5b7c1ba281f05f245bcc304f327c987a
```
Download the image:
```
$ wget $URL
```

Verify the checksum:

$ sha256sum -c <<< "$HASH *$TARGZ"
go1.26.1.linux-amd64.tar.gz: OK

Install the compiler (replacing any older version):

$ sudo rm -rf /usr/local/go
$ sudo tar -C /usr/local -xzf $TARGZ

macOS

Open your browser at the Go download and install page.
Click the "Download" button, then pick the correct installer (ARM64 for Apple Silicon, x86-64 for Intel silicon).
Run the installer package from your Downloads folder. This installs/updates as appropriate.

Tip:

If you have an older version of Go installed via HomeBrew, you can remove it with:
```
 $ brew uninstall go
```
HomeBrew does not install the Go compiler in /usr/local/go/bin. You will need to adapt the login script commands if you want to use HomeBrew to install/update Go.

Windows

See download and install page.

Confirm compiler installation (Linux+macOS)

Logout and login again so the new login script commands run.
Confirm that GOPATH returns a sensible result:
```
$ echo $GOPATH
/home/pi/go
```

Confirm that the compiler is present:

Linux:

 $ go version
 go version go1.26.1 linux/amd64

macOS:

 $ go version
 go version go1.26.1 darwin/amd64

Compile GoSungrow

Check that Git knows who you are:
```
$ git config user.name
$ git config user.email
```
If you get null or silly answers (eg the second command returns user.name) then please run the following commands, substituting appropriate values for your name and email address:
```
$ git config --global user.name "«yourNameHere»"
$ git config --global user.email "«yourEmailAddressHere»"
```
The values you supply here do not have to be valid. They do not get sent anywhere. What these commands do is initialise ~/.gitconfig. If you have been using Git for any length of time, that file will almost certainly exist already.
Construct the following directory structure:
```
$ mkdir -p ~/go-projects/MickMake
```

Clone the GoUnify repository:

$ cd ~/go-projects
$ git clone https://github.com/MickMake/GoUnify.git

Clone the GoSungrow repository:

$ cd MickMake
$ git clone https://github.com/MickMake/GoSungrow.git

Move into the GoSungrow directory:
```
$ cd GoSungrow
```

Apply various patches:

Point to the triamazikamno fork of the GoSungrow repository and fetch the encryption branch from that fork:

 $ git remote add -t encryption triamazikamno https://github.com/triamazikamno/GoSungrow.git
 $ git fetch triamazikamno encryption

Fetch various Pull Request branches which have been submitted to the GoSungrow repository:

 $ git fetch origin pull/108/head:PR108
 $ git fetch origin pull/137/head:PR137
 $ git fetch origin pull/138/head:PR138
 $ git fetch origin pull/144/head:PR144

Create a local branch to hold the results of merging the various patches
```
 $ git checkout -b patch-set
```

Merge the patches in date order:

$ git merge -m "apply PR108" PR108
$ git merge -m "apply triamazikamno/encryption" triamazikamno/encryption
$ git merge -m "apply PR137" PR137
$ git merge -X theirs -m "apply PR138" PR138
$ git merge -m "apply PR144" PR144

PR138 causes a conflict (with some comment lines) so the -X theirs option tells Git to prefer the incoming pull request.

Compile GoSungrow for your native architecture:
```
$ go mod tidy
$ go build
```
Both commands can take time to complete. Compiling GoSungrow depends on the clock speed of your hardware and the number of CPU cores available. Please be patient!

If the hardware architecture of your support host differs from that of the host where you want to deploy GoSungrow then you will need to cross-compile for your final target platform. One example might be where your support host uses an Intel chip while your Home Assistant instance is running on an ARM chip (eg Raspberry Pi). Cross-compiling is explained later.

Check your work

The next three steps tell you to run GoSungrow like this:

./GoSungrow

The ./ prefix means "run the just-recompiled binary from the working directory". Please do not make the mistake of omitting the ./ prefix because that risks executing an older version of GoSungrow that does not have any of the patches.

1. Confirm GoSungrow compiled

$ ./GoSungrow version
GoSungrow v3.0.7
Self-manage this executable.

Usage:
  GoSungrow version
  GoSungrow version [command]

Examples:
	GoSungrow version  


Available Commands:
  check                   Version	- Check and show any version updates.
  list                    Version	- List available versions.
  info                    Version	- Info on current version.
  latest                  Version	- Info on latest version.
  update                  Version	- Update version of this executable.

Flags: Use "GoSungrow help flags" for more info.

Additional help topics:

Use "GoSungrow version help [command]" for more information about a command.

2. Update the APPKey

If you followed the optional step to apply the patches, you will also need to update the APPKey on any system where you intend to run GoSungrow. See APPKey configuration.

3. Set your gateway (optional)

Follow the instructions to set your iSolarCloud gateway configuration.

4. Confirm success

You can confirm everything is working by running:

$ ./GoSungrow api login
Email:	you@yourdomain.com
Create Date:	Thu Feb 09 13:14:55 CST 2023
Login Last Date:	2023-12-07 12:42:57
Login Last IP:
Login State:	1
User Account:	something
User Id:	999999
User Name:	someone
Is Online:	false
Token:	999999_99999999999999999999999999999999
Token File:	/home/pi/.GoSungrow/AppService_login.json

Cross-compiling

This section is optional. If you don't need to cross-compile, skip down to using the recompiled binary.

I want to run GoSungrow on a Raspberry Pi. Although I can install the Go compiler (as above) and compile GoSungrow on the Pi, it is much faster to do the work on macOS. All these commands are run on macOS:

Cross-compile for 64-bit Raspberry Pi OS:

$ GOOS=linux GOARCH=arm64 go build -o GoSungrow-linux-arm64

I am told that the Windows powershell equivalent of the above is:

$env:GOOS="linux"; $env:GOARCH="arm64"; go build -o GoSungrow-linux-arm64

Copy compiled binary to target Raspberry Pi system ("iot-hub"):

$ scp GoSungrow-linux-arm64 iot-hub:./GoSungrow
GoSungrow-linux-arm64    100%   90MB  90.0MB/s   00:01

Check result:

$ ssh iot-hub file GoSungrow
GoSungrow: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=T7VxiW_Bb7zpmTzK5Gjk/ek581bp4wUYxRJpI4LW7/67TEDExnbLJooHJ3cURP/8Pi_onP5w88QBDpLdkcP, with debug_info, not stripped

Comparison with "native" compile on macOS:

$ file GoSungrow
GoSungrow: Mach-O 64-bit executable x86_64

Cross-compiling helper script

Copy the script below and paste into a file named build-all.sh:

#!/usr/bin/env bash

compile_for() {

   echo "Compiling for $1/$2"
   GOOS=$1 GOARCH=$2 go build -o GoSungrow-${1}-${2}

}

go clean

compile_for darwin amd64
compile_for darwin arm64
compile_for linux amd64
compile_for linux arm64

if [ -n "$(which lipo)" ] ; then
   echo "Constructing universal binary for macOS"
   lipo -create -output GoSungrow-mac GoSungrow-darwin-amd64 GoSungrow-darwin-arm64
fi

The build-all.sh script should be at the path:

~/go-projects/MickMake/GoSungrow/build-all.sh

Give the file execute permission and run it:

$ cd ~/go-projects/MickMake/GoSungrow
$ chmod +x build-all.sh
$ ./build-all.sh

The result of running the script is four binaries:

GoSungrow-darwin-amd64 for macOS on Intel chips
GoSungrow-darwin-arm64 for macOS on Apple silicon
GoSungrow-linux-amd64 for Linux on Intel chips
GoSungrow-linux-arm64 for Raspberry Pi

If the lipo tool is available, the script also assembles the first two binaries into:

GoSungrow-mac macOS "universal" binary

Using the recompiled binary

There are many ways to use the recompiled binary. About the simplest is to include it in a directory that is in your Unix PATH. The most common pattern for home directories is:

$ mkdir -p ~/.local/bin
$ cp ./GoSungrow ~/.local/bin/.

If the ~/.local/bin directory did not already exist, you may need to logout and login to give your .profile or .bashrc a chance to discover it and add it to your PATH.

Once the binary is in a directory that is in your PATH, you can execute it just by typing the command name (ie without the ./ prefix). For example:

$ GoSungrow api login

Part 2 — removed

If you try to use the patched images provided by triamazikamno, your Home Assistant log will report:

The configuration for entity «thing» uses the deprecated option 'object_id' to set the default entity id. Replace the "object_id": "«value»"' option with "default_entity_id": "«value»" in your published discovery configuration to fix this issue, or contact the maintainer of the integration that published this config to fix this. This will stop working in Home Assistant Core 2026.4

Assuming this means what it says, the triamazikamno variants of GoSungrow will stop working. You now really have no choice but to follow the instructions in Part 1 and recompile the program from its (patched) source code.

Part 3 — Using a patched binary

You can not use this approach if you intend to direct the MQTT feed from GoSungrow to your Home Assistant instance. See the explanation above at Part 2.

However, if you want to use a triamazikamno version of GoSungrow outside of Home Assistant but you do not want to recompile GoSungrow yourself, you can proceed as follows:

Use your browser to open the following URL:
- https://github.com/triamazikamno/GoSungrow/releases/tag/v3.0.7
Scroll down to "Assets" and expand the disclosure triangle if necessary.
Identify the asset which is appropriate to your platform. Examples:
- macOS on Intel = GoSungrow-darwin_amd64.tar.gz
- macOS on Apple silicon = GoSungrow-darwin_arm64.tar.gz
- Linux on Intel = GoSungrow-linux_amd64.tar.gz
- Linux on 64-bit Raspberry Pi = GoSungrow-linux_arm64.tar.gz
Download the asset to your system. You can either do that from within your browser or you can copy the asset URL to your clipboard, then paste it into a wget command. Something like this would get the job done:
```
$ mkdir ~/GoSungrow-patched
$ cd ~/GoSungrow-patched
$ wget https://github.com/triamazikamno/GoSungrow/releases/download/v3.0.7/GoSungrow-linux_arm64.tar.gz
```
Just make sure you use the correct asset URL in the wget command.
Unpack the .tar.gz (a tape archive – sometimes called a "tarball" – with gzip compression):
- On macOS (assuming you asked your browser to do the download), the asset will be in your Downloads folder. Double-clicking the downloaded asset creates a folder of the same base name as the asset and extracts the asset's contents into that folder.
- On Linux (assuming you have just done the wget as above and your working directory is still ~/GoSungrow-patched), you can extract the asset's contents into the working directory like this:
```
 $ tar -xzf *.tar.gz
```
Either way, you wind up with a folder containing the GoSungrow binary plus some other odds and ends which you can ignore.
Complete the following steps from Part 1:
- Check your work
- Using the recompiled binary

Part 4 — Using a patched Docker image

You can not use this approach if you intend to direct the MQTT feed from GoSungrow to your Home Assistant instance. See the explanation above at Part 2.

triamazikamno has provided patched images for GoSungrow on DockerHub. Although the images were intended for use with Home Assistant, they are just Docker images and can also be used outside of Home Assistant.

Initial setup

Create a directory to hold the GoSungrow configuration and its runtime artifacts. These instructions assume the following but the actual directory can have any name and can be located anywhere:
```
$ mkdir -p $HOME/GoSungrow
```

Use the following JSON as a template:

{
  "sungrow_host": "«Host URL»",
  "sungrow_user": "«USERNAME»",
  "sungrow_password": "«PASSWORD»",
  "sungrow_appkey": "«APPKEY»",
  "mqtt_host": "localhost",
  "mqtt_port": "1883",
  "mqtt_user": "",
  "mqtt_password": "",
  "debug": false,
  "sungrow_timeout": 60
}

Edit the JSON:
- "sungrow_host": see iSolarCloud gateway configuration and replace «Host URL» with the appropriate Host URL.
- "sungrow_user" and "sungrow_password": replace both «USERNAME» and «PASSWORD» with your iSolarCloud credentials.
- "sungrow_appkey": see APPKey configuration and replace «APPKEY» with the appropriate key.
- "mqtt_host": the default value of "localhost" assumes the broker is running on the same host as the GoSungrow container but this field can contain a hostname, domain name or IP address.
- "mqtt_port": the default port for MQTT is 1883 so only change this if you know your broker is running on a non-standard port.
- "mqtt_user" and "mqtt_password": default to null strings, which assumes your broker does not check credentials. Set appropriate values if your broker authenticates messages.
- "debug" and "sungrow_timeout": should be left as is.
Save the edited JSON to the path:
```
$HOME/GoSungrow/options.json
```

Running the container

From the following list, choose the image which is appropriate for your host's architecture:

Image	Typical Platform
`triamazikamno/armhf-addon-gosungrow:3.0.7`	Raspberry Pi 3
`triamazikamno/armv7-addon-gosungrow:3.0.7`	Raspberry Pi 4 in 32-bit user mode (kernel mode is irrelevant)
`triamazikamno/aarch64-addon-gosungrow:3.0.7`	Raspberry Pi 4/5 in full 64-bit mode
`triamazikamno/amd64-addon-gosungrow:3.0.7`	Debian guest on Proxmox-VE running on Intel

In the following command, replace «IMAGE» with the image you chose in the previous step:

$ docker run -d --name gosungrow --net=host \
   -v "/etc/ssl/certs:/etc/ssl/certs:ro" \
   -v "$HOME/GoSungrow:/data" \
   «IMAGE»

Execute the command. For example, on a Raspberry Pi 4 running full 64-bit Bullseye or Bookworm, the command would be:

$ docker run -d --name gosungrow --net=host \
   -v "/etc/ssl/certs:/etc/ssl/certs:ro" \
   -v "$HOME/GoSungrow:/data" \
   triamazikamno/aarch64-addon-gosungrow:3.0.7

Notes:

--net=host is only needed to facilitate the use of "mqtt_host": "localhost" in the options.json file. If you run the GoSungrow container as part of a stack in which Mosquitto is also running, you can employ non-host mode and change "localhost" to "mosquitto".
The first -v maps the host's SSL certificates into the container. The container will inherit any changes made by routine updates to your operating system.
When you execute the docker run command on a non-Intel platform, you may see the following message:
```
 WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
```
You can ignore that message. See GoSungrow Issue 32 for more information.

Part 5 — Patching the broken Home Assistant add-on

This part explains how to use the result of Part 1 to patch the existing (broken) GoSungrow add-on:

Assumptions:
- The (broken) GoSungrow 3.0.7 add-on has already been installed on your Home Assistant instance;
- You have configured the add-on. Typically, that means you have to configure:
  - sungrow_host (defaults to https://augateway.isolarcloud.com but will need to be changed for other regions);
  - sungrow_user required
  - sungrow_password required
  - sungrow_appkey you must change this - see APPKey configuration
  - mqtt_host (defaults to core-mosquitto- correct unless you use a different broker)
  - mqtt_port (defaults to 1883 - correct unless you use a different port)
  - mqtt_user required (set up in core-mosquitto)
  - mqtt_password required (set up in core-mosquitto)
- When you try to start the GoSungrow 3.0.7 add-on, it aborts;
- You have used Home Assistant's UI controls to stop the add-on. In other words, the:
```
 Settings » Apps » GoSungrow » Info tab
```
  shows "Start". Please do not proceed if the add-on is constantly restarting.
- You have not previously followed the steps in this part (Part 5).
  
  If you have done Part 5 before, please see Undoing Part 5.
- You do not have any other add-ons installed which have gosungrow in the name. In particular, the presence of GoSungrow2MQTT will cause a mess so please don't proceed if you have that installed.
Refer to Advanced SSH and Web Terminal for instructions on:
- installing the required add-on;
- configuring the add-on;
- starting the add-on; and
- the conventions this gist adopts with respect to the add-on (in particular, that # indicates a command).

Define the following alias (please don't skip this step):

# alias DI='docker images --filter "label=io.hass.name=GoSungrow" --format "table {{.Repository}}:{{.Tag}}\t{{.ID}}"'

You should be able to see the existing (broken) image:
```
# DI
REPOSITORY:TAG                         IMAGE ID
ba22da74/amd64-addon-gosungrow:3.0.7   6763a1a629ba
```
Your output may be slightly different but you should at least be able to identify a line with "gosungrow" and version 3.0.7.

Construct the required variables:

# ba22da74=$(DI | grep "ba22da74/.*-gosungrow:3.0.7 " | awk '{print $1}')
# baseline=$(echo $ba22da74 | awk -F/ '{print"baseline/"$2}')
# patched=$(echo $ba22da74 | awk -F/ '{print"patched/"$2}')

Verify the required variables

# echo -e "ba22da74=$ba22da74\nbaseline=$baseline\npatched=$patched"
ba22da74/amd64-addon-gosungrow:3.0.7
baseline/amd64-addon-gosungrow:3.0.7
patched/amd64-addon-gosungrow:3.0.7

Please make sure those echo commands produce sensible results.

Retag the brpken image. This prevents it from being removed:
```
# docker tag $ba22da74 $baseline
```
Confirm that the tagging has worked by re-running the images command:
```
# DI
REPOSITORY:TAG                         IMAGE ID
ba22da74/amd64-addon-gosungrow:3.0.7   6763a1a629ba
baseline/amd64-addon-gosungrow:3.0.7   6763a1a629ba
```
You can see both repository+tag combinations point to the same ImageID. An ImageID is a hash of the image file so two repository+tag combinations pointing to the same ImageID means they are both pointing to the same image file on disk.
Create a context directory and make it your working directory:
```
# mkdir context
# cd context
```
Here is where things get slightly complicated. Your goal is to copy the compiled binary that you produced in Part 1 so that it winds up in this context directory. The result also needs to be called GoSungrow:
- If you compiled GoSungrow on your HA instance, you only need to move the compiled binary into the context directory. This command should get the job done:
```
 # mv ~/go-projects/MickMake/GoSungrow/GoSungrow . 
```
- If you compiled GoSungrow on your support host, you may be able to use SCP to copy the binary. Here is an example:
```
 # scp «user»@«hostOrIP»:go-projects/MickMake/GoSungrow/GoSungrow-linux-amd64 GoSungrow                                                         
 Password:
 GoSungrow-linux-amd64    100%  100MB  73.8MB/s   00:01
```
  Notes:
  - My Home Assistant instance is running as a Proxmox-VE guest on an old Intel MacBook Pro with so the linux-amd64 variant is what I need. You need to pick the GoSungrow variant that matches your Home Assistant's hardware platform.
  - The Advanced SSH and Web Terminal doesn't support running the SCP in the other direction (pushing from your support host to your Home Assistant instance).
Make sure the Unix permissions are set correctly:
```
# chmod 755 GoSungrow
```
Check the result:
```
# ls -l
total 102572
-rwxr-xr-x    1 root     root     105029473 Dec  8 12:11 GoSungrow
```
The permission flags on the left hand side need to be -rwxr-xr-x. This step is particularly important if you recompiled GoSungrow on a Windows platform.

Create a Dockerfile:

# echo -e "FROM ${baseline}\nCOPY GoSungrow /usr/local/bin/GoSungrow\n" >Dockerfile

Confirm the result:

# cat Dockerfile
FROM baseline/amd64-addon-gosungrow:3.0.7
COPY GoSungrow /usr/local/bin/GoSungrow

Build a new image (which replaces the broken GoSungrow binary with the patched version):
```
# docker build -t ${patched} .
```
Ignore the deprecation warning.
Inspect the result:
```
# DI
REPOSITORY:TAG                         IMAGE ID
patched/amd64-addon-gosungrow:3.0.7    6dd1108599fe
baseline/amd64-addon-gosungrow:3.0.7   6763a1a629ba
ba22da74/amd64-addon-gosungrow:3.0.7   6763a1a629ba
```
Three repository+tag combinations but now we have two distinct images (ie different ImageIDs). In the above:
- 6dd1108599fe is the newly-built (patched) image, while
- 6763a1a629ba is two tags pointing to the same (broken) image.
Change the ba22da74 tag to point to the newly-built image:
```
# docker tag $patched $ba22da74
```
Confirm the result:
```
# DI
REPOSITORY:TAG                         IMAGE ID
ba22da74/amd64-addon-gosungrow:3.0.7   6dd1108599fe
patched/amd64-addon-gosungrow:3.0.7    6dd1108599fe
baseline/amd64-addon-gosungrow:3.0.7   6763a1a629ba
```
This step of using the original repository+tag combination to point to the patched image is what causes Home Assistant to load the patched image rather than the broken image.
Go back to the Home Assistant GUI:
- Double-check that you set the configuration options for the GoSungrow add-on correctly (in particular, that you are using the correct gateway and APPKey).
- Switch to the "Info" tab and click "START".
If HA seems to freeze, try quitting your browser and reconnecting to the GUI. Worst case you may need to restart HA, and then start the GoSungrow add-on again.

Advanced SSH and Web Terminal

To run commands on your Home Assistant instance, you must use the "Advanced SSH & Web Terminal" add-on:

To prepare the add-on for use, go to Settings » Apps » Advanced SSH & Web Terminal. In the:

"Configuration" tab:
- you need to set a username and password. This example uses "hassio" as the username. It turns up in the ssh command below.
"Info" tab:
- "Show in sidebar" should be turned ON.
- "Protection mode" needs to be turned OFF.
- if you changed any settings in either tab, click "RESTART". If you don't see "RESTART" then click "START".

To use the add-on, do one of the following:

Either – from your support host (Linux, macOS, Windows), replace hassio with the username you set in the "Configuration" tab above and connect to your HA instance:
```
 $ ssh hassio@homeassistant.local
```
The prompt you get is:
```
 ~ #
```
The # indicates you are running as root and the ~ indicates that your working directory is root's home directory.
Or – from the HomeAssistant web GUI, click "Terminal". A terminal window opens and the prompt you get is:
```
 ~ $
```
Although the Unix convention is that a $ prompt means "running unprivileged" while # means "running as root", the HA Terminal window is in fact running as root and the working directory is root's home directory.

Whenever this gist gives you commands that should be executed in the Advanced SSH and Web Terminal add-on, the convention is:

a line starting with "#" means "copy/paste everything except the # and press return".
a line that does not start with "#" indicates the expected response from the preceding command.

Any directories or local files that you create via the Advanced SSH and Web Terminal will disappear when the Advanced SSH and Web Terminal add-on restarts. This includes any automatic restart when you reboot your Home Assistant instance. This is the expected behaviour (think of it like a student lab at a university).

Conversely, any Docker images that you install or patch while using the Advanced SSH and Web Terminal add-on will persist.

Configuration

iSolarCloud gateway configuration

Sungrow appears to operate the iSolarCloud servers shown in the table below. There may be more. If you discover another server then please add a comment to this gist and I will update the list.

Clicking a link in the "Web URL" column will take you to a web portal where you can login. The "Host URL" column is the URL you need to use for GoSungrow.

URLs marked with "†" are guesses based on the .eu pattern. Each domain name resolves in the Domain Name System but I have no way of testing whether any gateway other than the Australian host works in practice. If you use one of these servers and are able to confirm the Host URL is correct, please let me know in the comments below.

"Server"	Web URL	Host URL
Chinese	www.isolarcloud.com.cn	https://gateway.isolarcloud.com.cn ^†
European	www.isolarcloud.eu	https://gateway.isolarcloud.eu
International	www.isolarcloud.com.hk	https://gateway.isolarcloud.com.hk ^†
Australian	au.isolarcloud.com	https://augateway.isolarcloud.com

To apply a "Host URL":

If you are using the GoSungrow add-on in Home Assistant:
1. Open the Home Assistant GUI.
2. Click "Settings".
3. Click "Apps".
4. Click "GoSungrow".
5. Click the "Configuration" tab.
6. Enter the Host URL from the table into the sungrow_host field.
7. Click "Save" then follow your nose.

If you are using the GoSungrow binary, run:

 $ ./GoSungrow config write --host "«Host URL»"

Example:

 $ ./GoSungrow config write --host "https://augateway.isolarcloud.com"

If you are editing a JSON configuration file, replace the «Host URL» field with the value from the table:

 {
   "sungrow_host": "«Host URL»",
 }

Example:

 {
   "sungrow_host": "https://augateway.isolarcloud.com",
 }

APPKey configuration

The situation with APPKeys is confusing. Some people report success with one key, other people another key. Below is a list of known keys. Try them in order until you find one that works:

B0455FBE7AA0328DB57B59AA729F05D8
ANDROIDE13EC118BD7892FE7AB5A3F20

If you discover new APPKeys, please let me know and I'll add them to this list.

To apply an "APPKey":

If you are using the GoSungrow add-on in Home Assistant:
1. Open the Home Assistant GUI.
2. Click "Settings".
3. Click "Apps".
4. Click "GoSungrow".
5. Click the "Configuration" tab.
6. Enter the APPKey from the table into the sungrow_appkey field.
7. Click "Save" then follow your nose.

If you are using the GoSungrow binary, run:

 $ ./GoSungrow config write --appkey «APPKey»

Example:

 $ ./GoSungrow config write --appkey B0455FBE7AA0328DB57B59AA729F05D8

If you are editing a JSON configuration file, replace the «APPKEY» field with the value from the table:

 {
   "sungrow_appkey": "«APPKEY»",
 }

Example:

 {
   "sungrow_appkey": "B0455FBE7AA0328DB57B59AA729F05D8",
 }

Undoing Part 5

Suppose you have previously:

Followed part1 to recompile GoSungrow; and then
Followed part5 to patch the Docker image used by Home Assistent.

Now suppose you need to repeat those steps. Such a need might arise if a new pull request or other patch is added to part1.

Before you can repeat part5 successfully, you will need to undo the effect of your previous run.

Proceed like this:

If GoSungrow is running, stop it.
Go into the Advanced SSH & Web Terminal.

Define the following alias:

# alias DI='docker images --filter "label=io.hass.name=GoSungrow" --format "table {{.Repository}}:{{.Tag}}\t{{.ID}}"'

Inspect your system:
```
# DI
REPOSITORY:TAG                         IMAGE ID
ba22da74/amd64-addon-gosungrow:3.0.7   047c79b40187
patched/amd64-addon-gosungrow:3.0.7    047c79b40187
baseline/amd64-addon-gosungrow:3.0.7   6763a1a629ba
```
Focusing on the prefixes in the above:
- baseline/ is the original broken version of GoSungrow;
- patched/ is the result of your previous run of part5; and
- ba22da74/ is the "magic incantation" that makes everything work.
Both ba22da74/ and patched/ point to the same image on disk (Image ID 047c79b40187).

If you don't see this pattern then please stop here because the remaining instructions are likely to do more harm than good. Instead, please try the last resort.

Construct the required variables:

# ba22da74=$(DI | grep "ba22da74/.*-gosungrow:3.0.7 " | awk '{print $1}')
# baseline=$(DI | grep "baseline/.*-gosungrow:3.0.7 " | awk '{print $1}')
# patched=$(DI | grep "patched/.*-gosungrow:3.0.7 " | awk '{print $1}')

Verify the required variables:

# echo -e "ba22da74=$ba22da74\nbaseline=$baseline\npatched=$patched"
ba22da74=ba22da74/amd64-addon-gosungrow:3.0.7
baseline=baseline/amd64-addon-gosungrow:3.0.7
patched=patched/amd64-addon-gosungrow:3.0.7

Please make sure that echo command produces sensible results.

Move the "magic incantation" (ba22da74/) so that it points to the same image as baseline:

# docker tag $baseline $ba22da74

Check your work:

# DI
REPOSITORY:TAG                         IMAGE ID
patched/amd64-addon-gosungrow:3.0.7    047c79b40187
ba22da74/amd64-addon-gosungrow:3.0.7   6763a1a629ba
baseline/amd64-addon-gosungrow:3.0.7   6763a1a629ba

Now, baseline/ and ba22da74/ both point to image ID 6763a1a629ba.

Remove the extraneous image and tag:
```
# docker rmi $patched $baseline
# docker system prune -f
```
Check your work:
```
# DI
REPOSITORY:TAG                         IMAGE ID
ba22da74/amd64-addon-gosungrow:3.0.7   6763a1a629ba
```
You have a single image remaining. This is also the situation you would be in if you told Home Assistant to uninstall GoSungrow, and then re-install it from the App Store.
Checking to see whether you have any older triamazikamno images lying around on your system. Those images were built without an embedded io.hass.name=GoSungrow label so the DI alias will not match those images:
```
# docker images 2>/dev/null | grep -e "^IMAGE" -e "triamazikamno"     
IMAGE                                      ID            DISK USAGE   CONTENT SIZE   EXTRA
triamazikamno/amd64-addon-gosungrow:3.0.7  f2cbc9418287       161MB             0B        
```
If you find one or more such images, remove it/them. For example:
```
# docker rmi triamazikamno/amd64-addon-gosungrow:3.0.7
```
Tip:
- it is usually sufficient to type docker rmi , then the first few letters of the image you want to remove (eg tri), and then press tab. The bash auto-completion system will supply the remainder. The alternative is to use copy/paste.
Tell Docker to clean up any dangling artefacts:
```
# docker system prune -f
```
Now you are ready to re-do Part 5.

The last resort

If you get hopelessly muddled with "images everywhere" and you have no idea how to sort it all out, the simplest approach is to nuke everything and start over:

In the Home Assistant GUI:

Go to Settings » Apps » GoSungrow.
Switch to the Configuration tab and make a note of all your settings.
Switch to the Info tab:
- If the GoSungrow add=on is running, stop it.
- Click "Uninstall".

In the Advanced SSH & Web Terminal:

Run the command:

# docker images 2>/dev/null | grep -e "^IMAGE" -e "gosungrow"

Remove every GoSungrow-related image you see. For example, if the command above returned three images:

IMAGE                                      ID            DISK USAGE   CONTENT SIZE   EXTRA
baseline/amd64-addon-gosungrow:3.0.7       6763a1a629ba       118MB             0B        
patched/amd64-addon-gosungrow:3.0.7        c9d883bb2bd0       224MB             0B        
triamazikamno/amd64-addon-gosungrow:3.0.7  f2cbc9418287       161MB             0B

You would execute these commands:

# docker rmi baseline/amd64-addon-gosungrow:3.0.7
# docker rmi patched/amd64-addon-gosungrow:3.0.7
# docker rmi triamazikamno/amd64-addon-gosungrow:3.0.7

Tell Docker to clean up any dangling artefacts:
```
# docker system prune -f
```

In the Home Assistant GUI:

Re-install GoSungrow.
Re-apply your settings in the Configuration tab.
Do not start the add-on.

Now you are ready to do Part 5.

Change History

2026-03-18
- Added instructions on undoing prior run of Part 5.
2026-03-17
- Adds PR144 to Part 1
- Removes Part 2 (will stop working in Home Assistant Core 2026.4)
- Rewrites Part 5
- Re-tested in both:
  - cross-compiling situation (Intel macOS compiling for AMD64)
  - native compiling situation (AMD64)
2025-12-08
- Incorporate comments from @51iMM - thanks!
- Adds confirmation that recompilation can be done on the HA instance.
2025-12-08
- Adjusts Part 1 to include additional pull requests.
- Adds Part 5 to explain how to construct an updated image for use in Home Assistant using the results of Part 1.
- Relocates material on Advanced SSH and Web Terminal which is now referenced by Parts 1 and 5.
2024-05-02
- Evidence now suggests there is no correlation between iSolarCloud servers and AppKeys. Text adjusted.
2024-05-01
- Consolidate all information about iSolarCloud gateways and APPKeys into a new section and cross-reference existing sections to the consolidated material.
2024-03-15
- Adds Part 4 to leverage existing updated DockerHub images for anyone who wants to run GoSungrow in a Docker container outside of Home Assistant.
2024-03-13
- Adds Part 3 to leverage existing recompiled binaries (which are inputs to the updated DockerHub images) for anyone who simply wants to obtain a patched version of GoSungrow without having to recompile it themselves.
2024-02-28
- Includes reminder to click SAVE when changing settings.
2024-01-30
- Adds reminder to set cloud gateway for non-AU systems.
2024-01-22
- Move go mod tidy before go build.
2024-01-14
- Emphasise need to use ./ prefix when testing the recompiled binary.
- Add short section on using GoSungrow from ~/.local/bin.
2023-12-24 - restructure to make clear the distinction between recompiling and using replacement images in Home Assistant.
2023-12-06 - revise "hack" to clarify that the hack can be applied without opening a connection via SSH.
2023-12-09 - revise "hack" to use images provided by triamazikamno on DockerHub.
2023-12-07 - add steps to recompile from triamazikamno fork to resolve er_invalid_appkey problem:
- Additional step during compilation
- Update the APPKey
2023-11-29 - re-tested using go 1.21.4 on:
- M2 MacBook Pro running macOS Ventura 13.6.2
- Intel Mac Mini running Debian Bookworm guest on Proxmox VE
- Raspberry Pi 4B running Raspberry Pi OS Bullseye
- Raspberry Pi 4B running Raspberry Pi OS Bookworm
2023-09-18 - satisfy GoUnify dependency.

gR-xbY commented Sep 6, 2024 •

edited

Loading

Hello @Paraphraser! Thank you for taking the time to write this excellent gist. I followed all the steps and was able to connect my account. However, it is not finding any devices... but I do have a device linked to this account. Do you know the reason for this?

Token File:	/data/.GoSungrow/AppService_login.json
2024/09/06 20:37:07 INFO: Found SunGrow 0 devices
2024/09/06 20:37:07 INFO: Caching Sungrow metadata...
2024/09/06 20:37:07 INFO: Cached 0 Sungrow data points...
No results found.
No results found.
2024/09/06 20:37:07 INFO: Syncing 1 entries with HASSIO from getPsList.
2024/09/06 20:37:07 INFO: Starting ticker...
2024/09/06 20:37:07 INFO: Fetch Schedule: 5m
2024/09/06 20:37:07 INFO: Sleep Delay:    40s
CU

sharkpunch5 commented Sep 7, 2024

I'm trying both APPKEYs however I get an error with each one

first key gives me - ERROR: not Authorized
2nd key throws - ERROR: unknown error ''

Paraphraser commented Sep 7, 2024

Author

@gR-xbY Well, on the face of it, you have a valid Sungrow account but none of your devices have been attached to the account.

It's 18 months since I got my Sungrow inverter so my memory is a bit hazy but there are two things I recall. First, the installer tried to set things up with the wrong email address. I stopped him before he got too far. Basically he showed me what he had typed in and asked "is that right?" I said "no, and I'd rather do the setup myself".

Second, when doing the setup myself I was following some guide I found on Sungrow's web site which required a few steps to create the account and add everything to it - everything being the inverter, the WiFi dongle, and the inline meter - the same things that show up in GoSungrow when I do a show ps list. I did all the setup work in the iSolarCloud iPad app.

So maybe you have two accounts, and the one you are using doesn't have your equipment attached to it. Or, maybe you've set up the account and haven't done the steps needed to attach your equipment to it.

But please don't ask me for any "how to" for that side of things because I just don't remember and, even were I to dig it out from my archives, the app has changed so much it'd probably be wrong and I'd be sending you up the garden path. Your best bet is to either ask your installer or nose around Sungrow's web site.

Paraphraser commented Sep 7, 2024

Author

@sharkpunch5 I use the B0 key. If I switch to the ANDROID key (or random gibberish), I get:

ERROR: unknown error 'E914'

I have not been able to create the conditions where I get either "not authorized" or ERROR: unknown error '' with no error code between the '' so I suspect that something else is wrong.

Look, to be honest, I've lost count of the number of times someone says they've followed the gist, only to find they missed a critical step so let's take that as our working assumption. Please go into "Advanced SSH and Web Terminal" and run this command:

docker images | grep -e "^REPOSITORY" -e "gosungrow"

and include the output in your reply.

Paraphraser commented Sep 7, 2024

Author

@sharkpunch5 perhaps see also this comment plus the comment immediately following that one.

gR-xbY commented Sep 9, 2024 •

edited

Loading

@gR-xbY Well, on the face of it, you have a valid Sungrow account but none of your devices have been attached to the account.

It's 18 months since I got my Sungrow inverter so my memory is a bit hazy but there are two things I recall. First, the installer tried to set things up with the wrong email address. I stopped him before he got too far. Basically he showed me what he had typed in and asked "is that right?" I said "no, and I'd rather do the setup myself".

Second, when doing the setup myself I was following some guide I found on Sungrow's web site which required a few steps to create the account and add everything to it - everything being the inverter, the WiFi dongle, and the inline meter - the same things that show up in GoSungrow when I do a show ps list. I did all the setup work in the iSolarCloud iPad app.

So maybe you have two accounts, and the one you are using doesn't have your equipment attached to it. Or, maybe you've set up the account and haven't done the steps needed to attach your equipment to it.

But please don't ask me for any "how to" for that side of things because I just don't remember and, even were I to dig it out from my archives, the app has changed so much it'd probably be wrong and I'd be sending you up the garden path. Your best bet is to either ask your installer or nose around Sungrow's web site.

@Paraphraser

The funniest thing is that I'm a solar panel installer here in my region. I have an installer account and a client account, both with the inverter configured correctly (i tried both accounts). I tested the show ps list, and it simply doesn't return anything. What I noticed is that the SolarCloud platform recently had an update. I was looking at the API endpoints, and it seems they have also changed. Is your addon in Home Assistant still working normally after this update?

root@haos:~/go-projects/MickMake/GoSungrow# ./GoSungrow api login
Email:  <replaced>
Create Date:    Fri Sep 06 23:50:25 CST 2024
Login Last Date:        2024-09-09 09:38:58
Login Last IP:
Login State:    1
User Account:   <replaced>
User Id:        <replaced>
User Name:
Is Online:      false
Token:  <replaced>
Token File:     /root/.GoSungrow/AppService_login.json
root@haos:~/go-projects/MickMake/GoSungrow# ./GoSungrow show ps list
┏━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Ps Key ┃ Ps Id ┃ Device Type ┃ Device Code ┃ Channel Id ┃ Serial # ┃ Factory Name ┃ Device Model ┃
┣━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┫
┗━━━━━━━━┷━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━┷━━━━━━━━━━┷━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━┛

Paraphraser commented Sep 9, 2024

Author

@gR-xbY An installer! Brilliant. Don't suppose you know how to set a Sungrow to do zero export? I used to be able to do that with my old SolaX.

Anyway, to your question. I've just run the command and (with appropriate sanitisation to protect the innocent):

[marble Mon Sep 09 12:54:37 Inverter Data] $ GoSungrow show ps list
┏━━━━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┓
┃ Ps Key           ┃ Ps Id   ┃ Device Type ┃ Device Code ┃ Channel Id ┃ Serial #    ┃ Factory Name ┃ Device Model   ┃
┣━━━━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━┫
┃ 9999999_1_1_1    │ 9999999 │ 1           │ 1           │ 1          │ B2222334445 │ SUNGROW      │ SG5.0RS        ┃
┃ 9999999_7_1_1    │ 9999999 │ 7           │ 1           │ 1          │ B2222334445 │ SUNGROW      │ SG Smart Meter ┃
┃ 9999999_22_247_1 │ 9999999 │ 22          │ 247         │ 1          │ B2222334445 │ SUNGROW      │ WiNet-S        ┃
┗━━━━━━━━━━━━━━━━━━┷━━━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┛

The way I use GoSungrow is via a cron job running at 3am each day. The script fetches voltage and current for both MPPTs, the daily yield, feed-in and purchased energy, and the total lifetime yield, plus some other odds and ends. A total of 12 metrics at 5-minute resolution for "yesterday" which I munge a bit and load into an SQLite database.

The selection of metrics and "munging" was aimed at continuing the time-series from the SolaX. I was basically mimicking the SolaX daily CSV so I could feed it into my existing process.

So long as I see 288 rows per day, I know everything's cooking with photons.

I'm not particularly interested in fancy graphs. If I want those, I can use the iSolarCloud app. The only report I care about comes out of the SQLite database and looks like this:

---------  ----  ------  ---------  ----  ------  -------  --------  -----
Last 24    pv    charge  discharge  ac    toGrid  selfUse  fromGrid  house
---------  ----  ------  ---------  ----  ------  -------  --------  -----
A kWh       0.0     0.0        0.0   0.0     0.0      0.0       0.0    0.0
B kWh       0.0     0.0        0.0   0.0     0.0      0.0       0.0    0.0
C kWh      29.6     0.0        0.0  28.1    16.4     11.8      21.0   32.8
---------  ----  ------  ---------  ----  ------  -------  --------  -----
Total kWh  29.6     0.0        0.0  28.1    16.4     11.8      21.0   32.8
---------  ----  ------  ---------  ----  ------  -------  --------  -----

The SolaX was a hybrid with batteries. The Sungrow is non-hybrid and I don't have any batteries (which is why charge/discharge are zero). I was a bit annoyed that the LiFePO₄ batteries didn't last more than 7 years so I decided not to waste money until that situation improved (and for the first time in my life I can offer bouquets rather than brickbats to the New South Wales State Government - in this case for setting the standard that batteries need 10 year warranties).

A B and C refer to Peak, Shoulder and Off-Peak time-of-use; yesterday being Sunday was all Off-peak tariff. So long as I see something sensible in that report, I know the inverter was working yesterday. And, by inference, that the tool-chain involving GoSungrow hasn't broken.

gR-xbY commented Sep 26, 2024

@Paraphraser , After several tests, I found that running ./GoSungrow data get getPsDetail PsId: returned the data correctly, meaning that the communication was working properly. After further testing, I noticed that using my username as the email instead of the ID worked, but it didn't work with other users created later. In other words, two important points here: you need to use the first user registered on the inverter (owner), and you cannot use the ID, you must use the registered email.

Paraphraser commented Sep 26, 2024

Author

@gR-xbY but here's the thing, I have three use-points for my interactions with Sungrow cloud services:

My "daily use" of GoSungrow is from the command line in the form of a script triggered by cron to download "yesterday's" data.
The GoSungrow add-on running in Home Assistant, but only so I can confirm it is working, I don't use the data it produces. It is, nevertheless, running constantly.
Sporadic use of the iSolarCloud app on my iPad.

In the first two cases, my login credentials are my user ID, not the associated email address. It has always been that way. I don't think I ever tried the email address. Conversely, the iSolarCloud app that runs on my iPad logs-in with the email address. I don't think I ever tried the user ID.

I can't tell you why I chose the user ID for the CLI. Nor can I tell you why I chose the email address for the iPad app. Probably "seemed like a good idea at the time". But it might be as simple as the iPad app coming first and one of the displays showing the "User ID", so I made a note of it and that's what I used when I first set up the CLI.

I can tell you why I'm using the user ID for the HA add-on. It's because I dumped the CLI config as a copy/paste source when I was first setting up the add-on. Nothing cleverer than that.

Still, the material point is that I am logging-in, successfully, with both methods, so I think there might be a bit more to it. 🤷‍♂️

Paraphraser commented Sep 26, 2024

Author

@gR-xbY after a bit more nosing around, this is the pattern I see from GoSungrow api login:

Email:  someone@domain.com
Create Date:    Thu Feb 09 13:14:55 CST 2023
Login Last Date:        2024-09-26 16:19:01
Login Last IP:  
Login State:    1
User Account:   aabbccddee
User Id:        666666
User Name:      Moi

"Email" is what I use to login on the iPad app. "User Account" is what I use in the other two places. In the iPad app, the aabbccddee value is associated with the label "User ID", and the Moi value is associated with the label "Nickname". I haven't found anywhere in the iPad app where the 666666 value is displayed.

So, some of what you report and how I interpreted that in my earlier response might be explained by this difference in terminology. I hope that makes sense.

gR-xbY commented Sep 26, 2024

@Paraphraser This is the point of us having a very basic API from Sungrow in terms of documentation. The important thing is that I was able to make it work in the way I mentioned above. However, I would like to understand more about how you implemented this cron job to fetch only the data from the previous day. I think it makes more sense to me, so I don't have to keep pulling unnecessary data all the time.

Paraphraser commented Sep 28, 2024

Author

@gR-xbY See if Paraphraser/gosungrow-fetch helps. It contains my script plus an extensive README to explain both how I go about it and how you could tailor it to your own needs. I hope it helps.

gR-xbY commented Oct 1, 2024 •

edited

Loading

@Paraphraser It's interesting how you approached this; it sparked an idea for me. I decided to develop a simple script that encapsulates the GoSungrow API alongside a Node.js application running in Docker. This script periodically executes user-defined GoSungrow endpoints and sends the filtered results to an MQTT broker. This way, in Home Assistant, we can create sensors that subscribe to these topics and receive only the information that truly matters. You can run this container directly on your Home Assistant setup or locally.

You can take a look at GoSungrow2MQTT. I think it's very simple and usable, I'm using it and it works perfectly for me now, without those previous errors and timeout problems.
An example of the configuration for some calls:

[
  {
    "endpoint": "getPowerStatistics",
    "topic": "inverter1/powerStatistics"
  },
  {
    "endpoint": "getPowerStatistics",
    "filter": ["dayPower", "nowCapacity"],
    "topic": "inverter2/powerStatistics",
    "params": {"ps_id": "your_custom_psId_2"}
  },
  {
    "endpoint": "queryMutiPointDataList ",
    "topic": "inverter2/mutiPointDataList",
    "params": {
                "ps_key":"1129147_14_1_1,1129147_14_1_1,1129147_14_1_1,1129147_14_1_1,1129147_14_1_1,1129147_14_1_1,1129147_14_1_1,1129147_14_1_1,1129147_14_1_1,1129147_11_0_0",
                "points":"p13150,p13126,p13142,p13143,p13019,p13141,p13121,p13003,p13149,p83106",
                "minute_interval":"5",
                "start_time_stamp":"20220215000000",
                "end_time_stamp":"20220215235900",
                "ps_id":"your_custom_psId_2"
              }
  }
]

I hope it's useful =)

DerSpatz commented Dec 26, 2024

I followed the guide (thanks!) under Part 2, and it works as it should, but unfortunately, the tagging is lost after a reboot. What can I do to make the changes persist after a reboot?

I tried running the (modified) command automatically after a reboot, but Home Assistant makes this extremely difficult.

Paraphraser commented Dec 26, 2024

Author

Overnight we had the most amazing lightning storm I have ever seen - almost continuous lightning for the better part of an hour and, in some cases, more simultaneous flashes than any human could possibly count. In retrospect, I wish I had known it was coming so I could've set up a video camera.

I mention that because we live at the end of what I sometimes think must be the most fragile bit of copper on the grid. A thunderstorm of any magnitude is likely to see an outage. Last night was no exception.

Because (a) thunderstorm = outage and (b) thunderstorms are many, I have UPSes everywhere. Last night, the outage was sufficiently long for the relevant UPS to get to 50% capacity so I shutdown everything, including my HA instance.

As it happens, the grid came back about half an hour later and, seeing as I was awake when I would far rather have been well into the land of nod, I turned things back on again.

and it was lucky I decided to do that because it turned out that the storm had tripped three of the house RCDs (one "lights" and two "power" circuits). We hadn't had a direct strike so I've no idea why those three sensed an earth leakage while others didn't trip...

The upshot of all that is that my HA instance which is a Proxmox-VE guest running in an old Intel MacMini was fully shutdown. The screen shot above is "as I type this" showing uptime of four and a half hours, plus the fact that GoSungrow exists as the expected tag-troika pointing to two distinct images which, in my case, are all a year old.

I know my HA instance has had occasional reboots in that 12 months. Last night's is just the most recent. I offer that screen shot as evidence that tags do persist across reboots.

That all said, I am mindful that "things" do disappear from terminal sessions across reboots. There's a few things I'd dearly love to set up from .profile and/or .bashrc but there seems to be no way to make edits or new files stick. I've assumed (as distinct from certain knowledge) that this is some artefact of the "Advanced SSH and Terminal" being a container and that the "home" directory is ephemeral.

On the other hand, there's my attached screen shot showing my images are persisting, and that must be occurring outside container-space.

Only two possible explanations occur to me:

You have a different platform (eg your HA is running on a dedicated appliance) and this is a "platform difference"; or
Maybe you don't have "protection mode" turned off in the Advanced SSH and Terminal.

I'm only running my HA instance so I can test the gist scenarios. Making some practical use of HA is on my to-do list but it hasn't happened yet. That, in turn, means my HA knowledge is pretty superficial so whether a platform difference (eg running HA natively rather than as a guest OS; or one of HA's off-the-shelf appliances) even makes sense, is something I don't know.

Similarly, I've never tried running the Advanced SSH and Terminal addon with protection mode enabled so I have no idea whether that's even plausible as an explanation for what you're seeing.

Other than that, dunno. Sorry. 🤷‍♂️

bamcauliffe commented Apr 19, 2025 •

edited

Loading

Which API Key to use?
I had been using ANDROIDE13EC118BD7892FE7AB5A3F20 successfully for the 9 months or so.

I was having troubles not being able to get the Energy Dashboard working in Home Assistant.
I could not find the following entities per the Home Assistant Documentation.

Electricity grid
sensor.gosungrow_virtual_XXXXXXXXXXXXXX_grid_to_load_energy
sensor.gosungrow_virtual_XXXXXXXXXXXXXX_pv_to_grid_energy

Solar Panels
sensor.gosungrow_virtual_XXXXXXXXXXXXXX_pv_energy

Home Battery Storage
sensor.gosungrow_virtual_XXXXXXXXXXXXXX_battery_discharge_energy
sensor.gosungrow_virtual_XXXXXXXXXXXXXX_battery_charge_energy

I tried changing some entities from a state_class of “measurement” to “total” , however as the data in the entities that I was using did reset to 0 at midnight, it needed a “last_reset” to midnight this morning so that the data could be correctly incorporated.
I thought there might be a problem with the image that I loaded, so I rebuild the Add-on.
This did not help so I remove the Add-on and removed the docker images and re-installed the Add-on.
This also gave problems.
So, I did a backup restore.

I tried using the API key per above but it would not work and I got “unknown error e914”.
I saw that Paraphraser was getting this error when using the API Key above.
So, I tried the B0455FBE7AA0328DB57B59AA729F05D8 instead.
This different API Key now successfully works.

I tried changing some entities from a state_class of “total” to "total_increasing" and will see if this fixes the midnight resetting issue.

Regarding the missing entities from above MickMake does say in https://community.home-assistant.io/t/home-assistant-community-add-on-isolarcloud-sungrow/411602/101?page=5
Apr-2023 “Yes, alas this is the problem, because the endpoints are all different across models.”

monojk commented Oct 12, 2025

I end up with "Error: unknown error 'E914'" after installing following Part1 (install from source). I get the same error when using the Part3 (precompiled outside of home assistant).
It fails with either appkey B0455FBE7AA0328DB57B59AA729F05D8 or ANDROIDE13EC118BD7892FE7AB5A3F20
Any ideas?

Paraphraser commented Oct 12, 2025

Author

Just to be sure that nothing had changed under the hood, I recompiled GoSungrow with the latest Go compiler and otherwise followed Part 1. I had no trouble.

The only places E914 has been mentioned are issue 101 and earlier in this gist's comments.

The person who made the issue 101 comment never made any other contributions to that issue so I don't know whether they fixed it themselves or just gave up.

Although I've been able to cause E914 by switching to the other AppKey, I've always wondered whether E914 might be a generic error that means "I don't like the totality of your credentials".

Aside from some people needing B0... while others need the ANDROID... AppKey, I've never been too clear on what is "correct" when it comes to identifying yourself as a user. When I run:

$ GoSungrow api login

I get a display that includes:

Email
User Account
User Id
User Name

The credentials I actually login with are the User Account and password. I have no idea whether Email or User ID would work as synonyms for User Account (User Name is clearly non-unique so that won't work).

Maybe it's as simple as that.

Otherwise, dunno. Sorry.

monojk commented Oct 12, 2025 •

edited

Loading

Thanks for your reply. I changed the user from the userid@server to the sungrow user name.
I noticed that by default the GoSunGrow uses a different config file than I thought (same dir)

pi@rp4b:~/GoSungrow-patched $ ./GoSungrow config read
Using config file '/home/pi/.GoSungrow/config.json'
+-------------------+------------+---------------------------+--------------------------------+----------------------------------+
|       FLAG        | SHORT FLAG |        ENVIRONMENT        |          DESCRIPTION           |       VALUE (* = DEFAULT)        |
+-------------------+------------+---------------------------+--------------------------------+----------------------------------+
....
| --appkey          |            | GOSUNGROW_APPKEY          | SunGrow: api application key.  | B0455FBE7AA0328DB57B59AA729F05D8 |
....

Before, I had the old appkey there. But now I get the error:

pi@rp4b:~/GoSungrow-patched $ ./GoSungrow api login
Error: getApi: Appkey: empty string
...
pi@rp4b:~/GoSungrow-patched $ ./GoSungrow api login --appkey B0455FBE7AA0328DB57B59AA729F05D8
Error: getApi: Appkey: empty string

Paraphraser commented Oct 12, 2025

Author

First things first. Do you have the iSolarCloud app installed somewhere? If you don't have it installed but you do have a device capable of running the app then I strongly recommend installing it.

Key question: Can you login using that app and see your solar system?

The reason I ask is that I understand the Sungrow "cloud" can be a bit sensitive to too many failed logins in succession and can lock your account.

Make sure you can actually login using iSolarCloud and get that resolved first. It's easier to call Sungrow to moan about the app not working than GoSungrow not working.

Then try:

$ GoSungrow config read

It will tell you which config file it is using, plus give you a dump of the contents of the config file.

Now, pay attention to the "Flag" column. It's telling you how to change configuration values:

$ GoSungrow config write --user «username» --password «password» --appkey «appkey»

Confirm the settings via another config read and then try:

$ GoSungrow api login

monojk commented Oct 13, 2025

Ah, I found the problem:

/home/pi/.GoSungrow/config.json is the config file
email account is to be set under "user" not the "User Account" nor the "User Name"

Thanks for your help

51iMM commented Dec 4, 2025

Thanks for taking the time for this extensive guide!
Using HA, I was able to move from the x-access-key issue to a patched version, and also sort out the issues of using API key and username.
Still somewhat confused that my personal API key wont work, (I do have access to the SunGrow developers so I might be able to ask them).
But I managed to get connected using the above guide and provided API Key..

But still I'm facing issues.

When starting the service i am now prompted by the following error in the log.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc8 pc=0x8dad53]

Anyone that knows how to resolve this?
Full log below:

s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[13:56:39] INFO: Setting up GoSungrow config ...
[13:56:39] INFO: Writing GoSungrow config ...
Using config file '/data/.GoSungrow/config.json'
New config:
+-------------------+------------+---------------------------+--------------------------------+----------------------------------+
| FLAG | SHORT FLAG | ENVIRONMENT | DESCRIPTION | VALUE (* = DEFAULT) |
+-------------------+------------+---------------------------+--------------------------------+----------------------------------+
| --config | | GOSUNGROW_CONFIG | GoSungrow: config file. | /data/.GoSungrow/config.json |
| --debug | | GOSUNGROW_DEBUG | GoSungrow: Debug mode. | true |
| --quiet | | GOSUNGROW_QUIET | GoSungrow: Silence all | false * |
| | | | messages. | |
| --timeout | | GOSUNGROW_TIMEOUT | Web timeout. | 1m0s |
| --user | -u | GOSUNGROW_USER | SunGrow: api username. | xxxxxxxxxx |
| --password | -p | GOSUNGROW_PASSWORD | SunGrow: api password. | xxxxxxxxxx |
| --appkey | | GOSUNGROW_APPKEY | SunGrow: api application key. | B0455FBE7AA0328DB57B59AA729F05D8 |
| --host | | GOSUNGROW_HOST | SunGrow: Provider API URL. | https://gateway.isolarcloud.eu |
| --token-expiry | | GOSUNGROW_TOKEN_EXPIRY | SunGrow: last login. | 2025-12-04T21:49:20 |
| --save | -s | GOSUNGROW_SAVE | Save output as a file. | false * |
| --dir | | GOSUNGROW_DIR | Save output base directory. | * |
| --mqtt-user | | GOSUNGROW_MQTT_USER | HASSIO: mqtt username. | xxxxxxx |
| --mqtt-password | | GOSUNGROW_MQTT_PASSWORD | HASSIO: mqtt password. | xxxxxxxxxx |
| --mqtt-host | | GOSUNGROW_MQTT_HOST | HASSIO: mqtt host. | core-mosquitto |
| --mqtt-port | | GOSUNGROW_MQTT_PORT | HASSIO: mqtt port. | 1883 |
| --modbus-user | | GOSUNGROW_MODBUS_USER | Modbus username. | * |
| --modbus-password | | GOSUNGROW_MODBUS_PASSWORD | Modbus password. | * |
| --modbus-host | | GOSUNGROW_MODBUS_HOST | Modbus host. | * |
| --modbus-port | | GOSUNGROW_MODBUS_PORT | Modbus port. | 502 * |
+-------------------+------------+---------------------------+--------------------------------+----------------------------------+
[13:56:39] INFO: Login to iSolarCloud using gateway https://gateway.isolarcloud.eu ...
Email: john@doe.com
Create Date: Tue Sep 23 09:49:11 CST 2025
Login Last Date: 2025-12-04 21:49:20
Login Last IP:
Login State: 1
User Account: xxxxxxxxxx
User Id: xxxxxxxxxx
User Name: xxxxxxxxxx
Is Online: false
Token: xxxxxxxxxx_aa49bz9btmrp8xvqcni671bgeryjnf6pv4khyycib2xp9j1d2f1y92unsrhqwbqqvzzr4y92tk8f0cgvra5baxedgyb7dgf3v1y3es9yy2zg66eua5nmdq7fw530rkcj
Token File: /data/.GoSungrow/AppService_login.json
Email: john@doe.com
Create Date: Tue Sep 23 09:49:11 CST 2025
Login Last Date: 2025-12-04 21:56:40
Login Last IP:
Login State: 1
User Account: xxxxxxxxxx
User Id: xxxxxxxxxx
User Name: xxxxxxxxxx
Is Online: false
Token: xxxxxxxxxx_zih9mw280dxwh9x3srhmepxydxa8h6pffku80hi0dw15dqbtbumkcrzrdbzsyvetxqiuw4wr1j6dz27sfabf8gepp0fbzrwj8vj6xipkjpat3ngj3axvv17gun7a3s7c
Token File: /data/.GoSungrow/AppService_login.json
[13:56:40] INFO: Syncing data from gateway https://gateway.isolarcloud.eu ...
Email: john@doe.com
Create Date: Tue Sep 23 09:49:11 CST 2025
Login Last Date: 2025-12-04 21:56:40
Login Last IP:
Login State: 1
User Account: xxxxxxxxxx
User Id: xxxxxxxxxx
User Name: xxxxxxxxxx
Is Online: false
Token: xxxxxxxxxx_zih9mw280dxwh9x3srhmepxydxa8h6pffku80hi0dw15dqbtbunkcrzrdbzsxvetoqiuw4wr1j6dz27sfabf8gepp0fbzrwj8vj6xipkjpat3ngj3axvv17gun7a3s7c
Token File: /data/.GoSungrow/AppService_login.json
2025/12/04 13:56:40 INFO: Connecting to MQTT HASSIO Service...
2025/12/04 13:56:40 INFO: Connecting to SunGrow...
2025/12/04 13:56:41 INFO: Found SunGrow 5 devices
2025/12/04 13:56:41 INFO: Caching Sungrow metadata...
2025/12/04 13:56:41 INFO: Cached 748 Sungrow data points...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc8 pc=0x8dad53]
goroutine 1 [running]:
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).SetBatteryPoints(, {{, , }}, {0xc000b6e270, {0xc000309db7, 0x7}, {0xc24482a6c29039d0, 0x8004319e, 0x4b5fa20}, ...})
/Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:336 +0x4d3
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).GetEnergyStorageSystem(, {0xc000b6e270, {0xc000309db7, 0x7}, {0xc24482a6c29039d0, 0x8004319e, 0x4b5fa20}, {{0xc00007b720, 0x2, 0x2}}, ...})
/Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:298 +0x34d
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).GetData()
/Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:259 +0xb8
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.EndPoint.GetEndPointData(...)
/Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/struct.go:367
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).CallEndpoint(, {, _}, {{0xc000c707b0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...}, ...})
/Users/isit/git/GoSungrow/iSolarCloud/data.go:160 +0x3f3
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).getDataSinglePsIdRequired(0xc002813478, {0x2ed71f8, 0xc00086aa80})
/Users/isit/git/GoSungrow/iSolarCloud/data.go:283 +0x36c
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).GetDataSingle(0xc002813478, {0xc000609680, 0xf})
/Users/isit/git/GoSungrow/iSolarCloud/data.go:238 +0x14f
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).GetData(0xc002813478)
/Users/isit/git/GoSungrow/iSolarCloud/data.go:209 +0x152
github.com/MickMake/GoSungrow/cmd.(*CmdMqtt).Cron(0xc0000a6840)
/Users/isit/git/GoSungrow/cmd/cmd_mqtt.go:375 +0x2b7
github.com/MickMake/GoSungrow/cmd.(*CmdMqtt).CmdMqttRun(0xc0000a6840, 0x0?, {0x0?, 0x0?, 0x0?})
/Users/isit/git/GoSungrow/cmd/cmd_mqtt.go:273 +0x85
github.com/spf13/cobra.(*Command).execute(0xc0004f8000, {0xc00003e1a0, 0x0, 0x0})
/Users/isit/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:940 +0x862
github.com/spf13/cobra.(*Command).ExecuteC(0xc0003f6300)
/Users/isit/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:1068 +0x3bd
github.com/spf13/cobra.(*Command).Execute(...)
/Users/isit/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:992
github.com/MickMake/GoUnify/Unify.(*Commands).Execute(...)
/Users/isit/go/pkg/mod/github.com/!mick!make/!go!unify@v1.0.3-0.20230904042338-0db745f1bada/Unify/struct.go:277
github.com/MickMake/GoUnify/Unify.(*Unify).Execute(0xc0004792c0)
/Users/isit/go/pkg/mod/github.com/!mick!make/!go!unify@v1.0.3-0.20230904042338-0db745f1bada/Unify/struct.go:216 +0x3bf
github.com/MickMake/GoSungrow/cmd.Execute(...)
/Users/isit/git/GoSungrow/cmd/commands.go:94
main.main()
/Users/isit/git/GoSungrow/main.go:11 +0x6f
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

Paraphraser commented Dec 8, 2025

Author

@51iMM It has been on my to-do list for a while to update this gist to explain how to (1) recompile GoSungrow with patches such as the one which is expected to fix "nil pointer" exceptions then, (2) explain how to generate an updated Docker image to produce a patched add-on. Your comment prompted me to "get on with it".

I do not have batteries so I have never encountered this error, which means I have no way of testing whether the alterations to the gist will fix your problem. Please follow the steps in parts 1 and 5 and see if it works. If not, we are no worse off. If it does (fingers crossed) then great! Please report back either way.

51iMM commented Dec 8, 2025

Thanks! I will try to do this,
As mentioned i did follow the initial guide and managed to get the triamazikamno compilation in place and that resolved some of my issues, but since I ran in to the "nil pointer" problem it sounds intriguing to verify if re-doing this based on your updates in the guide, will improve things.
I will for sure report back the result.

51iMM commented Dec 8, 2025 •

edited

Loading

I did manage to follow the guide, and it was somewhat of a challenge since I'm a windows user :)
But i believe i pushed through and reached a patched version, unfortunately does my issue remains.

As from a Windows perspective, this is what i did.

installed Go for windows
installed Git
Enabled me to use powershell prompts.

There are some modifications needed to be able to run the patching from powershell, this is what I ended up with
$PRS = "108","137","138"; foreach ($PR in $PRS) { git fetch origin pull/$PR/head:PR$PR }

and

$PATCHES = "PR108","triamazikamno/encryption","PR137","PR138"; foreach ($PATCH in $PATCHES) { git merge -X theirs -m "apply $PATCH" $PATCH }

As a windows user I also had to add the following to successfully run the last command
(error: *** Please tell me who you are.)

git config --global user.name "Myname"
git config --global user.email "email@example.com"

Since i run HA on a VM I need to target the image to linux amd64, using go build natively it will compile it as an .exe,
this can be done using this oneliner in powershell before the 'go build'

$env:GOOS="linux"; $env:GOARCH="amd64"; go build -o GoSungrow-linux-amd64

I then jumped to Step 5
Here I had some issues, I believe they were due to having multiple docker images, trying to follow the guide before this new part was added. also I have tried to install GoSungrow2MQTT witch will be included in the
"docker images | grep -e REPOSITORY -e gosungrow"

Either way i uninstalled GoSungrow in HA and also took the time to clean up the remaining docker images before installing and repeating the steps. this then went through without any issues.

To transfer the file to my HA, i used WinSCP to place it in the suggested folder, that way I do not need to set up my Windows with a SCP share.

Once i added config and started, unfortunately for me i ended up with the error "panic: runtime error: invalid memory address or nil pointer dereference"

So perhaps i did something wrong or perhaps there is something else at play for me..

goroutine 1 [running]:
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).SetBatteryPoints(, {{, , }}, {0xc0003fbc50, {0xc0008237e7, 0x7}, {0xc245c190939b44a5, 0xf5ea6de0, 0x4b5fa20}, ...})
/Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:336 +0x4d3
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).GetEnergyStorageSystem(, {0xc0003fbc50, {0xc0008237e7, 0x7}, {0xc245c190939b44a5, 0xf5ea6de0, 0x4b5fa20}, {{0xc0004b8220, 0x2, 0x2}}, ...})
/Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:298 +0x34d
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).GetData()
/Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:259 +0xb8
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.EndPoint.GetEndPointData(...)
/Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/struct.go:367
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).CallEndpoint(, {, _}, {{0xc0007f4420, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...}, ...})
/Users/isit/git/GoSungrow/iSolarCloud/data.go:160 +0x3f3
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).getDataSinglePsIdRequired(0xc000ae3478, {0x2ed71f8, 0xc00063b500})
/Users/isit/git/GoSungrow/iSolarCloud/data.go:283 +0x36c
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).GetDataSingle(0xc000ae3478, {0xc0005de990, 0xf})
/Users/isit/git/GoSungrow/iSolarCloud/data.go:238 +0x14f
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).GetData(0xc000ae3478)
/Users/isit/git/GoSungrow/iSolarCloud/data.go:209 +0x152
github.com/MickMake/GoSungrow/cmd.(*CmdMqtt).Cron(0xc0000b0840)
/Users/isit/git/GoSungrow/cmd/cmd_mqtt.go:375 +0x2b7
github.com/MickMake/GoSungrow/cmd.(*CmdMqtt).CmdMqttRun(0xc0000b0840, 0x0?, {0x0?, 0x0?, 0x0?})
/Users/isit/git/GoSungrow/cmd/cmd_mqtt.go:273 +0x85
github.com/spf13/cobra.(*Command).execute(0xc0004f6000, {0xc00003e1a0, 0x0, 0x0})
/Users/isit/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:940 +0x862
github.com/spf13/cobra.(*Command).ExecuteC(0xc000400300)
/Users/isit/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:1068 +0x3bd
github.com/spf13/cobra.(*Command).Execute(...)
/Users/isit/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:992
github.com/MickMake/GoUnify/Unify.(*Commands).Execute(...)
/Users/isit/go/pkg/mod/github.com/!mick!make/!go!unify@v1.0.3-0.20230904042338-0db745f1bada/Unify/struct.go:277
github.com/MickMake/GoUnify/Unify.(*Unify).Execute(0xc0004872c0)
/Users/isit/go/pkg/mod/github.com/!mick!make/!go!unify@v1.0.3-0.20230904042338-0db745f1bada/Unify/struct.go:216 +0x3bf
github.com/MickMake/GoSungrow/cmd.Execute(...)
/Users/isit/git/GoSungrow/cmd/commands.go:94
main.main()
/Users/isit/git/GoSungrow/main.go:11 +0x6f
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[10:13:26] INFO: �[32mSetting up GoSungrow config ...�[0m
[10:13:27] INFO: �[32mWriting GoSungrow config ...�[0m
/usr/local/bin/run.sh: line 83: /usr/local/bin/GoSungrow: Permission denied
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[10:52:13] INFO: �[32mSetting up GoSungrow config ...�[0m
[10:52:13] INFO: �[32mWriting GoSungrow config ...�[0m
/usr/local/bin/run.sh: line 83: /usr/local/bin/GoSungrow: Permission denied
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

Paraphraser commented Dec 8, 2025

Author

I am not sure what to make of that log. In particular, the presence of this line in the upper part:

panic: runtime error: invalid memory address or nil pointer dereference

makes absolutely no sense, given this line in the second part:

/usr/local/bin/run.sh: line 83: /usr/local/bin/GoSungrow: Permission denied

The "line 83" seems to be saying that GoSungrow can't actually be started at all so the question becomes, "how do you get a panic from something that isn't actually running?"

My suspicion is that this log contains both "before" and "after" entries, but only you will know whether that's likely.

However, taking things at face value, there are two plausible explanations for why you are still hitting the panic:

The patches were applied successfully but the panic is coming from some area of GoSungrow that the patches did not address. If that's the case then we're all S.O.L. Sorry.
The patches were not applied successfully because of some artefact of the Unix-to-Windows commands.

My I.T. trajectory has been such that I was a DOS user up until about 1987 when I switched to (classic) MacOS, then MacOS X and its forever-being-renamed progeny from 2000 onwards. I had a brief encounter with Windows circa 2009 but it was a locked-down work PC where anything out of the ordinary required a call to the HelpDesk. I say that so you have some context for my next remark.

With respect to:

$PATCHES = "PR108","triamazikamno/encryption","PR137","PR138"; foreach ($PATCH in $PATCHES) { git merge -X theirs -m "apply $PATCH" $PATCH }

I have absolutely no idea whether that actually works.

In using variables (PRS and PATCHES) I was trying to "future proof" in case any more pull requests came along. It might've been better if I had laid out the commands in full:

git remote add -t encryption triamazikamno https://github.com/triamazikamno/GoSungrow.git
git fetch triamazikamno encryption
git fetch origin pull/108/head:PR108
git fetch origin pull/137/head:PR137
git fetch origin pull/138/head:PR138
git checkout -b patch-set
git merge -m "apply PR108" PR108
git merge -m "apply triamazikamno/encryption" triamazikamno/encryption
git merge -m "apply PR137" PR137
git merge -X theirs -m "apply PR138" PR138

If you decide to try another build, maybe see if doing it that way cures the problem.

Now, let's switch focus away from the panic to the permissions error:

/usr/local/bin/run.sh: line 83: /usr/local/bin/GoSungrow: Permission denied

That implies that the recompiled binary does not have execute permission.

In the gist right after the step where you copy the recompiled binary onto the HA machine, you'll see this:

# ls -l
total 102572
-rwxr-xr-x    1 root     root     105029473 Dec  8 12:11 GoSungrow

My guess is that if you repeat that command, you won't find those "x" in the permissions bits on the left hand side. Probably something like -rw-r--r--.

I don't understand Windows permissions so I have no idea whether it even has the concept of an "execute" permission. Another possibility is the Windows end of the scp (if that's what you used) is stripping the execute bits for some reason.

Whatever the explanation, the command to fix that is:

$ chmod 755 GoSungrow

then repeat the ls -l to make sure it shows -rwxr-xr-x, and then proceed to create the Dockerfile etc.

I should probably add somewhere that if you try another rebuild, you'll need to put everything back to square one. Something like:

# docker tag ba22da74/amd64-addon-gosungrow:3.0.7-backup ba22da74/amd64-addon-gosungrow:3.0.7 
# docker rmi patched/amd64-addon-gosungrow:3.0.7 ba22da74/amd64-addon-gosungrow:3.0.7-backup
# docker system prune -f

In words:

Retag the -backup with the original name of the busted image.
Remove the various artefacts created during the previous attempt.
Clean up any dangling dross.

I've just proven to myself that it is possible to avoid using the notion of a "support host" (Linux, macOS, Windows, whatever) and do all the work in the HA "Advanced SSH and Web Terminal".

Step 2 of "Prepare your system (Linux+macOS)" says you can add those lines to either .bashrc or .profile. For HA it has to be .profile.

You won't need to do any cross-compiling for a target platform because the Go compiler will automatically build for the HA system. Instead of the scp command, the recompiled binary will be at the path:

~/go-projects/MickMake/GoSungrow/GoSungrow

so you can just move it from there into the context directory:

# cd
# mkdir context
# cd context
# mv ~/go-projects/MickMake/GoSungrow/GoSungrow .

Paraphraser commented Dec 8, 2025

Author

By the way, if you want to include example lines of code or log outputs, it's best to wrap them in lines of triple back-ticks. The back-tick is usually to the left of the "1" key on the keyboard. In Markdown parlance, the lines are called "code fences".

```

lines here get rendered in a monospaced font "as is"

```

51iMM commented Dec 8, 2025 •

edited

Loading

may thanks for your comments!
I will give it another go,
I was also suspect of the Permission denied issue.

I did a quick try and updated the permissions, it was as you suspected rw-r--r--
After that i just tried to continue from there, now I end up with
[14:05:50] INFO: Login to iSolarCloud using gateway https://gateway.isolarcloud.eu ...
Error: unknown error ''
Usage:
GoSungrow api login [flags]

So I believe best cause of action is to clean up and start from scratch.. in a structured way.
I did spend my initial time in MSDOS but took the Windows route when Windows 3.11 was introduced, and work has kept me in the Windows world ever since.
But with your help I got the opportunity re-visit some (for me) forgotten experiences.

51iMM commented Dec 8, 2025

I gave it another shot!
And i just had to change the API key two times, and then it worked!

I'm stoked!
Its been a lot of confusion and tinkering with this and finally i see stuff popping up in my MQTT broker.
So adding to my list of GoSungrow for windows dummies, fixing the security probably made the difference.
I just had to take a second time around the configuration circle.

Still I will try to talk to Sungrow on the advantage for them to crate an official integration for HA, I know they understand the need from customers in regards of this.
this current solution is not for the light-hearted.

Token: 750717_5rr7zqg7ep6agb8fxc58u1cuyfhkpsjcj1zefhv3y7yyh8amdj7uapzdzhzfjbvpw07aie2i1kq0k9agnkg6e4wherraz294s4gdsn19rc38m3nkh1m0q1rj2z0jbw1v
Token File: /data/.GoSungrow/AppService_login.json
[15:30:19] INFO: Syncing data from gateway https://gateway.isolarcloud.eu ...
2025/12/08 15:30:19 INFO: Connecting to MQTT HASSIO Service...
2025/12/08 15:30:19 INFO: Connecting to SunGrow...
2025/12/08 15:30:20 INFO: Found SunGrow 5 devices
2025/12/08 15:30:20 INFO: Option[fetchschedule] set to '2m'
2025/12/08 15:30:20 INFO: Caching Sungrow metadata...
2025/12/08 15:30:22 INFO: Cached 748 Sungrow data points...
2025/12/08 15:30:24 INFO: Syncing 155 entries with HASSIO from getPsList.
2025/12/08 15:30:24 INFO: Syncing 252 entries with HASSIO from getPsDetail.
CUCUCUCUCUCUCUCUCU?CUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU
2025/12/08 15:30:24 INFO: Syncing 3707 entries with HASSIO from queryDeviceList.
CUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU??CUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCU?CUCU?CU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCU??CUCUCUCUCUCU?CUCUCUCUCU?CU?CUCUCU?CUCUCUCUCU?CUCUCUCU?CUCUCUCUCUCUCUCUCUCU??CUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCU?CUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCU
-CUCU--CU--CUCUCUCUCUCUCU--CUCU-----CUCU-CUCU--CUCUCUCUCU-CUCUCUCUCUCU--CUCU-CUCUCU-CUCUCU-CU-CU-CUCU-CU-CU-CUCUCU--CUCUCUCUCUCUCU-CU-CU--CU--CU-CU-CU--CUCUCUCUCUCU-CU--CU-CU-CUCUCUCU-CU-CU---CUCUCU--CU-CU-CU-CU-CUCU-CUCUCUCU-CU--CU-CUCU--CU-CU-CU-CUCU--CU-----CU--CUCUCUCUCU-CU--CUCUCUCUCU-CU--CUCUCU--CUCU---CU-CUCUCUCU-CU--CU---CU-CU-CU-CU-CUCUCU-CUCUCU--CUCUCUCUCUCUCUCUCU------CU-CU-CU-CUCU-----CU----CUCU-CU-CUCU--CU-CUCUCUCU-----CUCUCU-CUCUCU--CUCUCUCUCU--CUCU-CU--CUCUCU-CUCU---CU-CU-CU---CUCUCUCUCUCU---CU------CU-CUCUCU-CUCU-
2025/12/08 15:30:24 INFO: Starting ticker...
2025/12/08 15:30:24 INFO: Fetch Schedule: 2m
2025/12/08 15:30:24 INFO: Sleep Delay: 40s

Cucucatchuu!
Thanks @Paraphraser

Paraphraser commented Dec 9, 2025

Author

As from a Windows perspective, this is what i did.

installed Go for windows
installed Git

Git is in the assumptions for Part 1. Go in the "Install/Update Go compiler" section so I think that's covered.

Enabled me to use powershell prompts.

I do not know what that means. Is powershell something that comes with Windows or is it a separate install?

There are some modifications needed to be able to run the patching from powershell

I have adapted the instructions to use discrete commands so there are no more for-loops.

As a windows user I also had to add the following to successfully run the last command
(error: *** Please tell me who you are.)

This is one of those problems an existing Git user (like me) will never hit during testing because my ~/.gitconfig is always set up. It isn't just Windows users who need to do this so I've added a check/setup step.

this can be done using this oneliner in powershell before the 'go build'

$env:GOOS="linux"; $env:GOARCH="amd64"; go build -o GoSungrow-linux-amd64

I have added the equivalent of that for arm64 below the existing cross-compiling example. I also realised that you had used hyphen separators rather than underscores. I assume there was a reason for that on Windows. It makes no difference on Linux or macOS so I've changed to use hyphens for consistency.

Here I had some issues, I believe they were due to having multiple docker images, trying to follow the guide before this new part was added. also I have tried to install GoSungrow2MQTT witch will be included in the
"docker images | grep -e REPOSITORY -e gosungrow"

Someone having both add-ons installed would be a bit unusual, wouldn't it?

I suppose you could always adapt the command to filter-out anything with mqtt in the name:

# docker images | grep -e REPOSITORY -e gosungrow | grep -v "mqtt"

To transfer the file to my HA, i used WinSCP to place it in the suggested folder, that way I do not need to set up my Windows with a SCP share.

Getting the binary to the right place is always going to be situation-specific. I can't try to capture all the possibilities.

As I said yesterday, doing everything on your HA instance is still an option. Then there's no need to cross-compile and no need to copy between systems.

Cucucatchuu!

😎

Still I will try to talk to Sungrow on the advantage for them to crate an official integration for HA, I know they understand the need from customers in regards of this.

An official integration, supported by them, would be brilliant.

The "good" thing about GoSungrow is that you can get to any value that your inverter collects. Elsewhere I've explained that I don't actually use either HA or the add-on so a lot of this gist is just me paying-it-forward to the wider community. Anyway, I just like nutting-out problems.

The downside of GoSungrow is, of course, that it is not being actively maintained (for reasons that are not clear) and is somewhat crash-happy. Unless someone with more Go skill than I have steps up, forks the project, and takes on the maintenance, it seems to me that there will be more and more "drift" over time as Sungrow releases products.

Putting those together, an "official integration" which afforded access to any value that your inverter collects (rather than some cut-down list derived from what some Sungrow in-house technoweenie thought was all anyone would ever need) would be perfect.

this current solution is not for the light-hearted.

I so agree!

Anyway, thanks for all your detailed feedback which I've now been able to incorporate into the gist.

Paraphraser/Compiling GoSungrow.md

Updating GoSungrow

about this gist

Part 1 — Compiling GoSungrow

Assumptions

Using your Home Assistant instance to recompile GoSungrow

Prepare your system (Linux+macOS)

Install/Update Go compiler

Linux (including your Home Assistant instance)

macOS

Windows

Confirm compiler installation (Linux+macOS)

Compile GoSungrow

Check your work

1. Confirm GoSungrow compiled

2. Update the APPKey

3. Set your gateway (optional)

4. Confirm success

Cross-compiling

Cross-compiling helper script

Using the recompiled binary

Part 2 — removed

Part 3 — Using a patched binary

Part 4 — Using a patched Docker image

Initial setup

Running the container

Part 5 — Patching the broken Home Assistant add-on

Advanced SSH and Web Terminal

Configuration

iSolarCloud gateway configuration

APPKey configuration

Undoing Part 5

The last resort

Change History

gR-xbY commented Sep 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sharkpunch5 commented Sep 7, 2024

Uh oh!

Paraphraser commented Sep 7, 2024

Uh oh!

Paraphraser commented Sep 7, 2024

Uh oh!

Paraphraser commented Sep 7, 2024

Uh oh!

gR-xbY commented Sep 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Paraphraser commented Sep 9, 2024

Uh oh!

gR-xbY commented Sep 26, 2024

Uh oh!

Paraphraser commented Sep 26, 2024

Uh oh!

Paraphraser commented Sep 26, 2024

Uh oh!

gR-xbY commented Sep 26, 2024

Uh oh!

Paraphraser commented Sep 28, 2024

Uh oh!

gR-xbY commented Oct 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DerSpatz commented Dec 26, 2024

Uh oh!

Paraphraser commented Dec 26, 2024

Uh oh!

bamcauliffe commented Apr 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

monojk commented Oct 12, 2025

Uh oh!

Paraphraser commented Oct 12, 2025

Uh oh!

monojk commented Oct 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Paraphraser commented Oct 12, 2025

Uh oh!

monojk commented Oct 13, 2025

gR-xbY commented Sep 6, 2024 •

edited

Loading

gR-xbY commented Sep 9, 2024 •

edited

Loading

gR-xbY commented Oct 1, 2024 •

edited

Loading

bamcauliffe commented Apr 19, 2025 •

edited

Loading

monojk commented Oct 12, 2025 •

edited

Loading

51iMM commented Dec 8, 2025 •

edited

Loading

51iMM commented Dec 8, 2025 •

edited

Loading