Bluetooth

Home Assistant in Docker doesn’t see Bluetooth devices, even if everything works on the host. Causes: ❌ Container has no direct access to /dev/hci0 ❌ BlueZ inside container conflicts with host daemon ❌ Passive BLE scanning requires --experimental flag in BlueZ Solution: Don’t run Bluetooth stack inside container - passthrough D-Bus from host instead. ✅ Docker Compose Configuration Minimal Setup services: home-assistant: container_name: home-assistant image: ghcr.io/home-assistant/home-assistant:stable volumes: - config:/config - /run/dbus:/run/dbus:ro # ← Critical for Bluetooth cap_add: - NET_ADMIN - NET_RAW - SYS_ADMIN restart: unless-stopped networks: - traefik - prometheus volumes: config: driver: local networks: traefik: external: true name: traefik prometheus: external: true name: prometheus ⚠️ Don’t add devices: - /dev/hci0:/dev/hci0 - not needed with D-Bus passthrough and may cause conflicts. ...

On Orange Pi 3B, the built-in Bluetooth chip Spreadtrum UWE5622 is connected via UART (/dev/ttyBT0). Unlike USB adapters, it requires: Loading firmware and calibration data before initialization Running hciattach_opi with correct flags Correct startup order: chip initialization first, then BlueZ daemon Symptoms: bluetoothctl scan on → No default controller available btmgmt info → Index list with 0 items hciconfig -a shows hci0, but bluetoothctl doesn’t see it Error org.bluez.Error.Busy when trying to power on Cause: The service orangepi3b-sprd-bluetooth.service runs hciattach_opi with the -n flag (no-detach), which holds the device and prevents BlueZ from registering the controller. ...