Ruuvi-go-gateway Docker and Home Assistant Bluetooth issue

[Ian]

Hi @Scrin,

I’m hoping you can help. I’ve been using RuuviCollector for years on a Pi Zero W with InfluxDB and Grafana and finally got around to setting up a Pi 4B to run Home Assistant and thought I should move the whole setup over and change to ruuvi-go-gateway and ruuvibridge all in Docker containers.

I started with Home Assistant and got that working and then setup ruuvi-go-gateway and ruuvibridge. Everything was going well (or so I thought) but I hadn’t noticed that ruuvi-go-gateway was stopping bluetooth from working in Home Assistant.

As soon as I start the ruuvi-go-gateway container, Home Assistant stops receiving any bluetooth information. If ruuvi-go-gateway is already started when Home Assistant loads then I get this error:

Raspberry Pi Trading Ltd bcm43438-bt (E4:5F:01:F1:F4:EA)
Failed setup, will retry: hci0 (E4:5F:01:F1:F4:EA): hci0 (E4:5F:01:F1:F4:EA): Failed to start Bluetooth: adapter ‘hci0’ not found; Try power cycling the Bluetooth hardware.

I take it the issue is that ruuvi-go-gateway is having exclusive use of the bluetooth adapter. I am mapping the interface to ruuvi-go-gateway using the following in the Docker compose file:

devices:
- /dev/ttyAMA0:/dev/ttyAMA0

The ruuvi-go-gateway config file is using the default:

HCI device index for the bluetooth adapter to use. 0 by default, which should correspond to the hci0 device
hci_index: 0

Is there something that I’m missing in the Docker config which allows multiple containers to access the same hardware or is this just a limitation and both containers can’t use the same bluetooth adapter?

Would running ruuvi-go-gateway locally (not via Docker) get around this or would it still have the same issue?

I’d rather not have two ‘servers’ on 24 / 7 if I can help it, just for enviromental / power wastage reasons.

Or would an alternative be to try a second bluetooth adapter so Home Assistant can use one and ruuvi-go-gateway can use the other?

I’m a novice when it comes to Docker (this was my first go) so any help / pointers are gratefully recieved.

Thanks

Ian

[Scrin]

Hi,

your assumption is correct, both home assistant and ruuvi-go-gateway want to have direct/exclusive access to the bluetooth adapter to directly scan for broadcasts, which is the “normal way”.

The reason why this was not an issue with RuuviCollector is that RuuviCollector used a really hacky two-step approach to collecting the data, the first step enables scanning on the bluetooth hardware and ignores the result, and the 2nd step is using a rather hacky way to just dump all bluetooth traffic going between the bluetooth adapter and the system (regardless if it’s RuuviCollector or homeassistant that’s currently “scanning”). The most notable downside of this approach was that this was really prone to breakage and bugs when things are updated on the system, and the data would easily become corrupted if anything else on the system was doing anything with bluetooth

The easiest way to have both ruuvi-go-gateway and homeassistant on the same system scanning data at the same is to have two bluetooth adapters, and then configure these to use their own adapters. For ruuvi-go-gateway this is done with the hci_index in the config file and/or the devices: mapping in the compose file when running in docker. I have not tested this but I believe hci_index: 0 will be correct if you map just one bluetooth adapter to the container, even if it’s the 2nd adapter on the actual system

[Ian]

Thanks for the quick response, confirming my assumption and explaining the difference between how RuuviCollector worked and the issues with using that method.

I’ll borrow the USB bluetooth dongle from my main PC and see if I can get that one running for ruuvi-go-gateway and use the internal one for Home Assistant.

I’ll update this thread with my results, in case anyone else runs into this issue.

I appreciate you creating these tools, I’ve found RuuviCollector really useful over the years.

[Ian]

So I have got it working with the second bluetooth adapter.

It seemed there was some inconsistency after reboots as to which adapter ends up as HCI0 and HCI1, so Home Assistant sometimes complains that it can’t initialise the adapter as that’s the one that ruuvi-go-gateway is using. Oddly, even though I am specifically telling ruuvi-go-gateway which adapter it should use (the internal one on the PI) it seems to take more notice of the HCI number as after the reboot it started using the external dongle, even though the docker compose file was specifically stating to use /dev/ttyAMA0.

After a couple of reboots it seems that it has stuck with this configuration although it doesn’t really make sense from what I’ve set up.

Ultimately I’m happy enough that I can get two adapters to work on the computer although I’ve run into another snag. My bathroom ruuvi tag is just on the cusp of being able to be recieved by the raspberry pi so often drops out depending on the time of day. This wasn’t something I was expecting as my raspberry pi zero w has been working flawlessly from the same postion for years.

I was using a FLIRC case for the pi 4 which was part of the problem but even in the official case I’ve had to move it all to rather precarious location (with trailing cables) to get the bathroom tag to appear and that case has increased the temperature that the pi is running at quite a lot. So I am now looking for two external bluetooth dongles with aerials to hopefully negate that problem (I’d disable the internal bluetooth), but with the Sonoff Zigbee USB dongle taking up more space than it should and the USB NVME drive which it is all running off, squeezing them on is going to be interesting. I suspect it will entail extension leads and / or a USB hub, which I’m sure will add some extra fun to proceedings,

Then there’s the small matter of migrating my current data from the influx 1.8 database on the pi zero w to a new one (possibly influxdb 3?) on the pi 4.

It’s quite a lot of effort for pretty graphs