Hi there,
We are currently evaluating BalenaCloud for our new Device/ Fleet Management. Now we need to dockerize our Application, which itself is easy to dockerize but we got a balena specific problem where you might be able to help us.
We are running on 8 Raspberry Pis and 1 BalenaFin for Testing, another IoT-Gateway will be tested as well in the next few days.
Our Application does need access to /dev/ttyAMA0 to use Bluetooth in our Stack. On our pre-balena Raspbian with docker installed the container can easily access the interface with the --devices flag:
docker run --device=/dev/ttyAMA0 tower -h some.ip.address.here
Using this as our base to deploy our application to balena we figured out the following procedure, which is still not working:
FROM balenalib/armv7hf-debian-openjdk:11-jre-stretch
WORKDIR /app
COPY wiringpi_2.50_armhf.deb wiringpi_2.50_armhf.deb
RUN dpkg -i wiringpi_2.50_armhf.deb
RUN apt-get install bluez
ADD tower.jar tower.jar
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["java","-jar","/app/tower.jar"]
Hi there,
Added the “pi3-miniuart-bt” in device settings > Define DT overlays. But the Console still outputs that the devices could not be managed/ reset which diagnoses a general connectivity issue to the Bluetooth Device.
I recently spoke to my colleague about the current problems. We then looked at the host-os for something that potentially blocks the serial interface and found:
“ps aux | grep hci”
If this service is running, our application won´t be able to use the Bluetooth device over the serial interface.
Is there a way to disable the service starting the hciattach process?
Am i missing further configuration of the device/ dt_overlays or uart specific stuff?
@phil-d-wilson i had a look into your balena-locator repo to match our Dockerfile or find some hints here and there, but because noble uses hci instead of uart this is mostly the wrong path for us.
Nevertheless, i really like your locator project. Clean example to use BLE with Balena!
We are now trying to port our service to use hci as well, but we had major problems in the past with not using uart for our service.
Greetings, Hope i was able to describe my problem good enough though
balenaOS will start bluetoothd on the host OS and the containers are then able to access the bluetooth adapters via DBus API. If your application for any reason needs to talk to the bluetooth adapter directly (or in your case to the serial port directly), you can stop bluetoothd.service and hciuart.service on the host OS, which should unlock the serial port and let you access it. For testing, you can just open a host OS shell, do systemctl stop bluetooth.service and systemctl stop hciuart.service and then restart your application. If that helps, you would need to incorporate the stopping of services into the startup script of your container, since systemctl enable and systemctl disable do not work on balenaOS. Containers can talk to host OS systemd via DBus and we have an example for stopping the bluetooth service in our docs: Communicate outside the container - Balena Documentation