Solar Forecast PV

Thanks for the hint. These parameters are really new. I performed calls with each of them and checked the results.

  • time & time-tz
    are just delivering timestamps in different formats. This shouldn’t be changed by the user. The binding is handling current timestamps in the correct way and it shall not guess around which format is delivered

  • no sun
    Just delivering zero values before and after sunset / sundawn. Binding is already handling this properly

  • inverter
    For each plane you need to specify Kilowatt Peak kwp in configuration. Your inverter can’t handle that? Then please reduce what your inverter can handle or am I wrong?

  • start
    This will jeopardize the calculated values. I you start forecast from e.g. 12:00 the today channel, which shall deliver the total daily forecast, is missing the morning hours.

  • damping
    This parameter is valid! It really delivers different forecast values. Then you would have the possibility to tweak these parameters to get best possible forecast for your system.

My proposal is to add 2 config parameters for morning / evening damping.
The other options will result in errors in the binding calculations plus they don’t have any effect on the forecast values.

1 Like

Hi Bernd,

Yes, the damping parameter(s) are the most interesting ones. The inverter parameter is clipping the peak energy to the max inverter power. I have confirmed that the estimated peak values are reduced to the inverter value. So it might be useful for specific setups.


Hi Bernd,

first of all, thanks for your work at this and also your other bindings.

As Solcast has daily rate limits for the API, it is required to set the refresh interval to 120 min for two sites, which is quite a long time.
I just had a idea how the limited number of API requests might be used more efficient: don’t or far less request the API at night (at least one request during night to get todays forecast would be required) and use those „saved“ requests to refresh more often during day.

Please let me know what you think about that idea.

AFAIK it’s a per hour limit so that won’t help.

120 mins should be fine, remember it’s a free service, if you want more, go pay for it.
Real weather doesn’t change drastically within this time (or that’s in the forecast already), though so the benefit is rather theory than real.

That’s right for Forecast.Solar, but Solcast has a daily limit:

That might be true, if it is, forget about that idea. Then forecast updates every 2 hours are good.
I don’t know if much shorter periods would be sensible as the forecast provider might not update the forecast in this period.

Even though you’ve already withdrawn your proposal, I’d like to add, that I had the same idea and did no update at night time when I’ve inspected the Solcast json by javascript (using the Astro binding to calculate the dawn and dusk).
This - of course - was to “spend” the free api calls at day time only :wink:

Not sure though, if this really improved the prediction for a certain point in time. But if there is any value in increasing the update frequency at day time, this could be an option… :wink:

1 Like

Hi, some more explanations

  • no sun
    Will not add the zeros (for nicer spline renders) at sunrise/sunset, only return available data

  • inverter
    Yes, if you have a (lot) more kWp installed as your inverter can handle, it limits the forecast peaks

  • start=now
    Especially for scenarios when you want to know what for the rest of the day could come



Thanks for this first hand information! As suggested I’ll adapt the changes in my binding.

Special thanks to you @Forecast.Solar for providing this excellent service. I think each member of the openHAB Community is happy to benefit from your PV production forecast of their home location!


I’m in the process of implementing Solcast.
Solcast offers the service to improve the prediction through a back channel (powerItem).
Unfortunately, I can’t get any further with the configuration because I don’t know how to specify the “powerItem” parameter:

