Hi All, thanks to @Dehumanizer and @petro I am back up and running, and have put up a repo based on dehumanizer’s and prepared it and submitted it for inclusion in HACS.
It will auto-update - but I’m going to hold off updates until the add process is complete. I don’t know how an integration goes from manual install to included - that’s a bridge to cross when we come to it.
I’m not a python programmer but can copy-pasta. I am a current user of the Solcast API in another project and have had to deal with Solcast API changes in the past, so am willing to attempt to take on the maintenance of the API aspects, and accept PRs for other things.
There is one potentially breaking change: When changing references from oziee to bjreplay I changed the manufacturer of the solcast devices from Oziee to BJReplay; I don’t think it has broken anything, but you should be aware that it has changed. See Comparing v4.0.23...v4.0.24 · BJReplay/ha-solcast-solar · GitHub for the changes.
I’m not active on this forum (only just signed up now), and I’m not an active developer (retired from work for health reasons), but I’ll do my best to accept pull requests and deal with API changes, as I found this integration very useful.
I’d post more links, but am limted to two as a new user.
Do we know the reason why everything was suddenly deleted? In the coming weeks I want to dive deeper into the solcast API and develop a new package for PyPi. Ultimately also an integration for in core.
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
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)?!
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.
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)
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
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.
