Bug: rtl_433 Alpine:latest code doesn't work on RPi4

[BarryMar]

Hi there.

I've been trying to see if I can get a Nooelec NESDR SMArTee v2 RTL2832U ( https://www.nooelec.com/store/sdr/sdr-receivers/smart/nesdr-smartee.html) to work with rtl_433-hass-addon on my Raspberry PI4 to interpret my LaCrosse Technologies LTV-TH2 Weather Sensor 915 MHz output.

I was able to get good data with rtl_433 on my Mac with code from Homebrew, so I knew it was theoretically possible to do. Unfortunately, every time I tried to use rtl_433-hass-addon it ended immediately in "[cmd] /run.sh exited 1".

Trying the rtl_433 Docker code used by this addon on a straight Raspberry PI 400 with latest Raspberry PI OS 32-bit, the Alpine code would instantly die with an "Assertion failed" error.

According to hertzg/rtl_433_docker#3 this is a known problem with ARM Alpine 3.13 in Latest caused by some stale library code in various distributions. There are two possible solutions:

1. Use the alpine-3.12 version based images (example: hertzg/rtl_433:alpine-3.12-latest)
   

2. Use debian based images (example: hertzg/rtl_433:debian-buster-latest)
   

After I figured out how to get into my real HAOS Root with https://github.com/adamoutler/HassOSConfigurator , I was able to get the code to run properly in this environment with the same command as the P400:

docker run --device /dev/bus/usb/001/003 hertzg/rtl_433:debian -f 915M

I'm still learning the basics of Docker at the moment, so I don't know what's all possible to do with it or how to reconfigure the files from this codebase yet.

Is it possible to make the rtl_433-hass-addon Docker initialization code branch for ARM processors to use the Debian build instead of Latest?

[deviantintegral]

Oy, that's tricky!

It looks like it's not just Alpine, judging by moby/moby#40734

Can you check to see if it still breaks on Alpine 3.14?

To switch to Debian, we'd have to rewrite a good chunk of the Dockerfile, which is fine, but it'd be good to avoid if we can. Also, I would worry that a future update would break things there too. We may have to do that if 3.12 goes out of support. We'd probably want to do it for all architectures, not just armhf.

As a workaround, you should be able to alter the Dockerfile to point to any one of the Alpine images at https://github.com/home-assistant/docker-base.

[BarryMar]

OK, I'll see if I can give it a go in a few days. I'm new to Docker, so there's a lot of stuff I have to figure out about using it.

As an aside, I determined in #24 that the code does in fact work properly in HAOS 64 bit. This particular problem seems to just be a 32bit ARM problem, which means I guess it could affect HAOS32 bit and RPOS Supervised HA installs.

[deviantintegral]

I have a Raspberry Pi 4 as well, but it has the 64 bit version of HAOS on it. Testing any PRs on 32-bit would be a stretch for me right now, but I could verify it doesn't break on x64 and arm64.

I won't likely be driving any changes around this, but I'm glad to review PRs.

[deviantintegral]

Since I wrote the above, I had the opportunity to learn about cross-architecture Docker builds. I was working with arm64, but I think there should be a way to test this without needing a second Raspberry Pi.

[deviantintegral]

I have a Raspberry Pi 4 as well, but it has the 64 bit version of HAOS on it

I totally got this wrong, I actually have 32-bit HAOS installed there. The latest containers have been working fine on that system. My guess is this has been fixed upstream, or fixed by ensuring that all systems pull the same container image. Feel free to reopen if this is still an issue in 0.2.1 or higher. Thanks!