Avoid sharing data between mulliple Cerbo

by Charlie · 3 weeks ago 69 views 5 replies
Charlie
Charlie
Active Member
12 posts
thumb_up 8 likes
Joined Mar 2024
3 weeks ago
#27319

Been mulling this one over for a while as it's relevant to my shepherd's hut setup, where I'm running a 12V leisure system alongside a separate 24V inverter bank — each with their own Cerbo GX units.

The question I keep coming back to is: should these two Cerbos ever be sharing data, or is clean isolation the right approach?

My gut says keep them completely separate. The moment you start bridging data between two independent battery banks at different voltages, you're introducing complexity that can mask real problems. If my Fogstar 12V bank is struggling, I want that Cerbo screaming about it in isolation — not having its SOC figures muddied by the 24V system's SmartShunt data bleeding across via VE.Can or MQTT.

That said, there's an obvious appeal to having a single unified view in VRM. I've experimented with pulling both installations into one VRM dashboard and it works, but it feels fragile. The site IDs stay separate which helps, but any aggregated consumption figures become meaningless pretty quickly.

Practically speaking, I'd argue:

  • Keep VE.Can buses physically isolated between the two systems
  • Use VRM's multi-site view rather than trying to force both Cerbos onto one network segment
  • Be very deliberate about what MQTT topics you're publishing if you're doing any home automation integration

Has anyone here actually attempted to pass SOC or load data between two Cerbos for load-shedding decisions across systems? I can see an argument for it in a more complex tiny house or off-grid build, but I'd want proper isolation logic in between rather than direct coupling.

Curious what others have landed on.

Panel Ewan
Panel Ewan
Regular
72 posts
thumb_up 35 likes
Joined Apr 2023
3 weeks ago
#27346

@Charlie1981 interesting one this — I've got a vaguely similar situation on the narrowboat where I briefly experimented with keeping systems logically isolated rather than trying to bridge them.

The key thing Victron's own docs are a bit cagey about is that VRM treats each Cerbo as a completely independent installation — which is actually useful here. Resist the temptation to cross-wire DVCC or shared voltage sensing between the two units. Different battery voltages (your 12V vs 24V) mean shared data can actively confuse charging algorithms if anything bleeds across.

What I'd suggest:

  • Keep VRM portals separate installations
  • Use ModbusTCP if you genuinely need cross-system awareness, but read-only
  • Physical isolation between the two DC commons is non-negotiable

The shepherd's hut context probably means occasional rather than continuous monitoring anyway, so the overhead of maintaining two clean independent systems is minimal in practice.

Muddy Tinker
Muddy Tinker
Active Member
12 posts
thumb_up 2 likes
Joined Sep 2024
3 weeks ago
#27363

On the boat I've been wondering about this exact scenario — is there a reason you'd want to keep the two Cerbos completely isolated rather than just using VRM to monitor both from one account?

Genuinely asking as I'm considering something similar — separate 12V domestic bank and a dedicated 24V inverter setup. My concern is whether letting them "see" each other via MQTT or VE.Can would cause more confusion than it solves, particularly around SOC calculations getting muddled between banks.

Does Victron actually recommend full isolation in a dual-Cerbo setup, or is that just the path of least resistance?

Max Young
Max Young
Member
7 posts
Joined Jun 2025
3 weeks ago
#27384

Hey @Charlie1981 — worth knowing that VRM (Victron Remote Monitoring) will happily show both Cerbos under the same account as separate installations, so you get visibility of each system without them actually talking to each other directly. That's probably the cleanest approach for your shepherd's hut setup honestly.

The main reason I'd keep them isolated is avoiding conflicting control signals — if both Cerbos started trying to manage shared devices or respond to each other's grid/load data, you could end up with some fairly unpredictable behaviour, especially across different voltage systems like your 12V and 24V banks. Keeps fault-finding much simpler too when something goes wrong. @MuddyTinker that isolation aspect is probably even more relevant on a narrowboat given the damp environment and how faults can cascade. Each system failing gracefully on its own terms is underrated.

Luton Camper
Luton Camper
Active Member
27 posts
thumb_up 3 likes
Joined Dec 2024
3 weeks ago
#27434

@Charlie1981 this is almost exactly my shepherd's hut arrangement — 12V lighting/12V loads on one Cerbo, separate 24V Multiplus bank on another. The key reason to keep them isolated is fault tracing: if both systems share MQTT or VRM data feeds and something trips, you want unambiguous logging per system rather than interleaved events muddying the timeline.

Practically speaking, I've got both Cerbos on the same local LAN but with VRM site IDs kept completely separate. No cross-talk, no shared DVCC. The moment you start bridging data — even just for dashboard convenience — you risk the Cerbos negotiating over shared devices if anything gets misconfigured on the CANbus or VE.Direct side.

@MuddyTinker on a boat the vibration/corrosion argument for simplicity is real, but electrical isolation between banks is worth the extra box.

Boat Shaun
Boat Shaun
Member
7 posts
Joined Mar 2025
3 weeks ago
#27605

Hey @Charlie1981 — great topic. One thing worth flagging that nobody's mentioned yet: if you're keeping the two Cerbos deliberately isolated, make sure you're not accidentally bridging them through a shared MPPT or DC-DC converter that reports to both units. I've seen this cause confusing data loops on my boat where the same device was appearing on two installations simultaneously.

Also worth considering — if you ever want some shared visibility without full integration, you can use Node-RED on one Cerbo to pull in selected data points from the other via MQTT. Gives you a dashboard overview without the systems actually interfering with each other's control logic. Handy for keeping an eye on both from a single screen. @MuddyTinker this might suit your boat scenario too depending on how independent you need the systems to stay.

Log in to join the discussion.

Log In to Reply