@klaasnicolaas you can read through the past messages if you’re interested in the drama 
1 Like
Is it necessary to delete the integration in “Devices & Service” or is it sufficient to just delete it in HACS and then add the new integration in HACS?
So the main issue here for anyone adding the code is that the solcast infrastructure is creaking with the increase in hobbyist activity.
In HA many people triggered their fetch using the same logic . Eg on the hour and this caused impact. Reaching out to solcast they say:
‐‐--------
Apologies for the issues. With the explosion of hobbyist users, we’ve had to make changes to ease the use on our infrastructure.
We made some changes this morning which should resolve the toolkit, though as for your API request, we recommend randomising when you make the call to minimise the chance that you’re making API calls at the same time as other users.
We are currently keeping an eye on our hobbyist traffic and determining potential other solutions.
The readme was updated to provide some suggestions for using random in automations.
It maybe that solcast offer a paid service for hobbyists to build up their infrastructure. I am looking at moving to a paid service using the built in Forecast.Solar for a more stable service
1 Like
I have 4.0.22 running fine - @BJReplay @tabascoz I guess it’s probably best to wait until it has become clear which repository will be the one going forward (I also hope somebody will be willing to take over this project - would be a shame to loose it)?!
1 Like
Yes there’s probably 4 or 5 forks now that have 4.0.23 but there’s not much point adding any of them until someone with the time and inclination steps forward as a maintainer. Unless the integration stops working I’d highly advise people to do nothing until HACS adds a new repo source for the integration.
4 Likes
Is an API key needed for this integration to work? I’ve installed and configured it but all values are 0
for meteo forecast no API needed, just give it some time
1 Like
I’ve also just installed this. It’s working and I agree it seems to offer figures closer to Solcast (which I found to be more accurate than forecast.solar)
1 Like
An open source solution does sound attractive. I had a quick look at the open-metro integration code and from what I could see it only supports a single set of panel orientations. Same with forecast.solar, single set.
I have panels on both sides of my roof and need a forecast for both arrays which solcast supports (although it does consume 2 API calls to retrieve the two data sets).
At the moment therefore I think I’ll stick with solcast and hope we agree on one main repository - there seems to be several offers at the moment
2 Likes
the values haven’t updated for me since one hour ago unfortunately - they are still zero. I will monitor the difference to solcast and the true yield for a week or so and the decide.
@andreas-bulling
@geoffreycoan
please report any issue or feature request to meteo forecast dev and support him
he also just started with his project
4 Likes
Thank you, Francis, absolutely. Hit me up on the repo!
I’ve put forward my repo (on 4.0.22) for inclusion in HACS. There’s a massive backlog, so I expect it will take a while - there are requests at least three weeks old in the queue.
In the meantime, so as not to slow down my submission when it reaches the front of the queue, I’ll start a new branch now, and cherry-pick some of the 4.0.23 changes:
- The fix to state_class= SensorStateClass.TOTAL
- The improved handling of error codes
- If polling api fails keep using current data
I’m inclined to leave the API counter logic intact (as it currently is in place in 4.0.22
I’ll update readme, and, in particular, include randomisation in fetch logic.
3 Likes
I’m in the same boat, but you can add a second integration instance for this and then select both in Energy dashboard.
But this is probably a subject more to be discussed at Open-Meteo Solar Forecast - #3 by elRadix It’s working OK for me, looks promising.
Question for anyone who has been around for a while - any idea why the automatic polling was removed from oziee’s Solcast Service?
I found when it was removed - it was last in 3.0.47 - around May last year. Does anyone recall any conversation around why?
Given the issues around randomising scheduling, I’m trying to understand if it is worth re-including scheduling in the integration with randomisation, and the API counter, and a warning that if you restart HACS, you’ll probably hit your limit for that day (which, presumably, is no big deal).
Thanks in advance for any advice you can share.
1 Like
This was probably due to the decrease in API polling quota for hobbyists from 50 to 10 API calls a day. As one can hardly spread 10 calls across 24 hours, it was the right decision to leave the polling up the to the users. Everyone should prioritize those 10 calls as they see fit. HA offers more than enough capabilities for scheduling.
2 Likes
With some on only 10 api calls per day and others on 50 if I recall the suggestion was to push to a local automation running the service, which is what I have. Mine runs every half hour during the day (on an offset of x minutes into each half hour), and every 2h after dark. That sits me in inside my 50.
2 Likes
As a quick hotfix to the randomness it might just be worth adding a random 0-10min sleep timer on the update API call. Then anyone using the new version automatically has it.
3 Likes