GoSungrow fails with new Sungrow Developer API: missing required x-access-key header

[fpolterauer]

Hello MickMake,

first of all thank you for providing GoSungrow – it's a great tool and many
Home Assistant users rely on it.

I’m currently trying to connect GoSungrow with the official Sungrow
Developer API. My Developer App was enabled by Sungrow, but the login
fails with the following error:

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

This happens whenever the gateway URL is set to:
https://gateway.isolarcloud.eu
or
https://api.isolarcloud.com

From analyzing the traffic and the Sungrow documentation it seems that:

1. The new Sungrow Developer API (V2) requires an additional HTTP header:
   x-access-key:

2. GoSungrow only sends the "appkey" parameter (GOSUNGROW_APPKEY), but does
   not include x-access-key in the request headers.

3. Sungrow now rejects all API calls that do not contain x-access-key.

4. OAuth2-based login flows (Authorize URL + Redirect URL) are also not
   supported by GoSungrow at the moment, which makes the new API unusable
   with the current code.

Because of this, GoSungrow cannot authenticate against the new Sungrow
Developer API anymore and always returns 403 or the x-access-key error.

Would it be possible to add support for the new API header
(x-access-key) and/or the new OAuth2 login flow?

This would allow Home Assistant users to continue using GoSungrow with the
official Developer accounts provided by Sungrow.

If you need someone to test builds, I would be happy to provide logs,
access keys (privately), or run experimental binaries.

Thank you for your work and for looking into this!

[KPD38]

I am having the same issue. Would love some help getting a fix.

[Paraphraser]

I will try to respond to this issue in two ways.

First, please study this screen shot:

In words:

1. Change into the relevant directory of the GoSungrow source code.

2. Display the available git branches. In that list, two branches are important:

   • the master branch which is the source code "just as it comes" from GitHub and which was last updated two years ago.

   • the patch-set branch which is an amalgam of master, plus the encryption patches from @triamazikamno, plus the code from the three pull requests on this repo:

     • The APP_KEY has been changed to ANDROIDE13EC118BD7892FE7AB5A3F20 #108
     • Fix nil pointer exceptions fetching battery information #137
     • fix(cmd): Handle missing device_type argument #138

   The asterisk next to patch-set indicates that this is the working branch.

3. Use git grep to search for the x-access-key header. The search finds a hit.

4. Switch to the master branch.

5. Repeat the search. No hit.

On the face of it, therefore, the relevant header key is present. Accordingly, my initial hypothesis would be that neither @fpolterauer nor you have followed the steps in:

• gist part 1 which explains how to recompile GoSungrow from its source code in a way which includes all the fixes mentioned in the patch-set above; then
• gist part 5 which explains how to take the recompiled binary from part 1 and use it to replace the broken binary in the GoSungrow add-on.

Please don't take umbrage at my statement that you might not have followed the gist because I really do understand that the gist is not all that easy to find and neither is the need to use it readily apparent. The problem is that I don't control this repo so I can't put links to the gist in a prominent place such as on the main README. If you were to search other issues you would find links to the gist but that presupposes that those other issues would seem relevant when you went looking. Responding to each issue and linking to the gist is the best I can do in the circumstances.

Anyway, does "not following the gist" sound like a reasonable hypothesis? If "yes" then I will assume that your next step will be to try that. I'll also mention that it is fairly common for people to skip the configuration steps from the same gist.

---

Now, having said all that, I'll give you my second response. @fpolterauer stated that the problem being reported was peculiar to two gateway URLs. I'm in Australia so I'm using augateway.isolarcloud.com and it works fine for me. The corollary is that I can't actually test those other gateway URLs to make sure they work.

So, IF you have followed the gist as above and it still does not work then we (all GoSungrow users) need to wait until someone who uses one of the failing gateways and is therefore in a position to debug the code as it runs and who has the necessary Go programming language skills (which is not me) is able to figure out the necessary changes and propose those as a pull request. As soon as a new pull request appears, it can be included in the list at step 6 of compile-gosungrow, after which it can be deployed either standalone or via the HA add-on, as per the gist.

---

In an ideal world, MickMake would come back and handle all this himself. For now, we need to depend on volunteers contributing patches, plus this fairly cack-handed approach where each person needs to recompile and redeploy by following the gist.

The last point I will make is that, strictly speaking, you only need to follow parts 1 and 5 if you hit the problems being solved by PRs 137 (batteries) and 138 (device-type issues). If you don't actually need those then you can just follow gist part 2 which includes the x-access-key header. There is no need to recompile. You can pull down the patched Docker image (the HA add-on) and perform the command-line magic to tell HA to use the patched image.

I hope that all makes sense and helps both of you to resolve your problem.

[KPD38]

Many thanks Paraphraser. I was not aware of these additional fixes. Will work through.