Solar Forecast PV

ollo · November 27, 2024, 12:33pm

… here we go?!?

@weymann - would changing the policy to ADD here help to bridge API outages, keeping the data fetched already?

weymann · November 27, 2024, 10:02pm

No, this will cause multiple values for each timestamp in normal cases which is the majority of the updates.

You just pasted this one liner from your rule. Under which circumstances this line called?
btw this isn’t a call towards timeseries which is described here.

        // Query forecast TimesSeries Items via historicState
        val energyAverage =  (Solcast_Site_Average_Energyestimate.historicState(now.plusDays(1)).state as Number)

ollo · November 28, 2024, 10:24am

Hi Bernd,

I used the Actions rule to get the forecast for Tomorrow as documented here. Will give the Query a try and see if that works better when there is no API access. Thanks for the hint.

That rule gets executed based on a number of triggers, some unrelated to the forecast data. I need the Energy estimate for the next day to calculate if/how much I should charge my battery over night during cheaper spot market price hours.

So you are saying that the timeseries data should stay even if there is no new data fetched from the API? I thought I saw the data disappear in the event.log

Thanks!

ollo · November 28, 2024, 7:27pm

Hi Bernd,

I tried your recommended way, yet there is an issue: “The historicState method has been deprecated and will be removed in a future version, use persistedState instead”.

So the correct way should be:

val RemainT = (ForecastSolar_Site_Energy_Forecast.persistedState(now.plusDays(1)).state as Number)

Since I’m using InMemory service to persist timeseries Items, this is what I’m using now:

val RemainT = (ForecastSolar_Site_Energy_Forecast.persistedState(now.plusDays(1),“inmemory”).state as Number)

I guess we will see if that works to bridge the outage during the next scheduled maintenance window.

weymann · December 1, 2024, 9:06pm

Ah yeah, sounds reasonable. When timeseries was introduced it was quite awkward to access “future data” with historicState call.

From your traces are there any entries from fs-plane getting OFFLINE?

ollo · December 2, 2024, 7:32am

Hi Bernd,

hmm, in the event.log I see the site Thing going offline only. I have 3 planes and this is what I get:

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
2024-11-26 23:04:46.960 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarforecast:fs-site:6b43e97309' changed from OFFLINE: Exception during update: solarforecast:fs-plane:2e8cfd2212 # Forecast invalid time range to OFFLINE: Exception during update: solarforecast:fs-plane:6b43e97309:63e5201225 # Forecast invalid time range
2024-11-26 23:04:46.991 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarforecast:fs-site:6b43e97309' changed from OFFLINE: Exception during update: solarforecast:fs-plane:6b43e97309:63e5201225 # Forecast invalid time range to OFFLINE: Exception during update: solarforecast:fs-plane:6b43e97309:5c84898dc4 # Forecast invalid time range
2024-11-26 23:05:46.991 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarforecast:fs-site:6b43e97309' changed from OFFLINE: Exception during update: solarforecast:fs-plane:6b43e97309:5c84898dc4 # Forecast invalid time range to OFFLINE: Exception during update: solarforecast:fs-plane:2e8cfd2212 # No forecast data available

2024-11-26 23:24:47.339 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarforecast:fs-site:6b43e97309' changed from OFFLINE: Exception during update: solarforecast:fs-plane:6b43e97309:5c84898dc4 # No forecast data available to OFFLINE: Exception during update: solarforecast:fs-plane:2e8cfd2212 # Forecast invalid time range
2024-11-26 23:24:47.370 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarforecast:fs-site:6b43e97309' changed from OFFLINE: Exception during update: solarforecast:fs-plane:2e8cfd2212 # Forecast invalid time range to OFFLINE: Exception during update: solarforecast:fs-plane:6b43e97309:63e5201225 # Forecast invalid time range
2024-11-26 23:24:47.401 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarforecast:fs-site:6b43e97309' changed from OFFLINE: Exception during update: solarforecast:fs-plane:6b43e97309:63e5201225 # Forecast invalid time range to OFFLINE: Exception during update: solarforecast:fs-plane:6b43e97309:5c84898dc4 # Forecast invalid time range
2024-11-26 23:25:47.402 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarforecast:fs-site:6b43e97309' changed from OFFLINE: Exception during update: solarforecast:fs-plane:6b43e97309:5c84898dc4 # Forecast invalid time range to OFFLINE: Exception during update: solarforecast:fs-plane:2e8cfd2212 # No forecast data available

