Thanks a lot! I think I will wait for a binding update then!
I am using Forecast.Solar to charge my battery on the night tariff rate between midnight and 7am. I am using my own developed OH binding for Growatt inverters.
Typically the Forecast.Solar forecast is absurdly optimistic during the night time window – see example from today below where its forecast (blue line) during the night time low tariff window was ~5kWh whereas the actual (red line) and ‘to go’ (green line) results ~1kWh.
This over optimism resulted in me charging the battery by ~4kWh less than I should have done, and therefore having to pay for that energy at the day tariff rather than at the 30% lower night tariff.
I wonder if this is a specific problem with Forecast.Solar? And/or if Solcast is better?
Any thoughts?
What data point are you using? I’m thinking you’re using the “overal forecast” for the day? That sums up the forecast for the whole day (midnight to midnight), and therefore has of course also the dark hours “within” so to speak.
What i do is to calculate the “hours until sunrise”, so my rules can see, when to expect solar energy:
As you can see, after midnight the forecast is calculated for the present day and then gets updated as we move forward. It can be, that there’s a sudden peak or decline - depending on weather forecasts (overshadowing, rain/snow, …), that’s why there’s no “20kWh forecast declines linearly until midnight”.
but I can see, why your misconception is there in the first place, the declining ends exaclty with sunset - but don’t start with sunrise.
Yes that is correct. At 00:15 I look at the forecast for the newly started day. And if it is forecasting a lot of solar energy to be produced during that day, it will not charge the battery during the period 00:15 … 07:00 … Whereas if it is forecasting very little energy during the day, then it will preload the battery before the sun rises (and the tariff rises)…
if it’s solely a issue of “Who’s got the better forecast”, it depends as I have learned. In my region (southern germany), Solcast appears to be more reliable with regard to what I actually experience. But there’s differences in how both services use weather predictions and/or snowy PV modules in their forecasts. I did let both run in parallel and made comparisons with my actual production.
Yes, that was (essentially) my question. (I am in the east of UK). I suppose the underlying question is what data sources do the two providers use for their predictions? I suppose if it is land based data then Germany would have better forecasts than UK. Whereas if it is satellite based it should not make much difference.
EDIT: I also wonder if the UK weather binding could add value to the solar forecast binding. Or??
I don’t think so. The binding simply forwards the API-data to things and items, to add another layer with some (especially only locally available) data sources doesn’t seem a good idea.
I use the forecasts only for a rough estimation, but you could of course combine local weather predictions like overshadowing, rain/snow, … to your rules and built your logic there.
Due to the fact Solcast has very strict API throttling it “looks” more stable. But you can see also too optimistic data including up/down peaks during the night. Jan 6th and 7th (first 2) forecast.solar was pretty stable and more accurate than Solcast. See pictures below.
I wouldn’t do so. As far as I can see from the docs on the bottom forecast.solar is using DarkSky API as weather forecast. Don’t think another weather forecast on top makes sense.
I can see in your graph this drastic discrepancy. Is this systematic behavior on your side?
Solcast last week
Forecast Solar last week
Pretty much. Yes.
Hello.
The binding is working well so far, yet I wonder if maybe I am misunderstanding something w.r.t. the value/item forecast_solarhome_today. I was expecting that this item would show, at time t, the forecast at time t for the total production of the entire plant for that whole day. Naturally, unless in the morning that forecast was totally off, I would expect this value to remain more or less steady during the day. However, on a typical day, I am seeing such weird flip-flopping values:
Am I misinterpreting something here? Or else how do such values make sense? Why would predictions change to radically throughout the day? And why, for instance, would they even change long after the sun has set for that day?
You are not misinterpretating. I guess the fluctuations reflect the extreme difficulty of weather forecasting on a micro scale. (Think of local cloud formation…)
1 Like
Okay, thanks! Still, I find it weird that the forecast does not even settle on a value after sunset.
there’s basically two channel “types”:
- general forecast
- actual forecast
your item seems to be one of the “general” ones. the general channel values differ as Andrew explained throughout the day because of fluctuations in overclouding or whatever. the actual channels also follow those fluctuations, but they fall gradually until sunset.
one channel/item is for comparisons based on “whole day”-operations/rules, the other for “remaining day” operations.
for example: I use the “remaining”-values for my rules to check, how much energy I can expect for the remaining day until sunset (e.g. can I turn on “luxury devices” without risking a low or empty battery over night). the “whole day”-forecast is irrelevant in my case.
Hi Bernd, any news/ idea when an updated version of the add-on will be available, that supports the time-series feature of OH 4.1? 
Hey,
i’m looking forward for this too, i’ve checked out the PR at https://github.com/openhab/openhab-addons/pull/13308 and thought it was integrated there, as you’ve mentioned before, but thats not the case 
The update towards TimeSeries takes much more efforts than I thought! It’s not working out of the box. See picture below of the OH 4.1 Release Notes. You need e.g. an influxdb to store future values - standard RRD4J will not do it. Due to this fact a graph for future values isn’t provided also
So the OH4.1+ binding has channels
- power / energy estimate as TimerSeries - raw forecast data
- actual / remain / total data for todays forecast - interpolated
- rule actions for any timestamp / time period you want
When I use the example in the readme the things go online but the items are not updating. Anyone had this issue before?
openHAB 4.0.1
Release Build
@weymann I just updated from OH v4.1 to v4.2M1 and I find that the binding does not work any more. I suppose this is due to the new time series stuff. ?? During the OH update process I did not specifically load your new jar. So I am wondering if the OH update process did somehow change to your new jar without me actually doing anything?
EDIT: after further checking, it seems that with the upgrade from OH v4.1 to v4.2M1 the following things happen…
- Yes, the new version of the Jar gets installed
- The prior existing things remain, but all of their channels are deleted
- Unfortunately the ‘solution’ is to delete and recreate all the things
- PS my issue was NOT due to the lack of persistence service, since I don’t actually use such channels
@J-N-K is it correctly interpreted that persisting future values won’t work when you run rrd4j ?
I’m struggling to infer that from the description in the Release Notes.
Given that’s our default OH database it’s the most important that all bindings to make use of TimeSeries should work with, shouldn’t they.
Do the openweathermap and Energi DS bindings work with rrd4j ?
Correct. RRD4J can’t be used with timeseries because the databsse is not modifiable. In fact, for most cases where future values are useful (like prices / forecasts) the aggregation done by rrd databases would be a bad idea anyway.
1 Like