Building a Bluetooth Auto-Reconnect Daemon with BlueZ and D-Bus

Most Bluetooth utilities assume a desktop session. But on a headless Linux box, a media server, or a minimal install, there's no desktop — yet you still want your trusted devices to reconnect automatically. That's the problem Bluetooth Autoconnect solves by talking to BlueZ directly.

BlueZ and D-Bus

BlueZ is the Linux Bluetooth stack. It doesn't expose a traditional library API; instead it publishes objects on the system D-Bus. Adapters, devices, and the daemon itself all show up as D-Bus objects with properties, methods, and signals. To automate Bluetooth you subscribe to those signals and call those methods.

Listening for the right signal

When a trusted device comes into range, BlueZ emits signals. The daemon watches adapter state, matches devices marked trusted, and calls org.bluez.Device1.Connect when a target appears. Because it reacts to signals rather than polling, it stays efficient and reconnects promptly.

Retries and backoff

Connections fail — a device might be momentarily unreachable or a previous connection might not have torn down cleanly. A naive loop that hammers Connect can wedge the adapter. The daemon uses a configurable retry interval with backoff, giving BlueZ time to settle between attempts.

Running as a systemd unit

The daemon ships as a systemd service, which gives it three things for free: it starts at boot, it restarts on failure, and it logs through journald. This is what lets reconnection happen before any user logs in, which is the whole point of running it at the system level.

Why D-Bus instead of a shell script

You could script bluetoothctl, but that's a CLI tool wrapping the same D-Bus interface — you'd be parsing text output of a tool that wasn't designed to be scripted at that granularity. Going straight to D-Bus is more robust, more testable, and doesn't depend on bluetoothctl's output format staying stable.