I can’t seem to get bluetooth working with HA, and I’m running into some errors. I’m running HA 0.99.3 in docker on a custom build computer with Ubuntu Server 18.04. I have set network_mode to host and just to be sure gave the container privileged access.
The logs return the following even though I’m actively searchinig for bluetooth devices on my phone:
2019-10-06 17:57:31 WARNING (SyncWorker_8) [homeassistant.components.bluetooth_le_tracker.device_tracker] No Bluetooth LE devices to track!
2019-10-06 17:57:31 ERROR (MainThread) [homeassistant.components.device_tracker] Error setting up platform legacy
When I’m trying to run bluetoothctl inside my container I get the following errors:
user@ubuntuserver:~/apps$ sudo docker exec -it home-assistant /bin/bash
bash-5.0# bluetoothctl
dbus[149]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5905.
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.0#
No idea what this really means. Both the host and the container have bluetoothctl version 5.50.
I can see how this might not be related to HA, but I’m hoping to get some help for my specific situation.
Yes I have. Decided to take another look a week later. I would’ve posted the solution if I hadn’t forgot about this topic.
I can’t find the exact solution, but I know a simple restart of the Bluetooth driver on the host (I’m using docker) solved it. I believe it was something like
sudo systemctl restart bluetooth
Im not behind my PC at the moment, but if this doesn’t work I’ll try to find the page I got this from later today.
That’s very unfortunate @antoniomolram. I know this won’t answer any questions specific to this issue, but in the end I thought it worked wonky at best and I knew I would run into limitations of the built-in Blueooth soon enough. So after my last post I switched to monitor with 2 separate Raspberry Pi Zero’s. These are cheap and have low power usage. It’s a bit of a learning curve, but once you get the hang of it it’s pretty accurate. Especially comfortable with a Bluetooth tracker like the Nut Tracker 2 which I’m using.
I did exactly the same as @Rourke - got fed up of the internal bluetooth integration not working and switched to monitor - this had the added advantage that I can now put a second monitor device upstairs which eliminates dropouts due to range issues.
Same thing here, I tried compiling bluez from source to no avail, I tried bluez 5.58 that comes with the latest docker and the latest bluez version 5.63 and neither worked. Mind that if you try compiling 5.58 on latest Ubuntu you have to adjust profiles/audio/media.c:1284 rename pause to anything else like bluez_media_pause and on 1334 do the same with the right-hand side, I got this from a maintainer’s commit.
I think I’ll just wait until new docker images come up with newer bluez drivers and that can potentially fix the issue. I tried removing my camera integration too and it didn’t help.
Has anyone found actual solution and root cause for this problem?
I’m having this same problem when I try to passthrough my bluetooth module to my HA docker container. I’ve tried every possible solution suggested in this thread.
I had the same problem and followed this advice, which did seem to fix it. I didn’t install BlueZ (Step 3) because I don’t think that was needed on my Debian machine as it already has a working bluetooth stack or at least it responds to commands like bluetoothctl already.
My casual interpretation is that bluetooth uses the dbus, but that requires privileged access and hence is not easily made available to a Docker container. Somehow installing dbus-broker gets around this restriction, but I’m not completely clear whether it replaces or complements the existing dbus service.