Solar Forecast PV

First of all: thank you @weymann for putting so much effort into this.

I am trying the 4.3.M2 buil because for me the addon stopped working from OH 4.1 onwards.

There are two errors I spotted:

right after changing the config, I get:

2024-10-11 10:06:39.904 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'solarforecast.things'
2024-10-11 10:06:39.913 [DEBUG] [solcast.handler.SolcastBridgeHandler] - No PV plane defined yet

When using the stonehenge location, I get:

2024-10-11 10:42:06.064 [ERROR] [.core.model.script.Exception Solcast] - Handle Invalid value for EpochDay (valid values -365243219162 - 365241780471): -365243219528

Log also shows


Solcast Hausdach Call https://api.solcast.com.au/rooftop_sites/5ca9-.../estimated_actuals?format=json failed 429

which would mean that the stonehenge location is metered after all or my http 429 error is somehow persistent.
I should add, I did not get any updates for the values. I went straight to 429

Hi Stefan,

as far as I know causes each trigger two api calls! One for the forcast and one for the estimated actuals. And that means you have only 5 free triggers, which fits perfectly to your experience.

1 Like

I can see there is some acitivity when I run the action rule. Estimates are printed to the log.
But the Items do not update for sc-site or sc-plane.


2024-10-14 17:06:00.641 [INFO ] [g.openhab.core.model.script.SF Tests] - Forecast Average 6 days 67.747 kWh
2024-10-14 17:06:00.642 [INFO ] [g.openhab.core.model.script.SF Tests] - Forecast Optimist 6 days 137.321 kWh
2024-10-14 17:06:00.643 [INFO ] [g.openhab.core.model.script.SF Tests] - Forecast Pessimist 6 days 20.932 kWh

Bridge:


Bridge solarforecast:sc-site:SolCastDachSite  "Solcast Dach" [	apiKey="xxxxx-LGp73-plthoLJdMiD-9ySi1Tn" ] 	{
	Thing sc-plane SolCastHausdachThing              "Solcast Hausdach" [	resourceId="xxxxx-d153-bd09-0a26",		refreshInterval=0	]
}

Items:

> 
> Number		SolcastDach_E_TillNow				"Solcast E till now Roof [%.3f %unit%]"				(gSolcastEnergyTillNow)								{channel="solarforecast:sc-site:SolCastDachSite:energy-actual"}
> Number		SolcastDach_Actual_Power			"Solcast Pwr Roof [%.3f %unit%]"					(gSolcastActualPower, gDisplayDachActual)			{channel="solarforecast:sc-site:SolCastDachSite:power-actual"}
> Number		SolcastDach_Remaining				"Solcast Remaining E Roof [%.3f %unit%]"			(gSolcastRemainingEnergy)							{channel="solarforecast:sc-site:SolCastDachSite:energy-remain"}
> Number		SolcastDach_Today					"Solcast Forecast  E Roof [%.3f %unit%]"			(gSolcastForecastToday)								{channel="solarforecast:sc-site:SolCastDachSite:energy-today"}
> Number		SolcastDach_Tomorrow				"Solcast Forecast2 E Roof [%.3f %unit%]"			(gSolcastForecastTomorrow)							{channel="solarforecast:sc-site:SolCastDachSite:energy-estimate"}

Note: I got rid of the UoM because they are a common source of trouble.

Well, I just can’t find it. Been looking back and forth, but the closest cue to why it fails is the message

2024-10-17 11:12:04.548 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'solarforecast.things'
2024-10-17 11:12:04.564 [DEBUG] [solcast.handler.SolcastBridgeHandler] - No PV plane defined yet

Things file is

Bridge solarforecast:sc-site:SolCastDachSite  "Solcast Dach" [	apiKey="xxxx-xxxxx" ] 	{
	Thing sc-plane SolCastHausdachThing              "Solcast Hausdach" [	resourceId="xxxxxxxxx-xxxx",		refreshInterval=280	]
}

I did redact the key and resource Id ;-). I am lost here. Can anyone share a working solcast configuration, please ?

Configuration looks correct. Here’s mine:
things-file

Bridge solarforecast:sc-site:home   "Solcast PV Forecast" @ "Dach" [ apiKey="xxxx", channelRefreshInterval="30" ] {
         Thing sc-plane east   "Solcast Ost" @ "Dach"   [ resourceId="xxx", refreshInterval="120" ]
         Thing sc-plane west   "Solcast West" @ "Dach"  [ resourceId="xxx", refreshInterval="120" ]
}

items-file

