// CERBO GX MQTT DASHBOARDS
Turn a Cerbo GX MQTT feed into a real-time dashboard
Realtime data off a Cerbo GX means MQTT, not REST — and there are two brokers that matter: the local FlashMQ broker on Venus OS and the official VRM cloud broker. This page walks the honest route from raw topics to a polished, always-on display, then shows you ours running live on real hardware. We’re an independent service and not affiliated with Victron Energy. Rated 4.9 on Google.
- ● Live demo on this site
- ● Built & hosted for you
- ● Worldwide
/01 — THE SHORT ANSWER
What a Cerbo GX MQTT dashboard actually is
A Cerbo GX MQTT dashboard subscribes to the live MQTT feed published by your GX device — either the local FlashMQ broker running on Venus OS or the official VRM cloud broker — and paints those values onto a screen that updates the instant they change. Get the broker, the keepalive and the topic structure right and you have a genuinely real-time display; get them wrong and you are quietly back to polling a REST endpoint every few minutes and calling it ‘live’.
MQTT is the right transport because it is push, not poll. The GX device — a Cerbo GX, Ekrano GX, Cerbo-S, Venus GX or a Raspberry Pi running Venus OS — is the single source of truth for every connected MPPT, MultiPlus, BMV, Lynx and battery on the installation. It mirrors its internal D-Bus onto MQTT topics namespaced by your VRM portal ID, so one subscription gives you the whole system: state of charge, PV yield, AC loads, battery current, alarms and more, streaming as fast as the devices report.
The rest of this page is the honest route from that raw feed to a polished, always-on dashboard — the two brokers, the gotchas, and where DIY projects tend to stall. Then we show you ours, running live on real hardware.
/02 — THE TWO BROKERS
Local FlashMQ vs the VRM cloud broker
There are two brokers, and the right choice depends on where the screen lives.
Local broker (FlashMQ on Venus OS). Since Venus OS v3.20 the GX device runs FlashMQ with the dbus-flashmq plugin, a D-Bus-aware broker you enable under Settings → Services → MQTT. It listens on the LAN on TCP 1883 (plain) and 8883 (TLS). This is the lowest-latency, no-internet-required option — ideal for a wall display in the same building — but the client has to reach the GX on the local network or over a VPN.
VRM cloud broker. Victron also relays the same feed through mqtt<N>.victronenergy.com, where the broker index is derived from your VRM portal ID. It is TLS-secured and authenticated with your VRM credentials or an access token, so the dashboard can live anywhere in the world. Each cloud broker serves a bounded number of installations, so the exact hostname for your system matters.
Both brokers share one non-obvious rule: you must publish a keepalive to R/<portalid>/keepalive about every 30 seconds — the feed times out after roughly a minute — or it quietly drops back to just serial and system data. Data topics are namespaced N/<portalid>/<service>/<instance>/…; the R/ prefix requests a read and W/ writes a value back. Miss the keepalive and your ‘dead’ dashboard is usually alive — just starved.
/03 — THE REST TRAP
Why REST alone is never realtime
It is tempting to skip MQTT and just poll the VRM REST API on a timer. Don’t — not for a live screen. The REST API is genuinely excellent for what it is designed to do: pulling history, listing installations, reading alarms, fetching configuration and building reports. But its diagnostics and stats endpoints serve logged data, and the logging interval is the cadence the whole thing moves at — 15 minutes by default. Poll it every ten seconds and you will simply receive the same quarter-hour-old numbers over and over.
The same limit applies to VRM share links and iframe embeds: they are read-only and refresh at the logging interval, not in real time. They are perfect for a public ‘here is our system’ link; they are not a live control-room display.
So the division of labour is clear, and it plays to VRM’s strengths rather than against them. Use REST for history and context; use MQTT for the live numbers. A polished dashboard usually blends both — MQTT for the gauges that must move now, REST for the day, week and month charts behind them. VRM is doing exactly what it is built for; the realtime layer just needs the right channel.
/04 — THE HARD 80%
From a raw feed to an always-on dashboard
Subscribing to a broker is the easy 20%. Any MQTT client can print topics to a terminal. Turning that firehose into a display you would happily bolt to a wall for three years is the other 80%, and it is where weekend projects stall.
- A resilient connection loop that re-authenticates, re-subscribes and re-sends keepalives through Wi-Fi drops, GX reboots and broker cutovers — without a human noticing.
- Credentials kept server-side. TLS certificates and VRM tokens belong on a backend, never baked into browser JavaScript where anyone can read them.
- Decoding the raw values: enum states (system state, MPPT state, alarm codes) into words, unit scaling, derived figures, and sensible handling of stale readings so a frozen number never masquerades as a live one.
- A front end that runs 24/7 on a kiosk, TV or tablet without leaking memory or needing a nightly refresh — smooth gauges, readable at a glance, dark for a control room.
- Branding and hosting: your logo, your colours, a URL you can hand to a client, and somewhere reliable to run it.
None of this is exotic. It is just a lot of unglamorous engineering that has to be right every day, not only on the demo. That is the work we have already done — and you can watch the result running below.
/05 — SEE IT RUNNING LIVE
Our own off-grid van, streaming right now
We don’t ask you to take this on faith. Our own off-grid support van — the 365 Crafter, fitted with a Cerbo GX on Venus OS, MPPT solar and a lithium bank — streams its real telemetry through the official VRM API onto our custom VRM dashboards page, right now.
You can see the same live feed rendered two completely different ways — one clean and client-facing, one dense and technical — to make the point that once we hold the data, the presentation is ours to shape, not VRM’s fixed layout. There is also a fleet-style demo in which only the van is a real system; every other tile is clearly labelled as illustrative, because we won’t fake telemetry to pad a screen.
It is the honest version of a portfolio: real hardware, real state of charge, real solar yield, moving while you watch. If you want a Cerbo GX MQTT dashboard, the most useful thing you can do is look at ours running live and picture your own system in its place.
/06 — WHAT IT COSTS
How we price it (and what moves the number)
Every dashboard is quoted individually, because the work genuinely varies — we would rather scope it properly than post a headline number that turns out to be wrong for you. There are no set prices to quote here, but these are the honest cost drivers:
- Broker and reach: local-only, VRM cloud, or both — and whether the screen sits on the LAN or must be reachable worldwide.
- Scope: how many parameters, screens and derived views; a single glanceable kiosk is very different from a multi-view control room.
- One system or a fleet: a single Cerbo versus many installations aggregated into one view.
- Read-only or control: a display is simpler than a dashboard that also writes values back (ESS mode, relays) with the safeguards that demands.
- Branding, hosting and uptime: your look, where it runs, and how hard it must stay up.
Because we build, host and support the whole thing as a done-for-you service, we can quote the build and the ongoing running as one. Tell us what you are picturing and we will come back with a clear, itemised quote — our office hours are Monday to Friday, 9–5 UK time, and we work worldwide via remote delivery. Start on the contact page.
/07 — INDEPENDENCE & PREREQUISITES
What we are, and what we need from you
An honest disclosure first: 365 Techies is an independent service. We are listed in Victron Energy’s Recommended Software Integrator Program — though not a Victron dealer, distributor or reseller — Victron and VRM are their trademarks. We build on top of Victron’s excellent platform using its official, documented MQTT and VRM APIs; we don’t replace it, and we don’t speak for them.
What we need from you to start is short and reasonable:
- Working Victron kit reporting to a GX device — a Cerbo GX (or Ekrano/Venus GX, or a Raspberry Pi on Venus OS). This is the prerequisite; the dashboard reads what the GX already knows.
- VRM access as appropriate — typically an invited VRM account or an installation access token, plus your portal ID, scoped to what the job needs.
- MQTT reachable — the local broker enabled on the GX, or cloud access via VRM, depending on where the screen lives.
We are straight about the limits, too: non-Victron data can only appear if it is first fed into the GX device, and we won’t invent telemetry or overstate what MQTT can do. If your kit isn’t reporting cleanly yet, we can help sort that first — see off-grid Victron and the Victron system builder.
// RELATED
Related: Victron VRM API dashboards, customise your VRM dashboard, embed VRM on a website, Victron Grafana dashboards, custom VRM dashboards and off-grid Victron. The same MQTT feed also carries GPS position topics — that’s how Victron GPS tracking gets a near-live moving map, with the hardware options covered in adding GPS to a Cerbo GX.
FAMILY-RUN SINCE 1995 · ★ 4.9 ON GOOGLE · 200+ COMPUTERS UNDER OUR CARE · NO FIX, NO FEE · SAME-DAY REMOTE SUPPORT
// GOOD QUESTIONS
Frequently asked
Local FlashMQ broker or the VRM cloud broker — which should I use?
It depends on where the screen lives. If the display is on the same site as the GX device, the local FlashMQ broker (Venus OS v3.20+, ports 1883/8883) gives you the lowest latency and no internet dependency. If it must be reachable from anywhere, use the VRM cloud broker over TLS. Plenty of installs want both — local for the wall, cloud for remote — and a well-built dashboard can fail over between them.
My MQTT feed only shows serial numbers — what’s wrong?
Almost always the keepalive. Both the local and cloud brokers stop sending the full topic set unless you publish an empty keepalive to R/<portalid>/keepalive about every 30 seconds (before it times out around a minute). Miss it and you are left with just serial and system topics, which looks like a dead feed but is really a starved one. A production dashboard sends the keepalive on a reliable timer and re-sends it immediately after any reconnect.
Can I just poll the VRM REST API instead of using MQTT?
Not for a live screen. The VRM REST API is excellent for history, alarms, configuration and reports, but its diagnostics data follows the logging interval — 15 minutes by default — so polling faster just returns the same stale numbers. Share links and iframe embeds have the same limit and are read-only. Use REST for context and long-term charts; use MQTT for the values that must move in real time.
Can the dashboard change settings, or is it read-only?
Either. MQTT supports writes via the W/ topic prefix, so a dashboard can change values — ESS mode, relay states, setpoints — not just display them. Control adds real responsibility, though: authentication, confirmation, safe defaults and audit. We usually ship a read-only display first, then add controlled write actions deliberately, with the safeguards that anything touching a live power system deserves.
Can you show non-Victron sensors on the same dashboard?
Yes, but with an honest caveat: non-Victron data can only ride the VRM and MQTT feed if it is first fed into the GX device — for example as a supported sensor or a custom D-Bus service on Venus OS. Once it is on the GX it becomes just another topic we can render alongside your Victron values. If it can’t reach the GX, it needs a separate feed, which we can also handle.
Do you host it, and can you do this outside the UK?
Yes to both. We build, host and support the dashboard as a done-for-you service, and because delivery is remote we work worldwide — the GX device and VRM don’t care where we are. Our office hours for support and response are Monday to Friday, 9–5 UK time, stated plainly so you know when a human is at the desk. You keep ownership of your Victron kit and VRM account throughout.
There are MQTT examples on GitHub — why pay you?
Because the example that prints topics to a terminal is the easy part, and it is honestly worth trying first. The cost is in everything after: a connection that survives reboots and drops, server-side credentials, decoded enums, stale-data handling, a front end that runs untouched for years, plus branding and hosting. We have already built and proven all of it — our own van streams live on this site — so you buy the finished, supported result, not a weekend of debugging.
What do you need from me to get started?
Three things: working Victron kit reporting to a GX device (the prerequisite), VRM access as appropriate — usually an invited account or an installation token plus your portal ID — and MQTT reachable either locally on the GX or via the VRM cloud. That is enough for us to scope the job and come back with a clear quote. We keep access scoped to exactly what the work needs.
Can a built-for-you dashboard be deployed to our own hosting?
Yes. The whole thing is a static front end plus a small PHP relay, so it drops onto almost any ordinary shared hosting on a subdomain you control; your VRM token lives in one server-side file the relay reads and is never exposed client-side. You grant SFTP scoped to just that directory, you can revoke it whenever you like, and the deployment is yours — it’s exactly how our own 365 Crafter dashboards run.
Get a Cerbo GX MQTT dashboard that actually stays live
We’ve already solved the brokers, the keepalive and the always-on front end — and our own off-grid van proves it on this very site. Tell us what you want to see and we’ll quote the build, hosting and support as one. Worldwide delivery, handled from here in Dorset.
01202 775566 · help@365techies.co.uk · MON–FRI 9AM–5PM