@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.
Yes, I know. I’ve a similar graph showing fluctuation
But I would refuse to do any smoothening because I simply forward the data received by the provider.
What shall smoothening look like?
If I receive a 50% increase / decrease from the provider shall I say Ahh no, that’s too much - let’s take whatever-not-too-much% and calculate the forecast on my own?
Sorry for any misunderstanding. I wasn’t asking you to do smoothing. I just think it is a pity that the provider has killed the capability to incorporate user system feedback into its own forcasts. (It would probably be a good candidate to do with an AI algorithm)…
Hey,
i’ve just read the openhab 4.1 release notes and read about the new feature of time series support for forecasts.
As i’m looking for a solution to display the forecast and actual values, i think this is just an amazing feature which just makes this very easy to handle this values in openhab and use them for planning.
So as the services provide some more details, this should be really easy to support. Are there any plans/ideas to implement this? Otherwise i’would give it a try.
BR
Sönke
Thanks a lot for this great binding! I have one question: Currently I am using ForecastSolarHome_Actual_Power to visualize the forecast for today. However, as you can see, this obviously only shows the forecast for the past, not the future portion of the day.
Is there an easy way to change the visu such that it will pull ahead all forecast data for the entire day and visualize that as well? Maybe even for tomorrow as well?
Yes, SolarForecast is already in the official review process for upcoming OH release and the request to use TimeSeries is already placed by the reviewers.
From the first glance it looks easy but as consequence there will be many changes in the binding interface e.g.
Let me split this in data and visualization.
Data is available and can be queried in rules, see examples in readme
Visualization for future values isn’t possible for OH versions < 4.1. I personally use additional influxdb database which can be attached to make this happen
But since Dec. 23 OH 4.1 is out which supports time series to eliminate this gap. Binding will be adapted to this new feature so visualization of future values will come soon.
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…)