Bridge solarforecast:sc-site:homeSite "Solcast" [
] 	{
	Thing sc-plane homeSouth "Solcast" [

“SUN2000_PV_power” is the current power of the PV array.
Has anyone already done this and can help me?

I implemented this feature 2 months ago and I’m using this feedback channel towards Solcast. Sadly I learned afterwards: it’s useless :frowning:

Tuning API was present in the past but in the meanwhile it’s discontinued. You still get valid API feedback for transmitted values but according to docu it won’t have a tuning effect.

If you still want to get this running:

  1. powerItem needs to be configured with the item name, which reports the power value for this particular sc-plane - in your case homeSouth. If you’ve only one plane as configured above the inverter value is fine.
  2. powerUnit can be set to auto-detect if a valid QuantityType is delivered. Otherwise set it to kW for Kilowatt or W for Watt.
    Note: The W is upper case and your config contains kw - both lower case.

Switch on DEBUG level and you’ll see the calculations each 15 minutes in the traces.

Thank you for the quick reply and the great binding.

Hi Bernd,

Forecast.Solar extended the API by another interesting parameter called “horizon”.

Have you had a chance to extend the binding providing either the parameters or add a used editable field to add the parameters to the URL?

Is there any chance you provide the binding source so that we can tinker with it?


I’m quite new to the openhab and solar forecast looks very interested.
I created a thing :

with all items. But strange is actual power forecast:

It shows 0,402kW but actual production is already 0. Whats wrong ?
I checked setup and all looks ok (40°of the roof, orientation southeast and power 6,75kW)

I would say there is nothing wrong. It is a prediction based on different data. So this means it is not 100 % accurate, also it is not real time. There is scatter to the data of your plant.
Or what did you expect?

It’s prediction, and I think prediction must come sooner then real time value, but in my case prediction comes later :

prediction is green

Yes, of course this is possible!

Select the Item in the Web UI, then under the metadata section, Add Metadata, select State Description.
A popup will open, this allows you to configure the state description metadata. Fill %.2f W into the pattern field, and save it.

Explanation of %.2f W:

  • %2.f tells openHAB to display the state as a floating point number with two digits after the point
  • Adding W as unit makes openHAB convert the state from kW to W

thanks, I deleted this question, because in meantime I used second Y axis to show correct chart in kW :slight_smile:
But your solution is much better, but… :

it’s not correct:

edit: %2.f W is I think correct one

1 Like

but still not clear for me, why prediction comes later then real time values (see my post)

Check first the response in Channel raw. You’ll find it in fs-plane thing after activating Show advanced checkbox. Here you’ll see the direct json response from Cross check the time the first values are reported.

          "2022-10-15 07:47:00":0,
          "2022-10-15 08:00:00":30, 

Please also double check your configuration. Is your roof azimuth exactly Southeast -45 as configured? Also declination exactly 40? Maybe this is just your first guess?


this I received at 19:15 :

  • {“result”:{“watts”:{“2022-10-15 07:17:00”:0,“2022-10-15 08:00:00”:46,“2022-10-15 09:00:00”:67,“2022-10-15 10:00:00”:81,“2022-10-15 11:00:00”:86,“2022-10-15 12:00:00”:87,“2022-10-15 13:00:00”:80,“2022-10-15 14:00:00”:69,“2022-10-15 15:00:00”:54,“2022-10-15 16:00:00”:37,“2022-10-15 17:00:00”:25,“2022-10-15 18:00:00”:13,“2022-10-15 18:07:00”:0,“2022-10-16 07:19:00”:0,“2022-10-16 08:00:00”:233,“2022-10-16 09:00:00”:629,“2022-10-16 10:00:00”:1801,“2022-10-16 11:00:00”:3581,“2022-10-16 12:00:00”:3182,“2022-10-16 13:00:00”:2889,“2022-10-16 14:00:00”:1753,“2022-10-16 15:00:00”:1474,“2022-10-16 16:00:00”:681,“2022-10-16 17:00:00”:266,“2022-10-16 18:00:00”:42,“2022-10-16 18:05:00”:0},“watt_hours”:{“2022-10-15 07:17:00”:0,“2022-10-15 08:00:00”:16,“2022-10-15 09:00:00”:73,“2022-10-15 10:00:00”:147,“2022-10-15 11:00:00”:231,“2022-10-15 12:00:00”:318,“2022-10-15 13:00:00”:402,“2022-10-15 14:00:00”:477,“2022-10-15 15:00:00”:539,“2022-10-15 16:00:00”:585,“2022-10-15 17:00:00”:616,“2022-10-15 18:00:00”:635,“2022-10-15 18:07:00”:636,“2022-10-16 07:19:00”:0,“2022-10-16 08:00:00”:80,“2022-10-16 09:00:00”:511,“2022-10-16 10:00:00”:1726,“2022-10-16 11:00:00”:4417,“2022-10-16 12:00:00”:7799,“2022-10-16 13:00:00”:10835,“2022-10-16 14:00:00”:13156,“2022-10-16 15:00:00”:14770,“2022-10-16 16:00:00”:15848,“2022-10-16 17:00:00”:16322,“2022-10-16 18:00:00”:16476,“2022-10-16 18:05:00”:16478},“watt_hours_period”:{“2022-10-15 07:17:00”:0,“2022-10-15 08:00:00”:16,“2022-10-15 09:00:00”:57,“2022-10-15 10:00:00”:74,“2022-10-15 11:00:00”:84,“2022-10-15 12:00:00”:87,“2022-10-15 13:00:00”:84,“2022-10-15 14:00:00”:75,“2022-10-15 15:00:00”:62,“2022-10-15 16:00:00”:46,“2022-10-15 17:00:00”:31,“2022-10-15 18:00:00”:19,“2022-10-15 18:07:00”:1,“2022-10-16 07:19:00”:0,“2022-10-16 08:00:00”:80,“2022-10-16 09:00:00”:431,“2022-10-16 10:00:00”:1215,“2022-10-16 11:00:00”:2691,“2022-10-16 12:00:00”:3382,“2022-10-16 13:00:00”:3036,“2022-10-16 14:00:00”:2321,“2022-10-16 15:00:00”:1614,“2022-10-16 16:00:00”:1078,“2022-10-16 17:00:00”:474,“2022-10-16 18:00:00”:154,“2022-10-16 18:05:00”:2},“watt_hours_day”:{“2022-10-15”:636,“2022-10-16”:16478}},“message”:{“code”:0,“type”:“success”,“text”:“”,“info”:{“latitude”:50.2901,“longitude”:15.7923,“distance”:0,“place”:“126, Sendra\u017eice, okres Hradec Kr\u00e1lov\u00e9, Kr\u00e1lov\u00e9hradeck\u00fd kraj, Severov\u00fdchod, 503 03, \u010cesko”,“timezone”:“Europe/Prague”,“time”:“2022-10-15T19:13:56+02:00”,“time_utc”:“2022-10-15T17:13:56+00:00”},“ratelimit”:{“period”:3600,“limit”:12,“remaining”:6}}}

My azimuth and declination is ok, not guess.