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.
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)…
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.
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.
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.
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?
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?
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?