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.
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) [?:?]
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.
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.
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:
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
Once in the container, run the following:
apt-get update && apt-get install -y bluez bluetooth
service dbus start
bluetoothd &
Exit the container and stop+start the container without deleting the container in the middle:
docker-compose stop
docker-compose start
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
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.
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.
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.
I’ve got bluetooth working in docker on ubuntu (not RPi), but wanted to document it here in case anyone else runs into this issue.
This article was very helpful.
I wanted to create new docker image based on official image that installs/configures it such that you won’t need to do anything manually. It should be fairly easy to upgrade it when new official image is released:
./Dockerfile:
FROM openhab/openhab:latest
COPY ./openhab.conf /etc/dbus-1/system.d/
COPY ./bluetooth /etc/cont-init.d/
RUN apt-get update && apt-get install -y bluez bluetooth
Pretty straightforward, this uses openhab official images, installs bluez and bluetooth packages and copies some configuration files to make things easier
./openhab.config
<!-- This configuration file specifies the required security policies
for a user to communicate with BlueZ. -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<policy user="openhab">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.bluez.LEAdvertisement1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy>
</busconfig>
This allows docker to run without privileged permissions
./bluetooth
#!/bin/bash -ex
service dbus start
service bluetooth start
# wait for startup of services
msg="Waiting for services to start..."
time=0
echo -n $msg
while [[ "$(pidof start-stop-daemon)" != "" ]]; do
sleep 1
time=$((time + 1))
echo -en "\r$msg $time s"
done
echo -e "\r$msg done! (in $time s)"
# reset bluetooth adapter by restarting it
hciconfig hci0 down
hciconfig hci0 up
This starts up dbus and bluetooth and waits for those services to start. It then restarts the adapter just in case.
Save all 3 of the above files into same directory.
Now to build new docker image as myopenhab run the following in the same directory as Dockerfile