Thanks!

alaub81 · December 16, 2024, 12:53pm

Hi!

I just updated to openHAB 4.3.0 and now I am getting an error executing this forecast rules:

val solarforecastActions = getActions("solarforecast","solarforecast:sc-site:314e116f35")
val energyState = solarforecastActions.getDay(LocalDate.now.plusDays(1))
Solcast_Site_Tomorrow.postUpdate(energyState)
  
val solarforecastActions1 = getActions("solarforecast","solarforecast:sc-site:314e116f35")
val energyState1 = solarforecastActions1.getDay(LocalDate.now.plusDays(2))
Solcast_Site_DayAfterTomorrow.postUpdate(energyState1)

It is based on the documented ones here: SolarForecast - Bindings | openHAB

The error is the following:

val solarforecastActions1 = getActions("solarforecast","solarforecast:sc-site:314e116f35")
val energyState1 = solarforecastActions1.getDay(LocalDate.now.plusDays(2))
Solcast_Site_DayAfterTomorrow.postUpdate(energyState1)
   1. The method getDay(LocalDate) is undefined for the type ThingActions; line 2, column 129, length 6
   2. The method getDay(LocalDate) is undefined for the type ThingActions; line 6, column 344, length 6

someone can help me with that?

cheers
Andreas

weymann · December 16, 2024, 11:16pm

Correct link and it shows

    val solarforecastActions = getActions("solarforecast","solarforecast:fs-site:homeSite")
    val energyState = solarforecastActions.getEnergyOfDay(LocalDate.now.plusDays(1))

getDay was too fuzzy for an action name so it’s changed to getEnergyOfDay

alaub81 · December 17, 2024, 8:18am

oh, yes… Didn’t see the change… I changed it, but now, I get the following error:

2024-12-17 09:13:53.787 [ERROR] [.handler.AbstractScriptModuleHandler] - Script execution of rule with UID '9a2ed0a97a' failed: val solarforecastActions = getActions("solarforecast","solarforecast:sc-site:314e116f35")
val energyState = solarforecastActions.getEnergyOfDay(LocalDate.now.plusDays(1))
logError("SF Tests","{}",energyState)
Solcast_Site_Tomorrow.postUpdate(energyState)
  
val solarforecastActions1 = getActions("solarforecast","solarforecast:sc-site:314e116f35")
val energyState1 = solarforecastActions1.getEnergyOfDay(LocalDate.now.plusDays(2))
logError("SF Tests","{}",energyState1)
Solcast_Site_DayAfterTomorrow.postUpdate(energyState1)
   1. Ambiguous feature call.
The extension methods
	postUpdate(Item, State) in BusEvent and
	postUpdate(Item, Number) in BusEvent
both match.; line 4, column 231, length 10
   2. Ambiguous feature call.
The extension methods
	postUpdate(Item, State) in BusEvent and
	postUpdate(Item, Number) in BusEvent
both match.; line 9, column 501, length 10

If I comment out the line, where the item is getting the postUpdate, the Log shows the correct values for energyState:

2024-12-17 09:14:03.026 [ERROR] [g.openhab.core.model.script.SF Tests] - 2.147 kWh
2024-12-17 09:14:03.029 [ERROR] [g.openhab.core.model.script.SF Tests] - 1.663 kWh

Any ideas?

alaub81 · December 17, 2024, 8:24am

Found a solution on that:

Solcast_Site_DayAfterTomorrow.postUpdate(energyState as Number)

now it works again

perhaps there should be an update of the documentation?

weymann · December 17, 2024, 9:37am

How’s your item Solcast_Site_DayAfterTomorrow declared?
Is it Number or Number:Energy as described in readme?

Number:Energy           ForecastSolarHome_Tomorrow          "Tomorrow's total energy forecast"              { stateDescription=" "[ pattern="%.1f %unit%" ], unit="kWh" }

The state contains value (1.663) and unit (kWh) as you can see in the logs.

If you want to calculate something with the value you need the energyState as Number) conversion.

alaub81 · December 17, 2024, 10:44am

It is declared as it is documented.

