The other requirements mentioned in the Bluetooth section of the documentation are also met:
bluez 5.55 is installed
D-Bus implementation is dbus-broker 26
Kernel version is 6.1.21
Inside the container, I also get some strange output:
# bluetoothctl
Waiting to connect to bluetoothd...dbus[166]: 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)
As mentioned in the original post, my Docker command contains all arguments that you mentioned. However, neither --privileged nor --net=host changed anything.
@Levantha perchance … have you resolved this issue? I’m just curious, as I’d like to get ahead of any issues. and because i need to understand more about how docker integrates with dbus/device.
are the dbus events being sent with username or UID to authenticate? i’m not sure how to check this. according to dbus-broker wiki’s comparison, dbus-daemon allows both username & UID.
i may need to run a GUI application with docker soon (and with device integration), so i need to know if dbus-broker may cause problems.
# 78012: a related bluetooth and home-assistant issue where dbus-broker is mentioned
I haven’t logged into this forum before, so I may not remember to check again after a day or two. but if you happen to respond, then thanks!
I am sorry, but to be honest, I kind of gave up after nobody seemed to have a solution. After upgrading to Debian bullseye I planned to give it another try, but did not find the time yet.
You can test with —net= host just to see if this is related. I get conflicting info about whether this may cause problems. Another user specifically said it helped while others say it shouldn’t matter.
If host networking works please report back and I have other suggestions
You can test with —net= host just to see if this is related.
As written in my original post, I already tried that option. Just now I repeated the tests with the current version of Debian Bookworm on the Raspberry Pi as well as the latest stable version of HA. Unfortunately I get the same errors, down to the line number.
I finally found the solution. During my first tests I created /etc/subuid and /etc/subgid, mapping the pi user of the host system. After removing both files, everything works as expected.