Feature request - price rounding

Been thinking about this one a lot lately, actually.

Running a Victron system on my static caravan with a Fogstar Drift battery bank, and I've been experimenting with automated charge/discharge scheduling around Agile tariff pricing. The issue I keep running into is that the system is essentially all-or-nothing when it comes to price thresholds — it either goes full tilt at the absolute peak or bottoms out at the absolute trough, with no middle ground.

What I'd love to see is some kind of price rounding or banding logic built into the scheduling algorithms. Something like:

• Group prices into brackets (e.g. within 2p/kWh of each other = treat as equivalent)
• Avoid thrashing the batteries unnecessarily just to chase a marginal price difference
• Factor in realistic solar forecast before deciding whether to export or top up

The solar forecast bit is the kicker for me. Last week the system decided to sell stored power during the evening peak — fair enough in theory — but then there wasn't enough solar the next morning to recover, and I ended up buying back at a rate that wiped out most of the gain. A smarter rounding approach would've held back a sensible buffer rather than chasing the absolute maximum sale price.

I suspect this matters more for us off-gridders (or near-off-gridders) than for pure grid-tied folk, because we can't always just lean on the grid to bail us out when the forecast goes wonky.

Anyone else running Agile-style scheduling and finding the same brittleness? Curious whether anyone's bodged a workaround through Node-RED or similar.

@SparkySparky looks like your post got cut off mate! Missing the actual feature request 😄

Interested to hear where you're going with this though — I run a similar setup on my narrowboat (Victron MultiPlus + Fogstar cells) and I've been playing with time-of-use scheduling myself.

If it's what I think you're asking — rounding to nearest penny/half-penny thresholds to trigger charge cycles — that'd actually be really useful. Agile tariff users especially would benefit, the pricing can get weirdly granular.

Finish your thought and I'll give a proper reply! 🔋

@SparkySparky yeah looks like the post got chomped mid-sentence — happened to me a few times on here, think there's a character limit on the editor that doesn't warn you properly.

Running a similar setup myself (static caravan, Victron + Fogstar bank) so genuinely curious what you're proposing. Price rounding in the context of automated scheduling... are you thinking something like snapping charge windows to nearest pence/kWh threshold to avoid chasing fringe savings that don't really materialise in practice?

That would actually make sense for Octopus Agile users — sometimes the algorithm tries to optimise against a 0.2p difference which barely covers the cycle wear. A configurable rounding tolerance would be a decent QoL addition.

Finish the original post and let's see what you're actually after!

looks like half the forum is getting eaten today 😄

@SparkySparky curious what direction you were heading — price rounding for the scheduling triggers? I've been poking around with similar stuff on my boat setup, trying to get the Fogstar Drift to charge sensibly off overnight rates.

The decimal point chaos in some of these tariff APIs is real — Octopus pricing especially comes through with like six significant figures which feels unnecessary when you're just trying to set a threshold.

Would be interested to hear the actual request when you manage to repost it.

@SparkySparky guessing from the title you're after rounding energy prices to cleaner figures for scheduling triggers? Like snapping to nearest 0.5p or 1p increments rather than dealing with raw Agile tariff prices like 14.37p?

Makes sense for automation logic — tiny price fluctuations causing unnecessary charge/discharge events is a real headache. My cabin setup had similar issues before I tightened the thresholds.

Would be useful to know if you're running Node-RED or something like Victron's own scheduled charging, as the solution might already exist in the tool rather than needing a platform-level feature.