Get prices in Node-red directly out the Cerbo GX

Been tinkering with this exact problem on my static caravan setup and wondered if anyone else has hit the same wall.

I'm trying to pull Agile Octopus pricing data through my Cerbo GX into Node-RED so I can do some basic automation — essentially telling my system to prioritise grid charging during cheap slots. The Cerbo is running Venus OS and I've got Node-RED enabled through the Large image.

I've had a poke around with the MQTT nodes pointing at the local broker on the Cerbo, but dynamic pricing data just doesn't seem to live anywhere obvious in the VRM MQTT topic structure. The HTTP request node feels like it should work pointing at the Octopus API directly, but I'm not sure whether that's actually the "right" approach or whether Victron intend for Dynamic ESS to handle all of this natively.

A few questions I'm stuck on:

• Is the dynamic pricing data actually stored/accessible on the Cerbo itself, or does it only live in VRM cloud?
• Has anyone successfully built a Node-RED flow that fetches Octopus Agile half-hourly prices and feeds decisions back into ESS settings via MQTT?
• Is there a cleaner way to do this that doesn't involve hammering the Octopus API from Node-RED directly?

I've seen some flows shared on the Victron community forum but they seem very much aimed at three-phase home setups, not a modest static caravan system like mine.

Would love to see if anyone has something working, even rough and ready. Screenshots of flows always help too if you're willing to share!

@Julie1991 Great project — I've done something very similar on my Victron setup in the van.

The key thing I'd add: the Cerbo GX runs a stripped-back Linux environment, so rather than hammering the Octopus API directly from Node-RED on the Cerbo, I'd strongly recommend running Node-RED on a separate Raspberry Pi (or even a Pi Zero 2W) and publishing the Agile prices over MQTT to your Cerbo's Venus OS broker.

That way:

• Your Cerbo isn't doing heavy lifting
• You can cache the price data locally
• Venus OS MQTT broker accepts custom topics natively

The Octopus Agile API endpoint (/v1/products/AGILE-*/electricity-tariff/) returns half-hourly slots as clean JSON — straightforward to parse. Set your flow to refresh every 30 minutes and you're golden.

Happy to share my Node-RED flow if that'd help.

Done this on my static caravan Cerbo — the Octopus Agile API endpoint is https://api.octopus.energy/v1/products/AGILE-FLEX-22-11-25/electricity-tariff/E-1R-AGILE-FLEX-22-11-25-[YOUR_REGION]/standard-unit-rates/ and you just chuck an http request node at it every 30 mins, parse the JSON, and shove the current rate into a MQTT topic your Cerbo can actually see.

Worth noting your tariff code will differ — check your account dashboard for the exact product string or the whole thing returns nowt useful.

One gotcha that'll waste your afternoon: Cerbo's Node-RED runs as a separate instance to any external Node-RED you might have, so decide which one you're actually running this on before you end up with two half-finished flows doing conflicting things. Ask me how I know. 🙄

@Rob1963 just don't forget your API key or you'll be hammering that endpoint like a confused seagull hitting a chip shop window — rate limits are a real thing, chuck a 30-min inject node on it rather than polling every 5 seconds like I did initially on my Cerbo before realising my Fogstar battery knew more about restraint than I did.

Great thread! One thing worth adding to what @Rob1963 has started — once you've got the pricing data flowing into Node-RED, I'd strongly recommend storing the half-hourly slots in a flow context variable rather than hitting the API every time you need a price check. Octopus don't mind reasonable polling but there's no point being wasteful with calls.

I pull mine once around 4pm when the next day's prices typically publish, then reference the stored array throughout the day. Saves any headaches if your internet drops briefly too — you've still got today's rates cached locally on the Cerbo.

@MoorKev 😄 the confused seagull approach does work technically, just not elegantly!

So once you've actually got the price data landing in Node-RED — what's the next bit? Are people storing it in a context variable or writing it to InfluxDB so you can do historical comparisons?

I've been trying to work out whether it's worth triggering my Multiplus charge schedule based on the 30-min slots or just setting a flat overnight window. The Cerbo seems to want a pretty specific format when you push commands back via MQTT.

Also does the Agile API return prices for the next day before midnight or is there a lag? I keep seeing conflicting stuff. My setup is only a 5.1kWh Fogstar Drift so timing matters quite a bit — don't want to miss a cheap slot because the data arrived late.