Yes the user id 998 maps to the host user ‘homeassistant’ who is a member of the bluetooth group and can access hci0 in the host environment. In the docker, as user homeassistant, I get this when running bluetoothctl:
bash-5.1$ id
uid=998(homeassistant) gid=998(homeassistant) groups=998(homeassistant)
bash-5.1$ ls /run/dbus
system_bus_socket
bash-5.1$ bluetoothctl
Waiting to connect to bluetoothd...dbus[179]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5921.
This is normally a bug in some application using the D-Bus library.
D-Bus not compiled with backtrace support so unable to print a backtrace
Aborted (core dumped)
bash-5.1$
Still going at this - I think there must be a problem between differing versions of bluez on the host and container. Here is the container:
bash-5.1# cat /etc/*ease
3.16.0
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.16.0
PRETTY_NAME="Alpine Linux v3.16"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
bash-5.1# hcitool dev
Devices:
hci0 B4:D5:BD:F4:D0:34
bash-5.1# bluetoothctl --version
bluetoothctl: 5.65
bash-5.1# bluetoothctl
Waiting to connect to bluetoothd...dbus[182]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5921.
This is normally a bug in some application using the D-Bus library.
D-Bus not compiled with backtrace support so unable to print a backtrace
Aborted (core dumped)
bash-5.1#
Going round in circles!! So after a break, some more testing. It isn’t anything to do with bluez versions. I have bluez 5.65 in the container and 5.48 on the host. As soon as I enable privileged mode for the container, bluetooth works (with HA running in a virtual environment as a standard user within the container). Without it, bluetooth fails, even with the added capabilities (NET_RAW_, NET_ADMIN and SYS_ADMIN) applied to the docker and the python binary in the container.
I’m having this exact issues, Ubuntu Intel NUC 10, i’m getting the same errors from the container (dbus exposed via a volume), host is fully functional. I think you’re right feels like a permissions issue at this point.
Edit: Are you running your container in Privileged mode?
Have you found out the solution for the problem? I have the same exact versions of bluez like you but also the same issues. privileged mode works fine but don’t really wanna run it on that 247.
The solution I thought I had was to use an esphome Bluetooth proxy, but unfortunately even that isn’t working properly yet. Still some way to go before home assistant and Bluetooth work smoothly for me at least.
!!Disclaimer!!
I’ve been sitting on this problem the whole day, and I tried a ton of things which I have no idea of and never restarted the host system (my server) so it might have been something else, but I highly think it is this one,
I wish you success
!!Disclaimer!!
Okay Okay, I found the solution for me!!! without privilied. It’s the dbus broker.
The Bluetooth Doc in HA doc also hints to it. You need to install that on the host and restart the host. I used following commands on my Ubuntu 22 server
Restart the System and the Bluetooth Dev instantly showed up in HA.
Make sure you did the obvious things like rounting your /run/dbus and network set to host.
I have tried this on Ubuntu 18.04 and no joy. dbus broker is running fine and I can use the bluetooth device on the host, just not in the container. I wonder if it is something that 20.04 or even 22.04 has improved?
I had a hell of a time getting the ASUS USB-BT500 working in a Home Assistant docker container, but I got it. This is going to be less of guide and more of a list of the crap I threw at the wall to get it to work.
Grabbed the driver from ASUS’s site, unzipped, and followed the directions to install, notably sudo make install INTERFACE=usb
bluetoothctl would work on the host machine, but in the container I’d get
arguments to dbus_connection_get_object_path_data() were incorrect
...
Aborted (core dumped)
lsusb was able to list the bus and device of the bt500. which I added to the docker-compose.
which then brought it all to life and bluetoothctl shows up the controller and I can scan and see devices finer.
In HA however bluetoothctl just dies with the
Waiting to connect to bluetoothd...dbus[329]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5969.
This is normally a bug in some application using the D-Bus library.
D-Bus not compiled with backtrace support so unable to print a backtrace
Aborted (core dumped)
error
I have mapped through /run/dbus and attempted lots of different approaches at mapping the device, (It doesn’t seem be a tty device but I can get the USB details from lsusb. The major device type shows up as 189 rather than 188 for a standard device and I can see locally that there is a symlink from /dev/char/189:2 to /dev//bus/usb/001/003 (which is what shows up with lsusb)
The Linux docs have major type 189 down as
189 char USB serial converters - alternate devices
0 = /dev/cuusb0 Callout device for ttyUSB0
1 = /dev/cuusb1 Callout device for ttyUSB1
…
but thhere are not /dev/cuusb* devices listed on the host.
If I run the container in privileged mode then all is fine and HA recognises the device but I don’t want to run in privileged mode…
Tearing my hair out on this. The error is the same if you map no device at all so I am wondering whether I just need to find the magic device name to map across or whether there is something more fundamental I need to try ??? Any ideas???
So today I needed to power down the electricity to do some work. I turned the power back on and when I went into HA and I was surprised to be greeted with a notification the the Bluetooth adapter was found and whether I wanted to configure it. Had to double check that the container didn’t have the privileged flag set.
I think this is down to me running commands on the host and the Bluetooth adapter then being locked to that host so wasn’t accessible to the container. I suspect I probably just needed to do something to release the adapter (I did think I had restarted all the bluetooth stuff) but if anyone else comes across this and has ran out of things to try then restarting to clear everything out might solve it…
This fixed my issue on a Raspberry Pi 4. HA could see my BLE device but would not setup/connect. It connected and worked without issue after installing dbus-broker.