Did anyone manage to use the http output?
it’s an improved display / web interface
which you can start with:
output http
in the conf.template file
or
rtl_433 -F http
from the command line
then open http://localhost:8433/ or http://127.0.0.1:8433/
to see the devices in a scrollable list.
It used to work outside of HA but now it gives me this upon startup:
[rtl_433] Starting HTTP server on address 0.0.0.0:8433, serving
So I guess it’s not compatible with the HA add-ons ?
Thx
An issue was filed at Support for Govee Water/Leak sensor · Issue #2619 · merbanan/rtl_433 · GitHub and there’s more discussion there.
That’s really neat! For that to work, we’d have to update config.json to expose the ports. Then it would become available within the HA UI like how zigbee2mqtt works.
Thanks for the feedback,
should I submit a feature request or is this already on the list for future releases?
have a great weekend
I have the rtl_433_mqtt_hass.py file (https://raw.githubusercontent.com/merbanan/rtl_433/f101632737523c89013714b0abe2b0367d075921/examples/rtl_433_mqtt_hass.py) which is supposed to support the Govee sensor but if I simply replace the existing one in that add-in container (using the console in Portainer) and restart the addin, the old one comes back. How do i switch to the new file?
On freshly installed RTL_433 add-on v 0.4.0 I can’t use any protocols above 223.
How can I fix this?
Details of the problem is in this topic - RTL_433 - unable to add/use protocols above 223
Hey Everyone,
I am actively looking to fix things, and could use some feedback. For now install next with the current repository, and I have some instructions on how to make everything transperent, with a working autodiscovery!! Contributions welcome for autodiscovery. It is time the HA community takes it over. I know the project is looking for maintainers, and I am volunteering. But for now, these two things should really streamline for everyone! I’d love feedback.
I am fixing things. Just made this
GitHub - catduckgnaf/rtl_433_haos_autodiscovery_addon Please read the readme, and here as well.
I am working on updating everything to be streamlined. This will work with next or not.
I made a discord to discuss as well, rtl_433 HA
Hi all,
Is it possible to have the ouput (to influx) just some devices? Not all devices found by RTL_433 dongle?
This seems to be a correct thread to tackle with RTL_433 issues.
I have many Nexus type 433MHz sensors, and working well 12Months.
Lately, however, the RTL_433 has stopped working. It does not receive any data.
It did happen before and worked only for while (which is weird already)…now I haven’t got any updates for several days
The same applies to all sensors
The possibilities are
#1. I tested with a Virtual Machine( ubuntu) and the data is coming. So the dongle works
#2. MQTT works as I sent the data from the same VM to MQTT and I got an update immediately. (I use one sensor to send the data when battery is removed/put back)
This is the command I used: on VM (Ubuntu)
#rtl_433 -F “mqtt://homeassistant.local:1883,user=user,pass=pass,events=rtl_433[/model][/id]”
And MQTT Explorer is updated
#3…#1 and #2 proves that RTL_433 works at least on Ubuntu
#4. SDR dongle is recognized by RTL_433 (on HomeAssitant RASPI 4)
Starting rtl_433 with rtl_433.conf…
[rtl_433] rtl_433 version 22.11-248-g1e02cdc0 branch master at 202311082200 inputs file rtl_tcp RTL-SDR
[rtl_433] MQTT: Publishing MQTT data to 192.168.1.168 port 1883
[rtl_433] MQTT: Publishing events info to MQTT topic “rtl_433[/model][/id]”.
[rtl_433] Use “-F log” if you want any messages, warnings, and errors in the console.
[rtl_433] Detached kernel driver
[rtl_433] Found Fitipower FC0013 tuner
[rtl_433] Exact sample rate is: 250000.000414 Hz
[rtl_433] Allocating 15 zero-copy buffers
#5 so the conclusion is that something wrong with the HA system itself?
How to activate debug mode on RTL_433?
I activated debug-logs on HA but it generates a lot of prints.
logger:
default: info
logs:
homeassistant.components.: debug
filters:
homeassistant.components:???
How to filter the logs to pinpoint the issue?
Any help appreciated. I have tried to troubleshoot this for days already
You can set output kv and verbose in the configuration file for rtl_433.
It looks like you’re using the next addon. I can’t see what version you have in your VM - is it possible there’s a regression in upstream’s master branch? You could try switching to the stable addon version to test.
Hi…I have tried BOTH addons. Neither works.
VM:rtl_433 version 21.12 (2021-12-14) inputs file rtl_tcp RTL-SDR SoapySDR
HA:[rtl_433] rtl_433 version 22.11 branch at 202211191645 inputs file rtl_tcp RTL-SDR
I even installed a fresh HA to another SD card…with only rtl_433, file editor and MQTT broker. Still nothing.The issue must be on the HA itself??
Next I will try on another raspi 4 module…also with fresh HA.
UPDATE:
I did install HA on another raspi 4…but still the same issue.
However I installed RTL_433 on another raspi with raspberry OS and there it works fine.
The data is sent to HA via MQTT with this command
#rtl_433 -R 19 -F “mqtt://192.168.1.168:1883,user=user,pass=pass,retain=1,events=rtl_433[/model][/id]”
But I still wondering WHY rtl_433 stopped working on HA??
Do you use USB powered hub?
If not, try…It can make the difference…
Do you think it’s power issue? I use genuine Raspi Power unit
Which SDR do you have? I have also heard some of them might have issues even with good power. This site seems to have some of the best made ones and after research, I bought mine from them: https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/
That’s fine for the Pi, but for the rtl dongle it’s advisable to use a USB powered hub and, for sure connect it with a good extender cable, never directly…
Okay…I think I found the possible reason for rtl_433 freezing
I checked the logs (syslog) and found that there is some weird stuff happening, a reset?
Timestamp changes from 09:28:21–09:17:05??
RTL_433 is running but no measurements arriving via MQTT after 9:28. Is it frozen?
Hi all,
I have a home assistant deployment leveraging a NeoELEC v5 dongle with both the rtl_433 and rtl_433 MQTT Auto Discovery addons running fine, as in, I can query through MQTT explorer however it does not seem to discover the signal sent by the remote switch I use -reference of the model here.
I decided to try the rtl_433 dongle on base linux and windows without homeassistant in the mix and it does not seem to detect the signal unless I use rtl_433 -A and then I got the pulses being detected when I push my on and off button on the remote. I am not entirely sure how to translate whatever rtl_433 reports from the pulse analysis report into the homeassistant rtl_433 config file.
So here are a couple of questions:
am I correct thinking I should be able to program homeassistant+rtl_433 for that particular use case with a 433.92Mhz remote and ultimately control the five electrical outlet for on/off operations? The goal being to reuse a few 433.92Mhz remote outlets in homeassistant.
if so, should the auto-discovery addon help capture the signal? It does not work at all since even rtl_433 in CLI does not report anything until I am in pulse analysis mode so I would say it is expected but I prefer to check
finally, is there a guide somewhere to help me capture the signal and do whatever I would have to do to present the right data to Home Assistant? I have found how to capture the signal in a file using rtl_433 but I have very limited knowledge in analyzing RF so I am not entirely sure how to get from the rtl_433 pulse information output to the home assistant rtl_433 config file.
Could anyone help me with some pointers in terms of the next step I could consider to progress?
Thanks in advance.
–
For reference below, I am sharing some details of the output from the rtl_433 -A command when pushing the remote buttons.
Detected OOK package 2023-12-16 20:20:48
Analyzing pulses...
Total count: 450, width: 435.94 ms (108986 S)
Pulse width distribution:
[ 0] count: 308, width: 204 us [192;224] ( 51 S)
[ 1] count: 142, width: 588 us [576;608] ( 147 S)
Gap width distribution:
[ 0] count: 290, width: 560 us [544;576] ( 140 S)
[ 1] count: 142, width: 176 us [156;192] ( 44 S)
[ 2] count: 17, width: 5920 us [5896;5940] (1480 S)
Pulse period distribution:
[ 0] count: 432, width: 764 us [752;780] ( 191 S)
[ 1] count: 17, width: 6124 us [6100;6144] (1531 S)
Pulse timing distribution:
[ 0] count: 447, width: 196 us [164;224] ( 49 S)
[ 1] count: 432, width: 568 us [544;608] ( 142 S)
[ 2] count: 17, width: 5920 us [5896;5940] (1480 S)
[ 3] count: 3, width: 156 us [156;160] ( 39 S)
[ 4] count: 1, width: 10004 us [10004;10004] (2501 S)
Level estimates [high, low]: 15950, 2950
RSSI: -0.1 dB SNR: 7.3 dB Noise: -7.4 dB
Frequency offsets [F1, F2]: -392, 0 (-1.5 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with multiple packets
view at pdv/#AAB025050300C402381720009C27148190818181818181819090908190819081818181818190908255+AAB025050100C402381720009C27148193818181818181819090908190819081818181818190908255+AAB025050200C402381720009C27148190818181818181819090908190819081818181818190908255+AAB025050100C402381720009C27148190818181818181819090908190819081818181818190938255+AAB025050100C402381720009C27148190818181818181819090908190819381818181818190908255+AAB025050900C402381720009C27148190818181818181819090908190819081818181818190908255+AAB025050100C402381720009C27148190818181818181819090908190819081818181818181818455
Attempting demodulation... short_width: 204, long_width: 588, reset_limit: 5944, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=204,l=588,r=5944,g=580,t=154,y=0'
[pulse_slicer_pwm] Analyzer Device
codes : {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8afc8, {25}bf8aff8
Detected OOK package 2023-12-16 20:20:50
Analyzing pulses...
Total count: 375, width: 362.00 ms (90501 S)
Pulse width distribution:
[ 0] count: 257, width: 204 us [192;228] ( 51 S)
[ 1] count: 118, width: 588 us [580;608] ( 147 S)
Gap width distribution:
[ 0] count: 242, width: 560 us [536;572] ( 140 S)
[ 1] count: 118, width: 176 us [164;188] ( 44 S)
[ 2] count: 14, width: 5912 us [5896;5932] (1478 S)
Pulse period distribution:
[ 0] count: 360, width: 764 us [752;780] ( 191 S)
[ 1] count: 14, width: 6120 us [6096;6136] (1530 S)
Pulse timing distribution:
[ 0] count: 375, width: 196 us [164;228] ( 49 S)
[ 1] count: 360, width: 568 us [536;608] ( 142 S)
[ 2] count: 14, width: 5912 us [5896;5932] (1478 S)
[ 3] count: 1, width: 10004 us [10004;10004] (2501 S)
Level estimates [high, low]: 15954, 2912
RSSI: -0.1 dB SNR: 7.4 dB Noise: -7.5 dB
Frequency offsets [F1, F2]: 112, 0 (+0.4 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with multiple packets
view at pdv/#AAB023040E00C40238171827148190818181818181819090908190819081818181909081818255+AAB023040100C40238171827148190818181818181819090908190819081818181818181818355
Attempting demodulation... short_width: 204, long_width: 588, reset_limit: 5936, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=204,l=588,r=5936,g=576,t=154,y=0'
[pulse_slicer_pwm] Analyzer Device
codes : {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8af38, {25}bf8aff8
You won’t be able to control the outlets as RTL_433 only receives data, doesn’t send anything.
Yet, you could repurpose the remote control capturing the signal, but it will fire up the outlets too…
In that case you should use a Flex decoder, and auto discovery won’t work, you should create a manual mqtt entry.
In the log you posted there is a suggestion for the flex decoder.