Solar Forecast PV

jlikonen · April 9, 2025, 4:50am

I have managed to solve my problem some days ago. Persisting Solarforecast Items to InfluxDB was OK so I deleted them and the Things, and finally recreated them. Now the binding works. I don’t know what caused the problem.

hyzteric · April 19, 2025, 9:21am

So I don’t want to pollute the thread, but I had a weird bug and wanted to share how I solved it.
I have been using solcast for a while and it was working fine. I only do one refresh per day using the supplied rules.
I use those triggers :

>   Thing "solarforecast:sc-plane:home:east" changed to INITIALIZING or 
>   Time cron "0 0 13 ? * * *"

A few days ago I noticed a predicted 30kwh+ but it was raining all day… Ok just a refresh bug… but after a few days, I realize it is not updating anymore at all. All values stay the same.

I wanted to check the Things via the openhab interface to see if there were any error. But I could not find the things in the list.

In fact the binding was not installed anymore!

I don’t know how nor why it was uninstalled but I had to install the binding again (from marketplace, no manual jar file). Hopefully I use configuration files so nothing was lost.

But then this error :

> 2025-04-19 10:52:48.988 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarforecast:sc-site:home' changed from OFFLINE: Exception during update: solarforecast:sc-plane:home:west # Day 2025-04-19 not available in forecast. Invalid time range to OFFLINE: Exception during update: solarforecast:sc-plane:home:east # Day 2025-04-19 not available in forecast. Invalid time range

To fix it, I went to the openhab settings, selected the sc-plane Things then under “Action” I clicked Trigger Forecast Update. I had to wait for some time and it went back ONLINE.

Hope it helps anyone.

weymann · April 19, 2025, 10:22pm

Don’t worry, there’s no pollution! I highly appreciate for reporting problems and then show a solution based on solarforecast actions to solve it - well done!

I’m interested how this problem can happen and check also beyond this binding to prevent this.

Never seen this happen spontaneously.
Any upgrade installed during the last days or restored an backup?

Doesn’t matter if textual or UI configuration - things will stay.
This is my main point here: Things will go OFFLINE

For me personally it’s crucial to have forecast data to calculate BEV charging, home battery charging, HVAC control, dynamic tariff usage like Tibber, …

So i’m highly interested if the forecast goes OFFLINE and then
a) try to recover
b) send notification

This shall avoid the situation to recognize per accident that forecast goes OFFLINE

// not tested!
var Timer recoveryTimer = null
var Timer notificationTimer = null

rule "Solacast Offline"
  when
    Thing "solarforecast:sc-plane:homeSite:homeSouthWest" changed to OFFLINE 
  then
    recoveryTimer = createTimer(now.plusMinutes(5), [ |
      logInfo("solcast recover", "Solcast recovery")
      // trigger solcast manual update
      val solarforecastActions = getActions("solarforecast","solarforecast:sc-plane:homeSouthWest")
      solarforecastActions.triggerUpdate
      notificationTimer = createTimer(now.plusMinutes(5), [ |
        //check thing manually                  
        sendNotification("me@email.com", "Check Solcast Thing")
      ])
   ])
end

rule "Solacast Online"
    when
        Thing "solarforecast:sc-plane:homeSite:homeSouthWest" changed to ONLINE
    then
        recoveryTimer?.cancel()
        recoveryTimer = null
        notificationTimer?.cancel()
        notificationTimer = null
end

weymann · June 9, 2025, 7:41pm

There are 2 new prototype things available on the Marketplace version!

For forecast solar paid subscription:

adjustable-fs-site with mandatory apiKey to adjust the daily forecast
adjustable-fs-plane with mandatory configuration powerItemName, powerItemPersistence and holdingTime

For forecast solar public (no subscription):

smart-fs-site no additional configuration parameters, one addtional channel
smart-fs-plane with mandatory configuration powerItemName, powerItemPersistence and holdingTime

Main goal is to adapt the forecast values according to real production to give the forecast more precision during the day. See readme for further description.

michaeljoos · June 10, 2025, 9:31am

I have quickly tested this and added smart-fs-site and smart-fs-plane things to my system:

The power item is “PV_Energy_Meter” and I’m sure rrd4j persistence is available because I can see the history. But when I select rrd4j in Thing, then I get:

Item PV_Energy_Meter not found in persistence rrd4j

With MapDB the thing goes online, but this probably makes no sense because MapDB only saves 1 state and there is no history.

Also items shows 0 after 4 hours for Power and Energy Forecast. But here I’m not sure if I have another issue. Need to check . . .

I’m already on openHAB 5.0 M2 and I see it is not officially supported, right? Solcast I’m using without any issues and maybe this input helps for future use with OH5.

In the meantime I also have tested with “Adjustable Forecast Solar Site” and “Adjustable Forecast Solar Plane” (Trial subscription).

I see this when switch to Debug and Trace:

