VRM Forecast data doubled(?)

Hi!

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.

/Kaj

@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.

The forecast is now much too low, according to PV solcast it should be around 30 kWh for today and in VRM it shows 6 to 8 kWh

me2

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

Hi all,

We’re working on it, hang tight! Thanks for all the reports :slight_smile:

With kind regards,

Jarco

Seems to be working fine for me again 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.

Short- and Medium term seems to be back to normal, on VRM as well as the API.

Longterm (today + 4 and on) still a bit low, but that’s basically not an issue.

Thanks for the quick fix!

Hi all,

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!

With kind regards,

Jarco

Many thanks, Jarco.

The API calls seem fine and have been for the last 4 hrs or so.

I’ll continue to monitor the API calls at 10 min intervals and report back. :slightly_smiling_face:

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

Still all good, running nicely. :+1:

Thanks again Jarco & team. :slightly_smiling_face:

@jarco

It’s me again with another update…

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

Could you look into that please?

Best regards, Jochen

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.

Hi Jarco,

API doesn’t work again. Look at it please…

thanks Stanislav

What are you seeing, Stanislav?

Mine still seems OK, but I only look at the day ahead… e.g:

Hi Krafty,

it works… :slight_smile: something like 20 minutes dropout…

Stanislav

Ah, cool. :slightly_smiling_face:

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.

Hi Krafty,

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)

Stanislav

Today’s forecast data were correct (in VRM), but those for tomorrow (August 11th, 2025) are only half of what they should be.