GoSungrow Getting er_invalid_appkey repeatedly, new installation

Hi All Would appreciate some assistance with trying to resolve this issue, has been happening since I've installed the addin. I've just restarted the Home Assistant server after it being offline for a while Troubleshooting I've done checked access to the host: augateway.isolarcloud.com Restarted the Server and the Host VM Other Integrations are working fine Checked my login details, although this appears to be an API Key issue

Do I have to check for a new API key somewhere?

Any assistance would be greatly appreciated.

Error in logs [06:07:03] INFO: Login to iSolarCloud using gateway https://augateway.isolarcloud.com ... Error: appkey is incorrect 'er_invalid_appkey'

Dec 21 '24 06:12 NQTrojan

Please see this gist which deals with several scenarios for running GoSungrow. It sounds like you will need to follow the steps in Part 2 of the gist. Each "part" winds up at the configuration instructions which includes info about the app key.

Dec 21 '24 09:12 Paraphraser

Hi Paraphraser Thank you for pointing me to this resource, I appear to have been successful in getting through that error by trying another app key in that document.

I ran into some more errors due to other issues with the Home Assistant Server which I've been able to update and resolve and I appear to be making some progress but am stuck at this point

I am now getting this error after it appears to login to both iSolarCloud and my Home Assistant instance correctly

Error: network Error : non-CONNACK first packet received

Again thank you for your assistance with the earlier

Full Log [11:53:57] INFO: Login to iSolarCloud using gateway https://augateway.isolarcloud.com ... Email: deleted Create Date: Fri May 05 10:12:31 CST 2023 Login Last Date: 2024-12-21 19:44:36 Login Last IP: Login State: 1 User Account: deleted User Id: deleted User Name: deleted Is Online: false Token: 395675_02606f6671944c14b7c60c9f7fc9dc25 Token File: /data/.GoSungrow/AppService_login.json Email: deleted Create Date: Fri May 05 10:12:31 CST 2023 Login Last Date: 2024-12-21 19:53:57 Login Last IP: Login State: 1 User Account: deleted User Id: deleted User Name: deleted Is Online: false Token: 395675_a1b763cf7d8448ab9e871129bc1349ef Token File: /data/.GoSungrow/AppService_login.json [11:53:57] INFO: Syncing data from gateway https://augateway.isolarcloud.com ... Email: Create Date: Fri May 05 10:12:31 CST 2023 Login Last Date: 2024-12-21 19:53:57 Login Last IP: Login State: 1 User Account: deleted User Id: deleted User Name: deleted Is Online: false Token: 395675_a1b763cf7d8448ab9e871129bc1349ef Token File: /data/.GoSungrow/AppService_login.json 2024/12/21 11:53:57 INFO: Connecting to MQTT HASSIO Service... 2024/12/21 11:53:57 INFO: Connecting to SunGrow... 2024/12/21 11:53:58 INFO: Found SunGrow 5 devices Error: network Error : non-CONNACK first packet received Usage: GoSungrow mqtt run [flags] Aliases: run, Examples: GoSungrow mqtt run
Flags: Use "GoSungrow help flags" for more info. Additional help topics: ERROR: network Error : non-CONNACK first packet received 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

Dec 21 '24 12:12 NQTrojan

Can't be 100% sure but one possible explanation is that this error is talking about TCP handshaking where "connections" are established via packets with the SYN flag set, then SYN+ACK, then ACK. Then, as the client and server exchange packets, you expect to see ACK (ie "acknowledgement") packets at regular intervals confirming reception.

It might mean that something other than an ACK came back when an ACK was expected.

That's all at layer four of the OSI model.

Alternatively, the layer 7 protocol (aka "the API") between GoSungrow and iSolarCloud might have its own definition of ACK and the error might be talking about something missing or out-of-sequence at that level.

All I can really say is:

It isn't happening to me (Home Assistant running as a guest on Proxmox-VE) so it probably isn't either systemic or a temporary glitch affecting the AU gateway (that's my gateway too).
I have a bog standard Netcomm router from my ISP (AussieBroadband) and the only firewalling occurring is whatever is baked into that. I don't have device-level firewalls enabled anywhere.

I mention firewalls because any time packets go missing a misconfigured firewall is a likely suspect. Go anything that fits the bill?

Dec 21 '24 12:12 Paraphraser

Hi Nothing stands out, can I please check what API Key you are using?

Regards, Glenn

On Sat, 21 Dec 2024 at 22:51, Phill @.***> wrote:

Can't be 100% sure but one possible explanation is that this error is talking about TCP handshaking where "connections" are established via packets with the SYN flag set, then SYN+ACK, then ACK. Then, as the client and server exchange packets, you expect to see ACK (ie "acknowledgement") packets at regular intervals confirming reception.

It might mean that something other than an ACK came back when an ACK was expected.

That's all at layer four of the OSI model.

Alternatively, the layer 7 protocol (aka "the API") between GoSungrow and iSolarCloud might have its own definition of ACK and the error might be talking about something missing or out-of-sequence at that level.

All I can really say is:

It isn't happening to me (Home Assistant running as a guest on Proxmox-VE) so it probably isn't either systemic or a temporary glitch affecting the AU gateway (that's my gateway too).

I have a bog standard Netcomm router from my ISP (AussieBroadband) and the only firewalling occurring is whatever is baked into that. I don't have device-level firewalls enabled anywhere.

I mention firewalls because any time packets go missing a misconfigured firewall is a likely suspect. Go anything that fits the bill?

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

Dec 21 '24 13:12 NQTrojan

"B0455FBE7AA0328DB57B59AA729F05D8" but previous experience (other issues) suggests there's no relationship between app key and gateway server. Some people reported using this "B0" key then having to switch to the "ANDROID" key. There was a theory the switch of appkey might be triggered by logging in via the web GUI but I tried that and wasn't forced to switch.

🤷‍♂️

Dec 21 '24 22:12 Paraphraser

Hey Phil Just letting you know I had another look at this and found the issue. I had mistakenly assumed that the MQTT login was my Home Assistant login which of course is not true. I have a better understanding of HA now and recognised the issue straight away.

After resetting those MQTT settings and using the Android key from the article you pointed me to I can now confirm it's all working beautifully.

Thank you so much for your assistance and patience, really appreciate it.

On Sun, 22 Dec 2024 at 08:30, Phill @.***> wrote:

"B0455FBE7AA0328DB57B59AA729F05D8" but previous experience (other issues) suggests there's no relationship between app key and gateway server. Some people reported using this "B0" key then having to switch to the "ANDROID" key. There was a theory the switch of appkey might be triggered by logging in via the web GUI but I tried that and wasn't forced to switch.

🤷‍♂️

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

Dec 29 '24 09:12 NQTrojan