The Brother Scanner Docker container has one part I never wrote and could never read: brscan-skey, the closed-source daemon from Brother that makes the scanner’s front panel show my server as a Scan to PC destination and forwards the button presses. Shortly after the 2.0 release that daemon turned out to have a bug that silently kills the buttons after a few days, the vendor was not going to fix it, and the license allowed me to. Worse even, they told me to get in touch with the community for support. So I replaced it. openskey is an open reimplementation of that daemon in Rust, and this is the story of how it came to be and what I learned from the device on the way.

My NX1000 is a mirrorless camera from 2012 with a feature that was ahead of its time: Wi-Fi, and with it Auto Backup. Turn the mode dial, press a button, and every new photo walks over to a PC in the house. The camera still does that today, but the other end is gone. Samsung left the camera business, the Windows tool no longer installs, and the cloud services are switched off. So I wrote the other end myself. Samsung Camera Backup has two halves. An Android app makes the phone the camera’s backup target on the road. A small home server in a container does the same at home and processes the files afterwards. This post shows what the two halves do, how fast the camera really is, and what a 2012 firmware teaches about testing.

Seven years ago I wrote about digitizing analog documents: A Brother MFC-L2700DW, its Linux driver in a Docker container on the DiskStation, two rewritten shortcut scripts that turn a simplex document feeder into a duplex workflow, and a small Tesseract service for the text recognition. That setup has scanned every letter that reached this house since, and the container has quietly collected users, issues and pull requests along the way. This year it got the overhaul it had earned. Version 2.0 is out, and this post is the tour.

In our attic stands a very old Kettler Golf M ergometer. It is a wonderfully indestructible machine: A permanent-magnet brake, a dial for the resistance, and a battery-powered console (an FB601) showing pulse, cadence and some “derived” numbers for speed and distance. What it does not have is any data interface. No serial port, no Bluetooth, nothing — the only connector is an analog plug for an ear-clip pulse receiver. Since I measure everything else in this house, that clearly could not stand. This is the story of wiring it up to an ESP32, a story that grew far beyond its original scope: Past a failed first approach, into Home Assistant, onto a chest strap, through an AI training coach posting to Matrix, and finally into a full role-playing game.

As shown in some of my earlier posts, I run a fair number of services at home, and I like to measure things. Two of the things I measure are the electricity meters in the basement: one for the house and one for the heating. Both are modern meters with an optical (infrared) interface, and for years a small script has been reading them and pushing the numbers into MQTT, from where the rest of my homelab picks them up for dashboards and the occasional automation.

Running services in Docker is easy. Running them securely, observably, and without punching unnecessary holes into your host? That’s where things get interesting.