-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error: unknown error 'Repeated request' #111
Comments
This is what I see. My instance of GoSungrow is working so I think we can treat this as a known-good pattern:
Now, in comparison with mine, your output shows three cycles where the starting point of each cycle is:
The second cycle starts after:
and the third after:
Then, in that third cycle, the sequence skips over:
Another thing of note is three distinct values for the Internally, the GoSungrow Docker container uses the s6 process manager. That means the manager tends to restart any internal processes that fail. s6 also manages logging such that a bunch of processes running in parallel, each of which is writing log messages, will result in those messages being interwoven in the log you see in the Home Assistant API. What I'm about to say is based more on instinct than anything I can point to as hard fact so please take it with a few grains of salt. My instinct is that the variability in the log messages and the multiplicity of tokens likely implies that the If I'm right then, from the perspective of augateway.isolarcloud.com, it will look like the same remote machine is making parallel requests. It's probably not geared for that, which may well explain the "repeated request". So, why... I have never been able to replicate this particular "repeated request" problem but I have been able to make GoSungrow misbehave by deliberately mucking-up the linkage to the MQTT broker. And that leads me to a couple of questions:
I'm using the "Mosquitto broker" add-on. Only one user is defined on my HA instance and, of course, it has admin privileges. It's those admin credentials which I provide to GoSungrow via the How close is your setup to that? |
thanks for your response, it was interesting.. to answer your question.. my setup is the same as yours HA is using mosquito broker within the same HA PC I went into mosquito broker to share the log file (pasted below). What is very weird is that i went into mosquito broker to view the logs so I could post them here.. and then back to the sungrow app to check it had crashed (usually lasts about 2-3 mins then crashes).. it had not crashed. After a few more minutes it finally crashed.. Sungrow Log: s6-rc: info: service legacy-cont-init: starting 2024/04/16 00:10:32 ERROR: unknown error 'Repeated request' Aliases: Examples: Flags: Use "GoSungrow help flags" for more info. Additional help topics: ERROR: unknown error 'Repeated request' Mosquito broker log: Mosquitto broker |
Well, at the risk of telling you things you already know, I'm a bit leery of placing too much reliance on what I see in any Log tab in Home Assistant. That's because HA seems to have its own ideas of how much of a container's log it will show. And that's on top of the fact that a container's log is usually ephemeral anyway. In most cases old logs disappear when the container (ie an add-on) is recreated. What I have found with the GoSungrow add-on is that the container can be in a restart loop, and that the only way to discern that from the add-on's Log tab is to go out and come back in a few times, paying careful attention to any timestamps in the log entries. That said, after stopping and then starting the GoSungrow and Mosquitto containers (so as to get clean slates) this is my Mosquitto log:
For the record, I captured that log in the CLI via:
When I compare/contrast your log with mine, everything's the same up until Then we both get some bogus connection from localhost which is "disconnected due to protocol error". No idea what that means (it might be an internal health-check which is failing). Then, in mine, exactly two clients get mentioned:
Your log, on the other hand, has three clients:
Do you have another add-on which is an MQTT client (publisher and/or subscriber)? You can map IP addresses back to containers by wading through the output from:
I find it can be useful to pipe to
I'm not all that hopeful this gets us any closer to figuring out why mine works and yours doesn't. Maybe also run:
|
Also, why do you say "usually lasts about 2-3 mins then crashes"? The timestamps in your original log are all 11:07:33 (the second log all 00:08:01) so it seems to be crashing as soon as it starts. |
Maybe also run:
|
Hi, thanks for all your assistance.. I'll work through it and paste the results. **Do you have another add-on which is an MQTT client (publisher and/or subscriber)? You can map IP addresses back to containers by wading through the output from: $ docker network inspect hassio** output: docker network inspect hassio[ =================== docker network inspect hassio | grep -B 3 172.30.32.2 "Name": "hassio_supervisor", =========================== docker images ========================= Also, why do you say "usually lasts about 2-3 mins then crashes"? The timestamps in your original log are all 11:07:33 (the second log all 00:08:01) so it seems to be crashing as soon as it starts. oddly it usually crashes fairly early on, but sometimes does appear to last a bit longer.. the addon appearing to stay green and the log low to update (or at least show me it has crashed). I agree.. looking at the timestamps, it crashes pretty early. =========================== ~ # docker ps -a --format "table {{.Names}}\t{{.RunningFor}}\t{{.Status}}\t{{.Size}}" |
Unfortunately, the spurious IP address 172.30.33.5 we were chasing doesn't appear in your In your
From that pattern, I'm guessing that you don't have the "Watchdog" switch enabled in the "Info" tab of the GoSungrow add-on. What might be going on is the container has been left it in a kind of dangling state where, if it's resumed, it will inherit any gremlins from the previous invocation. I stress that I don't know this for a certain fact and I have no real means of proving it one way or another in the HA context. It's really just a wild guess. Eliminating it as a possibility involves:
The The If that doesn't work then I suppose you could try uninstalling and re-installing the GoSungrow add-on.
To do it thoroughly, you need to do some work in both the GUI and Terminal. In the GUI:
In the Terminal:
In the GUI:
At this point, if you were to start the container you would get "Request is not encrypted" so now we need to fix that. In Terminal:
In the GUI:
Other odds and ends you could consider trying:
If none of that gets anywhere then ... dunno. Sorry. |
I really appreciate the time you are putting into helping me here. Not in any specific order.. yes, I turned off the watchdog wondering if it related to the error.. it was on for dozens of previous attempts. I have reinstalled heaps of times, but only removed the dock files via the method you proposed (GUI + command prompt) once before (recently) in the hope that a fresh install would not have these issues... After my attempted removal, I applied the 'fix' for encryption key and found the same error appear. Just to be sure, I have also removed rednode as the failure seemed to happen around the time of that addon install (despite me not actually having set anything up in it as yet). ============ edit. ok it's been a few hours of trying stuff.. I am still getting the same problem of that error despite trying everything except for the DNS stuff.. I'll play around with that another day but at this stage am ready to give it a rest before I thrown the MicroPC against a wall . I actually did notice that somewhere during my tinkering my isolar connection to the Sungrow inverter was lost.. a bit weird.. got it reconnected to the wifi network but then got paranoid the modbus connection I was using had caused this issue (remember someone saying ages ago that modbus can interrupt the wifi connection). So i've also pulled the ethernet conneciton to the inverter and am going to sulk until Sungrow make their own addon ;) |
I see two main obstacles to getting a handle on this "repeated request" problem:
My goals in writing this post are:
Over at Issue 101 @grechi-diego wrote about striking "repeated request":
This is very interesting. To my recollection, this is the first time anyone has mentioned seeing the "repeated request" problem outside of the HA environment. I have never seen the "repeated request" problem. I suspect it'd be a heck-of-a-lot easier to diagnose if it was happening to me too. In my case, I run GoSungrow:
I run Home Assistant as a guest VM in a Proxmox-VE instance on an old Intel MacMini. I don't actually use Home Assistant for anything else. The only reason I have left it and the GoSungrow add-on running is the faint hope that I, too, will start to see the "repeated request" problem. Rolling all this together, I've been guilty of making an implicit assumption that the "repeated request" problem is somehow related to Home Assistant, or the implementation of the GoSungrow add-on as a Docker container, or some combinatorial issue. But now we have evidence that it can also happen to the standalone binary, which means we can eliminate everything except the GoSungrow application. We are left with the basic conundrum of why some people see "repeated request" while others (like me) are completely unaffected. I have a theory. I've done a survey of all the issues on this repo (open or closed).
The interesting hits on "repeated request" are: In both cases, what jumped out at me was the mention of "Found SunGrow 5 devices" and, more specifically, the "5". In the #107 link, @illuzn includes the results of running
The Now, for my sins, I have exactly one Sungrow inverter (key details sanitised):
So, I have three devices - all with the same PSID - and log entries to match, for example:
However, the two people who have reported the "repeated request" problem, and who have given sufficient information for their device-count to be known, have five devices. Plus we have @illuzn with an interesting experiment using different PsIds. I did another survey to try to gain some feeling for "numbers of devices" and whether they were correlated with problem reports:
To summarise:
I just thought I'd throw all that on the table in the hope that the people who are experiencing the "repeated request" problem can provide a little more information about their environments. In particular, please start including your
|
Thanks for doing all the hard work investigating this. I have a nice rainy day today so will do what you recommend and post now.. I have added descriptions of the 5 items listed. docker exec addon_ba22da74_gosungrow GoSungrow --config /data/.GoSungrow/con fig.json show ps list┏━━━━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━ ━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓ The found items are 👍 .. nothing weird there as obviously isolar keeps account of new (current) and old equipment attached to the account. |
In #107 the commands shown assume I was going to suggest trying it but I doubt it will work. Hmmm... Edit: still, it will be interesting if everyone encountering the duplicate request problem has a PSID list with more than one distinct PSID. |
Basterebbe un video dimostrativo su come risolvere i vari problemi.cosi per semplificare e capire le operazioni da EseguireIl 21 apr 2024 05:14, Phill ***@***.***> ha scritto:
I see two main obstacles to getting a handle on this "repeated request" problem:
Information about it is scattered across multiple issues; andContributions mostly focus on reporting the existence of the error and typically don't contain much about the environment in which the error is occurring.
My goals in writing this post are:
To try to draw together all the threads. GitHub will provide automatic cross-references in the linked issues I've mentioned and, with luck, that will send everyone to this issue.To try to encourage the provision of more environmental information when people say "I'm hitting this problem too".
Over at Issue 101 @grechi-diego wrote about striking "repeated request":
… both in HA and when running the GoSungrow binary
This is very interesting. To my recollection, this is the first time anyone has mentioned seeing the "repeated request" problem outside of the HA environment.
I have never seen the "repeated request" problem. I suspect it'd be a heck-of-a-lot easier to diagnose if it was happening to me too. In my case, I run GoSungrow:
As the standalone binary, triggered once a day by a cron job, to download "yesterday's" 5-minute data and load the results into an SQLite database. The specific command I use is:
$ GoSungrow show point data
where the arguments are the date range followed by a dozen point identifiers. It's a one-shot command (ie it doesn't loop like the HA add-on).
In Home Assistant using the replacement add-on image distributed by @triamazikamno. I do not rely on this and don't use any of the data it collects. I only set it up in the first place to confirm that the gist part 2 instructions work.
I run Home Assistant as a guest VM in a Proxmox-VE instance on an old Intel MacMini. I don't actually use Home Assistant for anything else. The only reason I have left it and the GoSungrow add-on running is the faint hope that I, too, will start to see the "repeated request" problem.
Rolling all this together, I've been guilty of making an implicit assumption that the "repeated request" problem is somehow related to Home Assistant, or the implementation of the GoSungrow add-on as a Docker container, or some combinatorial issue.
But now we have evidence that it can also happen to the standalone binary, which means we can eliminate everything except the GoSungrow application.
We are left with the basic conundrum of why some people see "repeated request" while others (like me) are completely unaffected.
I have a theory.
I've done a survey of all the issues on this repo (open or closed).
I can't claim my survey methods are 100% effective because I was using GitHub to look for keywords and expressions. GitHub is never going to find hits if the information is buried in screen-shots. But with that caveat…
The interesting hits on "repeated request" are:
@Triky101 at the very start of this issue ***@***.*** Issue 107
In both cases, what jumped out at me was the mention of "Found SunGrow 5 devices" and, more specifically, the "5".
In the #107 link, @illuzn includes the results of running show ps list and remarks on the difference in behaviour between invoking mqtt run with the first or second psid. To quote:
Running ./GoSungrow mqtt run psid1 generates the strconv.Atoi error which I'm encountering above.
Running ./GoSungrow mqtt run psid2 generates the "Repeated request" error I was encountering previously.
The strconv.Atoi error was a separate problem and I believe that was fixed in the work done by @triamazikamno.
Now, for my sins, I have exactly one Sungrow inverter (key details sanitised):
$ GoSungrow show ps list
┏━━━━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┓
┃ Ps Key ┃ Ps Id ┃ Device Type ┃ Device Code ┃ Channel Id ┃ Serial # ┃ Factory Name ┃ Device Model ┃
┣━━━━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━┫
┃ 9999999_1_1_1 │ 9999999 │ 1 │ 1 │ 1 │ B2222334445 │ SUNGROW │ SG5.0RS ┃
┃ 9999999_22_247_1 │ 9999999 │ 22 │ 247 │ 1 │ B2222334445 │ SUNGROW │ WiNet-S ┃
┃ 9999999_7_1_1 │ 9999999 │ 7 │ 1 │ 1 │ B2222334445 │ SUNGROW │ SG Smart Meter ┃
┗━━━━━━━━━━━━━━━━━━┷━━━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━┷━━━━━━━━━━━━━┷━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┛
So, I have three devices and log entries to match, for example:
2024/04/21 02:38:12 INFO: Found SunGrow 3 devices
However, the two people who have reported the "repeated request" problem, and who have given sufficient information for their device-count to be known, have five devices.
Plus we have @illuzn with an interesting experiment using different PsIds.
I did another survey to try to gain some feeling for "numbers of devices" and whether they were correlated with problem reports:
Error: identifier rejected:
#18 Found SunGrow 0 devices#19 Found SunGrow 2 devices#54 Found SunGrow 0 devices#59 Found SunGrow 2 devices
I have no idea what triggers this. For #18 there was some interaction with @MickMake but no obvious resolution. Same with #19. For #54 @hboltz reported solving the problem but didn't say how. And #59 is open with no comments and no resolution.
Error: strconv.Atoi: parsing "«digits»_«digits»": invalid syntax:
#38 Found SunGrow [3, 4 and 13] devices#41 Found SunGrow 2 devices#45 Found SunGrow 2 devices#92 Found SunGrow 4 devices#107 Found SunGrow [2 and 5] devices
As noted earlier, I think this problem was fixed by @triamazikamno.
Error: network Error : dial tcp: lookup Core-mosquitto: no such host:
#45 Found SunGrow 2 devices
This error is caused by not having installed and started the "Mosquitto broker" add-on for Home Assistant.
Error: network Error : dial tcp: lookup «something» on 127.0.0.11:53: no such host :
#64 Found SunGrow 2 devices#67 Found SunGrow 3 devices#80 Found SunGrow 2 devices#83 Found SunGrow 3 devices
This error is caused by having an incorrect host name in the host_name field in the GoSungrow add-on's "Configuration" tab.
Error: not Authorized:
#94 Found SunGrow 3 devices#101 Found SunGrow 6 devices
Caused by the credentials set in the mqtt_user and mqtt_password fields in GoSungrow add-on's "Configuration" tab being rejected by the MQTT broker.
panic runtime error: invalid memory address or nil pointer dereference:
#62 Found SunGrow 2 devices
No idea. Probably a glitch.
Error: No results found:
#54 Found SunGrow 0 devices#70 Found SunGrow 0 devices
My guess is this is the result of incorrect iSolarCloud credentials.
To summarise:
there's probably (just) enough data to support the conclusion that problems other than "repeated request" aren't correlated with the numbers of devices in the ps list; but
while n=2 is not enough data to support a conclusion that "repeated request" is correlated with either:
more than 3 devices in the ps list; ormultiple distinct PsIds in the ps list,
it's a glint of a possible theory.
I just thought I'd throw all that on the table in the hope that the people who are experiencing the "repeated request" problem can provide a little more information about their environments.
In particular, please start including your ps list.
If you are running GoSungrow from the command line, just:
$ GoSungrow show ps list
If your only copy of GoSungrow is the add-on installed in Home Assistant, you can get the information by going into the "Advanced SSH & Web Terminal" and running:
$ docker exec addon_ba22da74_gosungrow GoSungrow --config /data/.GoSungrow/config.json show ps list
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
@Paraphraser this is my contribution for now, will try to collect some more info later in after work hours. Running the binary from my PC in the LAN:
and no indication in the MQTT broker plugin logs that anything dogie is happening on its side:
Interesting observation I have is when I run the same command with
My devices list:
NOTE: The unknown device |
@igoratencompass very very interesting! In your In mine, the PsID is the same on all three lines (SG5.0RS, WiNet-S, SG Smart Meter), and the PsID is the prefix to each value in the "Ps Key" column. In other words, all my "xxxxxxx" are identical. When I run:
I seem to get two repeats of each:
but they are still consistent in that all my
The only value in the "Ps Id" column is that same What happens if you run those commands? Does I hadn't tried the
|
Hi @Paraphraser, first thanks for spending time ooking into this it's appreciated.
Yes the
Yes,
and I owe you some explanation here in terms of what and how was provisioned on my site here in Australia. And what was unfortunately messed up during the Plant provisioning :-/ First this is a single phase dwelling with single phase Smart Meter. What I purchased, apart from the panels of course, is a Sungrow Inverter SG5.0RS, WiFi module and an additional Consumption Meter that connects to the Smart Meter and is need to see consumption and export to the greed (otherwise I can only see what the system produces). The installation was done in coordination with the power supplier who first converted the Smart Meter into Solar enabled one (not sure what that means). Now about the mess up. After the installation, the technician had a hard time registering the meter and connecting the meter to my WiFi LAN, had to call SunGrow support etc. In the process a Plant was created in the iSolarCloud (on his device) that was never configured properly and left dangling -- after I installed iSolarCloud myself I could not do anything with it, the solar company went unresponsive and I couldn't make any progress in terms of provisioning. I can't even delete it, I don't get that option in the app assuming because the tech guy is the one who provisioned the meter first time? (P.S. Please let me know if you know about a way to delete this Plant, that might solve my problem) This is what produced that bogus What I did then is created another Plant which was provisioned all the way to the end and that's the real one with the I wander if the people that get the same error have done something similar, by accident or intentionally because they legit have multiple Invertes, causing the problem for the app. UPDATE: Problem fixed! Just after posting this I thought why not trying the Web version of the app and see if I get elevated permissions there ... and I did. Just deleted the bogus Plant and the |
@igoratencompass brilliant! With the benefit of hindsight, I think I probably had a lucky escape. My installer started to set things up but I saw what he was doing and, based on my pre-research reading Sungrow documentation and watching their YouTube videos, I was pretty sure he was wrong. I said, "please stop and let me do all that myself, please". The site just came up with all three devices, first time, no fuss. |
See also This comment on #112. |
Hi,
I had Sungrow addon working fine for a while, even after the encryption issue.
However a few weeks ago, it stopped working, and no matter how many times I try to fix/re-install it, I now keep getting this error.
Error: unknown error 'Repeated request'
Can anyone point me in the right direction ?
The Log:
---------------------------------+
[11:07:33] INFO: Login to iSolarCloud using gateway https://augateway.isolarcloud.com ...
Email: xxxxxx@gmail.com
Create Date: Sun May 05 10:19:10 CST 2019
Login Last Date: 2024-04-15 19:05:09
Login Last IP:
Login State: 1
User Account: hs0831qc
User Id: 74334
User Name: A1902250988
Is Online: false
Token: 74334_0dd0b55f2d62487395fbb88cdf4f1424
Token File: /data/.GoSungrow/AppService_login.json
Email: xxxxxx@gmail.com
Create Date: Sun May 05 10:19:10 CST 2019
Login Last Date: 2024-04-15 19:07:33
Login Last IP:
Login State: 1
User Account: hs0831qc
User Id: 74334
User Name: A1902250988
Is Online: false
Token: 74334_13618dddf69644f0acd62d0c57227fca
Token File: /data/.GoSungrow/AppService_login.json
[11:07:33] INFO: Syncing data from gateway https://augateway.isolarcloud.com ...
2024/04/15 11:07:33 INFO: Connecting to MQTT HASSIO Service...
2024/04/15 11:07:33 INFO: Connecting to SunGrow...
Email: Mtrikilis@gmail.com
Create Date: Sun May 05 10:19:10 CST 2019
Login Last Date: 2024-04-15 19:07:33
Login Last IP:
Login State: 1
User Account: hs0831qc
User Id: 74334
User Name: A1902250988
Is Online: false
Token: 74334_13618dddf69644f0acd62d0c57227fca
Token File: /data/.GoSungrow/AppService_login.json
2024/04/15 11:07:33 INFO: Found SunGrow 5 devices
2024/04/15 11:07:33 INFO: Option[loglevel] set to 'error'
PsId: required
JSON request: {"ps_id":1335646}
2024/04/15 11:07:33 ERROR: unknown error 'Repeated request'
Error: unknown error 'Repeated request'
Usage:
GoSungrow mqtt run [flags]
Aliases:
run,
Examples:
GoSungrow mqtt run
Flags: Use "GoSungrow help flags" for more info.
Additional help topics:
ERROR: unknown error 'Repeated request'
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
The text was updated successfully, but these errors were encountered: