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.
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
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.
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.
1 Like
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
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
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:
- use residual consumption (either as a static like 400W - or dynamic from historic use)
- predict all remaining consumers, which are outside normal residual consumption (heat pump, washers, pool heating)
- 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…
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 
@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 .
thingsyes. 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 .
itemsno. 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"
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.
In JS Scripting, this should work:
things.getThing(UID).setEnabled(true)
@weymann many thanks for the great binding!
Does anyone know what might be causing the following info message?
2023-11-30 18:01:02.506 [INFO ] [internal.SolarForecastHandlerFactory] - Persistence null cannot be queried. Feature Solcast Tuninng will not work
PS just a minor point: the log message has a type ‘Tuninng’
Typo already removed as part of ongoing Pull Request 13308.
Message says that default persistence cannot be found. Tuning takes the last 15 minutes from persistence and submits it to solcast. So if persistence cannot be found this particular feature won’t work. But it doesn’t affect the forecast.
Sadly I learned this feature is obsolete. API calls are still working but it seems the calculated values are not taken into account anymore.
It’s a pity. I my case resp. location I do see an enormous fluctuation in the daily forecast (blue line in the chart below), and some kind of smoothing would be very useful.
