A Raspberry Pi was already running on the shelf. A BME280 sensor costs around €10. This should have been a weekend project.

It mostly was, except for the part where I assumed reading a temperature sensor meant reading a register.

Four wires and a chip

The Bosch BME280 measures temperature, humidity, and atmospheric pressure over I²C. Four wires to the Raspberry Pi GPIO pins, enable I²C in raspi-config, and the sensor shows up at address 0x77 on the bus:

i2cdetect -y 1

That’s the easy part. The catch is what happens next.

You don’t just read the temperature

The BME280 doesn’t hand you 21.5°C. It gives you raw ADC values: 20-bit integers that mean absolutely nothing by themselves. To get an actual temperature, you have to:

1. Read the calibration coefficients Bosch burned into the chip’s EEPROM at the factory (registers 0x88, 0xA1, 0xE1)
2. Apply Bosch’s compensation formulas: double-precision floating point arithmetic that uses those coefficients to turn raw values into real measurements
3. Wait for the measurement to finish by polling the status register

The temperature compensation alone takes the raw value, applies a quadratic correction with three calibration constants, and spits out a value in hundredths of degrees Celsius. Pressure depends on the corrected temperature. Humidity depends on both.

It’s all straight from the Bosch datasheet, nothing clever. But it does mean the driver isn’t a five-liner. It’s implementing a spec, not importing a library.

Making it network-accessible

Once the driver worked, the next question was how to get those values into Home Assistant. The simplest path: a Flask API with two endpoints.

GET /bme280 returns the current reading as JSON. GET /bme280/publish reads the sensor and pushes the three values to an MQTT broker. A cron job on the Pi calls the publish endpoint every few minutes, and Home Assistant picks up the values in real time.

The MQTT discovery mechanism made the Home Assistant side almost frictionless. One mosquitto_pub command per sensor type — publishing a JSON config payload to the right topic — and the entities appear automatically in the UI. No configuration.yaml editing, no restart required.

BME280  ──I²C──►  bme280.py  ──►  Flask API  ──MQTT──►  Home Assistant

The full setup guide is in the repo.

What I didn’t expect

The Bosch calibration is non-negotiable. I started by reading the raw temperature register directly and scaling it naively. The result was numbers that looked almost plausible and were completely wrong. The compensation algorithm isn’t optional decoration, it’s what makes the output mean anything.

Polling beats events here. The sensor doesn’t push data, you ask it for a reading. A cron job every minute is all you need for room monitoring. Real-time streaming would be overkill and would probably wear out the sensor faster.

MQTT discovery is underrated. Manually declaring sensors in configuration.yaml works, but auto-discovery just feels right. Publish a config payload once, and Home Assistant takes it from there. Adding a new sensor type later takes about thirty seconds.

The room is now 21.4°C and 47% humidity. I know this without opening anything.

A note on the official Bosch SensorAPI

While writing the driver I peeked at the official Bosch SensorAPI for reference. Two things caught my attention.

The Linux userspace example doesn’t actually work on a Raspberry Pi out of the box. Several contributors tripped over the same bug independently: ioctl is called before dev_addr is assigned, so the I²C device address never gets set properly. The fix is obvious once you see it, and multiple PRs documented it, but they sat open for years. Some still are.

Then there’s PR #94 (still open as of early 2025), reporting undefined behavior in bme280_get_sensor_mode(): the left operand of a bitwise & is an uninitialized variable, caught by static analysis.

The chip itself is great. But manufacturer reference code is a starting point, not gospel. Implementing the compensation algorithm straight from the datasheet meant I understood every line of it. When a reading looks weird, there’s no mystery C library to blame.

guillaumedelre/bme280

Python driver for the BME280 sensor — temperature, humidity, and pressure over I²C, with MQTT publishing and Home Assistant integration.

A Dream Cheeky Thunder appeared on a desk shortly after. Four foam missiles, a USB cable, and a very clear team consensus: hook it to the cluster, wire it to the build pipeline, and let the CI decide who deserves a volley.

The launcher needed to respond to HTTP calls from anywhere on the network. No driver, no GUI, no manual aiming. Just an endpoint that makes it shoot in the direction of the guilty party’s desk.

This is the story of dream-cheeky-thunder.

No SDK, no docs, no problem

Dream Cheeky never published a protocol spec. The launcher speaks raw USB HID, and the only starting point was a vendored Python script from 2012 floating around in forum threads. Vendor ID 0x2123, product ID 0x1010, and a handful of control bytes that someone had reverse engineered years before.

That was enough. The protocol is simple: send a byte sequence to move the motors, send another to fire. The tricky part is that the launcher has no position feedback. No encoders, no limit switches beyond the physical hard stops at the extremes. You drive it blind.

From USB to HTTP

The CI pipeline needed to trigger the launcher over the network. A local script wasn’t going to cut it — the launcher had to be reachable from any machine on the cluster, including the build server. So: a REST API.

FastAPI was the obvious choice. The targeting flow from the CI side ends up being three HTTP calls:

curl -X POST http://localhost:8000/park      # reset to known position
curl -X POST http://localhost:8000/yaw/20    # rotate toward guilty desk
curl -X POST "http://localhost:8000/fire?shots=2"

The /park call matters more than it looks. Since the launcher has no position feedback, the server estimates the current angle by tracking how long the motors have been running. That estimate drifts. Bumping the hardware, interrupting a command, or just the imprecision of time-based tracking — they all accumulate. Parking drives both motors against the physical hard stops at full sweep, which guarantees alignment regardless of what the server thinks it knows. Skip it, and your aim is a guess.

The full API reference is in the repo. There’s also a web UI if you prefer clicking over curl.

Docker knows nothing about USB

Running this in a Docker container on the cluster was where the fun really started: containers don’t see USB devices by default.

The devices mount in compose.yaml exposes the USB bus to the container:

devices:
  - /dev/bus/usb:/dev/bus/usb

Not enough. First run came back with USBError: [Errno 13] Access denied. The device node is there inside the container, but it inherits permissions from the host, and on the host only root can open it by default.

The fix is a udev rule. Drop one file into /etc/udev/rules.d/, and the kernel sets the right group and permissions when the device plugs in. After that, the container user can open it without needing elevated privileges. The rule ships with the project, setup instructions are in the docs.

WSL2 made it interesting

Half the team runs Windows with Docker Desktop on WSL2. That’s where things got creative.

WSL2 has no access to USB devices by default: the Windows kernel holds them, and the devices mount alone does nothing because WSL2 simply doesn’t see the hardware. The fix is usbipd-win, which forwards the USB device from Windows into the WSL2 kernel over IP. Once that’s done, the Linux path works exactly the same: udev rule, devices mount, done.

The attachment doesn’t survive reboots, though. usbipd v4+ added a policy mechanism that automates reconnection, which killed the “it worked yesterday” mystery that had been annoying us for days.

What actually surprised us

Time-based positioning works well enough. No encoders meant we went in expecting the angle tracking to be basically useless. Turns out, parking before every sequence kept it accurate enough to reliably aim at a specific desk. Not millimeter precision, but foam missile precision is fine.

The devices mount is necessary but not sufficient. The permission error was confusing precisely because the device was clearly visible inside the container. The udev rule is the bit most tutorials quietly skip.

The coffee rule was never the same after this. Once the launcher was wired to the pipeline, broken builds suddenly became a lot more motivating to fix.

guillaumedelre/dream-cheeky-thunder

FastAPI + Docker + PyUSB — HTTP control for the Dream Cheeky Thunder USB missile launcher. Pull requests welcome, especially if you have a better angle calibration approach.