- Unable to determine first measure of forecast
- Parameters for query
- Call https://api.forecast.solar/xxxxxx
- ForecastSolarPlaneHandler setForecast called with {"result":{"watts":{"2025-06-10 05:29:15":0,"2025-06-10 05:30:0

API-Call and result looks good in my opinion. But items (e.g. Power Forecast) remain NULL.

The problem with “Item PV_Energy_Meter not found in persistence rrd4j” I see in both versions “smart” and “adjustable”.

DanielMalmgren · June 10, 2025, 6:18pm

This sounds like a brilliant addition! If I understand it correctly, the item named by powerItemName needs to be an item reporting the actual production in kW right now and that’s used for correction of the forecast?

I am mainly using the actions (getEnergy()) in my scripts though, I guess that won’t be affected by the correction, is that right?

weymann · June 10, 2025, 7:58pm

Good to mention it’s OH5. Looked into it and it’s a bug in rrd4j persistence implementation. This is now fixed for the next Milestone.
But I was able to provide a workaround which will run in OH5 - Marketplace bundle is updated.

Just note these are TimeSeries items so they need to be connected to a persistnce capable to store forecast like influxdb or inmemory.

michaeljoos · June 10, 2025, 8:00pm

Ah cool! I will try new version.

BTW this I have also seen:

Power item PV_Energy_Meter has no unit. Skip Energy calculation!

Is it mandatory to have a configured unit (W) for the power item? I have only used with state description until now and then I get this in log.

michaeljoos · June 10, 2025, 8:06pm

Yes, I use InMemory.

weymann · June 10, 2025, 11:12pm

Yes, in order to avoid ambiguous values the input needs to be well defined. Item shall be Type Number with Dimension Power. Unit conversion is done in binding so doesn’t matter if item contains W or kW values.

Not really, Power iten, not Energy! In above picture you see the example of my powerItem which posts frequently the power values. Actual energy production with the right unit is calculated inside the binding.

DanielMalmgren · June 11, 2025, 4:39am

Sorry, I don’t follow… I asked if I need an item with the production in kW (ie power), what is the difference?

If I understand things correctly you will use my production power item (W or kW) and from that calculate todays total energy (kWh) which will then be sent to Forecast with the actual parameter, is that right? In my case I can get todays total energy directly from the inverter, it would be nice to use that instead, it will probably be more correct.

Also, you missed my questions about if this affects the getEnergy() action

michaeljoos · June 11, 2025, 5:38am

Good news! Now everything seems to work

One question, but I know this is coming directly from API. In this picture we can see Energy Forecast from Solcast (dark green) and Solar Forecast (light green):

Would it be possible to implement in binding that Solar Forecast keeps the value until midnight and then reset to 0? It seems Solar Forecast does not send any values between sunset and sunrise. This looks not so nice in the graph

I have also not 100% understand the new functionality:

Main goal is to adapt the forecast values according to real production to give the forecast more precision during the day

Does it mean the binding reports back the actual power to Solar Forecast and then we have a “kind of learning”? Or is this just an internal binding calculation to continuously correct the energy forecast for the day?

OK, found the information here:

weymann · June 12, 2025, 12:11am

Thanks for this fruitful discussion! I see some more clarity is needed so please help me to imrpove readme in order to make it clear!

No changes for action handling. getEnergy will work as before just taking the corrected values into account!

Let me be very precise here. And please check what I can do better in readme to improve!

The actual parameter in forecast solar is only available for paid accounts!

At the top of readme #supported things you see new things added - cross check with relased binding!

adjustable* for paid subscription: this is using the actual paraameter towards forecast.solar
smart* for free subscription, not using actual parameter. Binding internal calculation!

image902×581 37.3 KB

DanielMalmgren · June 12, 2025, 4:59am

Ah, perfectly clear now, thank you!

A feature wish from me would then be to also include this in the actions, so when calling getEnergy() using a smart or adjustable site or plane it would take this into account. Would that be possible?

weymann · June 12, 2025, 3:13pm

That’s right. Let me check that.

Currently I don’t see a learning effect and docu is mentiong “onlyactual day is effected”

But you’re on the right track! In future I want to add more intelligence into the smart-* things.

weymann · June 12, 2025, 3:35pm

Perhaps I was again not precise enough
There are no technical changes for getEnergy or any other action. This means you don’t have adapt rules or something like that.
But of course results are different!

You can do your own test creating one normal forecast (fs-site,fs-plane) and a smart one (smart-fs-site,smart-fs-plane). You will receive different result, if you have a correction factor != 1

DanielMalmgren · June 12, 2025, 5:27pm

Ah, that’s great! Will try it out as soon as I get time!

Is the plan to get these changes into stable in time for 5.0?

weymann · June 15, 2025, 4:37pm

I put a new version onto Marketplace:

Good point! I don’t have this possibility but perhaps other users like this option too. For this some some changes are required:

configuration needs to be changed: item name is now calculationItemName and calculationItemPersistence
configured item needs to be type Number:Power or Number:Energy - binding can handle both types

Would be happy if you can test and provide feedback!

Fixed! Thanks to forecast.solar is now providing full=1 parameter values are delivered for all time periods.

Yes, depends on

how fast pull request can be reviewed
more delicate: as I see this would be the first thing (solarforecast) that depends on an item from another thing (your inverter). Perhaps this will raise some discussion.