MickMake
One more time: Found SunGrow 0 devices
Token File: /data/.GoSungrow/AppService_login.json [02:38:46] INFO: Syncing data from gateway https://gateway.isolarcloud.eu ... 2025/07/10 02:38:46 INFO: Connecting to MQTT HASSIO Service... 2025/07/10 02:38:46 INFO: Connecting to SunGrow... 2025/07/10 02:38:48 INFO: Found SunGrow 0 devices 2025/07/10 02:38:48 INFO: Option[fetchschedule] set to '2m' 2025/07/10 02:38:48 INFO: Caching Sungrow metadata... 2025/07/10 02:38:48 INFO: Cached 0 Sungrow data points... No results found. 2025/07/10 02:38:48 INFO: Syncing 1 entries with HASSIO from getPsList. CU 2025/07/10 02:38:48 INFO: Starting ticker... 2025/07/10 02:38:48 INFO: Fetch Schedule: 2m 2025/07/10 02:38:48 INFO: Sleep Delay: 40s 2025/07/10 02:41:48 INFO: Syncing 1 entries with HASSIO from getPsList. U No results found. ————————————————————————
Any solution for this issue? The previous users with this problem solved it, but never said how they did it. :-(
My setup is the GoSunGrow-add-on for HA, which runs on ProxMox on an Intel NUC.
Thanks for any suggestions or help! Chris
Sounds like it could be a valid account but your equipment isn't actually logging to that account.
You might be able to get more information like this (I'm assuming you have the "Advanced SSH & Web Terminal" installed in your Home Assistant instance):
-
Use SSH to connect to Home Assistant.
-
Open a shell into the GoSungrow add-on container:
docker exec -it addon_ba22da74_gosungrow bashIf that doesn't work then run:
docker ps -a --format "table {{.Names}}\t{{.RunningFor}}\t{{.Status}}\t{{.Size}}" --filter name=gosungrowwhich will give you the correct name in the NAMES column. Replace
addon_ba22da74_gosungrowin the previous command with the correct name. -
Now that you have a shell inside the container, try logging-in to iSolarCloud:
GoSungrow --config /data/.GoSungrow/config.json api loginIf login fails then you might get a hint as to why from the output.
-
If login succeeds then run:
GoSungrow --config /data/.GoSungrow/config.json show ps listIf you get nothing then it probably confirms my original suspicion.
-
You need two
exitcommands (or two control+d) to drop out of the container and then disconnect from SSH.
Note that you always need:
--config /data/.GoSungrow/config.json
when working inside the container. That file gets seeded from the "configuration" tab for the GoSungrow add-on in Home Assistant.
➜ ~ docker exec -it addon_ba22da74_gosungrow bash
bash-5.1# GoSungrow --config /data/.GoSungrow/config.json api login
Email: chriXXXXXXXXXXXXXXXXXXXXX
Create Date: Thu Jul 10 05:24:18 CST 2025
Login Last Date: 2025-07-14 02:57:32
Login Last IP:
Login State: 1
User Account: WhXXXXXXXXXXXXXX
User Id: 71XXXXXXX
User Name: CS_Vollzugriff/Installateur
Is Online: false
Token: 710117_69c127b60ba04947bf58cb2729e87e47
Token File: /root/.GoSungrow/AppService_login.json
bash-5.1# GoSungrow --config /data/.GoSungrow/config.json show ps list
┏━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Ps Key ┃ Ps Id ┃ Device Type ┃ Device Code ┃ Channel Id ┃ Serial # ┃ Factory Name ┃ Device Model ┃
┣━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┫
┗━━━━━━━━┷━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━┷━━━━━━━━━━┷━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━┛
bash-5.1# exit
Thank you for trying to help. This is the result of your "instructions". BTW, I didn´t mention the type of my inverter: SunGrow SH20T with the WiNet-S2-dongle, which is connected via LAN.
The thing is, when I login on the official iSolarCloud website, I can see all the data. So my equipment does connect and log to the account. Any other ideas? Highly appreciated. :-)
Thanks from Austria, Chris
I'm no expert on any of this. But, when I compare your output with what I see when I login using GoSungrow, the one thing that stands out is:
User Name: CS_Vollzugriff/Installateur
whereas mine is:
User Name: Phill
As far as I can tell, "Phill" comes from the "Nickname" field in:
- iSolarCloud » Account » tap in the Profile at the top of the screen
I'm pretty sure I would have typed "Phill" into some setup screen at some point.
When I ask for a translation of "Vollzugriff Installateur" I get "full access installer". That at least suggests the possibility that you are using an account which is intended to give you access to a whole lot of different customers' equipment. If so then, logically, there must be some step that goes before show ps list where you have to identify the customer so that the API knows which customer's ps list to fetch.
I have no idea whether MickMake is just an ordinary user or an installer or had some other level of privilege which allowed him to see more than his own equipment. If I assume MickMake is an "ordinary user" who can only see his own equipment, then he may not even have been aware that there might be situations where it would be necessary to "identify the customer", either as a preliminary step or by passing another parameter on API calls. And if that's true then it would probably imply that the necessary functionality doesn't exist in GoSungrow. Still, this is all speculation and, as I said at the start, I'm no expert.
So let's rule a line under that. What I do recall is when my own installer started to set things up, he was using a mixture of his own credentials and my email address. I had read a document on one of SunGrow's web sites which said it was something a user should do. Plus, he was using the wrong email address so I stopped him and did it myself. I know he can see my plant and I presume he can see the plants of all the other customers he has installed. I, of course, can only see my own plant.
My guess is that, when it comes to your plant that you probably need to login as an ordinary user rather than as a "Vollzugriff Installateur". That would avoid the "pre-identify the customer" step.
To be clear, when I say "login as an ordinary user" I mean the values in the sungrow_user and sungrow_password fields of the Configuration tab of the GoSungrow add-on.
At the command-line, the equivalent would be something like:
cp /data/.GoSungrow/config.json .
GoSungrow --config config.json config write --user «ordinaryUsername» --password «ordinaryUserPassword»
GoSungrow --config config.json api login
GoSungrow --config config.json show ps list
In words:
- Make a copy of the running config file.
- Set credentials in the copy.
- Login using those credentials.
- See if you can fetch the PS list.
I'd advise caution at step 3 because it looks to me like iSolarCloud imposes a lockout if you get too many login failures in a row.
You said you can see your own data when you login to the iSolarCloud web site. I don't think that's surprising because, presumably, you are both the installer and the customer so, when you login as an installer, you can see all your customers including yourself. If you need to click on your own plant to see your own data, it's that "click on your own plant" step that I'm talking about which is probably missing from GoSungrow. If you see your own plant by default then, presumably, there's some "settings" or "profile" somewhere via which the web site knows to show you your own plant first. Still just guessing...
I could get this far now:
2025/07/14 10:00:34 INFO: Found SunGrow 4 devices 2025/07/14 10:00:34 INFO: Option[homeassistant/select/GoSungrow/GoSungrow-option-mqtt_loglevel/cmd] set to 'enabled' 2025/07/14 10:00:34 Unknown log level, setting to default. 2025/07/14 10:00:34 INFO: Option[fetchschedule] set to '5m' 2025/07/14 10:00:34 INFO: Caching Sungrow metadata... 2025/07/14 10:00:34 INFO: Cached 716 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(, {{, , }}, {0xc000a92c00, {0xc000885897, 0x7}, {0xc21553309baaaaf6, 0x46cf303, 0x4b5fa20}, ...}) /Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:336 +0x4d3 github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).GetEnergyStorageSystem(, {0xc000a92c00, {0xc000885897, 0x7}, {0xc21553309baaaaf6, 0x46cf303, 0x4b5fa20}, {{0xc00046f3a0, 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(, {, _}, {{0xc000a53e00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...}, ...}) /Users/isit/git/GoSungrow/iSolarCloud/data.go:160 +0x3f3 github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).getDataSinglePsIdRequired(0xc0005c1478, {0x2ed71f8, 0xc000710a80}) /Users/isit/git/GoSungrow/iSolarCloud/data.go:283 +0x36c github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).GetDataSingle(0xc0005c1478, {0xc000a12d60, 0xf}) /Users/isit/git/GoSungrow/iSolarCloud/data.go:238 +0x14f github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).GetData(0xc0005c1478) /Users/isit/git/GoSungrow/iSolarCloud/data.go:209 +0x152 github.com/MickMake/GoSungrow/cmd.(*CmdMqtt).Cron(0xc00061e000) /Users/isit/git/GoSungrow/cmd/cmd_mqtt.go:375 +0x2b7 github.com/MickMake/GoSungrow/cmd.(*CmdMqtt).CmdMqttRun(0xc00061e000, 0x0?, {0x0?, 0x0?, 0x0?}) /Users/isit/git/GoSungrow/cmd/cmd_mqtt.go:273 +0x85 github.com/spf13/cobra.(*Command).execute(0xc00061d800, {0xc00003e1a0, 0x0, 0x0}) /Users/isit/go/pkg/mod/github.com/spf13/[email protected]/command.go:940 +0x862 github.com/spf13/cobra.(*Command).ExecuteC(0xc000004300) /Users/isit/go/pkg/mod/github.com/spf13/[email protected]/command.go:1068 +0x3bd github.com/spf13/cobra.(*Command).Execute(...) /Users/isit/go/pkg/mod/github.com/spf13/[email protected]/command.go:992 github.com/MickMake/GoUnify/Unify.(*Commands).Execute(...) /Users/isit/go/pkg/mod/github.com/!mick!make/[email protected]/Unify/struct.go:277 github.com/MickMake/GoUnify/Unify.(*Unify).Execute(0xc0000d92c0) /Users/isit/go/pkg/mod/github.com/!mick!make/[email protected]/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
What else do I have to change or fix to get further?... :-)
Thanks for your advice. :-)
Once again I feel the need to begin by emphasising that I am not an expert in any of this. I have a lot of experience writing code in many programming languages but Go has never been among them. This is just guesswork.
If we take the stack-trace at face value and assume the line numbers are accurate then the last line of this:
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(, {{, , }}, {0xc000a92c00, {0xc000885897, 0x7}, {0xc21553309baaaaf6, 0x46cf303, 0x4b5fa20}, ...})
/Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:336 +0x4d3
leads us to this line in the code:
batteryChargeEnergy.DataStructure.PointUpdateFreq = GoStruct.UpdateFreqDay
That's an assignment. The right hand side is initialised here and an equivalent assignment occurs at line 332 in SetBatteryPoints() so the right hand side would not appear to be the cause of the error.
That implies the left hand side is the problem. The batteryChargeEnergy variable appears to be initialised at line 334:
batteryChargeEnergy := entries.CopyPointFromName(epp.AddString("p13174"), epp, "battery_charge_energy", "Battery Charge Energy (p13174)")
The crash ("invalid memory address or nil pointer dereference") suggests that the most likely reason is entries.CopyPointFromName() failed.
Lines 330..332 have the same pattern and apparently succeeded. The most plausible explanation for the difference in behaviour is that the p13029 point exists while the p13174 point does not.
I find support for this in the structure of the CopyPointFromName() function. The Current variable is declared but is only initialised if one of the three if tests succeeds, which means there's a path through the code where Current is returned uninitialised (and, given the way most memory-safe languages behave these days, is probably nil).
Were this my code, I'd at least consider initialising
Currentto a valid structure with sensible defaults which would stick out like a sore thumb in reports or MQTT messages coming out of GoSungrow. But whether that would make sense in this context is something I can't say. Maybe allowing the code to crash is appropriate.
The main reason I'm laying out this thought process in detail is in the hope people who know more Go than I do can chime in if I've misunderstood.
I get silence when I run this command:
$ GoSungrow show ps points | grep -e "p13029" -e "p13174"
Silence means that neither of those point identifies is present in my list. One explanation is I simply do not have batteries so battery-related metrics do not make it into my list.
On the other hand:
$ GoSungrow show ps points | grep -i -c -e "battery" -e "charge"
64
A count of 64 means a significant number of rows that include those words.
I'm hoping that if you run:
$ GoSungrow show ps points | grep -e "p13029" -e "p13174"
that you'll get a hit on p13029 but not p13174.
It might also be instructive to run this:
$ GoSungrow show ps points | grep -e "p13003" -e "p13029" -e "p13112" -e "p13116" -e "p13119" -e "p13121" -e "p13122" -e "p13126" -e "p13130" -e "p13134" -e "p13144" -e "p13147" -e "p13149" -e "p13150" -e "p13173" -e "p13174" -e "p13199" -e "p8354"
Those are all the point identifiers mentioned in the queryDeviceList package.
Hi there,
I've got a similar problem. I can login via GoSungrow api login . But running GoSungrow show ps list I get an empty list.
┏━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓ ┃ Ps Key ┃ Ps Id ┃ Device Type ┃ Device Code ┃ Channel Id ┃ Serial # ┃ Factory Name ┃ Device Model ┃ ┣━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┫ ┗━━━━━━━━┷━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━┷━━━━━━━━━━┷━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━┛
I can see my power plant in the browser. Do I have to enable api access to my plant somewhere?
I found https://github.com/MickMake/GoSungrow/issues/18#issuecomment-1445300680 So it seems to me, Sungrow is messing up with the rights. Management rights don’t seem to be enough 😳
@JerryWho please see comment on issue 70 and see whether that makes sense in your context.
My working theory is:
- Use either iSolarCloud app or a web browser.
- Login as the owner.
- Configure GoSungrow to also login as the owner.
I haven't heard the term "Management rights" until now. Can you elaborate?