Scheduled Charge - system begins discharging immediately afterwards SoC hits 100%

by Dales OffGrid · 1 week ago 21 views 5 replies
Dales OffGrid
Dales OffGrid
Active Member
10 posts
Joined Feb 2025
1 week ago
#24450

Running a similar headless setup here — Victron MultiPlus-II with Fogstar Drift cells and absolutely zero comms between the BMS and the Cerbo GX, because apparently I enjoy making life difficult for myself.

Noticed the exact same behaviour: scheduled charge hits 100% SoC via the Lynx Shunt, MultiPlus-II dutifully stops, then roughly 30 seconds later the system starts pulling from the bank like it's forgotten everything it just did.

My suspicion is the shunt's SoC figure and the actual resting voltage are having a bit of a domestic — the shunt thinks it's full, but without CANbus telling the MultiPlus what the BMS actually sees, there's no handshake confirming "yes mate, genuinely full, crack on." So the scheduled charge window closes, inverter picks up loads again, shunt recalculates, decides it's no longer at 100%, and off we go.

Bodge that's partially helped me: tightening the tail current settings in VRM so the absorption stage runs longer before the shunt declares victory. Also bumped the charged voltage threshold up slightly so it's less trigger-happy.

Still not perfect though — especially annoying when I'm trying to top up overnight for EV charging the next morning and the garden office pulls the whole thing down by 6am.

Anyone else running a comms-free setup managed to crack this properly? Wondering if a Venus GX assistant could help here or if I'm just fighting physics at this point. 🔋

OldSailor79
OldSailor79
Active Member
13 posts
thumb_up 1 likes
Joined Nov 2024
1 week ago
#24487

@DalesOffGrid the lack of BMS comms to the Cerbo is almost certainly your culprit. Without it, the Cerbo has no idea the pack is genuinely full — it's just trusting the MultiPlus voltage reading, which can look "done" before absorption properly completes.

Worth checking your scheduled charge end condition in VEConfig. If it's set to time-based rather than tail-current-based, the inverter parks at 100% displayed SoC and then immediately sees a load — so it discharges.

I had almost identical behaviour on my cabin setup before I bodged a Victron SmartShunt into the loop. Gave the Cerbo something real to work with. Not a perfect fix for no comms, but it stopped the bounce.

Also double-check your float voltage isn't set below your resting cell voltage — that'll cause it to pull current the moment scheduled charge hands over.

Wayne
Wayne
Active Member
19 posts
thumb_up 4 likes
Joined Oct 2024
1 week ago
#24491

@DalesOffGrid had almost the exact same issue with my Fogstar setup before I sorted the comms. The Cerbo's basically flying blind on SoC, so when your scheduled charge ends it just sees voltage drop as the charger backs off and thinks "oh we're discharging now" — triggers the inverter to start pulling from the bank.

Worth checking your charge voltage settings too. If your absorption voltage is a touch low, the MultiPlus backs off before the cells are actually full, BMS disagrees, chaos ensues.

Stopgap if you can't get comms running — set a manual SoC override in VRM and give it a sensible tail current threshold. Not ideal but it'll stop the bouncing.

What firmware are you on? There were some scheduled charge quirks in older Cerbo builds that caught people out.

Tracy Allen
Tracy Allen
Regular
83 posts
thumb_up 35 likes
Joined Apr 2023
1 week ago
#24525

@DalesOffGrid the bit nobody mentions is that without BMS comms, the Cerbo is relying entirely on voltage to estimate SoC — and the moment your MultiPlus stops absorbing and the surface charge settles, voltage sags just enough to make the Cerbo think "oh dear, we're not at 100% anymore, better discharge." It's essentially chasing its own tail.

Two things worth checking in VEConfig: your absorption voltage and float voltage gap. If float is set too low relative to your LFP chemistry, the Cerbo sees the drop from absorption to float and interprets it as discharge. Fogstar Drift cells want a fairly tight float around 13.5V (12V nominal). Also worth enabling DVCC in the Cerbo if you haven't — it at least gives you centralised voltage/current control even without full BMS comms.

Proper RS485/CAN comms remains the actual fix, mind.

RetiredSquaddie
RetiredSquaddie
Active Member
40 posts
thumb_up 9 likes
Joined Jul 2023
1 week ago
#24575

@DalesOffGrid there's another angle worth considering here — the MultiPlus-II's charge algorithm itself. Even with a scheduled charge hitting 100%, the inverter will enter absorption phase and hold voltage for a set duration before dropping to float. If your absorption time is configured too short (common with custom battery presets), the charger declares "done" before the cells have genuinely balanced, then the Cerbo sees voltage sag as cells redistribute charge and interprets it as discharge demand.

Check your absorption time in VEConfigure — for LiFePO4 I'd typically set it to 1hr minimum, sometimes longer with larger cell counts. Also verify your float voltage isn't set below your resting cell voltage, because that'll actively pull current out immediately after charge termination. Classic trap with Fogstar cells specifically since their resting voltage sits slightly higher than the Victron LiFePO4 defaults assume.

Ed Campbell
Ed Campbell
Active Member
10 posts
thumb_up 2 likes
Joined Aug 2024
1 week ago
#24746

@RetiredSquaddie makes a fair point about the charge algorithm but I'd also look at your absorption timeout settings. Had this exact thing on my garden office setup — Cerbo thought it was done but the MultiPlus was still in absorption, then the scheduled window ended and it just... fell off a cliff into discharge.

Worth checking what your absorption time is set to in VEConfig. If it's too short and the battery hasn't actually settled at 100% (voltage-wise), the system gets confused pretty fast without proper BMS comms telling it the real state.

Fogstar cells can also sit at a slightly different resting voltage than whatever the Cerbo's estimating, which compounds the issue.

Log in to join the discussion.

Log In to Reply