Difference of APIs

#1

Hi, all. When I used swagger UI to build API request (https://api.solcast.com.au/swagger-ui/#!/pv_power/GetPvPowerEstimatedActuals), I have some question about those APIs. What’s the difference among “/pv_power/estimated_actuals”, “/pv_power/estimated_actuals/latest” and “/pv_power/forecasts”?

Thanks in advance!
H.

#2

For example if you make the following pv_power requests at UTC 15:13 you receive

/pv_power/forecasts

Forecasts are for predicted values in the future from your request time rounded to 30 minute intervals

Predictions starting at 15:30 UTC

{
    "forecasts": [
        {
            "period_end": "2018-08-06T15:30:00.0000000Z",
            "period": "PT30M",
            "pv_estimate": 0
        },...
}

Estimated Actuals are the observed values from the particular satellite feeds that are in the past relative to the request time -6 hours again making a request at UTC 15:13 the response would look like the last actual value is from 6 hours in the past 09:00.

/pv_power/estimated_actuals

{
    "estimated_actuals": [
        {
            "period_end": "2018-08-06T09:00:00.0000000Z",
            "period": "PT30M",
            "pv_estimate": 0
        },...
}

If you have signed up for the day behind data when you registered you will have access to the Estimated Actuals (latest) which if you make at UTC 15:13 the response will look identical to the Estimated Actual response, but include up to the last interval of your current request time.

/pv_power/estimated_actuals/latest

{
    "estimated_actuals": [
        {
            "period_end": "2018-08-06T15:00:00.0000000Z",
            "period": "PT30M",
            "pv_estimate": 0
        },..
}
#3

Thanks for your reply!
Do you mean “estimated_actuals” is the real pv value, and the “forecasts” is the value you estimate from the system? And the “estimated_actuals” is more accurate?

#4

Estimated Actuals is the real value created from the satellite imagery and can be considered the real value caveat on this is due to time differences on when an image scan starts and ends which can be from 1 to 15 minutes there may be sudden cloud formation missing in that interval.

Forecasts are predictions based on these same images used to calculate the Estimated Actuals and various other tuning, heuristics, and machine learning applied and should be quite accurate the closer to the time of the measurement, values for next 24 hours will be more accurate than values predicted 7 days in advance.

There are various methods and models to validate the accuracy of the Estimated Actuals that are and will be included in these measurements going forward.

#5

Thank you for your explanation! I am clear about these APIs now.

1 Like
#6

Hi,

Been using Solcast since February to determine the overnight charge to set my Powerwall 2 battery to, it’s been a very helpful guide. I have been meaning to fine tune my forecasts but only just looked at this now. I have 6380w of panels on a 5000w inverter and was inputting 5000 to solcast so the forecasts were lower than my actual. I’ve now fixed that up and input 6380 and clip any solcast value to 5000 when I process the returned file. Similarly I live in a valley and as a general rule the sun only hits the panels 1hr after sunrise and last direct sun is 1.5hrs before sunset. Again I have now accommodated for this and so far results are good, on a full sun day the solcast forecast is pretty much the insolation for my setup and matches the real result. I have had a few complete miss days in the past ie the forecast is much higher than the real on rainly cloudy days leaving me short on the battery but I appreciate the weather is fickle, I am learning to cover this in my reserve settings as time goes on, I will put more info on that another time.

My specific question relates to the forecasts api, if you look at https://pvoutput.org/intraday.jsp?id=62806&sid=57515&gs=0&dt=20180822 this has the midnight and 6am forecasts plotted against the real solar generated (22/8/18 is when I fixed up the wattage so dates before then are not as good). The one thing I don’t understand is the Solcast seems to be about 0.5hrs early. I could correct this I guess but I do more calls throughout the day to control other loads such as the hot water booster so for example the midday solcast remaining can be out by up to 2.5kwh less. Again i could correct it by just repeating the first reading.

So using your example above if I make a request at 15:13 UTC, the prediction at 15:30 UTC I assume is for following period of 15:30-16:00? this is how treat it but still seem half hour off

I am pretty sure I have my other settings ok, azimuth, tilt etc as the real graph matches insolation for my setup pretty well.

Its not a big deal just thought I’d ask

Keep up the great work.

#7

So using your example above if I make a request at 15:13 UTC, the prediction at 15:30 UTC I assume is for following period of 15:30-16:00? this is how treat it but still seem half hour off

It’s an averaged value over the interval timestep (30 minutes) with the value indicating the end of the interval. That would mean the prediction that states 15:30 UTC from above is:

“period_end”: “2018-08-06T15:30:00.0000000Z”,
“period”: “PT30M”

On the end of a period which is 15:30 with a period (interval) length of 30 minutes the predicted/estimated actual translates to

For the times of 15:00 UTC to 15:30 UTC the value is: VALUE GOES HERE

You can assume 30 minute intervals are the default period length

Hopefully this clears up confusion and allows you to get the appropriate timestep match on your forecasts.

#8

Thanks alot for getting back to me, i see the problem now, I have the wrong azimuth. I sent an email along time ago with lots of questions which got answered, my azimuth was one of them and it wasn’t clarified. The system is NW facing but I have been using azimuth -45, using 45 resolves the shift. From my memory the API documentation has changed from when I first started using it, it now clearly explains what to do. I will change my settings to include the time before a reading with this corrected azimuth i am sure that will sort things out.

Appreciate the help

1 Like
#9

Hi siliconrob,
At the sample request in your API document,
{
ghi: 690,
ghi90: 802,
ghi10: 537,
ebh: 407,
dni: 501,
dni10: 334,
dni90: 792,
dhi: 283,
air_temp: 37,
zenith: 37,
azimuth: 72,
cloud_opacity: 35,
period_end: “2017-01-30T05:00:00.0000000Z”,
period: “PT30M”
}
What does field “ebh” mean? I did not find it in the document.
Thanks!
H

#10

Looks like it is this

ebh - Direct Horizontal Irradiance

Mathematically: ebh = dni * cos(zen), W m^-2

1 Like
#11

Nice! I got it.
Thanks heaps!