// East
Number:Power            EM_PV_realPowerW_East_ForecastToday                     "Vorhersage aktuelle Leistung - Ost [%.3f %unit%]"        ( EM_PV, gChart )   [ "Point" ]     { channel="solarforecast:sc-plane:home:east:average#power-actual" }
Number:Energy           EM_PV_realEnergyProduction_East_ForecastToday           "Vorhersage Produktion Heute - Ost [%.3f %unit%]"         ( EM_PV, gChart )   [ "Point" ]     { channel="solarforecast:sc-plane:home:east:average#energy-today" }
Number:Energy           EM_PV_realEnergyProduction_East_ForecastTodayRemaining  "Vorhersage Produktion Heute Rest - Ost [%.3f %unit%]"    ( EM_PV, gChart )   [ "Point" ]     { channel="solarforecast:sc-plane:home:east:average#energy-remain" }
Number:Energy           EM_PV_realEnergyProduction_East_Forecast                "Vorhersage Produktion Vorhersage - Ost [%.3f %unit%]"    ( EM_PV, gForecast )   [ "Point" ]     { channel="solarforecast:sc-plane:home:east:average#energy-estimate" }
                
// West
Number:Power            EM_PV_realPowerW_West_ForecastToday                     "Vorhersage aktuelle Leistung - West [%.3f %unit%]"       ( EM_PV, gChart )   [ "Point" ]     { channel="solarforecast:sc-plane:home:west:average#power-actual" }
Number:Energy           EM_PV_realEnergyProduction_West_ForecastToday           "Vorhersage Produktion Heute - West [%.3f %unit%]"        ( EM_PV, gChart )   [ "Point" ]     { channel="solarforecast:sc-plane:home:west:average#energy-today" }
Number:Energy           EM_PV_realEnergyProduction_West_ForecastTodayRemaining  "Vorhersage Produktion Heute Rest - West [%.3f %unit%]"   ( EM_PV, gChart )   [ "Point" ]     { channel="solarforecast:sc-plane:home:west:average#energy-remain" }
Number:Energy           EM_PV_realEnergyProduction_West_Forecast                "Vorhersage Produktion Vorhersage - West [%.3f %unit%]"   ( EM_PV, gForecast )   [ "Point" ]     { channel="solarforecast:sc-plane:home:west:average#energy-estimate" }

// Combined
Number:Power            EM_PV_realPowerW_ForecastToday                          "Vorhersage aktuelle Leistung [%.3f %unit%]"              ( EM_PV, gChart )   [ "Point" ]     
Number:Energy           EM_PV_realEnergyProduction_ForecastToday                "Vorhersage Produktion Heute [%.3f %unit%]"               ( EM_PV, gChart )   [ "Point" ]
Number:Energy           EM_PV_realEnergyProduction_ForecastTodayRemaining       "Vorhersage Produktion Heute Rest [%.3f %unit%]"          ( EM_PV, gChart )   [ "Point" ]
Number:Energy           EM_PV_realEnergyProduction_Forecast                     "Vorhersage Produktion Vorhersage [%.3f %unit%]"          ( EM_PV, gForecast )   [ "Point" ]  { channel="solarforecast:sc-plane:home:west:average#energy-estimate" }

This has been working like a charm for weeks.

Did you check your configuration on the solcast website? Maybe something’s wrong there.

I did. And it has all been up and running. But it stopped after the upgrade to OH4.1.0 I think. Ever since I could not get it to run. I am pretty sure it does try to fetch data as the API tells me that I hit the limit. I do, however, never get updated Items. They are all NULL

When I go to the solcast website, the setup seems fine. For one system ( which I disabled in OH) I could pull JSON data. Seemed alright, giving me about 95 forecast points.
If only that " No PV plane defined yet " error was just a bit more elaborate


There is a deviation of your items definition and the manual.
You have “#” before last part of the channel, e.g. #power-actual, in the manual this is a colon “:”

The example in the manual is for Forecast.Solar. Solcast is different as it has channel-groups for average, pessimistic an optimistic. Hence you need the average#power-actual, pessimistic#power-actual or optimistic#power-actual.

That was it ! Thank you. I always thought its just swapping fs for sc but I didn’t notice that difference.
@weymann : It would not be entirely unreasonable to have a solcast example (items, things file) in the docs.

That happened to me too. For some reason I have two addons to choose from in the GUI. Addons folder is empty .
The tricky thing here is that you must pick the addon with the most likes even though the other one states that it is version 4.3.0 M2 or so, which would be the same like the current OH version.
If I pick that M2 addon, I get that above error. Using the other one did the trick.

A more general note for those who have trouble getting it to work:

  1. The influx retention policy has to be
