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.
10 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
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.
1 Like
@BJReplay, @autoSteve any reasons why you guys did not start from latest version (but from the one before that) from @oziee?
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
2 Likes
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.
Thanks!
1 Like
This feature is probably what will make me switch to your version guys! 
Are there any specific steps I have to do to switch from json file to long term stats though?
Great! Keep up!
Cheers!
I’ll bet you’re not messing with dampening factors. Oziee seemed to break the application of these in v4.0.23.