No input driver for SoapySDR compiled in

[nbcomaf]

I'm tearing my hair out trying to get this working. I have two identical RTL2838 dongles, exactly the same as @hertzg - and I've been trying to folllow this post to get two containers working with different frequencies. At first I had the issue of identical serial numbers so changed it on one of them. Now, whatever I try to do will not successfully start the container.

I had a single container working fine but adding the second seems to have messed things up somewhere. I now can't even go back to a single container with the previously working config. And I've tried so many things - I feared I may have somehow busted the dongles but have managed to confirm they are fine and get messages to my MQTT server by using native rtl_433 installed direct on my Ubuntu server.

What I think is the main issue is for some reason using -d :[serial number] in my docker-compose.yaml seems to force the container to try and run as SoapySDR.

rtl_433 version 22.11 (2022-11-19) inputs file rtl_tcp RTL-SDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "//.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
MQTT: Publishing MQTT data to 192.168.1.130 port 1883
MQTT: Publishing device info to MQTT topic "rtl_433/OilSonicWatchman".
[Protocols] Registered 212 out of 246 device decoding protocols [ 1-4 8 10-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-228 230-232 234-241 243-244 246 ]
[sdr_open] No input driver for SoapySDR compiled in.

And my docker-compose.yaml:

rtl_433:
    container_name: rtl_433
    image: ghcr.io/hertzg/rtl_433_docker:master
    user: 1000:1000
    environment:
      - TZ=Europe/London
    volumes:
      - /opt/smarthome/rtl_433:/etc/rtl_433
    devices:
      # - /dev/bus/usb/003/007
      - /dev/bus/usb
    command:
      - '-d :00000002'
      - '-f433.92M'
      - '-Fkv'
      - '-Csi'
      - '-Fmqtt://192.168.1.130:1883,user=XXXX,pass=XXXX,retain=1,devices=rtl_433/OilSonicWatchman'

Things I've tried:

• Modprobe blocklist, or not
• Udev rtl-sdr.rules
• Restarting the server and unplugging/replugging dongles at various times
• Different USB ports
• Setting in config file vs from docker-compose commands
• Different builds including specific version numbers

Can anyone shed some light on what I could maybe try next? I had a single dongle working fine but don't want gaps in my weather station data from a hop interval!

Many thanks in advance.

[hertzg]

Have you tried :master-debian tag?

[nbcomaf]

Yep. I get this:

Actions

      

rtl_433 version 22.11 (2022-11-19) inputs file rtl_tcp RTL-SDR SoapySDR with TLS

Use -h for usage help and see https://triq.org/ for documentation.

Trying conf file at "rtl_433.conf"...

Trying conf file at "//.config/rtl_433/rtl_433.conf"...

Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...

Trying conf file at "/etc/rtl_433/rtl_433.conf"...

MQTT: Publishing MQTT data to 192.168.1.130 port 1883

MQTT: Publishing device info to MQTT topic "rtl_433/OilSonicWatchman".

�������
[Protocols] Registered 212 out of 246 device decoding protocols [ 1-4 8 10-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-228 230-232 234-241 243-244 246 ]

[SoapySDR] avahi_client_new() failed: Daemon not running

[SoapySDR] avahi_client_new() failed: Daemon not running

