If that’s true it’ll never be accurate in cloudy areas like the UK. Cloud cover is hugely important to solar forecasts here.
1 Like
Hi All, I have some data-inconsistencies I’m hoping you can help me with.
I have two strings setup in SolCast. One points mostly south, one points mostly west.
SolCast is properly showing this in the individual Sites. If you look at the forcast chart, the West chart peaks later in the afternoon:
My first observation is that the Solcast integration is not properly merging the two strings.
Solar noon is at 1:40pm in Atlanta today, but SolCast is forcasting ‘Peak Time Today’ at 1:00pm
First, the time for ‘Peak time’ is oddly a round number. I would think that should be closer to solar-noon.
Actually, it should be well-past solar noon on account of my west-facing panels.
I am not seeing a West facing tilt in this chart, and I do dramatically overproduce in the afternoon.:
Total forecasted energy does seem to include my full array, these numbers feel right: (currently 4:oopm)
And what I think is a separate issue, the forecasts are grossly inflated when I look at the forecast in ApexCharts:
Apex Charts are configured with:
- entity: sensor.solcast_pv_forecast_forecast_today
name: Solar Forecast (D1)
extend_to: false
color: grey
opacity: 0.3
stroke_width: 0
yaxis_id: kWh
show:
legend_value: false
in_header: false
data_generator: |
return entity.attributes.detailedForecast.map((entry) => {
return [new Date(entry.period_start), entry.pv_estimate*2];
});
Does anyone have tips for improving the accuracy of SolCast forecasts?
I was curious about the *2 multiplier in the data_generator, but removing that shows the forecast dramatically underestimated.
I would like to 1: ensure the west-facing panels are considered, it appears they are not, and 2: correct the overestimation in the Apex-Chart graph.
The *2 is because detailedForecast is kWh per 30 min period
1 Like
Unfortunately it appears that this was a leaving present from Oziee. The BJReplay fork incorporated Oziee’s latest code changes and one of those was the measurement type of the PV today sensor. Changing this has zapped historical forecast history in the energy dashboard.
So far haven’t been successful in finding a way to recover this
If you have removed the original Integration (and deleted it’s entities as a by product) and installed the new one (with new entities, irrespective if same frontend name or not) then you have removed the historical data from your database…
It’s not an “issue” with the integration, it’s how Home Assistant works unfortunately 
This might be a way for you to “recover” your old forecast data if you have access to the old data via backup
(not sure if data is stored as deleted in HA DB or not so maybe it’s there either)
have a look at this thread but general gist would be to create a blank template senor and then import your historical data against it using the linked Integration…
edit: had a read through of the linked GitHub issue linked two posts back and the import Integration is mentioned as an option in there already…not harm having it mentioned here too I suppose
1 Like
There’s an FAQ been added to the BJreplay code for this issue Troubleshooting FAQ #donotreply · BJReplay/ha-solcast-solar · Discussion #38 · GitHub
One person has tried reloading history from a backup and using the suggested integration, it hasn’t worked so far, but if we find a way of doing so we will update the discussion item.
By the way, the BJreplay fork is alive and well, a number of recent new improvements have been made, importantly increased caching of solcast data sets so the integration doesn’t crash if solcast gives a 429 busy error on startup, and automatic retries when 429 errors occur, @autosteve has been doing a great job
2 Likes
Makes sense. Although I’m totally confused as to why the Apex Charts grossly over-estimates my production while the one from Energy page grossly under-estimates my production.
Hi All,
Billy from Solcast here, of whom some of you may have reached out to via support.
Though this might not be the best place to communicate, I just wanted to let you know that we are looking to be more involved and gather information on how better to serve the community.
In the coming weeks, I’d like to learn as much as possible about how Solcast/solar data is being used and how to improve our services to hobbyist/home users.
For the initial feedback, I have created this google form about possible subscription options should we decide to go down that path: https://docs.google.com/forms/d/e/1FAIpQLSefZqRZ9z2f9pjl4Tc3zpscPVSBzhsPbErdyAwzui2xXqRz4A/viewform
If you have any other feedback, please feel free to add it at the bottom of the form.
And I would like to thank the community and especially Oziee, for all the hard work and effort to get the Solcast integration to where it is today.
Cheers.
9 Likes
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 
1 Like
Hi, thank you for getting involved and I’ll happily fill out the form.
Anyhow, there’s apparently another integration in works, so maybe it’s worthwhile to reach to the developer? GitHub - klaasnicolaas/python-solcast-pv: ☀️ Asynchronous Python client for getting solarpanel forecast information
Thanks!
1 Like
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.
The BJReplay repository at GitHub - BJReplay/ha-solcast-solar: Solcast Integration for Home Assistant is currently awaiting a HACS pull request review before it can be included in the searchable integrations.
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.
With 
to all,
@autoSteve.
5 Likes
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.
That is community.
3 Likes
@BJReplay thank you all for your work keeping Solcast alive!
Do you have any ETA by when your PR for the HACS integration will be approved?
The HACS PR’s ETA are like Valve’s games ETA
2 Likes
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.
Until the HACS PR is merged just follow the readme at GitHub - BJReplay/ha-solcast-solar: Solcast Integration for Home Assistant for a manually-in-hacs install. All Oziee repo history should remain.
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.
3 Likes