It looks like either HassOS or HomeAssistant core update has broken the rtl4332mqtt addon I was using. I’m guessing something is now blocking or messing with the USB access.
Anyone have suggestions how to debug and unbreak it?
Version core-2021.2.2
supervisor-2021.02.6
Home Assistant OS 5.10
Log:
Starting RTL_433 with parameters:
MQTT Host = 192.168.1.221
MQTT User = hassio-mqtt
MQTT Password = hassio-mqtt-password
MQTT Topic = homeassistant/sensor/rtl433
RTL_433 Protocol = 100
RTL_433 Frequency = 433920000
RTL_433 Gain = 60
RTL_433 Frequency Offset = 0
rtl_433 version 20.11-71-g4b643041 branch master at 202102100913 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/root/.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"...
Registered 1 out of 178 device decoding protocols [ 100 ]
usb_open error -1
[cmd] /bin/ash exited 0
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
The USB error seems to suggest that the container is no longer able to access / connect to the USB device (RTL2838)…it is NOT a serial device although I’m unsure what it uses.
Unfortunately I updated both at once so I don’t know which may be the breaking thing. I can reproduce the error on a clean HassOS install.
It was actually the latest supervisor update that has caused USB device issues. Unfortunately there are reports that downgrading the supervisor isn’t working properly either.
The especially painful thing for me is going to be losing the per-room HVAC controls until its fixed (I had thermometers in every room to tweak the thermostat).
And I don’t suppose supervisor update is something I can restore from an old snapshot? I do have a snapshot from a few months ago…sadly I don’t have a VM disk backup
Sounds like someone has found a fix, and it just needs to be merged upstream…though given I know I found a workaround (which I think is wrong) to a open issue on the addon I am doubtful the fix will get merged any time soon.
I wish I had more time in my life and I’d fork and figure out how to fix and improve a couple complaints I had that could be better on the addon…but sadly it’ll be a while before my life is non-crazy enough to learn container development and debugging properly.
First, stop (and disable) the existing rtl4332mqtt addon
Then, go to Addons and add the repository
Now install the rtl4332mqtt addon by DarwinData and set it up with the same MQTT login you had for the old addon
Note, you will also need to also fix the startup-script /config/rtl4332mqtt/rtl2mqtt.sh per this bug issue due to a library error, and that the latest rtl_433 binary changes the naming so you may need to modify some of your sensors:
I’d suggest a new thread someone may know better how to “properly” do it.
The “lazy hack” way is just change the line in /config/rtl4332mqtt/rtl2mqtt.sh
/usr/local/bin/rtl_433 -F json -R $PROTOCOL -f $FREQUENCY -g $GAIN -p $OFFSET | while read line
The part -R $PROTOCOL sets the protocol enabled for the rtl_433 application, it accepts that parameter repeated more than once on the same line, such as -R 40 -R 41 -R 74 or even remove the -R $PROTOCOL and it would run with “a bunch of default protocols” enabled. See the rtl_433 project for more on the syntax and options as well as the most up to date list of what devices they support. The ones listed in the addon page seem outdated, the rtl_433 project keeps adding more supported decoders all the time - it builds the program when you install or rebuild the addon so you get all of them; I rebuilt to get support for my Atlas weather-station.
Ideally, I think someone would make the addon accept more than once, but that’s beyond my skills.