Rtl_433: Official Docker image?

[gcormier]

I've done a search of the open and closed issues here for mention of Docker and couldn't find any discussions.

Would there be any interest in an official Docker image for rtl_433 to run from containers? There could be 2 paths

1. A simple Dockerfile in this repository, such that users could build their own image
2. An additional layer that integrates this repository with dockerhub to automatically build new images when the repository is updated

If there is interest, I am by no means a docker expert, but I could fork and give it a shot and send a PR.

[zuckschwerdt]

rtl_433 itself is simple enough not to warrant a docker image. Basically it just needs a libc. There is a dep on libusb for error messages but that can be optional.
If someone wants a just-deploy-whatever-is-needed docker image it would need to contain librtlsdr and likely SoapySDR, and modules and then a mechanism to configure and run, possibly with supervision and esp. with output routing.
I guess consumers of rtl_433 output can benefit from a custom build. But just rtl_433 in itself? Not sure.

I'd rather offer precompiled static binaries and maybe a deb for, I guess most common, use on a Raspi. The user will need to configure stuff anyway, and that way without setting up e.g routing of MQTT through a network abstraction.

[gcormier]

A docker build brings it into the container ecosystem. My home server is all docker, which includes a home automation ecosystem.

So it inherits all the benefits of docker, including my ability to blow away Ubuntu 20.04 and it's terrible forcing of snap, install another OS, and I have no reconfiguration at all to be done.

With rtl_433 that was broken - first off there is either the building process, or, finding some sort of repository that is up to date. Second, I then need rtl_433 to be able to connect to a MQTT container inside docker which was not being exposed, so I started looking at exposing this container such that the host would talk to it. I'd also need systemd/whatever to handle a crash of rtl_433.. something I've enjoyed not doing in ages 👍🏼

Finally, it brings a single component outside of my perfect sphere of containers, and removes a level of automation I've come to enjoy.

I've got many other images that would not warrant a docker image as you suggested, other than the fact that it bundles them nicely and means I run an entire server from a single docker-compose.yaml :) It's a nice place to be.

[zuckschwerdt]

I'm sure other users want that level of plugable services. At least I've seen such setups recommended. Still we'd need a base image with SDR libs or bring that into the build.

What host and distro is your automation server running? What is your process of bringing configs into containers?

[gcormier]

This is the draft I have so file for my own proof of concept. It creates the base image, then create the rtl433 image.

FROM debian:latest AS debian-build-essentials
WORKDIR /tmp/
RUN apt-get update && apt-get install -y libtool libusb-1.0-0-dev librtlsdr-dev rtl-sdr build-essential autoconf cmake pkg-config libsoapysdr-dev git


FROM debian-build-essentials as rtl433
RUN git clone https://github.com/merbanan/rtl_433.git
WORKDIR ./rtl_433
RUN ./do_build.sh

ENV MQTT_SERVER="" MQTT_PORT="1883" MQTT_USER="" MQTT_PASS=""
# -F "mqtt://localhost:1883,user=USERNAME,pass=PASSWORD,retain=0,devices=rtl_433[/id]"

ENTRYPOINT ["./build/src/rtl_433", "-F", "mqtt://$MQTT_SERVER:${MQTT_PORT},user=${MQTT_USER},pass=${MQTT_PASS},retain=0,devices=rtl_433"]

Then, my docker-compose.yaml file (relevant section)

  rtl433:
    build:
      context: /home/greg/rtl_433
    environment:
     - MQTT_SERVER=homeassistant
     - MQTT_USER=yyyy
     - MQTT_PASS=xxxx

homeassistant is another container running in docker, so within docker, that name will resolve to the proper IP of the container.

[peteakalad]

https://hub.docker.com/r/hertzg/rtl_433 https://github.com/hertzg/rtl_433_docker

Not using it but seems to have most architectures covered and recently updated, probably automated updates

[gcormier]

Indeed, I have found a few out there, but was suggesting this be made more official :)

[gcormier]

This got things going nicely:

