forecast not updating because of api limit reached #187
Comments
|
This does not look like the API limit is exceeded. The Solcast API was unavailable many times and the integration gave up. There are five attempts logged, but it gives up at ten, so has the log that you shared been altered? Dutch: Het lijkt er niet op dat de API-limiet wordt overschreden. De Solcast API was vaak niet beschikbaar en de integratie stopte. Er zijn vijf pogingen geregistreerd, maar hij stopt bij tien. Is de log die je hebt gedeeld gewijzigd? |
|
No I just copied it from the logs. I didn't alter anything. Maybe because I have two sites in one account? One facing east and one facing west. |
|
No log timestamps to give a sense of timing makes things very hard to interpret. It does interest me that there were only five retries reported, and you have two rooftops. Ten divided by two is... I will take a look at that, but I'm fairly certain that it should do up to ten tries per site. I wrote the code. TL>DR: "API was tried 10 times, but all attempts failed." It failed. The API limit was not exceeded. Did it fail because the integration has an issue? I doubt it. 4,500+ user experiences would agree with that. Did it fail because the Solcast API was issuing "429 error, go away we're busy" responses? Most likely. But I could be wrong. I'm holding this issue open for now, but I strongly suggest that you try a 'developer tools' "Solcast PV Forecast: Update" (or run your fetch automation), or (if you're using the wonderful auto-update then) "Solcast PV Forecast: Force Update" and report back. At times Solcast gets really busy, and the 429 responses seem to last ages. The other night I had a thirty minute period where I could get nothing from them. |
|
@bert1111, thanks heaps for being a user by the way! Our interaction makes me want to book a trip back to the Netherlands. What an ace place. (From a HAOS shell for me, via SSH... [Spoiler alert for a debug logging improvement coming]. The 'Troubleshooting' discussion has the details about how to get these logs.)
|
|
I'm from Belgium by the way but you're close :). I'm going to set for debug in a bit but after rebooting HA and trying the force update I now see following in my HA logs. `Deze fout is ontstaan door een aangepaste integratie. Logger: custom_components.solcast_solar.solcastapi Exception in __http_data_call(): 'fetch': Traceback (most recent call last): File "/config/custom_components/solcast_solar/solcastapi.py", line 2158, in __http_data_call resp_dict = self.tasks['fetch'].result() ~~~~~~~~~~^^^^^^^^^ KeyError: 'fetch'` |
|
Damn. Soooo close. 🤣 The only way you could have hit that error is if the 'past' forecast data was trying to be fetched, indicating that your What is the content of |
|
You haven't messed with your Solcast API key at all have you? There is an issue that I have fixed, yet not released yet on that front... |
|
I just see someone else make a bug report with almost the same settings I am using. He uses two accounts and I only use one but he also uses the automatic updates. No I haven't changed anything. The data in the solcast.json is ranging from "forecasts": [{"period_start": "2024-06-24T22:30:00+00:00" to |
|
Very different settings. Very different issues i believe. Debug logs for the win. I can't do much by guessing. |
|
|
in the integration I now see this. |
|
Thuis oost and west look like they survived a perfectly normal startup sequence, with auto-update enabled. Good on you! Perfect logs for the job. API used is showing as '1'. This is weird for a two-site set up, but may be explained by a previous failure. The integration tracks this in a You've got an update scheduled for today at 13:24:36. Let's see if it turns to custard or not. Post logs, but I'm fairly certain it will succeed. (Your earlier error about the 'fetch' task I cannot work out. I have tried this code path many times without incident. |
|
I think it is the api is busy, this is the second morning in a row that the 09:xx has failed owing to 429 error, here are my logs from today.
[edit by @autoSteve, your post is weird Henry! I cannot format the logs as a code block, so here's the best that happens...]
```
2024-10-17 08:07:52.740 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration solcast_solar which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-10-17 09:36:00.415 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] The API is busy, pausing 16 seconds before retry
2024-10-17 09:36:16.440 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] The API is busy, pausing 43 seconds before retry
2024-10-17 09:36:59.466 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] The API is busy, pausing 48 seconds before retry
2024-10-17 09:37:47.572 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] The API is busy, pausing 62 seconds before retry
2024-10-17 09:38:49.609 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] The API is busy, pausing 81 seconds before retry
2024-10-17 09:40:10.640 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] The API is busy, pausing 103 seconds before retry
2024-10-17 09:41:53.679 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] The API is busy, pausing 106 seconds before retry
2024-10-17 09:43:39.743 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] The API is busy, pausing 127 seconds before retry
2024-10-17 09:45:46.781 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] The API is busy, pausing 147 seconds before retry
2024-10-17 09:48:13.900 ERROR (MainThread) [custom_components.solcast_solar.solcastapi] API was tried 10 times, but all attempts failed
2024-10-17 09:48:13.900 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] Forecast update for site 02d4-edbc-faba-cb5b failed
2024-10-17 09:48:13.900 ERROR (MainThread) [custom_components.solcast_solar.solcastapi] At least one site forecast failed to fetch, so forecast has not been built
```
Cheers Henry
|
|
|
And normal service returns, @bert1111. Looks perfect. |
|
But why does it throw an error that the api limit was exceeded? Or isn't that what the error was? Anyway I'll keep an eye on it. |
@hwb45, they do get feisty at times. I have built in retries to try tenaciously, unlike Oziee versions that just tossed their toes in the air at the first smell of a 429. But sometimes... bad things happen. Unexplained things have happened in this issue report, including a raised exception, which should not happen, nor be possible, but that may be because @bert1111 (to misquote @BJReplay, and no offence intended) may have tried sacrificing a chicken or some other unnatural act to try and revive something that was simply a temporary error, as noted in the readme. (You didn't go the voodoo route @bert1111, did you, by changing API keys and expecting a different result? 🤣 I'm still interested in the exception that you got that should not be, though. I cannot explain it, and that code was tested many times just days ago. Weird. If you did use voodoo it would be useful to know...) |
I didn't see anywhere that the limit was exceeded. I just saw that it gave up after ten attempts at getting one of your sites. Ten tries. API limit ten. Coincidence. |
|
No voodoo here 🤣. I wish I understood HA and programming better so I could be of more assistance. I tried but my memory and concentration issues aren't helping being a programmer. |
|
This is the log from the last automatic update. |
|
Please format logs enclosed in tripple back-ticks. ``` |
|
Back ticks and then GitHub will get you. ``` Not single quotes '''. If you want to quote a single thing, lile What I think has happened here is that the internal counter in the integration of API used was one, then two, while Solcast subsequently says different. Then the integration adjusts based on the specific API response of usage counter exceeded. This will reset at midnight UTC. |
|
Furher supported by
You've been force-fetching, and the integration specifically does not keep count of this with auto-update enabled. It is by design. Sadly Solcast removed the API call to ge the current state of API usage, so we've got nothing except internal monitoring until they bring the option to get it back. Maybe they will, maybe they won't... A 'force fetch' defeats the counter on purpose. It has to, and so bad things can happen if you cause them to be bad. |
|
(If you're listening, @billy-solcast, how about into the suggestions box: Including api used in the response for a forecast fetch? That's low cost, single call and could be used to re-adjust an internal counter...) |
|
Should force-fetches decrement available API count? If only to avoid issues like this one being raised 🤣? At least until @billy-solcast comes to the party with a remaining API count in the API response (though, TBF, I expect that's a significant change for them to consider, as it would either require an optional parameter for the request to say that you're asking for it, or a added component in the returned json, that might be breaking for people not expecting it). |
Well I just want to say, that wasn't the issue I raised. |
I know, but...
The thing is that every call uses one of your calls. @autoSteve made a judgement call that it was reasonable for a user might want to force the integration to refresh the forecast - even if the integration thought that all calls were used - so changed the force fetch call to both ignore the number of calls that had been made - so that it would run even if the count was already at the limit - and not increase the count of calls made. So, if you made say six forced calls yesterday, even if you weren't complaining about this, this is what might have happened: You might have thought that the force fetch call neither used an API count nor increased the used count - but as far as Solcast is concerned, each one very much did use an API count. The integration didn't know you'd made six calls - because it wasn't counting. Later on - after only 2 calls that it was counting - it got the error from Solcast indicating that you had exceeded your limit. So, as Steve pointed out - it now knows that the limit has been exceeded, so it sets its internal counter to the limit (which is 8 - as you've configured). That's why I suggested we change the way force-fetch works (slightly) - it ignores the fact that the integration thinks the limit might have been exceeded (so if I user thinks or knows that it hasn't), it at least tries), but it still attempts to fetch. But it increments the API used count otherwise. |
And, in regards to the issue you did originally raise - we're not ignoring it - but after the fact, without timestamped logs, it's hard to say what did happen. What we do know now, is that things appear to be working as expected:
And, if that's the case, whilst it's possible that, as far as Solcast is concerned, they've considered that you've made a successful API call, but returned a failure to the integration, there's not much we can do about that - other than refund the fees you've paid for access to the integration and to Solcast, of course 😉 - but again, that's highly unlikely. It's more likely that it hasn't used up API calls, but force fetches have. |
|
Regarding not incrementing the API use counter for a force update, this may be a silly thing to be doing @BJReplay, because it does leave a bit of an information gap. Rumbing about in the back of my head is the notion of a triad of API limit, API used, and auto-update API used. All three could be displayed on the dignostics page giving far greater situational awareness. What would result however, is the need to add yet another configuration option (involving Urdu) that would be something like "API calls to use for auto-update" or a name far more thought through. I'm not going to answer the call of that rumbling rumiation for now, preferring to see how many folks step on the API use rake head and get smacked in the face with the handle. The present implementation is simple. I like simple. Simple shit doesn't break. (Until it does...) |
Seems overly complex
Seems overly complex
Seems fair enough
Agreed. Perhaps the only variation would be to ignore the fact that you might appear to be at the limit, and attempt an update if already at the limit if force is called. |
Just revert the change here? But not the change higher up that checks the current limit |
Yeah, nah. It's a force fetch. Can't update the API used, as that's against the current simple implementation "rules" of "auto-update should only mess with that counter or it will get lost". Force is force. It's up to the user to be mindful of actual total used count above what auto-update will consume. Which brings my brain back to instrumentation of this, and added complexity, which brings my brain back to Urdu can't deal. |
|
Fair enough. |
|
P.S. Have been re-netflixing Three Body Problem. Is still good second time around. Less blurry, too. |
|
Hi, Don't know what the problem could be?
Thanks |
You are going to need to provide a tonne more information for anyone to say why @matomatusov.
I could keep asking questions... |
|
Despite providing very little information @matomatusov, I think I have an answer for you. 
Note in my diagnostic usage the value says 8. This is wrong. I have used two API calls in this UTC day period, and the logged forecast fetches reflect this. Now open the diagnostic sensor. I expect you will see something like this. The history shows correctly, yet the API used does not. 
So this is an instrumentation bug, and thanks for pointing it out. It will be fixed in a future version. |
|
Is it a bug with multi-array systems? I have a tell-tale on one of my background dashboards where I have tweaks and controls, and it doesn't seem to miss a beat. History doesn't go back that far because I'm in the habit of uninstalling and re-installing for testing 🤣
I set it up when it appeared that updates weren't happening (that was around that time that the UTC midnight resets weren't happening, but that was ages ago). |
|
I don't know if any one else has problems with the api calls but yesterday every single one failed with API busy except the one at 5:32 AM. |
Similar story for me. Yesterday, 19th, 1am took 4 retries, 6am 2 retries, 10am failed after 10 retries, 1pm failed after 10 retries, 6pm took 2 retries Today 20th 1am took 6 retries, 6am 2 retries, 10am failed after 10 retries |
|
There's not enough O's in smooth to describe my today... |
|
Two 429s today, otherwise OK. Perhaps more load in your hemisphere? |
Not that we're aware of.
Speculation is not actually helping. I am going to close this issue. I don't believe that it represents a problem that can be traced back to anything other the Solcast servers being busy. https://status.solcast.com/ doesn't tell us there is anything wrong and the history doesn't suggest that there have been problems since June
|
Describe the bug
forecast not updating because of api limit reached. It has worked for a few days I think and new I see this error.
To Reproduce
Steps to reproduce the behavior:
No Idea. I was in hospital after I updated to the latest version of solcast and didn't really monitor after I did the update.
Expected behavior
That it updates. The api limit can't be reached yet.
Screenshots
Logs
The text was updated successfully, but these errors were encountered: