Anyone else using a Victron Cerbo GX with non-Victron kit — how are you handling the data gaps?

I've got a Cerbo GX sitting at the heart of my system and it's brilliant for keeping tabs on my Victron MPPT and Multiplus, but I'm running a Fogstar Drift 200Ah lithium battery and a Renogy DC-DC charger alongside them, and the VRM dashboard just has these annoying blind spots where that kit should be. The state of charge feels like a bit of a guess half the time, especially when the DC-DC is pulling from the alternator on a long drive.

I've been looking at adding a Victron SmartShunt on the battery negative to give the Cerbo something proper to work with on the SoC front — £60-odd from Bimble Solar seems reasonable. But I'm also wondering whether I should just lean into a separate monitoring layer entirely, something like a Batrium or even just a basic Bluetooth BMS app, rather than trying to force everything through VRM.

Has anyone actually got a tidy solution for this kind of mixed setup? Particularly interested if anyone's managed to get reliable SoC figures when you've got multiple charge sources hitting the battery at once — solar, alternator, and shore power in my case. Would love to know what's actually working for people rather than just what looks good on paper.

@MeganStevens yeah this is the exact rabbit hole I fell down last winter with my cabin setup.

The Fogstar Drift doesn't have a BMS that talks to the Cerbo natively which is the frustrating bit. What I ended up doing was grabbing a Victron SmartShunt and letting that be the "translator" — it won't give you cell-level data obviously but at least the Cerbo gets proper SOC, voltage, current all in one place.

For the Renogy DC-DC, I just accepted the data gap honestly. Mounted it, set it, forgot it. The SmartShunt catches the net effect on the battery side anyway.

Some people bodge a Raspberry Pi with Node-RED to pull in extra data sources but that's a whole project in itself — went down that path briefly and... yeah. Maybe another day 😅

Hey @MeganStevens, classic mixed-kit headache! I'm running a similar setup with non-Victron lithium and a third-party DC-DC charger. What's worked well for me is using a Victron BMV-712 as the dedicated battery monitor — it feeds proper SOC data into the Cerbo and largely fills the gap left by not having native BMS comms. For the Renogy DC-DC, I just monitor it indirectly through the BMV's current readings rather than trying to get direct device data into VRM. Not perfect, but it gives you a coherent picture on the dashboard. Some people use a Raspberry Pi running Node-RED to pull data from third-party devices and push it into the Cerbo via MQTT — worth looking into if you want everything truly unified. What specific data gaps are bothering you most? That'd help narrow down the best approach.

Great thread @MeganStevens! The Fogstar Drift has a JBD BMS underneath, and there's a solid workaround — you can grab a cheap Bluetooth-to-RS485 adapter and use the overkill Solar app to pull cell-level data separately, even if it won't feed directly into VRM. Not perfect, but it fills the gap nicely for keeping an eye on cell balance.

For your Renogy DC-DC, I'd look at adding a basic current shunt on the input side — a Victron SmartShunt wired inline will at least give the Cerbo visibility of what's flowing in, even without native integration. You lose the Renogy's internal data but you gain accurate charge current figures on VRM.

Not ideal compared to an all-Victron setup, but perfectly workable day-to-day in my experience!

Has anyone actually managed to get Node-RED running on the Cerbo to pull in the JBD BMS data and stitch it into the VRM dashboard properly? I've got a similar gap in my shepherd's hut setup — the Cerbo sees my Victron MPPT and Multiplus fine, but the battery state-of-charge figures feel unreliable because it's estimating rather than reading directly from the BMS.

Specifically wondering:

• Is the Venus OS Large image stable enough for daily use on a Cerbo, or is it still a bit rough around the edges?
• Does adding the BMS data actually improve the SOC accuracy displayed in VRM, or does Victron's own algorithm still override it?

@12VWizard your comment got cut off — curious what workaround you were about to suggest for the JBD BMS specifically.

@SuffolkDweller replied:

@SolarDoug — yes, I've got Node-RED running on my Cerbo doing almost exactly that. The key bit is using the JBD BMS Bluetooth bridge (I'm using a cheap JBD-ANT dongle feeding into a Raspberry Pi Zero W) and pulling the data via MQTT into Node-RED on the Cerbo. You can then write virtual values into the Victron DVCC path so the Cerbo thinks it's seeing native battery data. Takes an afternoon to set up properly but once it's stable it's rock solid.

The Renogy DC-DC is trickier mind — I've not cracked pulling live current data from mine, so I just use a standalone Hall effect sensor on the line and feed that via an ESP32 into the same MQTT broker. Bodged together but the VRM dashboard looks lovely! Happy to share my Node-RED flows if useful.

@SuffolkDweller curious what you're using to surface that data — are you pushing it into the Cerbo's dbus so it actually shows up natively in VRM, or just sidestepping into something like Grafana/InfluxDB?

I've got a similar setup in my van — Cerbo, Fogstar Drift, and a Renogy DC-DC charger that the Cerbo basically ignores entirely. Ended up using a cheap ESP32 flashed with ESPHome to read the Renogy via RS232 and fire MQTT to a Pi running Node-RED. Works a treat but it's not showing in VRM which still bugs me.

The dbus-mqtt route looks promising for getting non-Victron devices to appear as proper virtual devices in VRM. Haven't fully cracked it yet though. Would love to know if anyone's got the JBD data appearing as a recognised battery in the Cerbo's overview page rather than just floating in a dashboard somewhere.

@FET_Queen @SuffolkDweller — I went down the dbus route for my Fogstar on the static and it's worth it once it's set up. The dbus-serialbattery driver is your friend — handles most JBD/JK BMS units and registers them as a proper battery service on the Cerbo. VRM then sees it as native kit. Only faff is keeping the driver updated when Venus OS gets a bump. Took me an afternoon to sort but hasn't needed touching since. Makes the DVCC integration actually usable rather than just guessing at SOC.

Really useful thread this. @BurnGlen is right that dbus is the way to go once you've committed to it properly. One thing worth mentioning for @MeganStevens specifically — the Renogy DC-DC charger is the trickier bit in my experience. Even if you get your Fogstar talking to the Cerbo nicely via a BMS UART connection, the Renogy sits outside that loop entirely. I ended up adding a simple current shunt on the DC-DC output and reading it via a Cerbo GPIO, which at least gives you charge throughput data even if it's not "smart" integration. Not elegant but it fills the gap.

@MeganStevens the Renogy DC-DC is the awkward one in your setup — there's no clean way to get that into the Cerbo natively. What I've done with similar kit is grab the current draw from a shunt on the input side and infer what the charger's doing from there. Not perfect but it fills the gap on VRM. The Fogstar Drift is more tractable — if yours has a BMS with a UART or RS485 output you might have more options than you think. What communication ports does yours actually have on the BMS?

@Trevor1975 is right about the Renogy — I just accepted it as a blind spot on my Cerbo and track it indirectly through the battery SOC trends. If current in doesn't match what I expect from solar alone, I know the DC-DC has been active. Bit rough but works in practice.

For the Fogstar specifically, once you've got dbus sorted like @BurnGlen says, the cell voltage visibility is genuinely useful — caught an early imbalance on mine that I'd have missed otherwise.