• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bluetooth
#1
Hello,

I try to use bluetooth functions in a debian container. For this I used the Image hilschernetpi/netpi-bluetooth and followed the instructions described on this site: https://github.com/Hilscher/netPI-blueto.../README.md.
After I have started the container I can use bluetoothctl, but it doesn't find any devices. With a normal raspberry pi and bluetoothctl I can find all bluetooth devices. Any ideas?

Thanks in advance,

Jonas
  Reply
#2
Hello,

I saw on my device the issue that the bluetooth could not used from a container which starts at device start up. If I restart the container, it could use the bluetooth device. I used the hilschernetpi/netpi-bluetooth:latest Image for my container.

In the Logs from the Container I saw the following messages:

After startup:
2018-04-19T14:53:50.847929090Z Initialization timed out.
2018-04-19T14:53:50.938205340Z Can't get device info: No such device
After restart from the container:
2018-04-19T14:55:57.756145761Z Can't get device info: No such device
2018-04-19T14:56:09.631514767Z Patch not found, continue anyway


Maybe it is on your side the same issue? Is it possible to get that working directly at power up?

Best Regards
Patrick Bulach
  Reply
#3
Well this needs investigation. The bluetooth container is one of the oldest container we ever made. I had a user Thomas using it intensively and providing valueable information in november 2017 here https://www.netiot.com/de/forum/?tx_typo...10f134f8ae

He got everything work with bluez 5.47 and his arm watch device.

But since all our containers are built automatically based on every update cycle of the os tree used (debian:jessie in case of the bluetooth container) I cannot exclude that something has changed in the os tree meanwhile that leads to a malfunction maybe.

Basically there are no known issues. Important is to set privileged mode to "on" and the network to "host" state when the containers is started. Else bluetooth in a container does not work in all cases. Since netPI shares Wifi and bluetooth in one antenna and chip there shouldn't be a hardware issue.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#4
Hello Armin,

for my issue the bluetooth is working after a restart from a container.

Do you have there some hint how it could also work at system start up?
Some workaround idea to restart the container somehow automatically after startup?

Best Regards
Patrick Bulach
  Reply
#5
Hi Patrick,

to be honest this would be the very first time I heard of that a container and its applications installed do not start right after a system boot. This would raise Docker to question if there would be such a basic error.

If you dig deeper into Docker technology you see that all application threads and daemons started in a container are 100% threads in the host linux. So there are no differences who is starting them and I really would wonder why this would happen now with the bluetooth daemon. I have not tested it myself yet on a netPI.

What I can say is that the provided example bluetooth container runs fine on a standard raspberry Pi 3 I have right in front of me. So there is no software problem at all. Also netPI is 100% the same circuit as an original Pi 3, so it can be a hardware issue.

Since the bluetooth container allows you to login from remote using putty what happens in your container when it didn't activate bluetooth and you login with root:root and call "bluetoothctl" in in the shell "scan on". Does it start to scan and output the found bluetooth devices on your console?

Give me time tomorrow to make checks with a netPI and then we will see.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#6
Restarting a running container cannot be triggered from a software that is running in a container. There is no access to this interface possible.

So my answer is: bluetooth must run from the beginning and I will tell you results tomorrow after I have investigated this issue on my netPI.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#7
Hello Armin,

My experience is from the netPi. I could show it to you very fast with e.g. teamviewer.

After system restart it will not find the device on the container. After container restart it will find it. (as mentioned also before)

I hope that we will find a way to get that working, or we get a problem on our project. (It is not a solution to restart container on ever device by hand after a power loss. I have not found
a way to controle the docker without the portainer.io - that it could be maybe controlled from a server.)

Best Regards
Patrick Bulach
  Reply
#8
Well Patrick,

after watching the source code again after 6 month I am pretty sure that I know what the problem comes from.

When raspberry circuitry is powered then of course the main CPU starts operating and is booting from SD card. But what you must know is that there is a second chip responsible for bluetooth called BCM43xx processor. This chip does not have any firmware after a power on.

If now the container is started the first time when netPI is fresh then the containers task is to load the bluetooth firmware into the chip using the command "hciattach /dev/ttyAMA0 bcm43xx 921600 noflow" located in the entrypoint.sh file.

My interpretation is that the hciattach command returns after having loaded the bluetooth firmware and the script continues to run ... and failes because there is no script code waiting for the bluetooth chip to start the firmware.

And later if you start the container a second time then the bluetooth chip is already loaded and needs no firmware and everything works fine.

So the task is now to find a parameter in the hciattach command to wait for chip initialization or to use any other command to make sure the bluetooth chip is ready.

Armin


You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#9
I investigated the potential problem but I am not able to reproduce any malfunction.

Just to synchronize ... I am using the latest netPI software V1.1.2.0 you can download from the web site's download section.

So what have I done? I started the container hilschernetpi/netpi-bluetooth:latest with network = host and privileged mode = on and device = /dev/ttyAMA0 mapped. Then I shutdown the device and repowered it, so that the it comes up from a fresh boot.

When Docker was ready back I watched the embedded log entry in the Docker web GUI. You can get to this log window yourself, if you click the container name in the running container list and then click as next to "!Logs".

There I can see the following

starting ssh ...
starting dbus ...
Starting OpenBSD Secure Shell server: sshdStarting system message bus: dbus.
init
Set Controller UART speed to 921600 bit/s
Flash firmware /etc/firmware/BCM43430A1.hcd
Set Controller UART speed to 921600 bit/s
Device setup complete

This log is the output of a console if you would run the container on a standard Raspberry Pi 3 and very helpful, cause netPI has no console due to the web based handling.

As next there is another click you can do once you clicked on the container name in the container list. It is the option ">_ Console". With this option you can immediately jump into the container and run a web based console.
In this console I did call bluetoothctl and a scan on on after the other and the device immediately starts scanning:

root@NTB827EB237AC1:/# bluetoothctl
[NEW] Controller B8:27:EB:89Big Grin0:6B BlueZ 5.47 [default]
[bluetooth]# scan on
[NEW] Device 7B:0F:C7:3A:06:AF 7B-0F-C7-3A-06-AF
[NEW] Device 00:1A:E8:2F:75:38 OpenStage 00:1A:E8:2F:75:38
[NEW] Device 58:3D:19:81:CC:12 58-3D-19-81-CC-12
Agent registered
Discovery started
[CHG] Device C8:F7:33:C6:B0:A0 RSSI: -70
[bluetooth]#


So I am sorry, I am not able to reproduce any problem.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#10
Hello Armin,

thanks for your response. We updated the netPI (it was 1.1.0.0 before) and load the container again, now it look likes to work directly after power up.

Thank you and a nice weekend.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Bluetooth testing DSongra 6 3,532 April-29th-2021, 06:08 AM
Last Post: DSongra
  HilscherAutomation / netPI-bluetooth entrypoint.sh error bbaskii 6 4,179 September-14th-2020, 04:42 PM
Last Post: bbaskii
  Bluetooth Access MGharat 10 8,539 February-25th-2020, 12:58 PM
Last Post: DSongra
  [SOLVED] Bluetooth Functions Jonas.Sellmann@outlook.de 4 3,577 September-21st-2018, 11:16 AM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 4 Guest(s)