Anyone else using a Raspberry Pi to log their Victron data locally?

Been running a Pi 4 (2GB) connected via USB to a Cerbo GX on my shepherd's hut setup for about 18 months now. Using the VRM local logging alongside a self-hosted Grafana/InfluxDB stack — gives far more granular control than the Victron cloud portal alone.

The key tool is dbus-serialbattery if you're running a third-party BMS, and venus-docker made the whole containerised approach much less painful than I expected. Data retention is handled locally on a 128GB SD with write cycles managed through a RAM-based tmpfs overlay — SD card longevity was my main concern early on.

A few things worth noting for anyone considering this:

• Victron's MQTT broker on Venus OS is your friend — Pi subscribes cleanly and you get near-realtime data
• Set your InfluxDB retention policy sensibly, otherwise you'll fill storage quickly with 1-second intervals
• The Cerbo's built-in VRM still runs in parallel, so you're not losing cloud backup

Main reason I went this route was intermittent mobile signal at the hut location in Suffolk — couldn't rely on VRM cloud being available when I needed to diagnose charging issues remotely over my local LAN.

Currently working on adding EV charging session data from my Hypervolt into the same dashboard. Would be curious whether anyone else has managed to pull third-party charger metrics into a unified Grafana setup alongside their Victron figures — there doesn't seem to be a clean integration yet.

Anyone else running a similar stack? Particularly interested whether anyone's moved away from InfluxDB toward something like TimescaleDB or Prometheus for this use case.

@SuffolkExplorer interesting setup. Quick question — are you pulling data directly from the Cerbo via MQTT or using the VRM local API? I'm planning something similar for my static caravan system and trying to decide which approach is more reliable long-term.

Also, does the Pi handle the logging overhead without throttling? I've read the Pi 4 can get warm in an enclosed enclosure, which concerns me given mine would likely sit in a battery compartment alongside the Cerbo.

One thing I'm particularly keen to track is EV charging sessions against solar generation — trying to correlate when to schedule overnight charging versus daytime if there's surplus. Has anyone mapped Victron's ESS data into Grafana in a way that makes that kind of analysis straightforward, or does it require custom InfluxDB queries? I'd rather not reinvent the wheel if there's an established dashboard template floating about.

@BlownFuse @SuffolkExplorer — on my narrowboat I'm doing something fairly similar but pulling directly from the Cerbo's built-in MQTT broker rather than relying on VRM local logging at all. The Cerbo runs a Mosquitto instance on tcp://venus.local:1883 — no auth by default, though you can enable it.

My Pi 4 runs a Python script via systemd that subscribes to N/<VRM_ID>/# and pipes everything into InfluxDB 2.x, then Grafana on top. Been solid for about eight months through all weathers.

One thing worth noting: the MQTT topic structure on Venus OS is well documented on the Victron developer GitHub — genuinely useful if you want to get granular with individual MPPT or BMV-712 registers rather than just top-level SOC/voltage. Means you're not dependent on whatever VRM decides to expose.

@SuffolkExplorer snap — almost identical setup in my shepherd's hut. Running a Pi 4 (4GB) pulling from the Cerbo via MQTT locally, feeding into InfluxDB 2.x with Grafana on top.

One thing worth flagging: I set up Node-RED as a middle layer between the MQTT broker and InfluxDB — makes filtering and transforming the data much cleaner before it hits the database. Victron's MQTT topics can get noisy otherwise, especially if you've got multiple devices on the VE.Can bus.

Also recommend enabling the keep-alive MQTT ping in Node-RED — had silent dropouts early on that I didn't notice for days until I checked the gaps in Grafana.

@AshChild curious what retention policy you're running on InfluxDB — I'm at 90 days full resolution then downsampling to hourly after that, seems a reasonable compromise on the Pi's SD card.

@SuffolkExplorer nice one — I've been doing something similar for emergency backup monitoring at home. One thing worth flagging: if the Pi loses power the InfluxDB writes can corrupt. Learnt that the hard way.

Running mine with a small UPS HAT on the Pi itself (the Waveshare one) so it gets a clean shutdown if mains drops. Makes sense given we're often relying on this kit during an outage which is exactly when you need the logging intact.

Also worth enabling InfluxDB's write-ahead logging if you haven't already — gives you a bit more resilience without the hardware cost.