Fortunately, there are raspberry PI examples so it was easy to get started. In short, the example allows the raspberry PI to connect to an Echo device through bluetooth. It can then send events directly. I managed to get this part to run. (This part is written in python)
Next to this, I have software from a previous project. It is written in Nodejs. This project also uses bluetooth (noble) to connect to a different device.
I created containers for both projects and managed to run them both individually. I also managed to run them simultaneously, but I get issues related to Bluetooth. It seems that they are both trying to use the bluetooth adapter, which is somehow conflicting. This is visible from sudden disconnects or failed attempts to connect.
My question is: do you think I can solve this issue by using an external bluetooth adapter (usb). In that case, I can have 1 container use the onboard ble, and the other the adapter, or will this still result in conflicts?
That sounds like a very interesting project! In terms of both Bluetooth containers, I think your suggestion for going with two bluetooth adapters is the best way to go. I don’t think that should result in any conflicts as long as each container is controlling just one of the dongles, but do let us know if you see something strange going on and we’ll take a look!
I just ordered the dongle, so lets see how that works.
To let the one container use the onboard BLE and the other the dongle, I thought I would use the service variables by setting dtoverlay=pi3-disable-ble. Would that work, or would it make both containers switch to the adapter?
I haven’t worked much with Bluetooth myself, but as far as I understand, dtoverlay=pi3-disable-ble will completely disable the Pi 3 internal bluetooth, while what you want to do is probably configure the bluetooth clients running in each container (i.e. BlueZ) to control the relevant devices (see https://wiki.archlinux.org/index.php/Bluetooth)