FROM debian:latest AS debian-build-essentials
WORKDIR /tmp/
RUN apt-get update && apt-get install -y libtool libusb-1.0-0-dev librtlsdr-dev rtl-sdr build-essential autoconf cmake pkg-config libsoapysdr-dev git


FROM debian-build-essentials as rtl433
RUN git clone https://github.com/merbanan/rtl_433.git
WORKDIR ./rtl_433
RUN ./do_build.sh

ENV MQTT_SERVER="" MQTT_PORT="1883" MQTT_USER="" MQTT_PASS="" MQTT_FILTER=""
# -F "mqtt://localhost:1883,user=USERNAME,pass=PASSWORD,retain=0,devices=rtl_433[/id]"

ENTRYPOINT ./build/src/rtl_433 $MQTT_FILTER -F "mqtt://$MQTT_SERVER:$MQTT_PORT,user=$MQTT_USER,pass=$MQTT_PASS,retain=0"

And my docker-compose.yaml file
rtl433: container_name: rtl433 build: context: /home/greg/rtl_433 environment: - MQTT_SERVER=192.168.1.33 - MQTT_USER=xxx - MQTT_PASS=yyy - MQTT_FILTER=-R 40 devices: - /dev/bus/usb/001/002

[zuckschwerdt]

Looks like you are pulling in packages you don't need and also clutter the image with the whole build environment?

[hertzg]

Hello (maintainer of hertzg/rtl_433_docker here 👋 )
The initial goal was to create a container image of rtl_433 for Raspberry Pi to help the efforts of Home Automation. I could help merging the projects together to add multiarch docker image support to the original repository if you think it would be beneficial @merbanan & maintainers.

@peteakalad Yes you are correct It's automated daily builds of tags and branches (of this repo) based on alpine docker image targeting all architectures supported by alpine image.

[zuckschwerdt]

I'd also be okay with just making your build the recommended "official docker solution". Less bottleneck on our end :)
If you are up to additional challenges, perhaps include SoapySDR and a good set of driver modules (at least rtlsdr,
LMS7, Pluto, sdrplay, hackrf, airspy, remote).

[hertzg]

I have no objections, I would like to have an option to have a very lightweight docker image but we can always create other build flavors targeting the correct combinations.

So far I only have alpine based images dependning on libusb and librtlsdr.
https://github.com/hertzg/rtl_433_docker/blob/fec128d42dae666d2bd06b75b30cbe20ed603b6c/rtl433/Dockerfile#L4-L9
and In runtime
https://github.com/hertzg/rtl_433_docker/blob/fec128d42dae666d2bd06b75b30cbe20ed603b6c/rtl433/Dockerfile#L33

Is there some documentation available to help build images of those flavours?

[gcormier]

I think it's awesome @hertzg is stepping in - as I mentioned I'm a docker noob!

[zuckschwerdt]

I think Alpine has SoapySDR but not any modules. I never had a need to get prebuilt modules, other than on Debian. Is there something like that for alpine? Worst case you could unpack the debs and see if lib deps match the Alpine base.

[hertzg]

SoapySDR seems to have been recently(Build time: 2020-11-23 19:16:28) added to alpine (only available in edge). It will take some time until it moves to next stable release.
It's only building the SoapySDR but not it's modules.

I generally prefer to avoid creating amalgamations (mixing package contents) as they tend to end up not working or flaky and headache to maintain. So far I think there are three ways we could go:

1. Try to support SoapySDR on Alpine one way or another and include it in alpine-* builds of rtl_433
2. Introduce a new debian-* flavor of images which includes both rtlsdr and soapysdr
3. Keep alpine as a base and build soapysdr and it's modules.

The second option has a downside of potentially ending up with different versions of rtlsdr compared to alpine-* flavors.
I will tinker with the first option a bit, but I'm more leaning more towards the 2nd option as it seems to be easier to maintain.
Also there is always the 3rd option but that would broaden the scope.

[gcormier]

While Alpine is much tinier/leaner then Debian, we are still talking 100MB versus 10MB, a trivial size difference by today's standards?

If option 1 is eventually no problem, then whichever of 2 or 3 is easier with the idea is is temporary until alpine has native soapysdr ?