Long story short, shortly after releasing RuuviBridge: a RuuviCollector replacement with Home Assistant support for Gateway users I got asked (by multiple people) whether there is a way to use RuuviBridge without the actual gateway, allowing one to replace the rather heavy and aged RuuviCollector, so here it is: ruuvi-go-gateway, a software replica of the physical Ruuvi Gateway, which will allow you to use 3rd party software and tools designed for the Ruuvi Gateway without actually having a gateway.
Do note that this software implementation of the gateway does not provide any of the “serverless” or “cloud” features available to owners of a physical Ruuvi Gateway, this software only supports the “3rd party MQTT or HTTP POST” features.
I don’t own a Zero W so I can’t verify with that, but at least on Raspberry Pi 3B the builtin bluetooth adapter is behind /dev/ttyAMA0 device, so this might probably work on Zero W as well:
Had no luck with this. I don’t know is the device the issue or some kind of configuration error. Container is just in a restart loop, status seems always be “restarting(139)” and can’t really debug anything as I cannot figure out any way to access any log files with this status. BT-adapter device index is 0 on RasPi itself and configured so.
I just realized the Raspberry Pi Zero W has an ARMv6 CPU (like the very original Raspberry Pi), which is likely the issue here, since I don’t provide ARMv6 compatible docker images or binaries, since I have no hardware that old to test it on.
You might get it working if you build the docker image yourself on the Pi, for example:
git clone git@github.com:Scrin/ruuvi-go-gateway.git
cd ruuvi-go-gateway
docker build -t ruuvi-go-gateway .
and then use the locally built ruuvi-go-gateway image instead of the prebuilt one: ghcr.io/scrin/ruuvi-go-gateway
Using docker simplifies the deployment, since it removes the need of “installing” the software and its dependencies (if any) on the host system, and removes the need to setting up service scripts or other mechanisms to run it. Likewise uninstalling happens by just deleting the container, without needing to remove any installed files from all around the host system.
On top of that it offers increased compatibility and security to some extent, since the software in question runs in its own sandbox environment which includes any dependencies (if any). This is different from using a virtual machine, as the overhead for a docker container is practically zero, unlike virtual machines which run an entire operating system for each instance
I was using docker to keep the device os-image as clean as possible and not having to worry about dependencies, especially battles with different versions of python on same os are sometimes frustrating. Scrin had better answer than I anyway.
Thank you really much for the answer and actually this gave me the last kick to abandon the platform for this project and I decided to go ESP32 way in this project leaving the RasPi for some other project, or not.