Micro-Home: Giving the BBC micro:bit a Place in Home Assistant

The BBC micro:bit is usually introduced as a way to learn programming. That is a good use for it. It is not the only one.

Underneath the educational software is a board with two buttons, an accelerometer, a compass, an onboard temperature reading and a Bluetooth radio. Those are useful ingredients for a small home automation device.

So we built Micro-Home: firmware that turns supported micro:bit v1 and v2 boards into wireless sensors for Home Assistant, with an ESP32 handling the connection to the rest of the house.

It started with temperature, acceleration and one button. Then the scope grew: both buttons, a compass, and support for an older board as well as the newer one.

The interesting part was making those additions without turning a small project into an unnecessarily complicated system.

A Small Device With a Clear Job

The micro:bit does not need to join Wi-Fi, maintain a connection to Home Assistant or run an MQTT client. Its job is to read its sensors and broadcast a short packet.

An ESP32 running ESPHome listens for those packets and publishes the decoded values through Home Assistant's ESPHome integration.

micro:bit  -- BLE advertisements -->  ESP32 / ESPHome  -- Wi-Fi -->  Home Assistant

No pairing. No persistent Bluetooth connection. No extra sensors wired onto the micro:bit.

Home Assistant gets five entities:

Keeping the micro:bit's responsibilities small also makes the two hardware versions easier to support. The gateway sees the same packet format from either.

Use a Protocol That Already Exists

We used BTHome V2, a format designed to carry sensor values in Bluetooth Low Energy advertisements.

There was no reason to invent a private message format for temperature, a boolean or an angle. Standard object identifiers already describe those measurements.

Our full advertisement is 21 bytes, within the 31-byte legacy advertising limit. It contains temperature, two boolean values, total acceleration and direction, alongside the flags and BTHome service information.

One small protocol detail mattered: a button event is not the same thing as a button state. BTHome's button-event object can describe a press, but "no event" does not mean "released". We used two standard boolean objects, consistently ordered A then B, to represent held and released states properly.

The receiver uses the BTHome service UUID, 0xFCD2, and the configured device MAC to identify the data. Everything needed is in the advertisement itself, so the gateway can scan passively.

Where the Integration Needed Its Own Code

Using a standard radio format did not mean every part was available out of the box.

The ESPHome release we tested, 2026.10.0, does not include an upstream bthome platform. Micro-Home therefore includes a local external component that decodes this particular sensor profile and exposes the entities to Home Assistant.

That distinction is worth being clear about. This is a standard BTHome V2 payload with a project-specific ESPHome receiver, not a claim that ESPHome can decode every BTHome device through this component.

It validates packet lengths, object identifiers, boolean values and heading ranges before publishing. If valid data stops arriving for 30 seconds, readings become unknown rather than quietly keeping a stale button press forever.

The component also accepts the earlier one-button packet. That gives us a way to update receivers before replacing older transmitter firmware.

Supporting the Board That Came Before

The v2 implementation uses the nRF52833 and its LSM303AGR sensor hardware. The connected early v1 board is a different proposition: an nRF51822 with 16 KB of RAM, an MMA8653FC accelerometer and a MAG3110 compass.

Changing a board name in a build command was not enough.

Zephyr already provides support for the older accelerometer. The compass needed a small MAG3110 driver: verify the chip identity, configure sampling, check that data is ready and convert the signed readings into the units the application expects.

The v1 also needed smaller stack allocations to fit its memory budget. Its final debug build uses 13,020 bytes of static RAM; the battery build uses 10,684 bytes. Those numbers are useful build checks, not a substitute for runtime testing.

We kept separate board configurations and drivers, while sharing the sampling loop, compass calculation and packet encoder. The hardware differences stay where they belong, without maintaining two copies of the application logic.

Support is deliberately specific: early v1.3 boards with MMA8653FC/MAG3110, and v2 boards fitted with LSM303AGR. Later v1.5 sensor variants and FXOS8700-equipped boards are not currently supported.

Build Safety Is Part of Usability

Once a repository can produce firmware for two different microcontrollers, deploying the wrong image becomes an easy mistake to make.

The build helper makes the target explicit:

bash scripts/microbit.sh v1
bash scripts/microbit.sh v2

It keeps separate build directories for each board and profile. When asked to flash, it checks the mounted board's DAPLink identity before building and checks it again before copying the fresh HEX file.

That check cannot identify every fitted sensor, but it can refuse an unknown board or an obvious v1/v2 mismatch. Tests exercise those refusals using fake USB drive directories, without writing to real hardware.

These are small details. They make the project easier to pick up without knowing the history of the machine it was developed on.

The Trade-offs Are Part of the Product

The firmware samples every five seconds, then sends a 600 ms burst of repeated advertisements. Repeating a packet improves the chance that a scanner receives it. Advertising stops between bursts, and the CPU can idle instead of busy-waiting.

There are consequences to that choice.

The buttons are state monitors, not reliable click remotes. A quick tap between samples can be missed. If the intended use is an immediate light switch, this sampling design needs to change.

Die temperature is not room temperature. The reading comes from the processor, with native 0.25 degree Celsius resolution. Encoding it with two decimal places does not turn it into a calibrated ambient sensor.

The compass is a starting point, not a navigation instrument. It reports magnetic heading with the board level. Calibration, magnetic interference and axis alignment matter. There is no tilt compensation or true-north correction.

Less radio activity is not a battery-life measurement. Sensors remain enabled, and the board contains more than the application processor. A battery profile disables UART and logging, but whole-board current still needs measuring.

Finally, the BLE packets are unencrypted and unauthenticated. Someone nearby can read, spoof or replay them. The encrypted Home Assistant API protects a different part of the route; it does not secure the micro:bit's advertisements.

Making these limits visible is part of making the project useful. It gives someone enough information to decide whether it fits their actual use case.

Tested Beyond Compilation

Both board targets and their debug and battery profiles build with the pinned Zephyr toolchain. The host tests check packet bytes, signed values, both button combinations, compass maths, malformed inputs and the earlier packet format.

We also flashed both physical board revisions and received their actual extended BTHome packets over BLE. On the ESPHome side, logs confirmed the decoded sensor values and both buttons moving between pressed and released states.

That verifies the working data path. It does not establish calibrated compass accuracy, long-term battery life or reliable reception in every installation.

The repository documents the tested versions, supported hardware, build commands, gateway setup and the checks still worth doing on your own devices.

A Useful Next Life for Familiar Hardware

Micro-Home is a small experiment in giving existing hardware a focused job.

It is not trying to replace every commercial sensor. It makes a supported micro:bit useful inside an established home automation system, keeps the gateway understandable, and provides one repository that can build and deploy either hardware generation.

That is the kind of engineering we like at Estopia: useful first, clear about its limits, and structured so the next improvement does not require starting over.

The source and setup guide are available in the Micro-Home repository. This is a public project preview rather than a licensed open-source release.