Proxy Bluetooth on RBP4 to HA Container (with docker compose)

Configuration
1

On my RaspberryPi 4 with Raspbian I am running a HA from docker image with docker compose. A lot of stuff, integration and devices are working flawlessly (including ZigBee).

I am trying now to start using Bluetooth, following Bluetooth - Home Assistant.

BlueZ is running on my host machine and /run/dbus:/run/dbus:ro added to the volumes in docker composer file, as below:

version: '3'
services:
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /srv/ha_config:/config
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
    restart: unless-stopped
    privileged: true
    network_mode: host
    devices:
     - /dev/ttyUSB0:/dev/ttyUSB0
     - /dev/ttyACM0:/dev/ttyACM0
     - /dev/ttyAMA0:/dev/ttyAMA0

docker compose restart

`/run/dbus’ on my host:
image

But on the docker image the /run/dbus is still empty:
image

And of course HA Bluetooth integration is complaining:
image

Additionally
Test that BT is wokring on my host:
image

bluez service status

image
image1087×420 18.2 KB

Did anyone manage successfully to proxy Bluetooth to HA docker container on RBP platform?

Thanks for any help!

2 Likes
2

I have the same issue, my setup and errors is the same, and I am able to see the Mi Flora device when scanning with bluetoothctl.

Running bluetoothd -n gives this error:

image
image1574×109 5.69 KB

1 Like
3

I was searching for the same issue (“Retrying setup: DBus…”) with “docker-compose” and found this thread. I didn’t see anywhere about dbus in docker-compose (not just docker, and I’m still not great with docker things). So this post helped.

I ran docker-compose up -d and it looks like it’s working (but I don’t have any bluetooth devices!).
Is it possibly as simple as not “up -d” to recreate (vs. restarting) for you?
Thanks for your post.

4 Likes
4

That solved it for me

2 Likes
5

Glad it helped!
Docker compose is just a ‘wrapper’ over docker, so you can write down docker configuration in one .yml file, including multiple services (multiple docker images).

“up” command creates and starts the container, “-d” simply detaches docker from the current process (run containers in the background).

A kind question for you - what kind of system do you have (HW/OS - Raspberry Pi 4? Raspbian?)
I understood that in your case adding /run/dbus volume was enough to get rid of startup error for Bluetooth integration in HA?
Thanks!

6

Well, after multiple restarts (including the whole Pi) it started working also for me.

This command might be also helpful (although I am not sure did it have any influence in my case):

sudo systemctl restart bluetooth.service

Now dbus socket is visible in the container, as expected:
image

7

I’m glad yours is working now :slight_smile:
I use a Raspberry Pi 4 with Raspbian.
I know a ‘reasonable’ amount about docker-compose and Docker, but I don’t often have to translate Docker-specific options to docker-compose like this. It’s obvious enough when you know (-v is for volume), but I’m still getting used to that kind of thing without examples.

1 Like
8

Just to elaborate on what is happening here, merely running restart only restarts the existing container. Thus, even though home-assistant restarts, the container is the same. Thus, your new docker configuration is not parsed or applied. For this, a new container must be created. With the docker command you would take it down and back up. But with docker-compose up, it is smart enough to determine which containers have config changes and recreate those ones and bring them back up.

1 Like
9

In case anyone stumbles upon this thread trying to solve bluetooth issues.
If you run HA containers in docker rootless mode, dbus doesn’t seem to be working.
so try running HA with sudo docker compose up
This is what led me on the right path: Docker: Unable to Setup Bluetooth/D-Bus - #8 by Levantha

/etc/subuid and /etc/subgid are files based on which docker remaps user and group ids, but more importantly my guess the root cause is this:

Rootless mode does not use binaries with SETUID bits or file capabilities, except newuidmap and newgidmap, which are needed to allow multiple UIDs/GIDs to be used in the user namespace.
Rootless mode | Docker Docs

2 Likes
10

This worked for me, previously I couldn’t see any files in /run/dbus in the container.

11

I was strugging to get bluetooth working with HomeAssistant for ages until I found this thread and got it working with sudo (thanks @eff917 !). However I wasn’t satisfied running as sudo and wanted to find a solution which meant I could use my normal user.

I used the docker compose file from the “Getting Started” guide, and left privileged: true, network_mode: host, and the volume bind /run/dbus:/run/dbus:ro as suggested. To get the host network to function, I had to turn it on in Docker Desktop.

However even with this, I still had issues. On the host, /run/dbus contained a file called system_bus_socket, but when I looked /run/dbus inside the container it was empty! I think that AppArmor was blocking access, or at least when I created a custom apparmor profile it solved the problem. I added a fle called docker-homeassistant to the /etc/apparmor.d directory with the content:

profile docker-homeassistant flags=(attach_disconnected) {
    # Allow reading from D-Bus
    /run/dbus/** r,
    # Allow reading from Bluetooth files, not sure if this is necessary
    /var/run/dbus/** r,
}

I then loaded this profile:

sudo apparmor_parser -r /etc/apparmor.d/docker-homeassistant

To get the docker container to use this profile, I needed to add it to the docker compose service, like this:

    security_opt:
      - apparmor=docker-homeassistant

Hope this helps somebody - spent hours going around in circles until I found this thread!

My setup:

  • HP EliteDesk 800 G4 Mini
  • Ubuntu 24.04.1
  • Docker Engine 27.5.1
  • HomeAssistant 2025.1.4