Container can´t access serial Interface to establish BLE Device Resets.

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"]
version: '2.1'
networks: {}
volumes:
  resin-data: {}
services:
  tower:
    build:
      context: .
    privileged: true
    tty: true
    restart: always
    network_mode: host
    volumes:
      - 'resin-data:/data'
    command: -h 172.16.10.13 --debug
    devices:
      - '/dev/ttyAMA0:/dev/ttyAMA0'
    labels:
      io.resin.features.kernel-modules: '1'
      io.resin.features.firmware: '1'
      io.resin.features.dbus: '1'
      io.resin.features.supervisor-api: '1'
      io.resin.features.resin-api: '1'
    cap_add:
      - SYS_RAWIO
      - NET_ADMIN
  hostname:
    build: ./hostname/
    restart: no                               # Required to avoid container restarting indefinitely
    labels:
      io.balena.features.supervisor-api: 1    # Required to interact with the supervisor

I already run out of ideas, maybe we are missing just a small part of it.

Feel free to ask questions, ill give my best to answer all of them.:smiley:

Best Regards
(This is a Repost with the right account, hopefully we get some help here,…)

Hi there - can you try setting your dtoverlay, and retrying, please?

I2C and Other Interfaces - Balena Documentation

Hi,

thanks for the advice i am currently trying to set “pi3-miniuart-bt” in the configuration page of the fleet.

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.

What can i do to further analyze this problem?

Do you have another idea, how to solve the problem? Or how to debug it effectivly?

Hi @phil-d-wilson

As mentioned here: Communicating over UART0 with HCI uart BLE dongle (cross post) - #11 by mdcraver
i now added minuart-bt=on to the dt_overlay configuration

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”

root      1696  0.0  0.0   1524    88 ?        S    11:26   0:00 /usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow - b8:27:eb:43:ff:18

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

Hi,
i granted support access for one week and hope that at least somebody could have a look into this behavior/ situation.

Still looking forward to use balenaOS + balena.io for our fleet

Hello @Markus.Kohn.GWA first of all apologizes for the long delay answering your message.

could you please share over direct message your device ID so we can take a look into your device?

Thanks!

1 Like

Hi @mpous, no problem things take time to do. We all know that tickets and tasks are always there to be done.

Thank you very much for answering, i will send you the device id now via DM.

:slight_smile:

1 Like

Let me check this with the team and get back to you with a better answer @Markus.Kohn.GWA

Of cource, if you need anything else, just let me know. I will do everything to solve my problems here.

Good luck and again Thank you guys!

Hi there, are there any updates so far? @mpous

Hi,

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

2 Likes

Hi,

Thank you @mtoman for your for your investigation!

this sounds pretty much like what we already expected, what balenaOS is doing there.

I´ll Come back after I tried what you mentioned.

Best Regards :blush: