Solar Forecast PV

[HFM (Henning F. Mettge)]

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!
HFM

[weymann (Bernd Weymann)]

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 │ 4.1.0.202307312221     │ org.openhab.binding.solarforecast

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

[HFM (Henning F. Mettge)]

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.

Thanks for your help!
HFM

[weymann (Bernd Weymann)]

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

[florian-h05 (Florian H.)]

@weymann

Marketplace for OH 3.x and OH4.0.3 works but not for OH 4.1 Milestone.

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

[weymann (Bernd Weymann)]

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.

@weymann

• Doesn’t work with Marketplace - wrong binding installed - same exception as you posted!

[florian-h05 (Florian H.)]

@weymann

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?

@J-N-K FYI

[herbdaheim_97 (Herb)]

Hi Bernd,
I’m running openHAB 3.4.4 and from marketplace I got the version:
280 │ Installed │ 80 │ 4.1.0.202307312221 │ 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
java.util.zip.ZipException: Exception in opening zip file: /var/lib/openhab/cache/org.eclipse.osgi/18/0/bundleFile
at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:356) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.doOpen(ZipBundleFile.java:51) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.storage.bundlefile.CloseableBundleFile.open(CloseableBundleFile.java:135) ~[org.eclipse.osgi-3.17.200.ja
r:?]
at org.eclipse.osgi.storage.bundlefile.CloseableBundleFile.lockOpen(CloseableBundleFile.java:77) ~[org.eclipse.osgi-3.17.200
.jar:?]
at org.eclipse.osgi.storage.bundlefile.CloseableBundleFile.getEntryPaths(CloseableBundleFile.java:293) ~[org.eclipse.osgi-3.
17.200.jar:?]
at org.eclipse.osgi.storage.Storage.listEntryPaths(Storage.java:2095) ~[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?
Regards
Gerd

[weymann (Bernd Weymann)]

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.

@weymann

So let’s go into the machine room. Cleanup everything for mercedesme: Things, Bridges, Binding

• UI
  • ensure everything is uninstalled from openHAB release & Marketplace
  • delete binding from addons folder
• Your Server
  • check directory /var/lib/openhab/marketplace/bundles
  • any numbers in there? Check if one subdirs contains mercedesme binding and delete it
• openHAB Console
  • on your server login to openHAB console with
    ssh openhab@localhost -p 8101
    Password: habopen
    type bundle:list -s |g rep merc
    Nothing shall be found! Otherwise tell me!
• Perform a restart with systemctl restart openhab
  • Check again all steps above - no bundle in marketplace, bundle:list shows no MercedesMe binding

[herbdaheim_97 (Herb)]

Thanks,
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.

[Hannes4.0 (Hannes Leopoldseder)]

Hello,
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?

Thanks,
Hannes

[s0170071]

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.

[weymann (Bernd Weymann)]

Just

@Hannes4.0

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?

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

@weymann

Resources

org.openhab.binding.solarforecast-3.4.0-SNAPSHOT.jar

org.openhab.binding.solarforecast-4.1.0-SNAPSHOT.jar

[s0170071]

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 ?

[binderth (Thomas Binder)]

@s0170071

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.

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! ).

…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!

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…

[s0170071]

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.

[s0170071]

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
@weymann Is there anything that can prevent this ? I would love a method that triggers the api calls manually.

[weymann (Bernd Weymann)]

@s0170071

refreshInterval in the plane no quotes and for the other parameter there are quote

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.

@s0170071

Did you know that whenever you save your config, i.e. the items file, this triggers a whole lot of things in the background ?

• 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

[s0170071]

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"
when
     Time cron "00 00 06 ? * *"  // run 06:00 hours every day
then
     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);      
end

rule "disable things"
when
     Time cron "00 00 18 ? * *"  // run 18:00 hours every day
then    
    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);

end

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

[florian-h05 (Florian H.)]

In JS Scripting, this should work:

things.getThing(UID).setEnabled(true)

See JavaScript Scripting - Automation | openHAB.