Sprinter Van HUD
I'm Kevin Graehl — I run a mobile electric-vehicle modification and diagnostics business out of San Francisco, and I build the tools I actually need when nobody sells them. This project started as one simple frustration: solar, a battery bank, and a charge controller already on my work van, and no single place to see any of it. It turned into reverse-engineering a Bluetooth protocol Victron never documented, open-sourcing the result, and building a small side business selling the hardware to other people stuck with the same problem.
The van
This is a commercial work vehicle — my third Sprinter, in service for about a year, outfitted for my electric vehicle (EV) modification and diagnostics business. The front is a mobile office; the rear is a dedicated tool and parts garage for on-site EV work. The onboard solar and battery system exists to run diagnostic equipment, laptops, and shop tools in the field without depending on shore power, which is exactly why remote monitoring matters for the business — being able to check power and system status from a job site, or before heading out to one, saves a trip back to the vehicle.
How this project started
The van came with solar, a lithium battery bank, and a Victron charge controller already installed, but no way to see any of that data without walking out to check three separate screens. The goal: one dashboard, in the van, showing everything live — a genuine business tool, not a novelty.
The catch: Victron's newer gear broadcasts encrypted Bluetooth telemetry that's crackable if you have the device's "bindkey" from their app. But one of the three devices in this system — an older VE.Direct Smart dongle — doesn't support that scheme at all. No bindkey option exists for it, anywhere. Getting data out of it meant going a level deeper: sniffing its Bluetooth traffic directly, logging raw packets, changing bytes by hand and watching what changed on screen, and using AI to do the tedious bit-level parsing work that used to take days by hand. That's how this project actually works — not an SDK, not an official API, just watching what a device actually says over the air and decoding it byte by byte.
That work is, as far as I can tell, the first public documentation of reading live data off this specific Victron dongle without its official app or a bindkey — building on prior public work from other reverse-engineers (credited below) who cracked adjacent pieces of Victron's protocol family.
Why an ESP32 (and not just an app)
You could buy a single-vendor smart-home hub and get a nice app — for whatever that one vendor sells. This project pulls from Victron's solar controller, a shunt-style battery monitor, and a completely different brand's Bluetooth-enabled LiFePO4 battery, all onto one screen, because it's not tied to any single company's ecosystem. That only works with a programmable microcontroller sitting in the middle speaking each device's actual protocol — not a proprietary "smart" plug that only talks to its own app. An ESP32-S3 has enough radio (WiFi + Bluetooth together), enough RAM, and a big enough open toolchain (ESP-IDF) to be that translator. The alternative — paying 10x more for one manufacturer's closed ecosystem — buys convenience for exactly the devices that one company sells, and nothing else.
What it looks like right now
Full live telemetry, no login required:
Buy a built unit
As far as I know, one other seller (UK-based) sells anything comparable for older non-bindkey Victron gear. This is a small side project, not a company — email me and I'll build one by hand.
The code is free either way — building it yourself costs roughly half that, mostly just the display module itself.
One current sensor can't see two things at once
A question worth explaining, because it trips a lot of people up: if the panel is putting 10A into the battery and something in the van is drawing 3A, the dashboard shows one number — 7A — not both. A single current sensor only ever measures net flow at whatever point it's wired into; it has no way to separate "less sun" from "more load" after the fact, because by the time it measures anything, those two effects have already been added together.
Solving that for real needs a second, independent current sensor somewhere else in the circuit — one at the solar controller's own output, one at the battery's shunt — and simple subtraction: load = charge current − net battery current. That's exactly what the battery's own Bluetooth shunt (a few inches from the battery, reading true net current in/out of the whole bank) is for, once its data is fully wired into the dashboard.
Until then, there's a free workaround worth knowing: at night, and during the low-light minutes around sunrise/sunset, solar production is at or near zero — so the shunt's single net reading is the load reading at those times, no subtraction needed. Daytime readings are the only ones that need the second sensor to untangle.
Credit
This builds directly on other people's public reverse-engineering work:
keshavdv/victron-ble — reference implementation of Victron's Instant Readout AES-CTR decryption.
ferdy-lw/vicmon — documented the active GATT service used for VE.Bus/MPPT control; its handshake sequence was the key to reading the legacy dongle.
patman15/aiobmsble — pre-documented protocol for the Bluetooth LiFePO4 battery's BMS.
Why this exists at all
This whole thing is a closed loop built from inexpensive, individually-cheap parts talking to each other over protocols none of them were designed to share — a $20 display board, a solar controller, a battery's own BMS, a shunt, eventually a couple of relays. None of it is expensive. All of it is a little janky compared to a single $2,000 integrated system from one vendor. That's a real tradeoff, and I'm fine with it — the alternative is paying enterprise prices for a consumer problem.
What it buys back is genuinely simple: equipment left on by accident is one of the most common ways to kill a battery bank — an inverter, a water pump, anything pulling current all night without anyone noticing until the battery's flat and now needs replacing. A dashboard that's actually glanceable, from anywhere, catches that before it becomes a bill. Same logic applies on weekends — if I'm out kiteboarding and can't get back to the van quickly, I'd rather see a warning on my phone than find a problem after the fact.
A few more things on the list for exactly that reason: remote snapshot commands from a couple of cameras (interior and exterior — a still image on demand, not a live video feed), and eventually being able to trigger things like heat remotely before getting back to the van. Same theme throughout: cheap parts, real protocols, no vendor lock-in, and visibility into a system that would otherwise stay silent until something already went wrong.