So it is Number:Energy and state description is %.1f %unit% and unit is kWh. Item is configured via main UI.

With the older openHAB Versions everything besides the problem with getEnergyOfDay everything was good, until the upgrade to 4.3.0

Ciccio · January 6, 2025, 3:43pm

Hello, I tried to implement this rule:

rule "Tomorrow Forecast Calculation"
    when
        Item ForecastSolarHome_Today received update
    then
        val solarforecastActions = getActions("solarforecast","solarforecast:fs-site:homeSite")
        val energyState = solarforecastActions.getEnergyOfDay(LocalDate.now.plusDays(1))
        logError("SF Tests","{}",energyState)
        //ForecastSolarHome_Day1.postUpdate(energyState as Number)
end

but I get this error:

2025-01-06 16:41:01.157 [ERROR] [.handler.AbstractScriptModuleHandler] - Script execution of rule with UID 'energy-7' failed: An error occurred during the script execution: Cannot invoke "java.lang.reflect.Method.getParameterTypes()" because "method" is null in energy

The biding is running fine as I get the correct data for the ForecastSolarHome_Actual.

Do you know how to solve this issue?

Thank you

sihui · January 19, 2025, 6:08pm

Because the api call limit for Solcast is now only 10 calls per day for the free plan, I implemented the manual update trigger.

According to the docs

the actions for the Thing should be

getActions("solarforecast","solarforecast:sc-plane:homeSouthWest")

This did not work for me, I had to use

getActions("solarforecast","solarforecast:sc-plane:homeSite:homeSouthWest")

@weymann, thx for this great binding, could you please have a look? I’ll be glad to make a PR for the docs if necessary.

weymann · January 21, 2025, 12:32am

Sure, I’m happy for every contribution!

This needs to be corrected too, right?

rule "Solacast Updates"
    when
        Thing "solarforecast:sc-plane:homeSouthWest" changed to INITIALIZING or // Thing status changed to INITIALIZING

sihui · January 21, 2025, 2:10pm

Yes.

Done:

https://github.com/openhab/openhab-addons/pull/18150

weymann · February 2, 2025, 5:45pm

Dear Solcast users, since some months I see the pain regarding low update frequency due to reducing the throttling limit to 10 calls per day by Solcast e.g. from @sihui @stefan13 @fmeili1

I want to introduce 2 improvements to lower the number of Solcast API calls.

Forecast is stored now in persistence. This ensures no extra API calls after restarting the system or disable/start things. But it will not survive deletion of things.
Solcast Plane Configuration contains now config parameter guessActuals which is true as default. This ensures one instead of two API calls per plane.

Current Version
The current released version performs 2 calls per update

fetch actual data - contains values till next full half an hour.
E.g. query at 07:31 delivers data till 8:00
fetch forecast data - contains data from 8:00 plus 6 days

Improvement Proposal
Instead of call 1) the values from previous forecast are taken as actual values. Only if there is no previous data call 1) is executed.
So if you try out this marketplce version you’ll see 2 initial calls after exchanging the binding. Now forecast is in persistence and further updates will reduce to 1 call pere update as promised.

To observe this behavior sc-site and sc-plane are now equipped with an update group which cotains a counter and timestamp of API calls.

Feedback
Highly appreciated - fine or not, do you have improvement proposals or prblems,…

sihui · February 2, 2025, 6:24pm

As soon as HTTP Status Code 429 is gone

sihui · February 3, 2025, 9:00am

Looks great so far

I had to restart openHAB several times this morning because of a problem with another binding, the api counter still shows: {"200":1,"other":0,"429":0}, so I don’t have to disable the updating rule anymore during restart.
Also valid data is coming in, so at least for me I can say: very satisfied and thx a lot.

ollo · February 3, 2025, 12:02pm

Hi @weymann,

may I suggest to (initially) pull historic data for (at least) the current day at startup?! The reason is sunrise may happen before 8am locally, so when doing some calculations based on the timeseries some data points (before 8am) might be missing, in case there is no persisted data. Not all persistence service allow to “store” the data of a timeseries. I’m using rrdj4 as the default persistence service + inmemory service for timeseries. While that works great, any future data will get lost in case of reboot. Certainly past data gets persisted in rrdj4, but future data is gone at startup.

Thanks for your great work!