Yep, double and triple checked al UIDs. Also recreated all of my things a number of times now, tried reusing old names, giving them new names etc.
It seems I completely broke something by having the two bindings installed simultaneously and I’m not able to mend it now. My best guess is that when I do getActions() for “solarforecast” it doesn’t know which binding to use and somehow it still points to some old instance of the binding, even though I’ve tried purging everything.
edit: After some more testing: It’s not the getActions() that crashes, it’s when I try to do anything at all using the actions… When I try with a plane name that for sure doesn’t exist it crashes at the getActions() though, so I’m sure it finds my plane.
Ok, I’m back on track! I ended up having to stop OH and manually purging all solarforecast stuff from my jsondb. Now after starting and re-adding the marketplace binding things actually seem to work again!
What I’m not really clear on now is how to determine whether the correction actually does anything… I can see my script getting out a forecast, but I’m not really sure if it’s any different from before. Also tried connecting an item to the correction factor channel, but it stays NULL…
edit: Guess NULL was because of a bit of impatience… Now it says 0.000 though, not much better…
edit again: Noticed this in my log, guess that’s a problem. I’m now using an Number:Energy item, holding today’s production in kWh.
17:47:59.918 [WARN ] [ng.solarforecast.internal.utils.Utils] - Cannot convert Unit kWh to kW
I changed this based on your request approx 3 weeks ago. So I assume you’re no on the latest Marketplace version. In case of an error you should see something like this
Item {} unit {} doesn't match power or energy
Of course please don’t install Marketplace version parallel to Release version. It’s the same code installed twice and behavior is totally unpredictable. So please uninstall Marketplace version, aftwerwards install again and check the logs.
I installed it from marketplace after your post, just assumed that would give me the latest version? I can’t see any way of updating it, it says it was updated “10 juni 2025 kl. 16:57”.
Given that the first time ever that I installed the marketplace version of the addon was 21 june I am very sure that any older marketplace version than that isn’t relevant, so yes, I’m at the correct version.
I’m sorry, but that was not obvious to me, given that the binding has different names I thought they could be installed in parallel. It would be good if that was clearly mentioned in the first post of this thread.
Anyway, after completely purging my system from the binding (manually removing it from jsondb) and reinstalling from marketplace I’m now quite sure I only have the marketplace version installed.
edit: Since I can’t seem to find any addon version in GUI I checked Karaf now just to be sure:
327 x Active x 80 x 4.3.6.202506151608 x openHAB Add-ons :: Bundles :: SolarForecast Binding
@weymann did you give up on this one? I guess I’m the only one who has tried using a Number:Energy item for this since nobody else has commented about it, but it still would be nice to have it working.
This is in - you can connect now an Energy item. Remove your installed Marketplace binding and install it again, then you’ll have the newest version.
The actual production value is queried each time a new forecast is queried according to refreshInterval config parameter.
For power values I personally know for my system they are updated each second - so I know this is up to date.
Do you know the update frequency of your energy item in order to ensure that values are not e.g. 10 minutes old?
Yep, seems like you nailed it! Reinstalled the marketplace binding (went from 4.3.6.202506151608 to 4.3.6.202507251905) and now I get values in the correction factor!
However I’m back to the problem I had when first installing this marketplace version, when trying to use actions in the binding I get this strange error:
10:01:00.284 [ERROR] [l.handler.AbstractScriptModuleHandler] - Script execution of rule with UID ‘01fb28509d’ failed: class org.openhab.binding.solarforecast.internal.actions.SolarForecastActions cannot be cast to class org.openhab.binding.solarforecast.internal.actions.SolarForecastActions (org.openhab.binding.solarforecast.internal.actions.SolarForecastActions is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @46f153b7; org.openhab.binding.solarforecast.internal.actions.SolarForecastActions is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @664fdf3a)
Tried removing the things and recreating them, but still the same error. Am I the only one who seems to get this problem every time I upgrade the binding?
Did you perform during the time restart of openhab?
It’s not about changing the binding it’s the java runtime which is confused.
I propose the following.
Check ifor binding installations
a) Open console with openhab-cli console on your openhab device
b) Password is habopen
c) Check installed bindings with bundle:list -s | grep solarforecast
I’ve done some analyzing of my correction factor, trying to establish if there’s room for perfection. A factor of 1 means the binding uses the forecast straight off, right? What I notice is that the value starts very low in the morning, and not until 10 or 11 oclock it’s getting up to 1, I guess that means that I’ll be getting very low forecasts in the morning? I have the holding time set to default 120, would it make sense to increase that?
Sadly my development machine crashed so I’m not able to show you my curves. But I see your point because I’ve also similar behavior. Before noon factors below 1 and after noon bigger than 1.
The correction factor is calculated to match the formular forecast * correction factor = real production
So other way round. The forecast in the morning is too high and needs a down correction with factor below 1
holdingTime is just the waiting time when correction shall start. For me this value shall be as low as possible but high enough to avoid drastic ccorrections.
Imagine to set holdingTime = 1, so one minute after first value, which is quite low, e.g. 25Wh. If PV produced nothing factor will be zero. If PV produced 100Wh factor is 4. Both factors 0 and 4 are not realistic => correction starts too early.
I’ve given up on Forecast.Solar. That service is too often too much off. And no update on the Discord channel on this topic for more than a month.
I have created my own solar forecast which works surprisingly good, way more accurate than ForecastSolar. Using the Open-Meteo binding to fetch the “Global Tilted Radiation GTI (Instant)” parameter with the tilt and azimuth of my panels. This gets me the incoming radiation in Watt per m2. Multiplying this with the active area of the panels and the panel efficiency (~20%), it results in the current power generated. Since the data comes as a time series, one can sum up (RiemannSum) the data to calculate the energy for a given time range e.g. all day (sun rise to sun set) or day till now (sun rise to now) remaining today (now to sun set) or all tomorrow.
I’m pulling data in 15min resolution, but 1h resolution should be good too. The data is updated by Open-Meteo every 3h, it seems. It’s good enough to reliably control my battery charging rates.
Astro binding also has a radiation channel, non-tilted but I guess one can find out about the required math.
openweathermap has a cloudiness forecast channel, too, that you could use to optimize.
If you could build a forecast that works 100% offline without dependencies on commercial services, and publish it on the marketplace, I believe we all could benefit from it.
I didn’t mean to do it in a binding but in rules, DSL or JS, and to publish them on the marketplace.
Well, it’s still an online dependency. And not guaranteed to still exist as such in another year or two. What I proposed would be a way more sustainable solution for OH users.
I used your Solar Forecast PV since several months under OH4 without any issues. Recently I updated to OH5. After the update the binding was dropped from my list of installed things resulting in orphan links. After having installed the latest version from the marketplace (26. Juli 2025 00:06) all links were back with one exception: The raw json channel is still orphaned. Did you remove the channel from the binding or was there a syntactical change?
Curious, this SolarForecast binding had no changes when switching from OH4 to OH5. Maybe you had a Marketplace installation or jar in addons folder?
Yes, the raw channels are removed in Marketplace version. It contains more changes with adjustable and smart forecast but we were not able to have it ready for OH5 - still ongoing.
Yes, I had a market installation. In my backups I found ‘org.openhab.binding.solarforecast-4.3.4-SNAPSHOT~20250814-174206.jar’. So I assume, this is the version which still supports raw, right?
Why did you drop the raw channel with the new version? Will it be available again with the OH5 version?
