Anyone else using a Raspberry Pi to monitor their Victron system via VRM? Struggling with Node-RED flows

I've been running a Victron setup for about eight months now — 400W of panels, a SmartSolar MPPT 100/30, and a Multiplus-II 24/3000 with a 200Ah LiFePO4 bank. Everything talks to a Cerbo GX which pushes data up to VRM, and honestly the VRM portal is decent enough for day-to-day glances. But I want more — specifically, local alerts when SOC drops below 20% overnight without relying on an internet connection.

I've got a Raspberry Pi 4 sitting spare and I've been trying to set up Node-RED to pull data from the Cerbo via MQTT locally. I can see the topics coming through fine on mosquitto_sub, things like N/[serial]/battery/0/Soc and the MPPT yield data, but my Node-RED flow keeps dropping the MQTT connection every few hours and I can't work out if it's the broker config on the Cerbo side or something flaky with my Pi's network stack.

Has anyone actually got a stable local MQTT → Node-RED setup running long-term? I've seen a few guides that are two or three years old and reference older Venus OS versions — wondering if anything's changed in Venus OS 3.x that affects the local MQTT broker behaviour. I'm also curious whether people are triggering Telegram or Pushover notifications locally rather than through VRM's built-in alert emails, which seem to have a noticeable delay.

Reply by YorkshireSolar:

@SaltyTinker — your post seems to have got cut off there, but I reckon I know where you're heading with this!

I've had my Cerbo pushing data to a Pi via MQTT for about a year now. The VRM portal is decent enough but Node-RED gives you so much more flexibility for custom alerts and local dashboards.

One thing that caught me out early on — make sure you're subscribing to the correct Victron MQTT topics. The N/[VRM-ID]/system/0/Dc/Battery/Soc path for battery state of charge tripped me up for ages because I had a trailing slash causing silent failures.

Are you using the VenusOS MQTT broker directly, or routing through a separate broker on the Pi itself? That'll change the approach quite a bit. Happy to share my flow if it'd help.

@SaltyTinker your post did get clipped, but I've been down this exact rabbit hole with my motorhome setup so I'll chip in anyway.

The thing that tripped me up for weeks with Node-RED and VRM was the MQTT broker configuration — specifically, the Cerbo GX needs local MQTT enabled in the settings (it's off by default), otherwise your flows just sit there silently doing nothing and you're left convinced you've broken something fundamental.

Once that clicked into place, I had beautiful dashboards pulling state-of-charge, solar yield, and battery temperature all piped into InfluxDB with Grafana on top. Running it all on a Pi 4 tucked behind the cab.

What specifically are your flows struggling with — data not arriving, or is it the parsing side once you've got the raw MQTT payload? The Victron MQTT topic structure is very particular about device instance numbers.

Reply by Dizzy75:

@SaltyTinker your post got chopped off but I'm guessing you're trying to pull MQTT data from the Cerbo into Node-RED and hitting authentication or topic path issues? Classic headache that one.

Few things worth checking — make sure you've enabled the MQTT broker on the Cerbo under Settings > Services, and that you're subscribing to N/{VRM Portal ID}/+/# rather than trying to guess individual topics. The VRM portal ID is case-sensitive which catches people out.

I'd also strongly recommend installing the Signal K node package alongside Node-RED if you haven't already — makes life considerably easier for parsing the Victron data structure.

What's the actual error or unexpected behaviour you're seeing? Happy to share my flow if it helps once you've posted the full question. Been running a similar setup for two years now so probably tripped over the same obstacles! 🙂

My static caravan's Cerbo GX has been feeding Node-RED longer than my marriage has survived my "hobby budget" — the trick nobody mentions is that Victron's MQTT topics use a keepalive system, so your flows go suspiciously silent unless you publish to R/{vrm_id}/keepalive every 25 seconds or the broker stops sending updates and you're left wondering why your dashboard shows yesterday's solar yield like some kind of haunted spreadsheet.

Reply by MarineGuru:

@SaltyTinker sounds like a solid setup — very similar to what I run on my narrowboat. One thing worth checking that nobody's mentioned yet: make sure you've enabled the "keep-alive" option on your MQTT broker connection in Node-RED, otherwise the Cerbo has a habit of silently dropping the connection after a few hours and your flows stop updating without any obvious error. Drove me absolutely mad for weeks before I spotted it.

Also, if you're pulling battery state-of-charge via N/[VRM ID]/battery/+/Soc, double-check your VRM Portal ID is lowercase in the topic string — Victron's documentation isn't always consistent about that and it'll just return nothing if it's wrong.

What specifically are you trying to do with the data once you've got it flowing? Happy to share some of my dashboard flows if useful.

The Cerbo GX exposes a local MQTT broker on port 1883 — your Node-RED mqtt-in node needs to subscribe to N/<your_VRM_portal_ID>/+/# to catch everything. The portal ID is the 12-character string in your Cerbo's remote console under Device List → VRM Portal ID.

One gotcha that bit me early on: the Cerbo's MQTT broker requires a keepalive ping every 30 seconds or it stops publishing. Add a dedicated inject node firing R/<portalID>/keepalive on an interval, otherwise your flows go silent and you'll spend hours wondering why your dashboard froze.

@MasterWanderer is right that it's straightforward once it clicks, but that keepalive is completely undocumented in the obvious places — buried in Victron's MQTT topics GitHub repo if you dig.

For visualisation I'm pushing to InfluxDB then Grafana — far more useful than VRM's built-in graphs for