Maybe it now needs some time to make new calculations based on the current consumption/production?
Perhaps so, but does that explain the difference between VRM portal and the API calls to VRM?
My PV forecast is rubbish aswell, it predicts 5-7 Kw PV for today and updates itself to a higher range as it sees the estimate overshoot by real PV generation.
@jarco My PV forecast (VRM: 710066) is also totally wrong. If you look at the prediction for today, it predicts only a few kWh. Normally this would be 30-50 kWh.
On the contrary, if you look at the prediction in a multi-day view, the prediction is way too large, e.g. predicting almost 100 kWh for today. This really doesnāt make sense.
On Monday 4. august i couldnāt get data from vrm to feed my nodered(api-call), on tuesday pv forecast was very optimistic around 30% more than expected, one day later forecast more than doubled, today my pv forecast nearly trippledā¦so totaly useless now
@jarco and others, inside vrm the 7 day forecast seems within the ānormal rangeā now (with the ānormalā overshoot for algorithmic EVCS expectations in consumption -but not reality-)
since Iām not normally using the the API call (yet?) Iāll leave that for others to report on.
As youāve probably noticed by now, weāve implemented a fix. Itās a very temporary fix, so once the underlying issues are resolved youāll probably see a much lower forecast than youāre used to. Weāre hoping thatāll happen today or tomorrow, but canāt say for certain yet. Note that these visualisations donāt impact the (regular) Dynamic ESS scheduling.
Will keep you posted, please do let me know when youāre seeing incorrect forecasts again!
thank you very much, Jarco,
so far it looks very good, including the own values, which roughly correspond to the expected reality. API works well
have a nice evening Stanislav
After implementation of the fix the forecast seemed to be fine for the actual day (d0) and the next three days (d1-d3), noticeable by 4 similar sized bars with a significant drop for d4 & on in the 7 day graphic. (Note: the actual weather is sunshine and blue skies on endā¦)
Since then my impression was that time when the forecast becomes invalid (initially d4) keeps getting closer and closer to d1.Today it looks like this:
d0 is absolutely reasonable (50 kwh-ish), d1 & d2 already pretty low (30 kwH) and thereafter totally crappy. The irradiance forecast however corresponds to the sunny weather (which should last at least another week or so). Location is Munich, Germany.
Im donāt really need good predictions for d2 and beyond, but d1 cannot not be off by almost 50% (30 kWh < - > 50 kWh) this plays havoc with my Energy Management System during the evening / night when the forecast for the next day is off by this much. (BTW: similar behavior for several other installations I have access to here in southern Germany).
Iām currently observing a similar phenomenon in Northern Germany. Itās quite clear that Victron has changed something in its forecasting algorithm. Based on my experience over the past two years, I can tell you that it now takes a few days to settle down again. Iāve stopped evaluating such things within the first few days, but rather observe such changes over a certain period of time.
Iām interested in whether you got no/garbage data, an error or something else - reason being that Iād like to build some resilience into my charge target calculations in case such a thing happens again.
I can use my previous methods (openweathermap cloud cover forecast, etc) as a fallback, but the question is how to detect the need to fall back when it occurs, beyond simple āsanity checksā on the incoming VRM API response (which admittedly would have caught this error in my case).
This episode has been very useful in identifying a single point of failure (or rather, inconvenience) which Iād like to address.
If I (or anyone else) can come up with something, perhaps a discussion in the Node-Red forum would be appropriate.
In this case, the issue was that the API failed with a timeout error (the 20 minutes). I was testing various prediction models, and if the VRM prediction works, it seems to me the best option, even though the values are often different from reality (they claim that the predictions are calculated using AI, but it should be able to detect that the actual production is consistently about 15% higher ā although I do have correction factors that I can use to modify the prediction). From the API, I read values for todayās and tomorrowās predictions, as well as hourly predictions, into a relatively complex algorithm. Thatās why I need the values to be consistent (which they werenāt recently) and, of course, for the predictions themselves to be relatively OK (which they werenāt recently)