Set CCL when Grid-lost

Been thinking about this one for a while and curious what others do...

My setup runs DC feed-in through a Victron MultiPlus-II, and I've got CCL set to 0 during summer months so the MPPTs handle all the charging — works a treat normally. But I've been wondering what the sensible approach is when the grid drops out.

When CCL is at 0 and you lose the grid, the Multi obviously can't charge from AC anymore, which is fine... until you hit a cloudy stretch and the solar just isn't keeping up. At that point you potentially want the Multi to be able to pull from a generator or whatever AC source you've got available, but CCL is sat there at zero blocking it.

Has anyone set up any kind of automation — Node-RED, ESS assistant, Venus OS scripting — that detects a grid-lost event and bumps CCL back up to a usable value automatically? I'm running a Fogstar Drift lithium pack with a JK BMS, so I do have some comms available if I can figure out the right trigger.

I guess the alternative is just leaving a sensible CCL value in place all the time and relying on DC feed-in priority to do the heavy lifting, but that feels like a workaround rather than a proper solution.

What are others doing? Is there a clean way to handle this through VictronConnect or do you need to get into the weeds with Venus OS?

@Mike1980 good shout on this. One thing worth adding — you can handle this automatically with a Node-RED flow (or even Venus OS Large) watching the grid relay status. When grid drops, fire a command to bump CCL back up so the Multi can pull from the battery without fighting itself.

I do something similar on my garden office setup. MPPT handles daytime fine, but if grid goes down at night or during a cloudy patch you want the battery available immediately, not sat there throttled to zero.

Key thing: set a small delay (30-60s) before CCL changes — avoids false triggers from brief dropouts flipping your settings repeatedly.

Venus OS dbus path you want is com.victronenergy.system — grid lost flag is clean to read from there.

@CE_Builds Node-RED is great until the Pi running it decides to sulk at 3am and your batteries are getting hammered — ask me how I know 🙃

@Renogy_Nerd has a point — had exactly that happen on the boat last winter, Pi thermal throttled and the flow just... stopped. Silent failure is the worst kind.

What I ended up doing is using the DVCC charge current limit via a simple VE.Bus System Assistant rather than relying on Node-RED for anything critical. It's running on the Cerbo itself so there's no external dependency. If grid drops, the assistant responds directly without needing a separate device to stay alive.

Not saying Node-RED isn't useful — I use it for monitoring and alerts — but for anything that needs to respond reliably during a grid-loss event, keeping the logic inside the Victron ecosystem feels a lot more robust to me.

@KevWatson57 that's the narrowboat special, isn't it — carefully engineered automation running perfectly until the boat decides it's -4°C and everything that runs on silicon wants a lie-in.

I've been down the Pi-as-brain-of-everything rabbit hole on mine. Eventually pulled most of the critical logic back into VenusOS

@PanelSteve the real answer here is ESS Assistant with a proper BatteryLife state trigger in VEConfigure — if grid drops, the MultiPlus already knows, no Pi required, no Node-RED, no 3am drama.

Set your CCL handoff logic directly in the DVCC settings and let the Cerbo GX handle state comms to the MPPTs over VE.Can — that's literally what it's designed for.

Grid state → ESS mode 2 → DVCC CCL = 0 → MPPTs take full authority

Done natively, no single point of failure running on a £35 computer balanced on a shelf in a damp static van. Ask me how I know.