Hi Billy…thanks for “getting involved”…
I’ve a recent Solcast account with 10 API calls and it works relatively fine for me (but I’m maybe an outlier here). Before jumping into your questionnaire can you outline the thoughts/plans you have at Solcast around a paid subscription and the 10 vs 50 calls (as that seems a lot of what the Form addresses)…
From my end in terms of usage I pull the forecast and associated attributes 10 times (api limit) over the course of the day (at random intervals depending on length of day) to observe expected production against actual. I’m not using this in any automations to schedule/plan battery charging or water heating but I know others on here are.
Worth mentioning that I also use other solar forecast providers via Home Assistant who provide similar FOC access to you and would tend to “mesh” the forecasts together to get a good base (do have to say though the Solcast numbers tend to be very accurate in general but like any “forecast” you can’t be right all the time)
Also worth mentioning that while Oziee did get this up and running originally he’s had enough of the Community here and has upped sticks and left taking his code with him so it’s others who are now putting in the “hard work and effort” building from his original Integration
I was also able to snatch up latest version of the code so if anyone is interested it’s available (also with fix of blocking call while working with the stored files) here.
PS: I changed domain of the integration to ‘solcast’ to avoid conflict with other forks.
Until that time, all fixes and enhancements will be released as a beta version.
The current ‘latest’ release there is v4.0.31, with a ‘beta’ v4.0.34 under active community test. v4.0.35 is carrying an enhancement, and that shoud not be too far away. Open PRs.
So turn on the ‘beta’ releases slider in HACS download. There are performance and stability improvements for you to embrace, and an opportunity provide feedback (both positive and negative) in the discussions.
HACS is a great way to share custom Home Assistant integrations.
The community will pick up the pieces where the original departed and make the code stronger. @BJReplay has. And I have. And @isorin has.
With enough support and development, and currently thousands of users, maybe this fork will be included in HA one day as an out-of-the-box integration.
It is a proper integration that works. It is unique. And it will be stable, and we’re making it even better. And you should embrace it, and give love to it, thought, and feedback to those that develop it to make it better, not shy away. And it will be better. We will all be better off.
Is it possible to edit the HACS config to point at the new repository? So maybe that way we can avoid losing history and needing to reconfigure all the dependencies etc…
What’s the best way to migrate, or are we still waiting for something?
For anyone using the rest sensors I posted above and for @klaasnicolaas’s info the API seems to be a bit unreliable unless a user agent is specified. Also the resource URL has changed slightly. I now use the following:
- resource: https://api.solcast.com.au/rooftop_sites/<YOUR_SITE_ID_HERE>/forecasts?format=json&api_key=<YOUR_API_KEY_HERE>
headers:
User-Agent: Home Assistant # add this
Content-Type: application/json # and this
scan_interval: '00:30:00' # lower this if you have 10 calls a day, as an early adopter I have 50
sensor:
- name: "Solcast Forecast Data"
unique_id: 7390082f-b19d-4301-b386-36823458bac1
force_update: true
value_template: "{{ value_json.forecasts[0].pv_estimate|round(1) }}"
unit_of_measurement: kW
device_class: power
json_attributes:
- forecasts # this can be quite massive and you may get warnings in your log that history will not be saved
- name: "Solcast Forecast 10"
unique_id: 829f84af-93dc-4c11-bfe3-75363a76c310
force_update: true
value_template: "{{ value_json.forecasts[0].pv_estimate10|round(1) }}"
unit_of_measurement: kW
device_class: power
state_class: measurement
- name: "Solcast Forecast 90"
unique_id: a2a5acd4-4d46-4c12-896e-8d96389c58b9
force_update: true
value_template: "{{ value_json.forecasts[0].pv_estimate90|round(1) }}"
unit_of_measurement: kW
device_class: power
state_class: measurement
I was seeing sporadic failed requests that would sometimes only work again after a HA restart. However during these times I could access the API via a web browser without issue. Not sure if this is an API or HA restful integration issue but after adding the user agent option the HA requests have been operating perfectly for the last 48 hrs.
EDIT: And 3hrs after posting that I notice it has failed again. Only silently now. No errors logged. Website access to the API still works. Forcing an integration reload does not help, only restarting HA fixes it. This is looking a lot more like a HA issue.
No, I don’t - it is entirely in the hands of the HACS owners (providing that I have met my prerequisites) as it should be.
The PR requires three reviews - now received - and approval from an owner - still pending - and a HACS release / update.
There were more than 2,500 manual installs of the release version last time I checked and a hundred odd of the latest pre-release which is pretty stable.
If I were you, I would not wait for inclusion in HACS.
The latest beta v4.0.37 has proven itself most stable so far.
Before switching, do take a backup of your solcast.json in /config just in case. If history is lost for some strange reason, then see the repo discussions and utilise the backup.
For those reading this much later, do not remove the Solcast integration when switching to @BJReplay from Oziee. That will result in far too much work. And I hate extra work. Just change the custom repository in HACS, find Solcast, re-download, and all configuration should come across seamlessly.
Update, we found that the historical solcast forecast data was not held in the long term statistics but was instead held in the solcast.json file in /config
there seemed to be some bugs that caused this to occasionally get zapped, this has been fixed, and I was able to restore my old forecast data in the energy dashboard by merging appropriate lines from prior backups of solcast.json
For some as yet unknown reason, my HA host (I’m running on docker) rebooted not long after oziee nuked his repo, and for some also as yet unknown (and probably unknowable) reason I could not get HA to start at all with the oziee repo missing.
The logs indicated that this was the reason and whole trying to recover I was manually editing HA and HACS config to try to remove the oziee integration.
If you read up thread you will see references to v4.0.22 copies - that was what was available so that was what I used.
Given the grief that I had just been through trying to get HA to start, I wasn’t about to start a forensic search for the latest version. I took what looked good, and ran with it.
Only after I had my repo up did people point out they had v4.0.23
As it turned out, v4.0.23 was full of issues anyway, so using it would not necessarily have been a great starting point.
Oh sure, that makes sense though. I was just wondering about the reason so I had to ask as I’m using that v4.0.23 without issues so I wanted to know if there could be any reason I should not. hah
And honestly I did not look much into what was changed anyway. I just fixed that file handling warning complaining that it’s not async and that was it.
Stability and resiliency would also be great reasons to switch.
v4.0.23 had little protection for forecast gets encountering 429/too busy responses from Solcast, and solcast have been getting quite fiesty of late with returning these. We have built in a back-off retry mechanism, which appears to cope very well.
It also suffered from an integration/HA restart potentially hitting a 429/too busy at the wrong moment, and then everything turning to custard. To solve for this we have built in a cache of the sites detail, which is used in the case of failure.
These two features have slashed the number of issue reports.
Both are in the ‘latest’ v4.0.31.
And we have gone further, improving resiliency even more, and also on to some new features. The current ‘beta’ release is v4.0.39.
I do have set up dampening factors cause of the forest on the hill which blocks the sun too early. But i guess I just got lucky? Even with that 429. I saw that error some time back few times but sice I switched to my forked repo it’s quiet and I’m even charging the battery in the morning during off-peak hours using the forecast.
But yeah I’ll switch when I’ll have some time to tingle with it.
to all,