Adjusting DESS EV consumption forecast via Node-RED – HTTP 429 and local alternative?

Been messing around with something similar on my Cerbo GX for a while now — trying to build a half-decent charging schedule for two EVs without just hammering Octopus Agile prices manually every morning.

The Node-RED flow I've got pulls tariff data and cross-references it with the cars' required state of charge before departure times. Works most of the time. Problem is I keep hitting HTTP 429s from the external forecast API I'm using — clearly rate-limiting me. Annoying, because the whole point was to automate this so I didn't have to think about it.

Has anyone found a decent local alternative for consumption forecasting that'll run happily on the Cerbo without phoning home every five minutes? I've looked at running a lightweight model locally but the GX isn't exactly a powerhouse.

Also curious whether anyone's integrated this properly with DESS — I've poked at the API a bit but the documentation is... let's say charitable at best.

My current bodge is caching the last successful API response and only refreshing every 30 minutes, which reduces the 429s but means the forecast can go stale on days when prices shift dramatically (which on Agile is basically every other day).

Setup for context: Victron Multiplus-II, Cerbo GX, Fogstar Drift 280Ah lithium bank, two cars on dumb 7kW wall boxes.

Anyone running something more elegant than my pile of gaffer-taped Node-RED flows? Would genuinely like to know how others are handling this rather than reinventing the wheel badly.

Gazza89 | 847 posts

@VitoProject nice project! The 429s are almost certainly Octopus rate-limiting you if you're polling too aggressively. I'd suggest caching the Agile prices locally in a flow-level context variable — they only update once daily anyway so there's no need to hit their API more than once every few hours.

For a local alternative, have a look at pulling prices via the Octopus GraphQL endpoint and stashing them in InfluxDB on your Cerbo. Then Node-RED queries locally rather than hammering the API each time your EV consumption estimate updates.

What's your current poll interval on the HTTP request node? If it's anything under 30 minutes I'd throttle it right down first and see if the 429s clear before rebuilding the whole flow. Sometimes it's just that simple!

VoltChloe | 312 posts

@VitoProject I've been pulling Agile rates into Node-RED on my Cerbo for the boat setup — the trick that sorted my 429s was caching the half-hourly slots locally in a file node and only hitting the Octopus API once per day around midnight. Rates don't change after publication so there's genuinely no reason to poll repeatedly.

For a local alternative, have a look at Octopus Agile Proxy — runs on a Raspberry Pi alongside Home Assistant if you have one, or standalone. Keeps a local copy of prices and your flows query that instead.

Also worth checking your msg.headers — Octopus do return Retry-After on 429 responses, so you can build a proper backoff rather than guessing intervals.

Two EVs must be hammering your system capacity — what's your battery bank looking like?

SolarNotSure | 1,204 posts

@VitoProject the DESS consumption forecast is almost certainly your bigger problem here — it's notoriously conservative and doesn't account for simultaneous dual-EV charging loads at all. I've got two vehicles hitting a 22kW AC charger off a 48V Fogstar Drift bank and DESS was scheduling as if I had a kettle plugged in.

Worth overriding the consumption forecast entirely via the com.victronenergy.settings MQTT path and feeding your own calculated figure. Node-RED handles this cleanly — write directly to the Cerbo rather than relying on DESS's internal model.

For the 429s specifically: cache the Octopus Agile half-hourly rates locally (they publish 24hrs ahead after ~16:00), poll once, store in a flow context variable, query that instead. No need to hammer the API repeatedly.

What's your battery capacity? That changes the scheduling logic significantly.

FZ_Builds | 563 posts

@VitoProject worth knowing that the Octopus Agile API has a public endpoint that doesn't need authentication — https://api.octopus.energy/v1/products/AGILE-*/ — which won't rate-limit you the same way as the authenticated account endpoints. I cache the half-hourly slots locally in a flow-level context variable and only re-fetch when the cache is stale. Runs fine on my Cerbo aboard without a single 429 in months.

On the DESS side, @SolarNotSure is right that the built-in consumption forecast is fairly blunt. I've had better results feeding my own 7-day rolling average directly into the scheduled charge node rather than trusting DESS to guess it — especially with two EVs where the load profile is wildly inconsistent day to day.