MickMake / GoSungrow

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

Is this still working? #112

Open BlueScreenTT opened 7 months ago

BlueScreenTT commented 7 months ago

Hi

I see that all the pictures are from the "old" interface from Sungrow is this still working with the new version they have released "isolarcloud"

also i can not find anywhere to download the api key

\Thomas

Paraphraser commented 7 months ago

I see that all the pictures are from the "old" interface from Sungrow

Firstly, the owner/maintainer of this repository (@MickMake) has not been active since 2023 so that explains why nothing on the repository has changed recently. I do not know why MickMake has not been active. I also have no knowledge of when, or if, that situation is likely to change. If anyone else has any insights into this, they have yet to share their knowledge. We're all in the dark.

Secondly, although the foregoing explains why the first two images have not been updated, to the best of my knowledge the remaining images are the product of GoSungrow and Home Assistant, so there would seem to be no good reason why those would be affected by changes to the iSolarCloud app UI.

is this still working with the new version they have released "isolarcloud"

GoSungrow still works. Some people report problems such as you'll see being explored in #111. The working hypothesis at the moment is that the people having trouble are more likely to have either multiple inverters, or have replaced an inverter and their existing iSolarCloud account holds both historical and current data. A comment on issue 111 earlier today reported success deleting bogus plant data.

I have no idea about the relative proportions of users who have no trouble with GoSungrow in its current form, vs those who can't get it to work. I'm in the former group.

also i can not find anywhere to download the api key

Please read this gist. At least one of the four use cases summarised at the top probably covers what you want to do. The gist includes the new API key (B0455FBE7AA0328DB57B59AA729F05D8).

Someone else also posted a comment to issue 101 which included ANDROIDE13EC118BD7892FE7AB5A3F20 and said it worked.

I'm using the B0… key. I have not tested the ANDROID… key.


A lot of what is in the gist I mentioned above may seem overly-complicated at first glance and it probably is. However, it's the product of what various contributors have the skills, time and willingness to do.

In an ideal world we (the community of users) would know what is behind MickMake's inactivity and then be in a better position to decide whether to fork the repository. But that would also depend on someone wanting to step up and take ownership of processing pull requests, debugging problems, building release artifacts, distributing Docker images for Home Assistant, and so on. That's a big commitment and nobody has yet put up his/her hand to accept that responsibility.

In short, the situation now is the best we can do.

BlueScreenTT commented 7 months ago

Thank you for the answer :-)

biggest problem now is to get the API key

cant get in contact with the right people that can actually send it to me from Sungrow :-/

ill test to get it working when i finally get the key \Thomas

Den ons. 24. apr. 2024 kl. 09.22 skrev Phill @.***>:

I see that all the pictures are from the "old" interface from Sungrow

Firstly, the owner/maintainer of this repository @.*** https://github.com/MickMake) has not been active since 2023 so that explains why nothing on the repository has changed recently. I do not know why MickMake has not been active. I also have no knowledge of when, or if, that situation is likely to change. If anyone else has any insights into this, they have yet to share their knowledge. We're all in the dark.

Secondly, although the foregoing explains why the first two images have not been updated, to the best of my knowledge the remaining images are the product of GoSungrow and Home Assistant, so there would seem to be no good reason why those would be affected by changes to the iSolarCloud app UI.

is this still working with the new version they have released "isolarcloud"

GoSungrow still works. Some people report problems such as you'll see being explored in #111 https://github.com/MickMake/GoSungrow/issues/111. The working hypothesis at the moment is that the people having trouble are more likely to have either multiple inverters, or have replaced an inverter and their existing iSolarCloud account holds both historical and current data. A comment on issue 111 https://github.com/MickMake/GoSungrow/issues/111#issuecomment-2073954461 earlier today reported success deleting bogus plant data.

I have no idea about the relative proportions of users who have no trouble with GoSungrow in its current form, vs those who can't get it to work. I'm in the former group.

also i can not find anywhere to download the api key

Please read this gist https://gist.github.com/Paraphraser/cad3b0aa6428c58ee87bc835ac12ed37. At least one of the four use cases summarised at the top probably covers what you want to do. The gist includes the new API key ( B0455FBE7AA0328DB57B59AA729F05D8).

Someone else also posted a comment to issue 101 https://github.com/MickMake/GoSungrow/issues/101#issuecomment-2072929491 which included ANDROIDE13EC118BD7892FE7AB5A3F20 and said it worked.

I'm using the B0… key. I have not tested the ANDROID… key.

A lot of what is in the gist I mentioned above may seem overly-complicated at first glance and it probably is. However, it's the product of what various contributors have the skills, time and willingness to do.

In an ideal world we (the community of users) would know what is behind MickMake's inactivity and then be in a better position to decide whether to fork the repository. But that would also depend on someone wanting to step up and take ownership of processing pull requests, debugging problems, building release artifacts, distributing Docker images for Home Assistant, and so on. That's a big commitment and nobody has yet put up his/her hand to accept that responsibility.

In short, the situation now is the best we can do.

— Reply to this email directly, view it on GitHub https://github.com/MickMake/GoSungrow/issues/112#issuecomment-2074251183, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVMLI3ZTMCABG5FSRHNXRMLY65MSBAVCNFSM6AAAAABGWHLDRWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUGI2TCMJYGM . You are receiving this because you authored the thread.Message ID: @.***>

Paraphraser commented 7 months ago

The API key is B0455FBE7AA0328DB57B59AA729F05D8.

As I said, it's in the gist.

BlueScreenTT commented 7 months ago

Yes i see :-). Still dont work. Will not connect.:-/

Paraphraser commented 7 months ago

You are going to have to provide more information.

How are you trying to run GoSungrow? Are you doing it as the "add-on" in Home Assistant, or are you running the standalone binary?

If you are using the add-on, have you followed Part 2 of the gist? What do you see in the log inside Home Assistant?

If you are running it standalone, what is it saying when you try to run it? Did you recompile it yourself (gist part 1) or did you download a patched binary (gist part 3)?

Either way it's a good idea to sanitise your email address, iSolarCloud username and password before you post anything here. And, when you post log messages here, please remember to put the text inside triple-back-ticks (known as "code fences"), like this:

``` your log lines here ```

Putting stuff between triple-back-ticks means it appears "as is" and doesn't wrap the lines of text. It makes it much easier for someone else (like me) to see what is going on.

BlueScreenTT commented 7 months ago

So

yes i use the "plugin" in HomeAssistant.

i get the error

[07:17:32] INFO: Login to iSolarCloud using gateway https://augateway.isolarcloud.eu
Error: API httpResponse is 404 Not Found
Usage:
  GoSungrow api login [flags]

Examples:
    GoSungrow api login  

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

Additional help topics:

ERROR: API httpResponse is 404 Not Found
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

i have also tried with the .com adr then i get error

[07:33:16] INFO: Login to iSolarCloud using gateway https://augateway.isolarcloud.com ...
Error: unknown error 'Request is not encrypted'
Usage:
  GoSungrow api login [flags]

Examples:
    GoSungrow api login  

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

Additional help topics:

ERROR: unknown error 'Request is not encrypted'
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

