Some time back, I found a nice little python script that listens for bluetooth information from a number of Medisana body (fat) bathroom scale and passes the information (weight, fat, bone mass, etc) over to various plugins for further processing (e.g. via MQTT) to openHAB.
The installation of this script, however, is a bit tricky (I once wrote a tutorial here). Plus, it’s not that nice that, even though almost all crucial home automation software can be deployed via Docker, this one needs to be installed manually. So I wanted to containerize the script.
Starting some days back, I tried to bring this script into a Docker container. I’m not a pro in this, so it took me a while to get the basics right (ChatGPT is great for things like that). Even though I managed to create a container that can e.g. run bluetoothctl
from within the container (so Bluetooth via a container can work), I failed miserably to get the entire script running (not even test the bluetooth connection).
Now before I go into the details (why things aren’t working) is there anyone out there who has experience with that and can assist, and maybe letting me know whether I’m going into the right direction? The script is quite nice, and it would be nice making it available more easily.
Backup: The challenges I’m facing (summed up by chatGPT which assisted me along the way)
Bluetooth Hardware Access and Management:
- The BS440 script (and pygatt) tries to manage Bluetooth (e.g., using
sudo btmgmt le on
andsystemctl restart bluetooth
), which works great if installed natively on the host system but fails in a container lacking a full init system.
Systemd and Init System Challenges:
- Running a minimal container (e.g., based on
python:3.9-slim
ordebian:bullseye-slim
) without systemd causes errors like “System has not been booted with systemd as init system.” - Pygatt’s backend (via
adapter.start()
) triggers system-level commands that expect systemd and the Bluetooth management socket, resulting in errors such as “Unable to open mgmt_socket” and “Can’t open HCI socket.”
Cgroup and Filesystem Mount Issues:
- Mounting the host’s
/sys/fs/cgroup
as read-only prevents systemd from creating the necessary control groups (e.g.,/init.scope
), causing systemd to exit with code 255.
Debugging Difficulties:
- Attempts to run systemd in interactive debug mode revealed that the chosen base image sometimes lacked the expected binary paths (e.g.,
/sbin/init
vs./lib/systemd/systemd
). - When running interactively, tools like
journalctl
or evenps
were missing or not working as expected, complicating the debugging process.