Bluetooth binding 3.0.0, OpenHAB3, docker, RPi4

I’m on a RPi 4, 2mb memory - just migrating from openhab 2.5.9 to openhab 3.0.0 and switching from a openhabian based setup to a docker based setup.

I started rebuilding from scratch (switching from a file based setup to a setup configured within the web interface) and I’m on RaspiOS lite: 2021-01-11-raspios-buster-armhf-lite.zip, and Docker version 20.10.2, build 2291f61 - Openhab3 image is pulled as the latest from docker hub.

Openhab 3.0.0 docker image works fine, is configured to run in network mode “host”, wifi devices is found by the correct bindings, zwave and zigbee usb sticks working fine after adding the USB devices to the container

But I have not found any working way of making the Rpi’s built-in bluetooth work - I’ve also tried with the cotainer in privileged mode.

running “hcitool dev” at the host returns the mac address of hci0
There’s no hcitool inside the openhab image from docker hub

I’ve be trying to add a bluetooth bridge as “Bluetooth BlueZ adapter” - manually specifying the MAC adress retrieved from “hcitool dev” at the host, but always get communication error.
I have the same problem when trying to do the same in a docker image of “openhab 2.5.9”

Anyone know how to solve this issue? - I’m already running the container in “host” mode, and privileged mode does not make any difference.

Regards

Maybe you can get it working if you first install the bluez package into the container.

That’s the package providing that command, see:

https://packages.debian.org/search?searchon=contents&keywords=hcitool&mode=path&suite=stable&arch=any

It’s 70+ MB so probably not a good idea to install by default into the container for everyone.

You can add a script to install it on startup, or create your own image based on the openHAB images so it is installed. :slight_smile:

I can install bluez and bluetooth into the container with

apt install bluez bluetooth

and after that scanning devices from the shell inside the container works fine, eg

hcitool lescan

But seems like DBus is missing inside the container for bluetooth binding to work

2021-01-30 11:47:52.999 [WARN ] [th.bluez.internal.BlueZBridgeHandler] - Unknown exception
java.util.concurrent.CompletionException: org.freedesktop.dbus.exceptions.DBusException: Failed to connect to bus: No such file or directory
at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331) ~[?:?]
at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346) ~[?:?]
at java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1063) ~[?:?]
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) ~[?:?]
at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) ~[?:?]
at org.openhab.binding.bluetooth.util.RetryFuture$CallableTask.run(RetryFuture.java:76) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]

Maybe you can try this approach:

It seems to be an issue with a lot of info on this topic. :slight_smile:

For accessing bluez, openhab seems to rely on dbus.
So you need to have a dbus deamon accessible for openhab.
Instead of setting up dbus within docker i just mounted another volume to my container.

/var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket

Maybe this works for you

Hi I have try to configure the container like indicated:

But I have the same problem.
By openhab I can’t able to use bluetooth

The error is:
org.freedesktop.dbus.exceptions.DBusException: Failed to connect to bus: Failed to auth*emphasized

Here the docker configuration:

sudo docker run --name openhab
-v /etc/localtime:/etc/localtime:ro
-v /etc/timezone:/etc/timezone:ro
-v /opt/openhab/conf:/openhab/conf
-v /opt/openhab/userdata:/openhab/userdata
-v /opt/openhab/addons:/openhab/addons
-v /etc/firmware/:/etc/firmware/:ro
-v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket
-d
–privileged
–network=host
–restart=unless-stopped
openhab/openhab

I haven’t solved this yet …

Isn’t bluetooth stuff based on dbus binding to bluez objects? If so it should be sufficient to mount dbus socket within docker.

I’ve tried to bind /var/run/dbus/system_bus_socket to /var/run/dbus/system_bus_socket inside the container (rw mode) and also running the container in privileged mode - still I’m not able to use bluez and the pi4s native BT adapter - i’ve even tried installing bluez inside the conatiner in my previous attempts to make this work…

I was able to get Bluetooth “working” in my Docker-based OH3.2.M4 in my Pi4 and its built-in bluetooth functionality with the following steps.

  1. Add to your docker-compose the path to the system_bus_socket and the other devices listed below. Note that in pi4 host the path for system_bus_socket differs from what it needs to be in the container as in the container there is no /var. The necessary additions in my docker-compose:
    privileged: true
    devices:
      - "/var/run/dbus/system_bus_socket:/run/dbus/system_bus_socket:rwm"
      - "/dev/ttyAMA0:/dev/ttyAMA0"
      - "/dev/vcio:/dev/vcio"
  1. Launch the container with “docker-compose up -d” and then go inside the container (of course, this approach is for debugging purposes only and absolutely not suitable for production) by executing:

docker exec -it pi_openhab_1 /bin/bash

  1. Once in the container, run the following:
        apt-get update && apt-get install -y bluez bluetooth
        service dbus start
        bluetoothd &
  1. Exit the container and stop+start the container without deleting the container in the middle:
docker-compose stop
docker-compose start
  1. Then, go - again - into the container and run:
        service dbus start
        bluetoothd &

I had to run the following in the host so that BT would be working in the container:

    sudo killall -9 bluetoothd
  1. Add the Bluetooth-binding in OH and then the Bluez-binding. Then set the address for the Bluez-binding. After this step, the binding should work and you should find the Ruuvi.tags inside the inbox.

Note: the steps listed above I took just to demonstrate to myself if I could get BT working in the openhab container. Obviously, these steps are not a sustainable approach for anyone to really use BT in their openhab container.

What then would be the best option to enable BT support in the docker-based OH3 for pi4? Adding the dbus + bluetoothd to the image and enable them at startup? Or let everyone solve it themselves by everyone creating their own image? The former would lower down the barrier for ppl to use BT in the docker-based OH, I think. The latter requires a bit of extra steps but it should - afaik - provide a properly working solution.

1 Like

Still not working for me. On OpenHAB3.1 - latest stable from DockerHub
My PI4s hci0 device is found inside the container, and I get the MAC adr by running

hcitool dev

The mac returned is exact the same inside the container as on the host (so far so good).
I’ve killed the bluetooth daemon on the host. Inside the container openhab still returns error: offline -
COMMUNICATION_ERROR: Native adapter could not be found for address ‘DC:xx:xx:xx:xx:xx’

I’ve restartet the container several times - logged into it and manually startet dbus and bluez (bluetoothd) inside the container after stop/starting the stack in which it resides.

I’ve given up on making the PI’s native bluetooth adapter working inside the openhab container

Maybe this could be a timing issue: your openhab in the container starts before your bluez and bluetoothd are started and maybe the running OH cannot then understand the bluez and bluetoothd being available?

I tried my previously documented hack again yesterday, with the latest stable 3.2.0. I was able to make it work actually on just one go: I started the new 3.2.0 container, immediately went into the container and ran the bluez + bluetooth installation and startup as described above. At this point, I guess, my openhab was still starting. Once I went to the OH GUI, the bluetooth binding was still initializing but started soon successfully. So, in my last test I did not need to do the “exit container, stop it, start it again” hack at all to get BT working.

You’re right - it could be a timing issue and probably is in my case. I’ll try it again.

I had the same BlueZ COMMUNICATION_ERROR, in my case I managed to move further and have BlueZ adapter working by changing OH version from 3.1 to 3.2

Hi guys, just migrated from OH 2.5 to OH 3 and previously I had Bluetooth working and now I am unable to discover any devices and my presence scenarios have stopped working. I can see the adapters online but can’t discover any Bluetooth devices. See below, I think I am very close of finding the devices but have lost track and no idea what to do next.

Hi Henrik

Did you get it running? I am on version 3.3.0 in a container, running on RPi4 and had no luck so far, trying to follow some of the above hints.

/Karsten