plugin stops- unable to connect

[agrieco]

Hi,

I've had this wonderful plugin working for a few weeks. It has been working ok, but I have to restart it regularly. Here are the log messages that show up when this happens:

Unable to connect (Lookup error.).
Async read stalled, exiting!
rtlsdr_demod_write_reg failed with -7
r82xx_write: i2c wr failed=-9 reg=06 len=1
Reattached kernel driver

One thing you should know about my setup- I am remotely hosting the USB stick for the RTL on a remote device via usbip. I have a zwave stick on the same remote device and it seems to be fine, so I have no reason to believe that there is connectivity issues between the two devices (they are both on my local LAN).

Anyone seen this issue?

[agrieco]

I realize now after looking at the code, its a case of the rtl_433 executable terminating and this has nothing to do with the plugin. I did “work around it” by putting an outer loop in the script to re-call the rtl_433 binary a configurable number of times....ugly but until I can investigate the root cause- it works ok. Changes of me missing an event are small...but less than ideal for sure.

[slowsauce]

Hi, im having this exact or close to exact problem. im not quite understanding what did you do to fix it. im thinking of setting up an automation to just restart the addon if the mqtt system for my temperature sensors does not update within the defined update period.

[stripeyhorse]

is this in the current code @agrieco , or can someone please share how to automatically restart on crash/error

[messismore]

I had the same issue and changed the addon to restart rtl_433 whenever it crashes. Can you try whether my fork fixes your issue? If so, I'll issue a pull request.

[ZBiener]

@messismore : I tried your adding your fork, but it doesn't look like I'm getting restarts. The add-on still stops reading RF signals after a while. I'm a noob: I'm not sure how to confirm/disconfirm that it is actually starting. Help?

[messismore]

@ZBiener huh that's strange, I haven't had issues since. But I'm still learning Docker so I wouldn't be surprised if I did something dumb. I'll try to look into it but I don't know when that will be…

[ZBiener]

Thanks. I got around things by automating an HA restart of the plugin every few minutes. It's a hack, but works reasonably well. Thanks.

[grouts112]

Also having this same issue.. plugin seems to run for a few minutes then stops.. restarting the plugin kicks it back into life.
How did you automate a plugin restart ?

[ZBiener]

This is the gist. The restart won't happen if an MQTT update happened in the last 3 minutes. But it will check this every 5 minutes.

First, something that catches any MQTT update, in my case it is from a simplisafe sensor:

sensor:
  - platform: mqtt
    name: mqtt_general
    state_topic: "homeassistant/sensor/rf/SimpliSafe_Sensor/null"

And the the restart procedure:

automation:
- alias: reset_rtl_433_addon #it gets stuck
  trigger:
    - platform: time_pattern
      minutes: '/5'
      seconds: 00
  condition:
    condition: template
    value_template: '{{ ((as_timestamp(now()) - as_timestamp(states.sensor.mqtt_general.last_changed) | default(0)) | int) >= 180 }}'
  action:
   # - service: notify.notify
   #   data:
   #     message: "Restarting 433"
    - service: hassio.addon_restart
      data:
        addon: "77a50ada_rtl4332mqtt"

[grouts112]

Thank you @ZBiener .. after working out my specific 'addon:' number and tweaking the sensor name. I have this automation restarting the addon within 5 minutes of it getting stuck.
Not a fix, but a great work around !

[quaqo]

I also had this problem. I think it's related to a memory leak or something related to the continous fork of mosquitto_pub, as @messismore wrote.

I tried @ZBiener solution, it was a hack, very clever, but didn't quite like it (it was restarting often, because it was hanging very often as well).

I ended up with using rtl_433 own mqtt function and never had a problem since:

#!/bin/sh

export LANG=C
PATH="/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin"

CONFIG_PATH=/data/options.json
MQTT_HOST="$(jq --raw-output '.mqtt_host' $CONFIG_PATH)"
MQTT_USER="$(jq --raw-output '.mqtt_user' $CONFIG_PATH)"
MQTT_PASS="$(jq --raw-output '.mqtt_password' $CONFIG_PATH)"
MQTT_TOPIC="$(jq --raw-output '.mqtt_topic' $CONFIG_PATH)"
PROTOCOL="$(jq --raw-output '.protocol' $CONFIG_PATH)"
FREQUENCY="$(jq --raw-output '.frequency' $CONFIG_PATH)"
GAIN="$(jq --raw-output '.gain' $CONFIG_PATH)"
OFFSET="$(jq --raw-output '.frequency_offset' $CONFIG_PATH)"

# Start the listener and enter an endless loop
echo "Starting RTL_433 with parameters:"
echo "MQTT Host =" $MQTT_HOST
echo "MQTT User =" $MQTT_USER
echo "MQTT Password =" $MQTT_PASS
echo "MQTT Topic =" $MQTT_TOPIC
echo "RTL_433 Protocol =" $PROTOCOL
echo "RTL_433 Frequency =" $FREQUENCY
echo "RTL_433 Gain =" $GAIN
echo "RTL_433 Frequency Offset =" $OFFSET

set -x  ## uncomment for MQTT logging...

/usr/local/bin/rtl_433 -M newmodel -R $PROTOCOL -f $FREQUENCY -g $GAIN -p $OFFSET -F "mqtt://$MQTT_HOST:1883,user=$MQTT_USER,pass=$MQTT_PASS,retain=1,devices=$MQTT_TOPIC[/model][/id]"

Instead of a single json payload, this create MQTT_TOPIC/DEVICE/ID/property_1, etc...

For example I have it in HA, subscribed to: "MQTT_TOPIC/DEVICE/ID/temperature" for a temperature sensor.

Hope it helps.