Flexible "IgnoreAC" with Node-Red, rather than VeConfigs VirtualSwitch

Been meaning to post about this for ages, ever since I went down the Node-Red rabbit hole on my boat setup.

So the background: Multiplus-II, Cerbo GX, Victron BMS, the whole ecosystem. Shore power available at the marina but I genuinely don't always want the Multiplus charging — sometimes the batteries are topped off, sometimes I'm just plugged in for the convenience of the connection rather than actually needing AC input.

The VE.Config VirtualSwitch approach works, sure, but it's so rigid. Set a threshold, it triggers, done. No nuance whatsoever.

What I've been experimenting with is driving IgnoreAC dynamically via Node-Red flows instead. You can write directly to the relevant DBUS path and essentially tell the Multiplus to pretend shore power isn't there — on your own terms, based on whatever logic you fancy. SOC percentage, time of day, whether the solar is already covering loads... whatever.

My current flow does roughly this:

• If SOC > 85% and solar input is above a threshold → set IgnoreAC = 1
• Otherwise → IgnoreAC = 0

Sounds simple but it's saved my batteries from getting cooked on sunny days when I forget I'm plugged in.

Couple of questions for the group though:

1. Has anyone noticed any latency issues when toggling this way? Occasionally feels like there's a slight hesitation before the Multiplus actually responds.
2. Anyone doing something similar on a van conversion where the "grid code none" setup matches mine?

Feels like this is massively underused compared to the VirtualSwitch crowd. Would love to hear if others have gone down this path or found smarter

Good timing on this post @JohnDixon — I've been doing something similar on my static caravan setup, though without the boat complication of shore power being intermittent by nature.

One thing worth flagging: when you're manipulating IgnoreAC via Node-Red through MQTT or the dbus, make sure you've got a watchdog flow in place. If Node-Red crashes or the Cerbo reboots mid-logic, you can end up stuck in a state where the Multiplus is ignoring AC indefinitely. Burnt me once.

My flow uses a 60-second heartbeat that resets to a known-good state if it misses two consecutive ticks. Crude but effective.

Also — for anyone new to this — the relevant MQTT path is:
W/<VRM_ID>/vebus/<instance>/Ac/Control/IgnoreAc

Worth double-checking your firmware version too; behaviour shifted noticeably around v490 on the Multiplus-II.

@JohnDixon the beauty of driving IgnoreAC via Node-Red rather than a VirtualSwitch is you can layer in actual logic — SOC thresholds, time-of-use windows, grid tariff triggers — instead of just a glorified on/off toggle.

On my narrowboat I've got a flow that watches the com.victronenergy.system MQTT topics and only ignores shore power once the Fogstar Drift cells are above 80% and it's peak rate hours — keeps the Multiplus earning its keep rather than just passively charging.

Key tip: write a catch node to handle MQTT dropouts gracefully, otherwise your Cerbo goes into a sulk and you'll be scratching your head at 11pm wondering why nothing's doing what it should.

@RetiredPlumber the static caravan use-case is arguably cleaner for this — no engine alternator throwing curveballs into your logic.

@RetiredChef dead right on the logic side. Been doing similar for EV charging — node triggers IgnoreAC based on SOC and time-of-use tariff windows. Means the Multiplus stops pulling from grid the moment Agile prices spike, battery takes over for the car charge instead.

The VirtualSwitch approach just couldn't handle that kind of conditional stacking. Node-Red makes it almost too easy once you've got the MQTT topics sorted on the Cerbo.

One thing worth flagging — make sure you're debouncing your triggers properly or you'll end up toggling IgnoreAC repeatedly during edge conditions. Learnt that the hard way, logs were a mess.

@LutonNomad that's exactly the use case I've been trying to nail down — can I ask how you're handling the ramp-up delay when IgnoreAC kicks back in and the Multiplus reconnects to shore?

My concern with EV charging specifically is that the car's EVSE can pull pretty aggressively the moment it sees grid, and if the inverter hasn't fully settled I'm wondering whether that causes issues upstream.

Are you doing any kind of timed hold in your Node-Red flow before allowing the state to flip back? Or does the Multiplus handle the reconnect gracefully enough that it's a non-issue in practice?

Running a Zappi so I've got some control on the EVSE side too, but keen to understand whether the logic needs to live in Node-Red or whether I can lean on the car side for that smoothing.

@CopperSparky the ramp-up delay issue is exactly why you don't just flip IgnoreAC straight back off — I use a delay node set to about 90 seconds before re-enabling AC acceptance, gives the Multiplus time to resync without throwing AC frequency errors all over the Cerbo dashboard like confetti.

Throw in a rate-limit node upstream so you're not toggling it repeatedly if your SOC is bouncing around the threshold — learned that one the hard way on my static when the Fogstar BMS was being dramatic about a dodgy cell.

The DBUS path you want is com.victronenergy.vebus → /Ac/Control/IgnoreAC, write a 1 or 0, job done. Just make sure your Node-Red MQTT broker is actually talking to the Cerbo and not just pretending to — obvious, but apparently not obvious enough for past-me.