Failed to create secure directory (//.config/pulse): No such file or directory

RtApiPulse::DeviceInfo pa_context_connect() failed: Connection refused

ALSA lib confmisc.c:855:(parse_card) cannot find card '0'

ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_card_inum returned error: No such file or directory

ALSA lib confmisc.c:422:(snd_func_concat) error evaluating strings

ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory

ALSA lib confmisc.c:1334:(snd_func_refer) error evaluating name

ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory

ALSA lib conf.c:5703:(snd_config_expand) Evaluate error: No such file or directory

ALSA lib control.c:1528:(snd_ctl_open_noupdate) Invalid CTL default

ALSA lib confmisc.c:855:(parse_card) cannot find card '0'

ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_card_inum returned error: No such file or directory

ALSA lib confmisc.c:422:(snd_func_concat) error evaluating strings

ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory

ALSA lib confmisc.c:1334:(snd_func_refer) error evaluating name

ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory

ALSA lib conf.c:5703:(snd_config_expand) Evaluate error: No such file or directory

ALSA lib control.c:1528:(snd_ctl_open_noupdate) Invalid CTL default

[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-5

[ERROR] [UHD] Device discovery error: unknown key format: :00000002

[ERROR] [UHD] Device discovery error: unknown key format: :00000002

[ERROR] [UHD] Device discovery error: unknown key format: :00000002

[ERROR] [UHD] Device discovery error: unknown key format: :00000002

[SoapySDR] rtlsdr_get_device_usb_strings(0) failed

[sdr_open_soapy] Failed to open sdr device matching ' :00000002'.

[hertzg]

If you look closely to the example from my post you linked here, -d:${RTL_SERIAL_433_587}' there's no space after -d in my example. ;)

Closing this as this is not an issue with the image.

[nbcomaf]

Thanks @hertzg but I had noticed that and tried with and without the space too (thinking you may have included a space in your variable and because the command line version requires it).

If I use -d:00000001 I get the following (with both master and master-debian builds):

rtl_433 version 22.11 (2022-11-19) inputs file rtl_tcp RTL-SDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "//.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
MQTT: Publishing MQTT data to 192.168.1.130 port 1883
MQTT: Publishing device info to MQTT topic "rtl_433/833982892f98/devices[/type][/model][/subtype][/channel][/id]".
MQTT: Publishing events info to MQTT topic "rtl_433/833982892f98/events".
MQTT: Publishing states info to MQTT topic "rtl_433/833982892f98/states".
[Protocols] Registered 212 out of 246 device decoding protocols [ 1-4 8 10-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-228 230-232 234-241 243-244 246 ]
[SDR] Could not find device with serial '00000001' (err -3)

If I add the space in (i.e. d :00000001), it seems to find the device ok but wants to force SoapySDR and I get "No input driver for SoapySDR compiled in."

If I then choose master-debian build, I get the 'Failed to open sdr device matching ' :00000001'.

And to be clear, I have been trashing the container each time before retrying, and been as thorough and methodical as I can in trying all things I can think of. (Different USB extension cables, without an extension, with/without config file, removing other USB devices in case it was a power issue etc.)

Seems I can't win and have no idea why the container won't even start at all despite the dongles working fine with rtl_433 with the same config directly run on the host machine.

Do you have any other ideas for me to try, or any other info I can provide which may help to further identify the issue?

[hertzg]

When using docker-compose.yaml you should not use spaces between the parameters and values. When using docker run there you can use spaces, not sure why but it seems to be related to how getopt reads args (total speculation).

I'm not sure how to help here though, I would first start with only one device and a native binary on debian os, try to get it working with your device. I've never had a device that used SoapySDR.

Once you get that working you can try the :debian-* images with docker run in fully privileged mode and one by one start removing permissions.

Depending how far you want to take it then you can try the :alpine-* images to get minimal size containers.

Once you have a working setup with containers for one device then you can try adding second one. That might help uncover more.

I know it's not much but I hope that helps 🙌 cheers! 🍻

[nbcomaf]

Many thanks for your input @hertzg - I very much apprecaite it. I will keep on trying a few things and build up slowly as you suggest to see if I can get some success. I too agree there seems to be some issue with parsing of the arguments, but do not understand why I am experiencing it when there doesn't seem to be anyone else with the issue. Happy for you to keep this issue closed, but if I do discover anything useful I will post back here so you and others can know the details.

[nbcomaf]

I finally got this working. Trial and error over many attempts. The fix was removing the user: 1000:1000 line. No idea why, but with that in the container would always fail to start and complain about the device serial. Remove the user line and it starts fine. I ended up using .conf files for configuration too instead of all in the docker-compose commands.

Not quite got my second device passing through to MQTT yet, but confident I will now the container at least starts. It only updates every 15mins so a pain to test! I know the containters are definitely picking up the device ids fine which is the main thing. Posting in case anyone comes up against a similar issue in the future.

[hertzg]

user: 1000:1000 would cause the rtl433 process to start without root permissions, and that probably does not give access to /dev/tty* serial interfaces. That's why it's probably giving that cryptic error message which might have caused a lot of confusion.

[nbcomaf]

Cryptic and confusing ... yes! Just glad I stuck at it and eventually worked it out. Perhaps this will help someone in future. Ironically, the addition of the user line was a naive attempt to avoid permissions issues! Thanks anyway, and keep up the good work.