influxdb* : strategy = restoreOnStartup, forecast

with emphasis on forecast. influxdb at the start of the line is the group that contains all persisted items.If you have an existing influx installation, that may be overlooked. Check the log if there are influx errors.
If your influx stops working after a few days or after restart and complains about authorization, check if you accidently have two different tokens in place, e.g. one in influxdb.persist and one in the UI :wink:

  1. Also, for displaying the results in the BasicUI, they silently introduced the possibility to display future time scales. period=“D-D” for example displays the time series one day in the past and one day ahaed.

  2. The current version from 3.4.0_M2 the binding can trigger the update from the solcast manually. Thats cool, especially since you can only do it 5 times per day. To set it up, use OH 4.3.0_M2 and install the stock plugin. Did not work for me as it had lots of errors about JS conversions.
    You can stick to OH 4.2.0 and manually install the plugin from the internet. To do this ,
    a) log into the OH console openhab-cli or docker exec -it openhab /openhab/runtime/bin/client
    b) bundle:install https://github.com/weymann/OH3-SolarForecast-Drops/raw/refs/heads/main/4.x/org.openhab.binding.solarforecast-4.3.0-SNAPSHOT.jar
    c) bundle:start 325 (check if it is 325 with bundle:list) but it should print the number on install
    Note: bundle:uninstall removes the plugin. There used to be an addon folder where you could just drop the jar file but that did not work. Reboot.

Next: I have to figure out how I can accumulate my three PV systems in one graph. Displaying the group displays the individual members but not the sum.

Hi.
I just upgraded from 4.2.1 to 4.2.2 and suddenly my solar forecast doesn’t work any more, can’t really see what’s wrong. I have one site with one plane and it worked before the upgrade. Now my site thing says this:

Exception during update: solarforecast:sc-plane:SolcastSite:RosenlundSolcast # Forecast invalid time range

Can’t really find any more useful information
 Anyone can tell me what’s wrong? Tried restarting OH.

edit: Ok
 The plane thing actually says HTTP Status Code 429. Guess there were simply too many requests sent during the upgrade. Anyone knows if the amount of requests left could be checked anywhere?

Check, if the add-on is still installed. When I upgraded, it was lost and I had to reinstall it, as it is an add-on from the market place.

1 Like

Yep, it’s still there!

I suspect that maybe on a normal day my requests are out before noon (since I realize I have the interval set to 60 minutes and from what I understand a free user only has ten requests a day). But I guess the binding lives on using old info rest of the day but then when I restarted during the upgrade it couldn’t do that. Could this be the case?

Yes, that’s probably the case. And please note, that every trigger causes two calls to the API, so you actually have only 5 triggers per day. I wrote my own rules to evenly distribute these between sunrise and sunset to manage this limitation.

1 Like

I can confirm that today everything’s working again. New day, new calls
 But I guess given what you say I should raise my interval even further. No big problem for me if the forecast isn’t updated in the evening, but if I’m out of updates even before lunch it’s no good


Yeah, the addon prior to OH 3.4.0_M2 does contact the solcast service whenever you reboot or change the config.Space out your interval so you do have about 5 calls per day.

Hi @weymann

tonight the API of the Forecast.solar service went out of service. This is causing troubles with the timeseries updates and hence my rules failed. This is a bit unexpected as the timeseries contains forecast data for today so the items it fills should be valid even w/o an update through the API, no? My rules depend on the item ForecastSolar_Site_Remaining_Energy_Forecast as well as the forecast for “tomorrow” generated through the Actions:

val RemainT = (solarforecastActions.getDay(LocalDate.now.plusDays(1)) as Number).floatValue

Is there any chance to ignore the API problems as long as there is forecast data fetched already and fail “nicely” once the timeseries data runs out?

Here the logfile when the API went out of service:

