steeman.be

In the previous post I showed you the wireless rocket launch controller I built for VRO — two ESP32-S3 units, an encrypted radio link, and a handful of relays between an operator’s thumb and a pyrotechnic igniter. That post was the what and the why. This one is the how: the functional design, the decisions everything else derives from, the firmware architecture, the full catalogue of safety measures, the radio protocol, the sensing and display internals, and how the whole thing was tested and built. It’s long. That’s the point.

The last time I built launch electronics for a rocket, it was 2008 and the brain of the thing was a PIC16F88 running a four-channel flight timer. Eighteen years later I found myself building something rather bigger: a two-unit, wireless launch controller for VRO — Vlaamse Raket Organisatie , built on a pair of ESP32-S3s, that sits between the LCO’s thumb and a pyrotechnic igniter. Over a radio link. That last part usually raises an eyebrow. Wireless and pyrotechnics sound like they belong in different rooms. But somewhere along this build I arrived at a counterintuitive position: done properly, a wireless link can be safer than a spool of copper — because you can’t trust a radio the way you lazily trust a wire. The wire invites you to assume safety. The radio forces you to design it.

A few weeks ago I vibecoded my first Fri3d Camp 2026 badge app — a hardware self-test screen. It was a great first project: it touched every part of the badge, and it was genuinely useful. But it was also, honestly, a toy. It used the badge as a single device on my desk. The interesting thing about the Fri3d badge is that roughly 700 people carry the same little computer at the same time, each with a screen, buttons, a battery, and a Bluetooth radio. One badge on a desk is a gadget. Seven hundred of them in a field is a network. So the next app had to do something with that.

I have written code before. Once upon a time I was even trained as a software developer, though I never ended up using that skill professionally. I do still write code and firmware now and then. But it takes time — and honestly I’d never have justified spending much of it on a simple badge app. So when the new Fri3d Camp 2026 badge landed in my hands, I figured the really cool apps would have to come from someone with more time to spare.

The Fri3d Camp 2024 badge is an ESP32-S3, which makes it a first-class target for ESPHome — and therefore a native citizen of Home Assistant. This post documents a complete ESPHome configuration for the badge: which component drives each piece of hardware, the non-obvious choices that were required, and the entities that show up in Home Assistant once it is flashed. It is a companion to my earlier post on programming the badge with Claude Code ; that one covers the stock firmware and writing MicroPython apps, this one covers replacing the firmware with ESPHome.

Every Fri3d Camp hands out a badge, and the 2024 one is a serious little machine: an ESP32-S3 with a 2-inch colour LCD, five NeoPixels, a joystick, a buzzer, an IMU and a microSD slot — all in a Game-Boy-ish shell that boots straight into a retro game emulator. It’s a lovely object. But the thing that excited me most wasn’t playing Doom on it; it was the idea of writing my own software for it. And this time, rather than fighting datasheets alone, I paired up with Claude Code on the terminal.

My wife wanted a word clock for the house for ages. There’s something deeply satisfying about a clock that doesn’t show digits at all — it just lights up the words: het is half drie. So when I came across a complete Dutch design for one, I finally had no more excuses. What’s a word clock? # A word clock tells the time by illuminating groups of letters on a grid, so that the lit-up letters spell the time in words (rounded to five minutes). The face is a matrix of letters, and at any moment only the letters that form the current time are on. It’s a lovely bit of functional typography.

Twice a day, every day, the Royal Meteorological Institute launches a weather balloon from Uccle, just south of Brussels. Hanging under it is a small styrofoam box — a radiosonde — that climbs to around 30 km, bursts, and parachutes back down somewhere downwind. The balloons aren’t recovered, so the sondes become litter, and a small community of hobbyists tracks them on radio and goes out to pick them up.

My roof has a Platinum 3100S solar inverter (made by Diehl AKO). I recently installed a Solar-Log 500 to read its production and feed the numbers into Home Assistant — it works, but it’s a black box I don’t control, and I’d rather read the inverter directly with an ESP32 and cut out the middleman. The catch: the Platinum speaks a proprietary serial protocol. There’s no Modbus register map, no public documentation, nothing. So this turned into a reverse-engineering project — and this post is the honest story of an attempt that, so far, has hit a wall. I’m publishing the full dataset so anyone else can have a go.

The first two parts of the 3-2-1 backup rule are easy: three copies, on two different media. I had that covered with the Borg backup strategy on my home server — nightly Borg archives on a local USB disk, mirrored to a NAS. The hard part is the “1”: one copy offsite, somewhere physically separate from the house, so a fire or a theft doesn’t take the data and every backup of it in one go.