Monitoring multiple batteries with Cerbo/Ekrano GX using CAN-bus BMS HV Protocol

Running four Fogstar Drift 48V units in parallel on my narrowboat and the BMS visibility situation is frankly embarrassing — Victron's Cerbo just sees them as one happy blob rather than telling me which pack is being a drama queen at 3am. 🛥️

Anyone else gone down the rabbit hole of writing their own protocol translator to expose individual BMS metrics over VE.CAN? I'm tempted but my Python is roughly at the level of "I once made a to-do list app that deleted everything."

The real issue is that HV Battery protocol on the Cerbo/Ekrano is designed to aggregate, not interrogate — brilliant if all your cells behave identically, useless when pack three is clearly having an existential crisis and you can't prove it without a laptop and a stern expression.

What I actually want is:

• Individual SOC per pack on the Ekrano dashboard
• Per-BMS alarm visibility without digging through VRM like I'm on an archaeological dig
• Cell voltage deviation flagged per unit, not averaged into oblivion

Has anyone in the UK community managed this without it becoming a full-time job? Particularly interested if you've bridged a RS485/CAN translator into something the GX devices will actually respect. Pylontech users seem sorted but us scrappy DIY parallel-pack people are apparently on our own.

Surely someone on here has cracked this — or at least made a sufficiently impressive mess of it that we can all learn something.

@ThistleVicky yeah this is a known frustration with parallel battery setups on Cerbo. The CAN-bus HV protocol essentially aggregates everything into a single "virtual battery" — that's by design, not a bug.

Few options worth exploring:

• VE.Can with DVCC — still aggregates, but at least you get proper charge control
• Separate BMS comms via VE.Direct — some BMS units support this alongside CAN, gives you individual visibility in VRM
• Victron Battery Sense per unit — crude workaround but shows individual voltages at least

Fogstar Drift's BMS does have some decent monitoring built into their own app, so you could run that alongside VRM rather than trying to force everything through one interface.

Honestly for a narrowboat install I'd be more concerned about whether your cell-level balancing is healthy across all four units than the Cerbo visibility — what does the Fogstar app show for individual cell delta?

@ThistleVicky the root issue is that CAN-bus HV protocol was designed around a single BMS master presenting one set of data to the Cerbo — parallel units sharing a CAN bus will just overwrite each other's frames unless you've got one unit acting as master aggregator.

What I did with my setup was assign one Drift as the designated CAN master and daisy-chain the others via their balance leads, letting the master poll the subordinates. Not all firmware versions support this cleanly though — worth checking which Fogstar firmware revision you're on.

The other option people overlook: run each BMS into a separate RS485 adapter and use VE.Can bridging, though that gets messy quickly.

Victron's own documentation on multi-battery CAN topologies is surprisingly thin. DVCC settings also interact here in ways that'll catch you out if cell-level visibility is what you're ultimately after.

@ThistleVicky had almost identical situation with my setup — what actually helped me was designating one Drift as the "master" communicator and using the others in a managed parallel config where the master BMS aggregates and reports. Not perfect but Cerbo at least gets meaningful data rather than averaged nonsense.

Worth checking if Fogstar have pushed any firmware updates recently — I recall seeing something on their socials about improved multi-unit CAN visibility, though can't confirm if it's rolled out to the Drift line specifically.

The other option people don't mention enough: supplementing with individual cell-level monitoring via a separate shunt per battery feeding into Cerbo over VE.Can. More wiring headache but you'd actually see which unit is misbehaving. Depends how much bilge space you're working with on a narrowboat obviously.

@ThistleVicky worth knowing that some folk daisy-chain a separate RS485-to-USB adapter per BMS into a Raspberry Pi running Batmon or similar, then feed aggregated data into VRM via MQTT. Gives you per-unit SOC, cell delta voltages, temperature — everything the Cerbo's single CAN node view hides.

The Fogstar Drift BMS does expose Modbus over RS485 natively, so you're not fighting proprietary nonsense. Done something comparable with my own bank using a Pi Zero W — cheap and surprisingly solid. Main gotcha is ensuring your polling interval doesn't clash with the BMS's own internal cycle and cause timeouts.

Not a clean out-of-the-box solution like @CallumCampbell55's master/slave approach, but if you want genuine per-unit visibility rather than averaged data, it's the proper way to do it.

@ThistleVicky one angle nobody's mentioned yet — the Victron VE.Can to CAN-bus BMS cable only ever exposes a single BMS device instance on the Cerbo, so no amount of clever wiring gets you individual pack visibility natively.

What's actually worked in my van build (single pack, granted) is pairing the Cerbo with Node-RED running on a local RPi, polling each BMS independently via separate CAN interfaces using a cheap USB-CAN adapter per unit. You then push custom MQTT topics into VRM as user-defined data.

Bit of legwork upfront, but your Cerbo dashboard then shows four distinct SoC figures, temperatures, and cell deltas simultaneously.

@RetiredSquaddie's RS485 route achieves similar ends — depends entirely on whether your Drift firmware exposes full telemetry over that interface, which varies by batch from what I've seen on Fogstar's own community threads.