2024-11-26 22:44:46.566 [INFO ] [hab.event.ItemTimeSeriesUpdatedEvent] - Item 'ForecastSolar_Site_Energy_Forecast' updated timeseries [Entry[timestamp=2024-11-26T06:40:11Z, state=0 kWh], Entry[
timestamp=2024-11-26T06:45:00Z, state=0 kWh], Entry[timestamp=2024-11-26T07:00:00Z, state=0.01 kWh], Entry[timestamp=2024-11-26T07:45:00Z, state=0.021 kWh], Entry[timestamp=2024-11-26T08:00:00Z
, state=0.185 kWh], Entry[timestamp=2024-11-26T09:00:00Z, state=0.6 kWh], Entry[timestamp=2024-11-26T10:00:00Z, state=1.251 kWh], Entry[timestamp=2024-11-26T11:00:00Z, state=2.3 kWh], Entry[tim
estamp=2024-11-26T12:00:00Z, state=3.949 kWh], Entry[timestamp=2024-11-26T13:00:00Z, state=5.707 kWh], Entry[timestamp=2024-11-26T14:00:00Z, state=6.91 kWh], Entry[timestamp=2024-11-26T15:00:00
Z, state=7.589 kWh], Entry[timestamp=2024-11-26T15:05:07Z, state=7.609999999999999 kWh], Entry[timestamp=2024-11-27T06:41:40Z, state=0 kWh], Entry[timestamp=2024-11-27T06:45:00Z, state=0 kWh], 
Entry[timestamp=2024-11-27T07:00:00Z, state=0.017 kWh], Entry[timestamp=2024-11-27T07:45:00Z, state=0.021 kWh], Entry[timestamp=2024-11-27T08:00:00Z, state=0.255 kWh], Entry[timestamp=2024-11-2
7T09:00:00Z, state=0.791 kWh], Entry[timestamp=2024-11-27T10:00:00Z, state=1.594 kWh], Entry[timestamp=2024-11-27T11:00:00Z, state=2.5220000000000002 kWh], Entry[timestamp=2024-11-27T12:00:00Z,
 state=3.434 kWh], Entry[timestamp=2024-11-27T13:00:00Z, state=4.292 kWh], Entry[timestamp=2024-11-27T14:00:00Z, state=5.021 kWh], Entry[timestamp=2024-11-27T15:00:00Z, state=5.51 kWh], Entry[t
imestamp=2024-11-27T15:04:18Z, state=5.522 kWh]]
2024-11-26 23:04:46.927 [INFO ] [openhab.event.ItemTimeSeriesEvent   ] - Item 'ForecastSolar_Site_Power_Forecast' shall process timeseries []
2024-11-26 23:04:46.927 [INFO ] [openhab.event.ItemTimeSeriesEvent   ] - Item 'ForecastSolar_Site_Energy_Forecast' shall process timeseries []
2024-11-26 23:04:46.928 [INFO ] [hab.event.ItemTimeSeriesUpdatedEvent] - Item 'ForecastSolar_Site_Power_Forecast' updated timeseries []
2024-11-26 23:04:46.928 [INFO ] [hab.event.ItemTimeSeriesUpdatedEvent] - Item 'ForecastSolar_Site_Energy_Forecast' updated timeseries []
2024-11-26 23:04:46.929 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarforecast:fs-site:6b43e97309' changed from ONLINE to OFFLINE: Exception during update: solarforecast:fs-plane:2e8cfd2212 # Forecast invalid time range

This is the rule error:

2024-11-27 02:09:11.255 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'pv-5' failed: solarforecast:fs-plane:2e8cfd2212 # No forecast data available in pv

Thanks!

Within the maintenance window (Estimated: 2024-12-04, 04:30 - 06:30 CET) I received no ERROR in the logs? The window was a bit longer than predicted, as I didn’t receive any updates on my items from 26th 23:06h until 27th 09:07:

My rules don’t rely on channel-information, but on item information. So my rules did not crash, but just worked with “outdated” item-information for the API downtime. After 9h today everything worked with the API again, and the items’ values got updated.

Hi Thomas,

well, the maintenance window (Estimated: 2024-12-04, 04:30 - 06:30 CET ) is yet to come :wink: The outage was unexpected.

I guess my rule is failing due to the Action failing. Do you use your own forecast Item for future data? How?

As for the binding, I guess the timeseries is using the default policy which is “replace” so all future data went away. How about changing that to “add”? Would that help to bridge the outage?

Thanks!

1 Like

hihi. sorry, overworked, lack of coffee! :wink:

Past me did all that and present me forgot. So I had to take a look:

  1. I don’t rely on future power forecasts (Actual Power Forecast), but on the “daily aggregated” forecast (Remaining Production Today).
  2. I mix it with predictions on how much energy my house will need (EV charging, heating, washer/dish washer, 
), but only after sunrise.
  3. And with all that I fill a custom proxy item with the “free to use” prediction, again only after sunrise and before sunset.

So, when the outage occured today:

  • Remaining today item: stayed on “0” from 17:07h yesterday and got to 17kWh at 00:37 today
  • so my aggregated item stayed 0 (sunset to sunrise no change) until 08:12h, when the sun was on the right height to produce the first Watts of power.

But! You’re absolutely right. If you rely on a future timeseries, an outage should not “destroy” the timeseries, but keep the latest values.
As I said past me wrote the rules, when timeseries was not present, so I did not take that into account. :wink: