Closed BarryMar closed 2 years ago
I don't think this is a rate limiting issue, as we'd likely see much more corruption of the output. My guess is something is setting the width of the terminal incorrectly, though we don't do anything like that in the addon.
This may be already fixed in #14. Running there, I can see multiline output correctly, such as this which wraps at my browser width:
[doorbell] baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 200000 Hz, 5.0 us[weather_station] Use -h for usage help and see https://triq.org/ for documentation.
Or, is it possible it's a UI bug on the web side? Can you horizontally scroll the text if you have a trackpad?
OK, so I figured out what causes the weirdness to happen.
There's no horizontal scroll bar at the bottom of the log window, so it doesn't look like a width problem
However, I did get an interesting result when I intentionally misconfigured the rtl_433_conf_file variable to a nonexistant file - I can see the startup messages now and the device seems to be recognized. So I rewrote the config file again from scratch and can see normal startup stuff now. MQTT isn't working, but figuring out how that is supposed to work I'll leave for another day.
So in this case it looks like I wasn't actually getting slammed by the armhf issue on my HA0S setup because it must be using ARM64 of some sort or other? The other issue is still a valid problem if there are any folks using 32bit HAOS or normal RPOS Supervised installations.
When I took the same configuration file I was using back to the Mac and ran it, it gave me a "Protocol number specified (187) is larger than number of protocols" error. This in turn spits out a list of protocols it supports, of which the tail end is what we're seeing in the first two screenshots. Turns out the default file found at https://github.com/merbanan/rtl_433/blob/master/conf/rtl_433.example.conf has configurations for protocols 187 - 199. Comment them out and everything works great.
Looks like a warning in https://github.com/pbkhrv/rtl_433-hass-addons/blob/main/rtl_433/README.md is worthwhile here to not include those protocols. Maybe they only apply to a later RTL_433 build or something?
It would also be nice to be able to see all the spew from rtl_433 when a bad configuration file like that is sent to it.
So in this case it looks like I wasn't actually getting slammed by the armhf
armhf
is different than armv7l
. I also have an HA installation on a Raspberry Pi 4, and I'm able to run rtl_433
fine using Alpine 3.14. Let's keep any discussion of that over at #23 .
it gave me a "Protocol number specified (187) is larger than number of protocols" error.
Yes, that's because you're using the configuration from "master" which represents the in-development work. You'd need to switch to the 21.05 tag from the dropdown to see the example config from that version.
A similar topic came up recently on the forums: https://community.home-assistant.io/t/home-assistant-add-on-rtl-433-with-mqtt-auto-discovery/260665/105?u=deviantintegral
Since it sounds like the logging issue is solved, are we good to close this?
In trying to diagnose the problems in https://github.com/pbkhrv/rtl_433-hass-addons/issues/23 on my Raspberry Pi, I noticed that the Log output provided in the Home Assistant UI was initially truncated and didn't show what the full startup messaging looks like.
For example, if I run the following command in HAOS Root:
docker run --device /dev/bus/usb/001/003 hertzg/rtl_433:debian -f 915M
... the initial console output looks like this:
But if I run my (currently malfunctioning) rtl_433-hass-addons setup the header info gets chopped off and it starts much deeper in the sequence. I took the default rtl_433.example.conf and just changed the contents to match what I needed in the base config.
Is it possible to slow down the initial startup of the code with a SLEEP or something so the logger can properly capture more debug info?