so there is more life in the .com but i cant get rid of the "secure" error

problem is that i am running on the european server. i cant even login on the international server online so the thought was to use the .EU but yes it dont seem to exist

\Thomas

Paraphraser commented 7 months ago

Assuming you're in the EU, you need to set the gateway to:

https://gateway.isolarcloud.eu/

Compare the correct URL (above) with the incorrect URL you have been using, below:

https://augateway.isolarcloud.eu/

I am pretty sure it's that "au" after the "//" that is your problem.

I only know of two valid URLs. There's the EU one above and https://augateway.isolarcloud.com/ which is the default and is also the one I use myself. There may be other URLs for other parts of the world but I don't know what they are.

BlueScreenTT commented 7 months ago

yes it tries to connect but same problem. "Request is not encrypted" :-(

[09:39:37] INFO: Login to iSolarCloud using gateway https://gateway.isolarcloud.eu ...
Error: unknown error 'Request is not encrypted'
Usage:
  GoSungrow api login [flags]

Examples:
    GoSungrow api login  

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

Additional help topics:

ERROR: unknown error 'Request is not encrypted'
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

f....

i give up :-( ill just use the app

Paraphraser commented 7 months ago

"Request is not encrypted" is the direct result of not having performed all of the steps in gist part 2.

If you firmly believe you have done that then, please do this:

  1. Connect to Home Assistant.
  2. Go into the Advanced SSH & Web Terminal.
  3. Type the command:
docker images

Paste the output into your reply between triple-back-ticks.

BlueScreenTT commented 7 months ago

Ill try again. Might have gotten something wrong following the guide

Den fre 26 apr. 2024 11:55Phill @.***> skrev:

"Request is not encrypted" is the direct result of not having performed all of the steps in gist part 2 https://gist.github.com/Paraphraser/cad3b0aa6428c58ee87bc835ac12ed37#encryptionhack .

If you firmly believe you have done that then, please do this:

  1. Connect to Home Assistant.
  2. Go into the Advanced SSH & Web Terminal.
  3. Type the command:

docker images

Paste the output into your reply between triple-back-ticks.

— Reply to this email directly, view it on GitHub https://github.com/MickMake/GoSungrow/issues/112#issuecomment-2079043657, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVMLI34WIAEYOXV2VVEO2DDY7IQCBAVCNFSM6AAAAABGWHLDRWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZZGA2DGNRVG4 . You are receiving this because you authored the thread.Message ID: @.***>

BlueScreenTT commented 6 months ago

yeah so i might have messed up something last time. now i get a different error

Sungrow API EndPoint not yet implemented

[11:08:11] INFO: Login to iSolarCloud using gateway  https://gateway.isolarcloud.eu ...
Sungrow API EndPoint not yet implemented
Error: Sungrow API EndPoint not yet implemented
Usage:
  GoSungrow api login [flags]

Examples:
    GoSungrow api login  

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

Additional help topics:

ERROR: Sungrow API EndPoint not yet implemented
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
BlueScreenTT commented 6 months ago

WT.....

after 5 restarts and trying different options on the server connection it suddently connected ! ??

i have no idea what i did

-+
[11:20:56] INFO: Login to iSolarCloud using gateway https://gateway.isolarcloud.eu ...
Email:  xxxxxxx
Create Date:    Wed Mar 13 21:09:35 CST 2024
Login Last Date:    2024-04-28 19:20:56
Login Last IP:  
Login State:    1
User Account:   xxxxxx
User Id:    xxxxxx
User Name:  xxxxxx
Is Online:  false
Token:  xxxxxxxxxx
Token File: /data/.GoSungrow/AppService_login.json
[11:20:56] INFO: Syncing data from gateway https://gateway.isolarcloud.eu ...
2024/04/28 11:20:56 INFO: Connecting to MQTT HASSIO Service...
2024/04/28 11:20:56 INFO: Connecting to SunGrow...
2024/04/28 11:20:57 INFO: Found SunGrow 3 devices
2024/04/28 11:20:57 INFO: Caching Sungrow metadata...
2024/04/28 11:20:57 INFO: Cached 441 Sungrow data points...
2024/04/28 11:20:58 INFO: Syncing 244 entries with HASSIO from getPsDetail.
CUCUCUCUCUCUCUCUCUCUCU?CUCU?CU?CUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CU?CUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCU?CUCUCUCUCUCUCU?CUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU??CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU??CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCU
2024/04/28 11:20:58 INFO: Syncing 2436 entries with HASSIO from queryDeviceList.
2024/04/28 11:20:58 INFO: Syncing 148 entries with HASSIO from getPsList.
CU-CUCUCU--CU-CUCUCU---CU---CUCUCUCUCUCUCUCUCUCUCUCUCUCUCU--CU-CU-CU--CU----CUCU-CUCU--CUCUCUCUCUCUCU-CUCU-CU-----CUCU-CUCUCU-CU-CUCU--CUCU-CUCUCU-CUCU---CU-CUCUCU--CUCUCUCUCU---CU---CU-CUCUCU-CUCU--CU-CUCUCUCUCUCUCUCU-CUCUCUCUCU-CUCUCUCU-CU--CUCU--CUCU--CUCUCUCUCUCUCU-CU-CUCUCUCUCUCU--CU---CU-CUCU---CUCUCU---CUCU---CUCU--CUCUCU-CUCU-CUCUCUCU-CU-CU-CU--CU---CUCU-CU-CU---CU-CUCUCUCU-CUCUCUCUCU-CUCU-
CU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCU?CUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCUCU
2024/04/28 11:20:58 INFO: Starting ticker...
2024/04/28 11:20:58 INFO: Fetch Schedule: 5m
2024/04/28 11:20:58 INFO: Sleep Delay:    40s
Paraphraser commented 6 months ago

A couple of people have reported "EndPoint not yet implemented". See #19 and this gist comment.

The following search suggests the message is probably coming from GoSungrow rather than iSolarCloud:

$ git grep "EndPoint not yet implemented"
iSolarCloud/api/web.go: w.Error = errors.New("Sungrow API EndPoint not yet implemented")

At a guess, it likely means the iSolarCloud API has returned an endpoint (a metric) that GoSungrow doesn't know how to handle.

As to why it has gone away, your guess is as good as mine. The lack of ongoing complaints in those two hits I mentioned above suggests it is transient rather than persistent.

Will it come back? No idea. However, if it does, I will only be able to give you the same answer which boils down to "no idea".

Sorry I can't be more help.

Sn0w3y commented 6 months ago

And again..

Hello @ALL !

use GoSungrow config write --appkey ANDROIDE13EC118BD7892FE7AB5A3F20 and it works ;-)

Greetings :)

jangoetz commented 6 months ago

And again..

Hello @ALL !

use GoSungrow config write --appkey ANDROIDE13EC118BD7892FE7AB5A3F20 and it works ;-)

Greetings :)

That was the solution for me!!! Thanks a lot!!!

stniemin commented 6 months ago

