I seem to recall the SolCast documentation says they want a month of data before tuning, but I think mine started before that (possible because the the high granularity of the data—which you should also have). I don’t recall exactly how long; maybe a couple of weeks?
Got it – https://solcast.com/rooftop-solar/
Looks like 6 weeks for rooftop solar?
Pity that I lost a bunch of my old data (weird InfluxDB issue caused the Docker to quit the whole time) – could have uploaded it manually.
That sounds about right… but I’m pretty sure mine started tuning a lot sooner than six weeks 
Fingers crossed!
I got another email back from their support:
I’m unsure of the exact number of measurements before tuning will begin. The gaps are ok, tuning will be applied once the algorithm is able to produce a result from the available data.
Will monitor and post here once I start getting tuned 
I update to Solcast every 5 mins.
I can’t remember the exact time frame but it was less than 14 days.
Probably around 6 - 8 days. It would then Auto tune again every few days.
Since then it has stayed at 0.90 for my Setup.
Yep, you’re right. I uploaded data from 28 June (a bit historical data that I worked into the correct format, as well as live data using the automations in this thread). About 1.5 weeks worth of 5 minute intervals during sunlight hours, and only where I was certain I was getting maximum PV yield (basically whenever the batteries were charging or discharging in bulk mode, but not in absorption or float).
Today I saw that I have been tuned:
There haven’t been clouds out here in a while, so I’m guessing that’s why I got to 1.0 correlation. Will probably fall a bit once the weather turns nasty.
OK so now new question - I’ve added additional panels to my PV setup. How do I reconfigure Solcast to take into account the more W I can push?
Wait for it to tune and adjust?
Delete the site and add it again and tune from the start?
You can probably go either way… But its probably faster (and less data contamination issues for tuning) to just add a new account/site.
Hi @dannerph,
Just wondering if you have any plans to update this integration still? Its working fine as is, but would love to be able to set the refresh of forecast data time and have the service automated the push of data to the API (currently using an automation).
I unfortunately don’t have the skills to do this myself and know it must take time, but just wanted to know if i could pin any hopes on an update?
Thanks for everything you have done so far.
Hi @james_hiscott,
I am currently working on a D0 smart meter reading custom component (IEC62056-21 compatible) as a preliminary step to get more stable measurements from the energy meter. Once this is finished, I might find some time for the solcast component. However it seems, that the free plan of solcast does not support PV tuning anymore. However, my PV system is configured as full feed-in (highest cost benefit thanks to EEG), thus a good forecast is not on top of my priority list.
Regarding the technical implementation of accessible forecast values I am not sure what the best solution is: Currently I just aggregate the expected daily energy for the next three days, but wouldn’t it be beneficial to have an hourly forecast accessible for optimization? Maybe one sensor per day (today, tomorrow, the day after tomorrow) and hourly attributes attached to the sensor? What do you think?
If it is only about the forecast fetching time and API limit optimization, that should not be a big change and I can fix that quickly by adding some configurations.
Greetings
Philipp
Wow… that’s annoying re the free tier changes (only 10 API calls too)—looks like existing accounts are grandfathered (for now at least), as mine is still tuning (just checked) and still listing 20 API calls available.
Hi @dannerph yep I think the aggregate is helpful anyway, but a sensor per day would be perfect (I guess we could always do the calculation in HA anyway. So yes, maybe a setting for “forecast fetching time” and an API limit setting (or even more basic, a list of times to hit the API, whatever is quickest) would be more than fine.
@AussieByrd yep mine is still working on the old account settings, i noticed they changed that some time ago (maybe a month or so), but mine was still tuning and giving me 20 API requests.
@dannerph Tuning is still supported for all free-tier users posting measurements to the API. Hobbyist accounts also still have 20 calls per day.
2 Likes
good to hear that and welcome to the HA community! With my public researcher account, however, I only have 10 API calls per day and the website seems to be a little bit misleading to that respect.
@james_hiscott If you need a quick fix regarding the forecast fetching time, there is already a service call in the solcast integration, that triggers the forecast fetching. So simply add an automation for this . I think that will also be the best and most flexible solution in the future (instead of having a separate configuration of the fetching time within the component). The API limit was set to 10 in my initial implementation, so you should not get any problem (I will add a configuration on the API limit in the future).
1 Like
Thanks, Michael, that’s good to know!
Hi @dannerph, yes by default commercial and researcher accounts are limited to 10 API calls per day, and hobbyist accounts for home use get 20 per day. Your limit has been updated to 20.
2 Likes
Is one of the problems with calling for the forecast data more often and after sunrise, that you only get the forecast data from that moment onwards for the rest of the day?
So you make the call at 11am and you lose midnight to 10:30am data (and total) because you only see 11am through the 11:30pm data.
So really, its only worth making the forecast call before sunrise if you want a full forecast ‘total’ for the day?
@dannerph HA 0.117 seems to have broken your code and it fails to start now:
2020-10-29 11:31:06 ERROR (MainThread) [homeassistant.setup] Error during setup of component solcast
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 213, in _async_setup_component
result = await task
File "/config/custom_components/solcast/__init__.py", line 87, in async_setup
rooftop_site.start_periodic_update()
File "/config/custom_components/solcast/__init__.py", line 203, in start_periodic_update
async_call_later(self._hass, 20, self.update_history())
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1160, in async_call_later
return async_track_point_in_utc_time(
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1134, in async_track_point_in_utc_time
job = action if isinstance(action, HassJob) else HassJob(action)
File "/usr/src/homeassistant/homeassistant/core.py", line 174, in __init__
raise ValueError("Coroutine not allowed to be passed to HassJob")
ValueError: Coroutine not allowed to be passed to HassJob
I managed to fix the custom component – fairly simple. The lines
async_call_later(self._hass, 20, self.update_history())
needs to be
async_call_later(self._hass, 20, self.update_history)
(There’s two of them in __init__.py)
Will see if I can submit a pull-request.
Thanks @ebendl.
I now get the following my log:
2020-11-05 11:21:25 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback HomeAssistant.async_run_hass_job(<Job HassJobT...x7f7d7d0310>>>, datetime.date... tzinfo=<UTC>))
Traceback (most recent call last):
File "/usr/local/lib/python3.8/asyncio/events.py", line 81, in _run
self._context.run(self._callback, *self._args)
File "/usr/src/homeassistant/homeassistant/core.py", line 436, in async_run_hass_job
self.async_add_hass_job(hassjob, *args)
File "/usr/src/homeassistant/homeassistant/core.py", line 371, in async_add_hass_job
task = self.loop.create_task(hassjob.target(*args))
TypeError: update_history() takes 1 positional argument but 2 were given