Forecast off by ~10min?



I am pretty much a Solcast newbie, but am retrieving data for some days now (in order to optimise my battery management – up next :slight_smile: ). I also send my actuals every hour, hoping for tuning to chime in in the (near) future.
One thing I am observing, though, is kind of an overall offset of the otherwise pretty accurate forecast (well, we’re having sunny days right now…). See the dotted line vs. the current actuals:


So it’s actually nicely fitting, except the slight constant offset. Also, my PV points straight south, so I’d expect the peak at solar noon. This would be 1.24 pm CEST for my place, but the forecast peaks at 1.34 pm. I double checked all my setup settings, but it looks all good. What could be the reason for this?

Thanks, habitoti


Replying myself :slight_smile: … the ~10min shift would account for a ~2-3 degree rotation of my site. While it actually looks (from the plans) like it is 100% south, it could well be off by such a slight rotation w/o me even knowing (rather than doubting the underlying solcast computations :wink: ).
I’ll see how it looks tomorrow after “turning” my site by 2 degrees west.


The way you describe it seems almost like the measurements are ending where the predictions are starting and the shift is 10 minutes.

Maybe double check the wording of your measurements from the battery?


Actually I took the provided end date of the 30min average interval as timestamp for storing the data. Using the mid of that interval, i.e. subtracting 15mins, makes it llok much better now:


I think you’ll find that when you upload data that the time stamp is supposed to be the end time for the interval covered by the upload. If you’re now uploading using mid time you’re probably not tackling the root cause.

1 Like

When I upload my data, I provide the timestamp of the end of the period. It‘s about the downloaded forecasts and storing them in my influxdb for using with Grafana. When using the delivered end timestamp for an average that covers the 30mins before, it appears shifted by 15mins. Using the according midpoint (so store end timestamp minus 15mins) seems to make it fit perfectly to reality.

1 Like