Solar Forecast PV

The more important it would be to be able to set a time slot for requests in the binding configuration…

I use kind of “brute force” cron-driven script-based disabling/enabling of the binding as workaround.

I run one refresh in the early morning when I get updated forecast for today including conveniently calculated “Today Remaining” so that I can calculate how much/if any charging of the battery should be performed to utilize lower tarrif or prevent over-discharge.

Then I use it during morning to get updates to drive optimization of “export price”.

Once its after noon, the updates kind of don’t bring additional value into my automations.

I still prefer having 5 (indeed 2 calls per update :-() more accurate forrecasts to having more of them but less accurate as it is the accuracy that is driving savings.

    var headers = newHashMap("Authorization" -> "Bearer YOUR_OH_TOKEN_GOES_HERE", "WWW-Authenticate"-> "Basic")
    sendHttpPutRequest("http://localhost:8080/rest/things/solarforecast:sc-site:homeSite/enable", "text/plain","false",headers,1000);

Since upgrading to 4.1.2. I experience no updates in the channels/items, the binding is running:


338 │ Active │  80 │     │ openHAB Add-ons :: Bundles :: SolarForecast Binding

But there’s no updates visible:

I was forced to do an update on the binding, as it hasn’t been transferred while upgrading from 4.1.1 to 4.1.2 (the update/upgrade was exactly the time the updates stopped).

@weymann I have a question concerning the solar plane calculations when using Solar Forecast:

Are the calculations done in your own binding Java code? Or are they done remotely on the Solar Forecast server?

The reason why I ask is that I noticed a distinct change in forecast accuracy in the last couple of weeks. Prior to that the Solar Forecast for my roof planes was always too high compared to my actual solar production, so I had to apply a correction factor of 0.8, but now the Solar Forecast for my roof planes has become a more-or-less perfect 100% match (i.e. with a correction factor 1.0).

I can imagine several possible reasons for this improvement…

  1. Perhaps Solar Forecast just improved the accuracy of their cover for where I live (East of England)?
  2. Perhaps something changed in general in the solar plane calculation algorithm since the spring equinox March 20th?
  3. Perhaps something changed in specific in the solar plane calculation algorithm for my north facing roof? About 40% of my panels are on a north facing roof sloped at 31°. During winter the sun never touches those panels, whereas since March 1st the mid-day solar elevation just started to exceed the roof pitch 31°. So I am wondering if the solar plane calculation algorithm may have been wrongly forecasting solar irradiation in the winter time, and yet is now accurately forecasting it.
  4. Or … perhaps it is pure chance?

Hello, with which item and which prediction do I get the expected output per hour? All energy items I’ve seen accumulate the yield over the day.
I would like to create a graph of predicted and generated energy per hour.

Thanks, Heiko

problem still exists, no real entries as “ERROR” in the logs since.
But I caught this:

2024-04-02 11:19:25.891 [INFO ] [.solcast.handler.SolcastPlaneHandler] - New forecast Expiration: 2024-04-02T11:19:24.239566891Z, Valid: true, Data:{2024-03-31T11:30+02:00[Europe/Berlin]=3.0533, 2024-03-31T12:00+02:00[Europe/Berlin]=2.3472, 2024-03-31T12:30+02:00[Europe/Berlin]=4.9742, 2024-03-31T13:00+02:00[Europe/Berlin]=5.7648, 2024-03-31T13:30+02:00[Europe/Berlin]=5.3231, 2024-03-31T14:00+02:00[Europe/Berlin]=4.3295, 2024-03-31T14:30+02:00[Europe/Berlin]=3.004, 2024-03-31T15:00+02:00[Europe/Berlin]=2.462, 2024-03-31T15:30+02:00[Europe/Berlin]=4.8451, 
2024-04-09T04:00+02:00[Europe/Berlin]=0.0, 2024-04-09T04:30+02:00[Europe/Berlin]=0.0, 2024-04-09T05:00+02:00[Europe/Berlin]=0.0, 2024-04-09T05:30+02:00[Europe/Berlin]=0.0, 2024-04-09T06:00+02:00[Europe/Berlin]=0.0, 2024-04-09T06:30+02:00[Europe/Berlin]=0.0, 2024-04-09T07:00+02:00[Europe/Berlin]=0.0148, 2024-04-09T07:30+02:00[Europe/Berlin]=0.1375, 2024-04-09T08:00+02:00[Europe/Berlin]=0.504, 2024-04-09T08:30+02:00[Europe/Berlin]=0.9999, 2024-04-09T09:00+02:00[Europe/Berlin]=1.4887, 2024-04-09T09:30+02:00[Europe/Berlin]=2.0223, 2024-04-09T10:00+02:00[Europe/Berlin]=2.6534, 2024-04-09T10:30+02:00[Europe/Berlin]=3.1882, 2024-04-09T11:00+02:00[Europe/Berlin]=3.6326, 2024-04-09T11:30+02:00[Europe/Berlin]=4.0116}

it seems to be correct data, but what bothers me is the “New foracast Expiration date”, which seemingly is the exact timestamp the call was made…?

I removed the marketplace binding (with version 4.2.0 org.openhab.binding.solarforecast-4.2.0-SNAPSHOT.jar) and replaced it with the 4.1.x version ( org.openhab.binding.solarforecast-4.1.0-SNAPSHOT.jar)
and now it works as it was.

I think the readme on the marketplace is not correct, @weymann ?
(I’m running 4.1+: 4.1.2-release)


OH 4.1+ with TimeSeries