I had done the docker image swap fix a few months back. After the Home Assistant Supervisor 2024.04.4 update the GoSungrow add-on stopped working. I realized the original 3.0.7 docker image had been reloaded and the replacement one was not being used anymore. So, without knowing much about docker images, I removed the triamazikamno image and the backup one, then followed the instructions/part 2 again. After that GoSungrow is working again.

And for the record, I'm using the key B0455FBE7AA0328DB57B59AA729F05D8 with the .eu server.

Paraphraser commented 6 months ago

Hmmm. So now we have @stniemin giving us a classic case of the exception proving the rule. My hypothesis of a 1:1 relationship between an AppKey and an iSolarCloud server goes straight out the window.

There must be another explanation.

Every time I look at the ANDROID key, I wonder why it has that prefix?

New hypothesis: There is a relationship between the AppKey each person needs to use and the platform that person employed when first setting up the iSolarCloud account (or, perhaps, registering the most-recent inverter).

In my own case, after my (first and only) Sungrow inverter was set up, I used the iSolarCloud app on my iPad to do all the setup steps. In other words, I used iOS (or, if you're an Apple purist, iPadOS) and the B0455 key works for me.

What's the story with anyone (eg @jangoetz @Sn0w3y @grechi-diego) who has found they need to use the ANDROID key? Did you set things up on an Android device?

jangoetz commented 6 months ago

Hmmm. So now we have @stniemin giving us a classic case of the exception proving the rule. My hypothesis of a 1:1 relationship between an AppKey and an iSolarCloud server goes straight out the window.

There must be another explanation.

Every time I look at the ANDROID key, I wonder why it has that prefix?

New hypothesis: There is a relationship between the AppKey each person needs to use and the platform that person employed when first setting up the iSolarCloud account (or, perhaps, registering the most-recent inverter).

In my own case, after my (first and only) Sungrow inverter was set up, I used the iSolarCloud app on my iPad to do all the setup steps. In other words, I used iOS (or, if you're an Apple purist, iPadOS) and the B0455 key works for me.

What's the story with anyone (eg @jangoetz @Sn0w3y @grechi-diego) who has found they need to use the ANDROID key? Did you set things up on an Android device?

I can confirm that I did my first Setup on an Android device... But before yesterday, everything worked well with the "B0455" Appkey.

BlueScreenTT commented 6 months ago

i used https://gateway.isolarcloud.eu and B0455FBE7AA0328DB57B59AA729F05D8

all still working :-) even after a couple of reboots of my HA installation

Paraphraser commented 6 months ago

@BlueScreenTT and did you do your original setup with an iOS device or an Android device?

BlueScreenTT commented 6 months ago

So. i have my own account made from the web but i access the app via Android.

The Electrician responsible for the installation did the config in his app on an Android Phone and then shared the installation with me. So Android almost all the way

grechi-diego commented 6 months ago

L'ho configurato con un dispositivo Android

Il gio 2 mag 2024, 12:17 Phill @.***> ha scritto:

@BlueScreenTT https://github.com/BlueScreenTT and did you do your original setup with an iOS device or an Android device?

— Reply to this email directly, view it on GitHub https://github.com/MickMake/GoSungrow/issues/112#issuecomment-2090100685, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO6MNOFJ7DISX2JP4TIZUATZAIHFBAVCNFSM6AAAAABGWHLDRWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJQGEYDANRYGU . You are receiving this because you were mentioned.Message ID: @.***>

TheAussieTim commented 5 months ago

Hmmm. So now we have @stniemin giving us a classic case of the exception proving the rule. My hypothesis of a 1:1 relationship between an AppKey and an iSolarCloud server goes straight out the window.

There must be another explanation.

Every time I look at the ANDROID key, I wonder why it has that prefix?

New hypothesis: There is a relationship between the AppKey each person needs to use and the platform that person employed when first setting up the iSolarCloud account (or, perhaps, registering the most-recent inverter).

In my own case, after my (first and only) Sungrow inverter was set up, I used the iSolarCloud app on my iPad to do all the setup steps. In other words, I used iOS (or, if you're an Apple purist, iPadOS) and the B0455 key works for me.

What's the story with anyone (eg @jangoetz @Sn0w3y @grechi-diego) who has found they need to use the ANDROID key? Did you set things up on an Android device?

To throw a further spanner into the hypothesis works: I set up my iSolarCloud environment originally with my iPhone, and have never involved an Android device in the process. However, I've just returned to tinkering with this after a while of leaving it be, and in reading through solutions for the API error I've tested the ANDROID api with the augateway.isolarcloud.com host, and it successfully connects. So I'm totally not sure what significance that name has to the end user. Maybe it was involved in the creation of the api at the other end?

RafAustralia commented 3 months ago

Hey @Paraphraser

Your comments are really cool, and I envy how much u understand. these also show me how out of depth I am. But I do have a question. I have tried installing GoSungrow api on my HA and while install went ok. It crashes and I get error ….

Error: unknown error 'Missing parameter in request header: x-access-key'

I do have proper info from my contacts at sungrow who prepared all details codes and keys and created an API account… but there is nowhere to put in the missing code. How can this be added?

I am totally new to json and did some however little digging in my ssh but cannot seem to find config.json either.

Any pointers? Advice? Help? Would it be possible to discuss trying to add config.json and necessary directory entries to get it to start?

Being upfront… I am super fresh to json config so please do not hate my questions.... I just need little bit of help from someone who knows programming...

I hope once I can get GoSungrow configured I can get it to connect.

And thank u for any kind of reply in advance. Sincerely.

gosungrow_x_access_key

Raf

Paraphraser commented 3 months ago

@RafAustralia

I don't think I've seen that error before. I have no idea what it means. I have tried mucking-up my own settings but I can't replicate that problem.

Are you sure you followed all the steps in Gist Part 2?

There has been at least one example where someone eventually found that, although s/he believed the gist steps had been performed correctly, starting over from the beginning solved the problem. Perhaps you could give that a whirl.

I'm no HA expert but my understanding of the way it works is that HA encodes the contents of the configuration tab (YAML) into JSON and passes that to the GoSungrow container when it launches. Inside the container, a startup script parses the JSON and sets up a bunch of environment variables. Then it calls GoSungrow config write which takes the environment variables and generates a config.json. All of this is dynamic and occurs every time the add-on starts. It is that dynamically-generated and non-persistent config.json which is used by GoSungrow (the process) as it goes through the login process and begins fetching data.

This differs from the situation where you compile GoSungrow yourself as a standalone application. I don't know what happens on Windows but on macOS and Linux, you call GoSungrow and pass it various configuration parameters which are then written into:

~/.GoSungrow/config.json

Thereafter, calling GoSungrow api login or other commands reads that file to retrieve credentials. In other words, config.json is something you really only see as a permanent file (which you could actually edit) when you are running GoSungrow standalone.

You can't do any of that when it's running in a Docker container as an add-on for HA.

If you actually want to check the results of the HA startup process (from "Configuration" tab to what GoSungrow (the process running inside the Docker container) actually uses when it starts up, you can do it like this:

  1. Get into the advanced SSH terminal (as per the gist).

  2. Run the docker ps command. You'll see a list of running containers and one of those will contain "gosungrow" in its name. You need the "CONTAINER ID" from that line. It'll be something like "0fab5d5ff74d".

  3. Use the container ID like this:

    $ docker exec 0fab5d5ff74d cat /data/options.json /data/.GoSungrow/config.json

If anything is getting "hosed" between the "Configuration" tab and the options.json, you should be able to spot it in the first part of the output; if it's being misinterpreted between options and getting into config.json it will show up in the second part of the output.

I seem to recall that at least one person has run into trouble by using a password that contained characters that didn't survive this double-translation process so maybe that's your problem too.

I hope that all makes sense.

Why is it all so complicated? No idea. Leaving HA to one side, the pattern of passing configuration parameters into Docker containers using environment variables is fairly well-established. It's actually one of the "signatures" of a well-behaved container. Less-well-behaved containers expect you to create config files beforehand, or expect you to run them once so they can set up defaults which you then tweak. In my experience, the GoSungrow container is a bit unique in taking one JSON file, parsing it to environment vars, then re-interpreting back to another JSON file. But maybe that's a common pattern for HA add-ons. Who knows...

RafAustralia commented 3 months ago

Hey Phill

Thank you ever so kindly. For responding first and foremost. That in itself is already fantastic. So lets start with a thank you.

My level of code knowledge is way below what you explained. I just started 3 months ago. Fast learner with yaml coded my own version of modbus integration for double inverter but beyond that…. Im just too out of depth.

My downfall is knowledge of ssh commands or lack of there of…

I will explain where I am at.

With the user access key given by you in your explanation notes I can replicate your error request is not encrypted. So its kind of step in right direction. Note here clock date is out of whack. Not sure why. Will come back to that.

That means this access code must have already embossed x-access-key into its root code since its not asking for one.

Normal case of API would require access key, x access code. Rsa possibly. So if I try to use my access key it is obviously asking for one. Cos it doesnt recognise it.

Sungrow team was at my place just month ago. They sent me a proper api access with all credentials. So my gut tells me if only I could get to the file which contains all the 4-5 code lines to enter I would simply connect - thats my logic.

Now. I tried to read through your github explanations. I just found it yesterday. It is so complex. To me. But Im reading. Trying. And I will keep trying.

I downloaded git on my HA. Tried to find wget. Couldnt. Not quite sure how to configure it. Yet I tried manually enter commands to advanced ssh. Typing in the commands as per git but it just returns no such directory or other errors.

U are a coder. Im not. So I guess fore me Im missing the core knowledge to sort this out. I understand your process but just not sure how to get there myself.

I sort of edited my own version of config.json in visual studio - and have it validated online…. Could be a go if only I knew where or how to get it into the right place or how to bring up and replace the files I need.

Im super excited u said hi. Again thank u. Means a lot! Ill keep trying but it will be impossibly dauntingly gruesome slow process.

Ill be in front of a laptop later tonight and will put in some more effort.

Fun with HA hey?

🙏🏼❤️🙏🏼

Raf Sent from Nam Concept’s iPhone

On 24 Aug 2024, at 5:48 PM, Phill @.***> wrote:



@RafAustraliahttps://github.com/RafAustralia

I don't think I've seen that error before. I have no idea what it means. I have tried mucking-up my own settings but I can't replicate that problem.

Are you sure you followed all the steps in Gist Part 2https://gist.github.com/Paraphraser/cad3b0aa6428c58ee87bc835ac12ed37#encryptionhack?

There has been at least one example where someone eventually found that, although s/he believed the gist steps had been performed correctly, starting over from the beginning solved the problem. Perhaps you could give that a whirl.

I'm no HA expert but my understanding of the way it works is that HA encodes the contents of the configuration tab (YAML) into JSON and passes that to the GoSungrow container when it launches. Inside the container, a startup script parses the JSON and sets up a bunch of environment variables. Then it calls GoSungrow config write which takes the environment variables and generates a config.json. All of this is dynamic and occurs every time the add-on starts. It is that dynamically-generated and non-persistent config.json which is used by GoSungrow (the process) as it goes through the login process and begins fetching data.

This differs from the situation where you compile GoSungrow yourself as a standalone application. I don't know what happens on Windows but on macOS and Linux, you call GoSungrow and pass it various configuration parameters which are then written into:

~/.GoSungrow/config.json

Thereafter, calling GoSungrow api login or other commands reads that file to retrieve credentials. In other words, config.json is something you really only see as a permanent file (which you could actually edit) when you are running GoSungrow standalone.

You can't do any of that when it's running in a Docker container as an add-on for HA.

If you actually want to check the results of the HA startup process (from "Configuration" tab to what GoSungrow (the process running inside the Docker container) actually uses when it starts up, you can do it like this:

  1. Get into the advanced SSH terminal (as per the gist).

  2. Run the docker ps command. You'll see a list of running containers and one of those will contain "gosungrow" in its name. You need the "CONTAINER ID" from that line. It'll be something like "0fab5d5ff74d".

  3. Use the container ID like this:

$ docker exec 0fab5d5ff74d cat /data/options.json /data/.GoSungrow/config.json

If anything is getting "hosed" between the "Configuration" tab and the options.json, you should be able to spot it in the first part of the output; if it's being misinterpreted between options and getting into config.json it will show up in the second part of the output.

I seem to recall that at least one person has run into trouble by using a password that contained characters that didn't survive this double-translation process so maybe that's your problem too.

I hope that all makes sense.

Why is it all so complicated? No idea. Leaving HA to one side, the pattern of passing configuration parameters into Docker containers using environment variables is fairly well-established. It's actually one of the "signatures" of a well-behaved container. Less-well-behaved containers expect you to create config files beforehand, or expect you to run them once so they can set up defaults which you then tweak. In my experience, the GoSungrow container is a bit unique in taking one JSON file, parsing it to environment vars, then re-interpreting back to another JSON file. But maybe that's a common pattern for HA add-ons. Who knows...

— Reply to this email directly, view it on GitHubhttps://github.com/MickMake/GoSungrow/issues/112#issuecomment-2308177667, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BIGQNNDGMZMPYYPDGB54OBTZTA3ERAVCNFSM6AAAAABGWHLDRWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGE3TONRWG4. You are receiving this because you were mentioned.Message ID: @.***>

Paraphraser commented 3 months ago

@RafAustralia

Have you installed the Advanced SSH & Web Terminal? If not, please do that.

Have you gone to the "Info" tab of Advanced SSH & Web Terminal and:

  1. enabled "Show in sidebar"?
  2. disabled "Protection mode"?

If not, please do that.

Now you should see "Terminal" in the side-bar. When you click it, you will have a terminal window.

This is the same as connecting using an SSH client (ssh on macOS and Linux, something like Putty on Windows). You can do everything you need to do using the Terminal window so you don't actually have to worry about SSH.

Now, "request not encrypted" is pretty much the signature of not having followed all the steps in Part 2 of the gist.

So, let's see what's what.

In the terminal window, please run these commands:

$ docker ps
$ docker images

To be clear, the $ is a convention which means "type the remainder of this command and press return (or "enter" if that's what's written on your keyboard). The first command is just docker ps - right?

You should get something like this:

~ $ docker ps | grep gosungrow
0fab5d5ff74d   ba22da74/amd64-addon-gosungrow:3.0.7                       "/init /usr/local/bi…"   7 hours ago     Up 7 hours                                                                                                                                  addon_ba22da74_gosungrow
~ $ docker images | grep gosungrow
triamazikamno/amd64-addon-gosungrow               3.0.7          f2cbc9418287   8 months ago    161MB
ba22da74/amd64-addon-gosungrow                    3.0.7          f2cbc9418287   8 months ago    161MB
ba22da74/amd64-addon-gosungrow                    3.0.7-backup   2f8714749ba2   11 months ago   161MB

I want you to copy the answers that come back from running those commands and paste those lines into your reply.

You should do it like this. First, a line of triple back-ticks (the back-tick is usually to the left of the "1" on the top row of your keyboard):

```

then you paste your material here, then another line of back-ticks

```

This is known as a "code fence" and it stops GitHub from interpreting everything as running paragraphs.

Now, as to your other points. If you're trying to install tools like git and wget then you're following Part 1 of the gist.

Part 1 of the gist is for compiling GoSungrow to run anywhere except in Home Assistant.

You've said you want to work in Home Assistant. That means you need to follow Part 2 of the gist. Part 1 is irrelevant.

There's nothing stopping you from doing both, providing you actually want to be able to run GoSungrow from both the command line and in Home Assistant. You just need to keep your objectives straight in your mind.

Perhaps, just for now, concentrate on HA. That means focusing on Part 2 and ignoring Parts 1, 3 and 4.

RafAustralia commented 3 months ago

Hey Phill

Thank you again…

Yes my SSH is working totally and fully – always has been – I just do not use it much. It is running properly… no issues. Protection mode is disabled.

@.***

But when I type $ docker ps I get the following:

@.*** It says - command not found.

That’s why I said it confuses me as it almost seems the directories are not there…

Maybe and just maybe it did not install fully?

Raf

RafAustralia commented 3 months ago

Hey

Running $ docker images however returns the following: image

Raf

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. NAM Concept is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

From: Phill @.> Sent: Saturday, August 24, 2024 9:16 PM To: MickMake/GoSungrow @.> Cc: Rafal Tomaszewski @.>; Mention @.> Subject: Re: [MickMake/GoSungrow] Is this still working? (Issue #112)

@RafAustraliahttps://github.com/RafAustralia

Have you installed the Advanced SSH & Web Terminal? If not, please do that.

Have you gone to the "Info" tab of Advanced SSH & Web Terminal and:

  1. enabled "Show in sidebar"?
  2. disabled "Protection mode"?

If not, please do that.

Now you should see "Terminal" in the side-bar. When you click it, you will have a terminal window.

This is the same as connecting using an SSH client (ssh on macOS and Linux, something like Putty on Windows). You can do everything you need to do using the Terminal window so you don't actually have to worry about SSH.

Now, "request not encrypted" is pretty much the signature of not having followed all the steps in Part 2 of the gist.

So, let's see what's what.

In the terminal window, please run these commands:

$ docker ps

$ docker images

To be clear, the $ is a convention which means "type the remainder of this command and press return (or "enter" if that's what's written on your keyboard). The first command is just docker ps - right?

You should get something like this:

~ $ docker ps | grep gosungrow

0fab5d5ff74d ba22da74/amd64-addon-gosungrow:3.0.7 "/init /usr/local/bi…" 7 hours ago Up 7 hours addon_ba22da74_gosungrow

~ $ docker images | grep gosungrow

triamazikamno/amd64-addon-gosungrow 3.0.7 f2cbc9418287 8 months ago 161MB

ba22da74/amd64-addon-gosungrow 3.0.7 f2cbc9418287 8 months ago 161MB

ba22da74/amd64-addon-gosungrow 3.0.7-backup 2f8714749ba2 11 months ago 161MB

I want you to copy the answers that come back from running those commands and paste those lines into your reply.

You should do it like this. First, a line of triple back-ticks (the back-tick is usually to the left of the "1" on the top row of your keyboard):


then you paste your material here, then another line of back-ticks

This is known as a "code fence" and it stops GitHub from interpreting everything as running paragraphs.

Now, as to your other points. If you're trying to install tools like git and wget then you're following Part 1 of the gist.

Part 1 of the gist is for compiling GoSungrow to run anywhere except in Home Assistant.

You've said you want to work in Home Assistant. That means you need to follow Part 2 of the gist. Part 1 is irrelevant.

There's nothing stopping you from doing both, providing you actually want to be able to run GoSungrow from both the command line and in Home Assistant. You just need to keep your objectives straight in your mind.

Perhaps, just for now, concentrate on HA. That means focusing on Part 2 and ignoring Parts 1, 3 and 4.

— Reply to this email directly, view it on GitHubhttps://github.com/MickMake/GoSungrow/issues/112#issuecomment-2308358396, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BIGQNNCZYPF3G23C4CZVRSTZTBTQJAVCNFSM6AAAAABGWHLDRWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGM2TQMZZGY. You are receiving this because you were mentioned.Message ID: @.**@.>>

RafAustralia commented 3 months ago

@paraphraser

Hey Phill

got it... sorry was using $ sign... now corrected. see below:

docker ps

RafAustralia commented 3 months ago

Hey Phill

Learning curve – sorry…

Got these replies:


~ $ docker images

REPOSITORY                                         TAG         IMAGE ID       CREATED         SIZE

ba22da74/aarch64-addon-gosungrow                   3.0.7       8a21246efb09   8 hours ago     118MB

~ $ docker images | grep gosungrow

ba22da74/aarch64-addon-gosungrow                   3.0.7       8a21246efb09   9 hours ago     118MB
RafAustralia commented 3 months ago

@Paraphraser Hey Phill

Followed the whole config - step by step and got exactly the replies you pointed to. but it did not fix the issue... the error remains. Request is not encrypted...

below is the list of what I have done"

➜  / docker images
REPOSITORY                                         TAG         IMAGE ID       CREATED         SIZE
ba22da74/aarch64-addon-gosungrow                   3.0.7       8a21246efb09   8 hours ago     118MB
ghcr.io/esphome/esphome-hassio                     2024.8.0    321334918461   3 days ago      618MB
ghcr.io/home-assistant/green-homeassistant         2024.8.2    3a296e16b7ad   7 days ago      1.61GB
ghcr.io/home-assistant/aarch64-hassio-supervisor   2024.08.0   e31e6f4909b1   2 weeks ago     382MB
ghcr.io/home-assistant/aarch64-hassio-supervisor   latest      e31e6f4909b1   2 weeks ago     382MB
ghcr.io/home-assistant/aarch64-hassio-cli          2024.07.0   c8070b6e5695   4 weeks ago     61.6MB
b3e7ace5/aarch64-addon-winet-extractor             0.1.9       4c5830dbe74b   5 weeks ago     254MB
davidusb/image-aarch64-emhass                      0.10.6      2cd62c0dfcae   5 weeks ago     1.62GB
ghcr.io/home-assistant/aarch64-base                3.19        e2ee36ea6755   2 months ago    51.8MB
homeassistant/aarch64-addon-mosquitto              6.4.1       533fc4819d28   2 months ago    217MB
ghcr.io/hassio-addons/ssh/aarch64                  18.0.0      5f62926620f1   3 months ago    347MB
ghcr.io/hassio-addons/appdaemon/aarch64            0.16.6      4b571b979860   3 months ago    135MB
homeassistant/aarch64-addon-git_pull               7.14.1      5cf7b8387d9e   4 months ago    73.6MB
ghcr.io/home-assistant/aarch64-hassio-dns          2024.04.0   e91be38e9ff1   4 months ago    67.6MB
ghcr.io/home-assistant/aarch64-base                3.16        cf2d1c09c6e5   5 months ago    41.6MB
ghcr.io/home-assistant/aarch64-base                latest      c3542a930ae2   5 months ago    51.7MB
ghcr.io/home-assistant/aarch64-hassio-multicast    2024.03.0   8becb27d9446   5 months ago    51.9MB
homeassistant/aarch64-addon-configurator           5.8.0       06b103b34495   6 months ago    131MB
ghcr.io/hassio-addons/vscode/aarch64               5.15.0      178c7a8fc4b9   7 months ago    955MB
ghcr.io/home-assistant/aarch64-hassio-audio        2023.12.0   06eec6839c57   8 months ago    87.5MB
ghcr.io/home-assistant/aarch64-hassio-observer     2023.06.0   1b4771b44876   14 months ago   7.49MB

➜  / docker images | grep gosungrow
ba22da74/aarch64-addon-gosungrow                   3.0.7       8a21246efb09   9 hours ago     118MB

➜  / docker system prune -f
Deleted Containers:
a149ea25580aeb0691189bce1d0027cc4e2e6db73517252bf9dd43494aed639c

Total reclaimed space: 13.27kB

➜  / old_image=$(docker images | grep gosungrow | awk '{print $1 ":" $2}')
➜  / echo $old_image
ba22da74/aarch64-addon-gosungrow:3.0.7

➜  / new_image=$(echo $old_image | awk -F/ '{print"triamazikamno/"$2}')
➜  / echo $new_image
triamazikamno/aarch64-addon-gosungrow:3.0.7

➜  / docker tag $old_image ${old_image}-backup
➜  / docker images | grep -e REPOSITORY -e gosungrow
REPOSITORY                                         TAG            IMAGE ID       CREATED         SIZE
ba22da74/aarch64-addon-gosungrow                   3.0.7          8a21246efb09   9 hours ago     118MB
ba22da74/aarch64-addon-gosungrow                   3.0.7-backup   8a21246efb09   9 hours ago     118MB

➜  / docker pull $new_image
^[[B^[[B^[[B^[[B^[[B^[[B^[[B3.0.7: Pulling from triamazikamno/aarch64-addon-gosungrow
bdb2de7ba06c: Pull complete 
b45b9434c8a5: Pull complete 
b89eb5852b0a: Pull complete 
7e1833a2154d: Pull complete 
42085fd9f808: Pull complete 
2f9b37a4be89: Pull complete 
Digest: sha256:eb2722ff602a6260533c97b191d04d6eb7a6e45a1ec6f6aa9e92ac2033164aabB^[[B^[[B^[[B^[[B^[[B^[[B
Status: Downloaded newer image for triamazikamno/aarch64-addon-gosungrow:3.0.7
docker.io/triamazikamno/aarch64-addon-gosungrow:3.0.7

➜  / docker images | grep -e REPOSITORY -e gosungrow
REPOSITORY                                         TAG            IMAGE ID       CREATED         SIZE
ba22da74/aarch64-addon-gosungrow                   3.0.7          8a21246efb09   9 hours ago     118MB
ba22da74/aarch64-addon-gosungrow                   3.0.7-backup   8a21246efb09   9 hours ago     118MB
triamazikamno/aarch64-addon-gosungrow              3.0.7          005ee47d3a6a   8 months ago    189MB

I will give HA a reboot see if it changes anything... but that is part 2 which I think I followed to the dot.

Sadly -still the same error... regardless. Oh well... maybe you have some idea what else to try... :)

thank you so much again Phill

Paraphraser commented 3 months ago

@RafAustralia The reason the docker ps command didn't work is because you copied the $ as part of the command.

As a heads-up, you don't need to re-run that command because I'm pretty sure I understand what has gone wrong. However, I'm going to explain the basics of Unix/Linux command patterns because it's something you are going to need in future.

Please study this:

Screenshot 2024-08-24 at 23 46 01

What you're seeing in that first line is divided into several parts:

Then we get to ls. I typed the three characters lsreturn.

The two lines after that are the output from the ls command.

Then you see a repeat of the first line, followed by the cursor waiting for the next command.

If you are reading documentation about Unix commands, the most common pattern you will encounter is:

$ ls

The $ means "everything to the right of this is the command you should type, followed by pressing either return or enter."

The reason it is done like that is to separate commands from their output so that if I repeat what is in the screen shot:

$ ls
bridging_scripts  Documents  IOTstack  Music      Pictures  share      Videos
Desktop       Downloads  Logs      PiBuilder  Public    Templates

the message you should receive is "run the ls command, and the lines that don't have the $ at the start are the expected output.

The sequence pi@tri-dev:~$ is a kind of standard format for a Linux system prompt but, ultimately, the format is completely under your control. The contents of the ~ field will vary, depending on your working directory.

Another very common pattern replaces the $ with # which is intended to signal, "you should be doing this as the root user". In the next screen shot, the sudo -s command means "become root". Then I run the ls command again. And after that I finish off with the exit command which drops me back to the "pi" user:

Screenshot 2024-08-24 at 23 58 01

See how the system prompt changes? The pi has changed to root, and the $ has changed to #. If I were to write the instructions for running those commands, it would be:

$ sudo -s
# ls
# exit

OK. Let's rule a line under all that.

Here's the basic problem:

REPOSITORY                                         TAG            IMAGE ID       CREATED         SIZE
ba22da74/aarch64-addon-gosungrow                   3.0.7          8a21246efb09   9 hours ago     118MB
ba22da74/aarch64-addon-gosungrow                   3.0.7-backup   8a21246efb09   9 hours ago     118MB
triamazikamno/aarch64-addon-gosungrow              3.0.7          005ee47d3a6a   8 months ago    189MB

Conceptually, a Docker "image" is like a freeze-dried snapshot of a running computer. An image has an operating system (some version of Linux) plus just enough to run a particular service (in this case, GoSungrow).

When you go into the Home Assistant GUI and tell it to start GoSungrow, Home Assistant (HA) tells Docker to "run" the image named:

ba22da74/aarch64-addon-gosungrow:3.0.7

What Docker does is to search the list of images for a match on that repository name and tag, load the image into memory in a kind of sandbox and set it running.

Now, please look at the "Image ID" column. See how the first two lines have the same image ID "8a21246efb09". The Image ID is what counts. Because the image IDs are the same, those first two lines are the same image. In other words, these two name+tag combinations both point to the same image:

Then, look at the third line and see how it has a different image ID "005ee47d3a6a".

The problem is that 8a21246efb09 is the bad version of GoSungrow while 005ee47d3a6a is the good version. The good version is not being loaded because the name+tag is pointing to the wrong image ID.

We can't control the name+tag combination that HA uses when it asks Docker to launch GoSungrow but we can control what the name+tag points to.

The reason you have this problem is because you missed a step when following Part 2 of the gist. I'm not going to ask you to start over. I'm just going to tell you how to fix it.

  1. Go into the Home Assistant GUI and go through the steps (Settings, Add-ons, etc) until you get to the GoSungrow add-on and make sure it is not running.

  2. Go into the Terminal and type this command (remembering what I said about the meaning of $):

    $ docker tag 005ee47d3a6a ba22da74/aarch64-addon-gosungrow:3.0.7

    If (and only if) that command returns an error, please run:

    $ docker ps

    and then take a screen-shot of both the error from the docker tag command and the output from running docker ps. Then stop until you hear from me again.

  3. If the docker tag command appears to work (ie no error) then run:

    $ docker images | grep -e REPOSITORY -e gosungrow

    With any luck, the pattern will change and look like this:

    REPOSITORY                                         TAG            IMAGE ID       CREATED         SIZE
    ba22da74/aarch64-addon-gosungrow                   3.0.7          005ee47d3a6a   9 hours ago     118MB
    triamazikamno/aarch64-addon-gosungrow              3.0.7          005ee47d3a6a   8 months ago    189MB
    ba22da74/aarch64-addon-gosungrow                   3.0.7-backup   8a21246efb09   9 hours ago     118MB

    See how the ba22da74/...:3.0.7 and triamazikamno/...:3.0.7 images now have the same image ID 005ee47d3a6a? So now, when HA tells Docker to run the ba22da74/...:3.0.7 image it will be pointing to the "fixed" image.

  4. Get out of the Terminal. You can either press control+d (meaning "hold down the control key and then press the d key), or you can type the command:

    $ exit
  5. Go back into Settings, Add-ons, etc until you get to the GoSungrow add-on and start it.

With any luck, that will cure the "not encrypted" problem. If it still doesn't work, go back to the Gist and double-check:

  1. iSolarCloud gateway configuration; then
  2. APPKey configuration

The most-likely culprit will be using the wrong APPKey and, as explained in the gist, you just have to use trial and error to find the right key.

If you wondering why we have to put up with all this complicated gobbledeegook, it's because the owner of this GitHub repository hasn't updated the images in a while. Nobody knows why. This gobbledeegook is a hack. Hopefully it's an interim hack but nobody knows.

RafAustralia commented 3 months ago

@Paraphraser

Holly Molly Phill!!! It actually appears to have worked!!!

Wow... see the images below:

But it crashes out after a while.... see the end of the file... it logs in and does it all but in the end it comes to a stop... and exists the add on - puts it in the stop state...

--+
[21:27:37] INFO: Login to iSolarCloud using gateway https://augateway.isolarcloud.com ...
Email:  116KAThouse@gmail.com
Create Date:    Wed Apr 26 15:10:02 CST 2023
Login Last Date:    2024-08-25 05:27:21
Login Last IP:  
Login State:    1
User Account:   azfq2hgp08
User Id:    393335
User Name:  B2180401604
Is Online:  false
Token:  393335_5071aeee017442e9a8be4a44fa598dbc
Token File: /data/.GoSungrow/AppService_login.json
Email:  116KAThouse@gmail.com
Create Date:    Wed Apr 26 15:10:02 CST 2023
Login Last Date:    2024-08-25 05:27:38
Login Last IP:  
Login State:    1
User Account:   azfq2hgp08
User Id:    393335
User Name:  B2180401604
Is Online:  false
Token:  393335_32e89eb88ba54b338151ed00674b16de
Token File: /data/.GoSungrow/AppService_login.json
[21:27:38] INFO: Syncing data from gateway https://augateway.isolarcloud.com ...
Email:  116KAThouse@gmail.com
Create Date:    Wed Apr 26 15:10:02 CST 2023
Login Last Date:    2024-08-25 05:27:38
Login Last IP:  
Login State:    1
User Account:   azfq2hgp08
User Id:    393335
User Name:  B2180401604
Is Online:  false
Token:  393335_32e89eb88ba54b338151ed00674b16de
Token File: /data/.GoSungrow/AppService_login.json
2024/08/24 21:27:38 INFO: Connecting to MQTT HASSIO Service...
2024/08/24 21:27:38 INFO: Connecting to SunGrow...
2024/08/24 21:27:38 INFO: Found SunGrow 12 devices
2024/08/24 21:27:38 INFO: Caching Sungrow metadata...
2024/08/24 21:27:38 INFO: Cached 760 Sungrow data points...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc8 pc=0x450a20]

goroutine 1 [running]:
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).SetBatteryPoints(_, {{_, _, _}}, {0x40012c3f50, {0x4000afa600, 0x7}, {0xc1aab1f2c8ae500f, 0x29c51403, 0x443f8e0}, ...})
    /Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:336 +0x3b0
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).GetEnergyStorageSystem(_, {0x40012c3f50, {0x4000afa600, 0x7}, {0xc1aab1f2c8ae500f, 0x29c51403, 0x443f8e0}, {{0x40012dc320, 0x2, 0x2}}, ...})
    /Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:298 +0x2c8
github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).GetData(_)
    /Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:259 +0x94
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(_, {_, _}, {{0x40012c3260, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...}, ...})
    /Users/isit/git/GoSungrow/iSolarCloud/data.go:160 +0x30c
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).getDataSinglePsIdRequired(0x4000b4d450, {0x27cd1f8, 0x400125a000})
    /Users/isit/git/GoSungrow/iSolarCloud/data.go:283 +0x294
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).GetDataSingle(0x4000b4d450, {0x40009be160, 0xf})
    /Users/isit/git/GoSungrow/iSolarCloud/data.go:238 +0x124
github.com/MickMake/GoSungrow/iSolarCloud.(*SunGrowData).GetData(0x4000b4d450)
    /Users/isit/git/GoSungrow/iSolarCloud/data.go:209 +0x154
github.com/MickMake/GoSungrow/cmd.(*CmdMqtt).Cron(0x40004fe000)
    /Users/isit/git/GoSungrow/cmd/cmd_mqtt.go:375 +0x1fc
github.com/MickMake/GoSungrow/cmd.(*CmdMqtt).CmdMqttRun(0x40004fe000, 0x0?, {0x0?, 0x0?, 0x0?})
    /Users/isit/git/GoSungrow/cmd/cmd_mqtt.go:273 +0x70
github.com/spf13/cobra.(*Command).execute(0x40004fd800, {0x400003a1a0, 0x0, 0x0})
    /Users/isit/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:940 +0x5c4
github.com/spf13/cobra.(*Command).ExecuteC(0x40005ca000)
    /Users/isit/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:1068 +0x340
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(0x400053b400)
    /Users/isit/go/pkg/mod/github.com/!mick!make/!go!unify@v1.0.3-0.20230904042338-0db745f1bada/Unify/struct.go:216 +0x318
github.com/MickMake/GoSungrow/cmd.Execute(...)
    /Users/isit/git/GoSungrow/cmd/commands.go:94
main.main()
    /Users/isit/git/GoSungrow/main.go:11 +0x68
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

gosungrow fixed gosungrow fixed pt02

So your error got fixed - somewhat... just the add on doesnt like to stay on.

I know it would be nice to ask mickmake... but we got to do with what we got right?

You are super amazing Phill... its been a very very awesome learning curve :) Thank you already.

btw - I am on discord under "rafaud" if you use discord channels

Paraphraser commented 3 months ago

@RafAustralia

Going back to one of your earlier posts - the one beginning:

Followed the whole config - step by step and got exactly the replies you pointed to. but it did not fix the issue... the error remains. Request is not encrypted...

If you look through the sequence of commands you executed and then compare what you did with the gist, you'll see that gist Part 2, Step 7 has this instruction:

# docker tag $new_image $old_image

That's critical command you missed. It's what we fixed with the docker tag command I told you to run a bit later.

I'm only mentioning this because I want you to have faith in the original instructions should you ever need to re-do any of this work.


In another post beginning:

Yes my SSH is working totally and fully – always has been – I just do not use it much.

The reason I asked you to double-check that was because, earlier, you wrote:

Tried to find wget. Couldnt.

The thing is, the wget command is available in the Advanced SSH & Web Terminal but the gist Part 2 instructions don't say to use wget. The Part 1 instructions do mention wget but those are about recompiling GoSungrow which is something you shouldn't be doing on your HA instance.

All up, it wasn't clear to me whether you had opened an SSH connection to HA or to something else, or which part of the gist you were following. That's why I wanted to take you back to ensure the basics were in place.


Now, as to your latest problem:

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

I'm sorry but I don't have a solution for that. You said you weren't a coder so that probably looks like the usual unintelligible crud programmers like to foist on the world (and I've written my fair share of unintelligible error messages in my time so I have to accept some of the blame).

That's a programming error. I could elaborate but it wouldn't really add much to the discussion.

There is another error (which I hesitate to classify as a programming error) which you'll see mentioned here for which the signature is:

strconv.Atoi: parsing "1423777_1423778": invalid syntax

With that error, I suspect that when the owner of this repo was testing the code, the server at the Sungrow end which was sending data back to GoSungrow always returned a textual representation of an integer (nothing more than digits, possibly preceded by a + or -). That strconv.Atoi is a function which reads the textual (the A probably means ASCII) form of the integer and converts it to a binary form. Then the server at the Sungrow end started returning what you see in the message: 1423777_1423778 which is two integers separated with an underscore. The result of sending a non-integer to a conversion routine which is only expecting a single integer is a crash.

In the case of this strconv.Atoi error, we're guessing that it occurs when someone has more than one Sungrow inverter. I stress this is only a guess. We don't know. It doesn't affect everyone. I've never seen it but I only have a single inverter.

Now, to return to your error, the lines after the two lines I quoted above are called a "stack trace" and they are read in reverse order such that the line at the top is the actual point of the crash:

github.com/MickMake/GoSungrow/iSolarCloud/AppService/queryDeviceList.(*EndPoint).SetBatteryPoints(_, {{_, _, _}}, {0x40012c3f50, {0x4000afa600, 0x7}, {0xc1aab1f2c8ae500f, 0x29c51403, 0x443f8e0}, ...})
    /Users/isit/git/GoSungrow/iSolarCloud/AppService/queryDeviceList/data.go:336 +0x3b0

See how that mentions SetBatteryPoints? I don't have any batteries but I'm guessing you do and that's why the GoSungrow program is trying to do things with battery information. If you don't have batteries then I have no idea why GoSungrow is trying to deal with battery information or, if it always deals with battery information irrespective of whether batteries are present, why you're hitting this error when I'm not. I also have no idea whether the owner of this repo does or doesn't have batteries but, at a guess, I'd say maybe not, which might explain why this error hasn't been caught before.

Now I'll go back to how we got here. Late last year Sungrow changed their API to require encrypted comms. That led to a flurry of activity which eventually wound up with "triamazikamno" (you'll see that name in the Docker images) recompiling GoSungrow and pushing updated images to DockerHub.

To get to that point needed people with the skills to analyse the problem, figure out the solution, the "go" programming knowledge to apply that solution, and the Docker knowledge to build replacement images for the various hardware architectures. We were all extremely lucky that the people with those skills were available and were able to come together to do the work. If that hadn't happened, we would all have been stuffed.

Fixing problems like your "invalid memory address or nil pointer dereference" or the strconv.Atoi problem is going to need a similar conjunction of skills and it will likely also need those skills plus a situation where the error manifests. In other words, it might be tricky to figure out problems with battery metrics if the person doing the work doesn't have batteries; or tricky to figure out string conversion problems is the person doesn't have multiple inverters.

In short, and I'm really sorry to have to say this, but until that happens, I think you're basically stuffed.

Paraphraser commented 3 months ago

@RafAustralia

I am on discord under "rafaud" if you use discord channels

I do use Discord. As @paraphraser. On the IOTstack Discord.

The thing is that I doubt that I know more than 1% of what there is to know about Discord. I certainly don't know how to make use of "rafaud". I tried typing @rafaud into my IOTstack window but it didn't seem to know you. I'll try a friend request to see what happens.

RafAustralia commented 3 months ago

Heeey Phill I have sent you a friends request on discord.

Thank you for all the explanations… it all makes sense.

I do have multiple inverters and multiple batteries… so I could have seen this coming .. makes sense again…

gR-xbY commented 1 month ago

As some of you know this repo is no longer being maintained for some reason and has several connection issues. While there are some patches available, such as the one by triamazikamno, they don’t fully address the problem. Specifically, the addon still generates multiple unnecessary entities, complicating the selection of data to be returned and causing frequent connection flooding errors.

In response to this, I decided to develop the GoSungrow2MQTT, a simple script that encapsulates the GoSungrow API along with a Node.js app running in Docker. The script periodically executes user-defined GoSungrow endpoints and sends the results filtered to an MQTT broker. This way, in Home Assistant, you will be able to create sensors that subscribe to these topics and receive only the information that truly matters. Hope it helps.

RafAustralia commented 1 month ago

Hey cool…

I never made it to work – it was not accepting any login data although I have proper API access.

So does your script allow users to use their own API login keys and etc?

BlueScreenTT commented 1 month ago

Nice. Ill give it a try

Den tis 1 okt. 2024 05:05RafAustralia @.***> skrev:

Hey cool…

I never made it to work – it was not accepting any login data although I have proper API access.

So does your script allow users to use their own API login keys and etc?

— Reply to this email directly, view it on GitHub https://github.com/MickMake/GoSungrow/issues/112#issuecomment-2384688014, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVMLI33ILPNRAMNSS4MNNN3ZZIGOTAVCNFSM6AAAAABGWHLDRWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBUGY4DQMBRGQ . You are receiving this because you were mentioned.Message ID: @.***>