Solar Forecast PV

Hi @weymann,

this seems to be a great binding. As a newbie with PV I am experimenting a little bit. So I installed your binding and encountered an error:

FrameworkEvent ERROR

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.solarforecast [325]

  Unresolved requirement: Require-Capability: osgi.extender; filter:="(&(osgi.extender=osgi.component)(version>=1.5.0)(!(version>=2.0.0)))"

I am still on openHAB 3.4.2, not 3.4.4. Is this maybe the minimum requirement?

Have a good one!

I worked with this bundle till OH3.4.5. As you can see Snapshot version is 3.4.0 so I’m not assuming it’s causing version errors.

Can you check version installed?
If you’re on raspberry pi login and
ssh openhab@localhost -p 8101
Password: habopen
type bundle:list -s | grep solar

openhab> bundle:list -s | grep solar
244 │ Active │  80 │     │ org.openhab.binding.solarforecast

I’m on OH4 but what’s the version you get?

Hey @weymann,

I installed from marketplace and - like you exspected - I got a the 4.1 version. Very strange. I tried again (remove, another install), same result.

So, in the end, I removed it and took the download from the first post - with success. :slight_smile:

Thanks for your help!

1 Like

Correct, we observed this behavior also with MercedesMe binding.

Marketplace for OH 3.x and OH4.0.3 works but not for OH 4.1 Milestone.
Bundle needs to be dropped into addones folder

Karaf was recently upgraded, which I think breaks compatibility between addons compiled with/for a different Karaf version.

Correct, but that’s not the point.
Whyever OH4.1 snapshots are taking really wrong version from Marketplace. Reproducible with my MercedesMe binding which every time installs OH3 version. But OH4.1 binding version is added too.

That looks interesting. Can you please create an issue?


Hi Bernd,
I’m running openHAB 3.4.4 and from marketplace I got the version:
280 │ Installed │ 80 │ │ org.openhab.binding.solarforecast
which does not run.
With this version org.openhab.binding.solarforecast-3.4.0-SNAPSHOT.jar in addons I get the exception
2023-10-21 04:06:06.347 [ERROR] [Events.Framework ] - FrameworkEvent ERROR Exception in opening zip file: /var/lib/openhab/cache/org.eclipse.osgi/18/0/bundleFile
at org.eclipse.osgi.framework.util.SecureAction.getZipFile( ~[org.eclipse.osgi-3.17.200.jar:?]
at ~[org.eclipse.osgi-3.17.200.jar:?]
at ~[org.eclipse.osgi-3.17.200.ja
at ~[org.eclipse.osgi-3.17.200
at ~[org.eclipse.osgi-3.
at ~[org.eclipse.osgi-3.17.200.jar:?]

Is there a compatible jar for openhab 3.4.4?
Or any other hint to overcome this issue?

I used this binding up to OH 3.4.5 so it is compatible.

Error looks more the way that there’s a conflict of 2 parallel installed PV Forecast bindings. Saw this also for other bindings.

My suggestion is to clean up your current installation from any Forecast Solar installations: Follow instructions below. It’s the same problem as for MercedesMe binding but I think you can easily adapt to Solar Forecast.
I’m pretty sure after this cleanup and a fresh restart the 3.4 binding will work after dropping it into the addons folder.

I fixed it by updating to OH 3.4.5, clearing the caches, and fixing the ownership with openhab-cli.
Now the bundle is listed and running.

1 Like

thanks for this great binding.
Can I use it’s Community Marketplace version when I’m on OH release 4.0.1 (Release Build) or do I have to switch to another OH release?


Would anyone be so kind and post the things and items file if you got the solcast service up and running ? I noticed there is an example for solarforecast but not for solcast.


Just pick OH4.1 version in top post. Works in actual stable version OH4.0.3. Please don’t install from Marketplace - please download jar file and put it into addons folder. Saw too many problems for different bindings picking the correct version and afterwards cleanup is necessary

1 Like

Hi all,
I very much like the remaining kWh indication. I would like to use that to shut down my heat pump to fill up the battery until sun sets. However, this neglegts the residual consumption in the house.
How would I tackle this ? If the remaining consumption was evenly distributed until sunset, that would be easy…
Best I can think of is assuming the residual consumption is covered up until an hour before sunset but that woud vary a lot across the seasons.
Any ideas ?

That’s either individual or a rough rule set.
What I do:

  1. use residual consumption (either as a static like 400W - or dynamic from historic use)
  2. predict all remaining consumers, which are outside normal residual consumption (heat pump, washers, pool heating)
  3. calculate remaining needed consumption to fill up the battery to at least 90%)

then use all those parameters to calculate, if my controllable consumers (wallbox for EV, washers, heat pump,…) are allowed to run (if you’re feeling lucky add some priority to that also! :wink: ).

…and if you’re feeling REALLY REALLY lucky and you use dynamic energy prices (like tibber, awattar or the like) add the hourly prices for energy to that rule(s) also! :wink:

or work with some rough variables and just insert those into some rule-logic and you should at least cover 80-90% of the above with that and avoid complex ruling to achieve the best possible use of the last Wh…

Thanks. One more question about the Things file.
The channelRefreshInterval parameter is used with quotes or without ? I am asking because the readme uses for refreshInterval in the plane no quotes and for the other parameter there are quote.
I gues it does not make any difference.

Sorry for the spam, but IMHO this should go into the readme: Did you know that whenever you save your config, i.e. the items file, this triggers a whole lot of things in the background ? The system started rule AND it also triggers a request to the solcast API.

So you can save your items file like 3 times and then you’re stalled for the day :frowning:
@weymann Is there anything that can prevent this ? I would love a method that triggers the api calls manually.

Config parameters needs quotes for text types and no quotes for numbers like integer or decimal. You are right: one refreshInterval had quotes in readme - luckily openHAB is so smart to convert it into a number. But it is fixed now.

  • changing .things yes. Changing configuration causes disposing the Thing and set it up from scratch. But Solcasts mandatory parameters are copying keys and refresh intervals. Set it up once and leave it
  • changing .items no. You should be able to change your items whenever you want. Just added a few test items and they are updated without triggering new API requests

Here is how I enable an disable things:

Note, you have to get yourself an auth token and replace the one below. Also be aware that toggling things triggers the system started rule. Maybe there is even more than that triggered but I am not aware of that.

rule "enable things"
     Time cron "00 00 06 ? * *"  // run 06:00 hours every day
     var headers = newHashMap("Authorization" -> "Bearer oh.RestApiDisableSolcastThing.YOURTOKENHERE", "WWW-Authenticate"-> "Basic")
     sendHttpPutRequest("http://localhost:8080/rest/things/solarforecast:sc-site:SolCastWandSite/enable", "text/plain","true",headers,1000);      

rule "disable things"
     Time cron "00 00 18 ? * *"  // run 18:00 hours every day
    var headers = newHashMap("Authorization" -> "Bearer oh.RestApiDisableSolcastThing.YOURTOKENHERE", "WWW-Authenticate"-> "Basic")
    sendHttpPutRequest("http://localhost:8080/rest/things/solarforecast:sc-site:SolCastWandSite/enable", "text/plain","false",headers,1000);


btw, “enble” is not a typo in the disable rule :wink: Mind the “false” parameter later on.

In JS Scripting, this should work:


See JavaScript Scripting - Automation | openHAB.