Yes! It’s been in the next branch for a while with no issues, and I rolled a new stable tag today.
1 Like
I am running into difficulty specifying a specific decoder from within the config file.
I successfully capture the packets, but the raw data is returned non-decoded. The instructions for the specific project state the following for RTL_433 on the command line, but I’m not sure I’ve formatted it correctly in the HA Add On config file.
rtl_433 -R 0 -f 868.298M -X 'n=Marlec,m=FSK_PCM,s=10,l=10,g=1000,r=2000,preamble=aad391d391'
My HA RTL_433 config file is:
output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain}
report_meta time:iso:usec:tz
frequency 868.3M
output kv
decoder n=Marlec,m=FSK_PCM,s=10,l=10,g=1000,r=2000,preamble=aad391d391
protocol 188
Can anyone see what I am doing wrong?
Thanks for any pointers!
Are you implementing a brand new protocol, or one that is already supported? If it’s one that rtl_433 knows about, you just need the protocol number. If you are implementing a new decoder, you need the decoder line.
It’s a lot faster to test and debug new decoders outside of home assistant, so I’d suggest installing rtl_433 on your normal computer and working there until you get a working decoder line.
Pulling my hair out, please help to save my good looks 
6-12 months ago Home Assistant / RTL_433 stopped picking up my Bresser 7in1 weather station. Today I tried to troubleshoot the issue.
On my Pop_OS desktop PC, everything is fine:
When I then connect the radio to Home Assistant OS (NUC) again, the logs of the RTL_433 add-on do not show anything being detected:
This is the config:
frequency 868M
protocol 173
# pulse_detect auto
# sample_rate 1M
# gain 25
convert si
report_meta time:iso:tz:local
output kv
# output json
How can I troubleshoot this further? I am at a loss right now.
Is there any chance the protocol number somehow changed? I see it in your HA config file but not in the command line on your desktop.
Also, rtl_433 on your desktop is quite old (2021!), so it’s possible there’s been a regression since then. Could you try 23.11 or newer on your PC, to match what’s in Home Assistant?
It may also be worth browsing through the issues upstream at https://github.com/search?q=repo%3Amerbanan%2Frtl_433+bresser&type=issues in case others have noticed anything.
Thanks for the advice! I verified some more, unfortunately not a fix yet.
- I tried the newer rtl_433 version 23.11 on my desktop with the same result: the Bresser weather station is getting picked on the desktop perfectly.
- Confirmed there that protocol 173 is still the correct one.
- Checked out the issues upstream, but found nothing relevant.
I think I should now focus on the difference between PC (with PopOS/Ubuntu) and NUC (with HA-OS). Do you have any advice how I could further pinpoint the issue? Thanks in advance!
I’ve tried to get a friends Bresser 7 in 1 station to pick up with the Fitipower FC0012 tuner, but even if I got a some reading the tuner would stop reporting after couple of hours. The tuner worked fine with 433 signal, but with 868 it had troubles. The we tried a different tuner the Nooelec RTL-SDR v5 SDR and it worked great with this set up:
frequency 868.3M
verbose 7
gain 0
protocol 173 # Bresser Weather Center 7-in-1
convert si
output kv
report_meta level
#report_meta noise
report_meta stats
report_meta time:usec
report_meta protocol
pulse_detect minlevel=-36
pulse_detect magest
sample_rate 250k
There is also an option to set up the station to send data to your own web server (this depends on the firmware, the newer station do not have this option), you can try this to send data to NodeRED and then to HA. If you want I can help you with this. It is all local and uses your local wifi to get data from the station to Home Assistant.
Thanks @DominikW for your suggestions.
For now, I will try to connect the Fitipower to a Raspberry Pi 3 I have lying around. Perhaps that works.
Sending data to my own webserver/NodeRed is not really a preferred option because I would like to not use the Bresser display/server. RTL-433 has served me well for several years. If RPI3 doesn´t work out, I will check out the RTL-SDR v5. Thanks!
I am using the rtl_433 add on in home assistant. Something weird and I am hoping someone can answer
If I have the hop interval specified like the below then the device which is on 319.5 gets detected
# Uncomment the following line to also enable the default "table" output to the
# addon logs.
output kv
hop_interval 60
frequency 433.92M
frequency 319.5M
However if I remove the hop interval no device gets detected
# Uncomment the following line to also enable the default "table" output to the
# addon logs.
output kv
frequency 319.5M
Any help would be appreciated
not sure what i am doing wrong but I am having no luck getting to discovery to find my Acurite-5n1 but it shows in the log for rtl433 any tips on what I might be missing?
Dear all,
I just jumped into this topic. Will it be possible to receive a Honeywell doorbell type DW915s ringing? The doorbell uses 868Mhz and a protocoll called ActivLink. I think found it in this list.
And should this this cheap RTL2832U receiver work?
I also want to understand how to get my doorbell picked up. It’s on 433.92 so should be possible but the auto discover doesn’t pick it up. But I’m a total novice to all this and have zero idea how to resolve that!
Similar to some others in the thread, I left auto discover on and now must have a ton of devices picked up (no idea how to know how many). What do I need to do about these?
As a first step, Install rtl_433 as an Add-on. You know how to do that? Second, search the documentation of the (original) rtl_433 project to create a config file. Enable logging as part of the output parameter. Then you should get messages in the logging tab of any activity corresponding to your config file.
This is what I did. However, I receive no messages, but I’m still trying to make my steps.
Thanks. I have RTL and MQTT running (including the RTL MQTT Auto Discovery add in) and picking up other devices of mine (ie heating oil level sensor) but not picking up me 433.92 doorbell. Have tried it when pressing it too. No idea what I need to do to get it to pick it up though.
Similar issue for me. I try to receive a Honeywell doorbell type DW915s ringing? The doorbell uses 868Mhz and a protocoll called ActivLink. I think found it in this list .
Config file is
output mqtt://homeassistant.local:1883,user=xxx,pass=xxxx,retain=0
report_meta time:iso:usec:tz
frequency 868.3M
verbose 7
convert si
report_meta stats
sample_rate 250k
output kv
protocol 115
protocol 116
This is my log
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[20:40:17] WARNING: e[33mrtl_433 now supports automatic configuration and multiple radios. The rtl_433_conf_file option is deprecated. See the documentation for migration instructions.e[0m
Starting rtl_433 -c /config/rtl_433/rtl_433.conf
rtl_433 version 23.11 branch at 202311281352 inputs file rtl_tcp RTL-SDR
MQTT: Publishing MQTT data to homeassistant.local port 1883
MQTT: Publishing device info to MQTT topic "rtl_433/9b13b3f4-rtl433/devices[/type][/model][/subtype][/channel][/id]".
MQTT: Publishing events info to MQTT topic "rtl_433/9b13b3f4-rtl433/events".
MQTT: Publishing states info to MQTT topic "rtl_433/9b13b3f4-rtl433/states".
New defaults active, use "-Y classic -s 250k" if you need the old defaults
Registering protocol [115] "Honeywell ActivLink, Wireless Doorbell"
Registering protocol [116] "Honeywell ActivLink, Wireless Doorbell (FSK)"
e[106;96m[e[30mProtocolse[96m]e[0m Registered 2 out of 250 device decoding protocols
e[106;96m[e[30mInpute[96m]e[0m The internals of input handling changed, read about and report problems on PR #1978
e[106;96m[e[30mSDRe[96m]e[0m Found 1 device(s)
e[106;96m[e[30mSDRe[96m]e[0m trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Found Fitipower FC0012 tuner
Exact sample rate is: 250000.000414 Hz
e[102;92m[e[30mSDRe[92m]e[0m Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
e[106;96m[e[30mSDRe[96m]e[0m Sample rate set to 250000 S/s.
e[106;96m[e[30mInpute[96m]e[0m Bit detection level set to 0.0 (Auto).
e[106;96m[e[30mSDRe[96m]e[0m Tuner gain set to Auto.
e[106;96m[e[30mInpute[96m]e[0m Reading samples in async mode...
e[105;95m[e[37mSDRe[95m]e[0m rtlsdr_set_center_freq 868300000 = 0
e[106;96m[e[30mSDRe[96m]e[0m Tuned to 868.300MHz.
Allocating 15 zero-copy buffers
e[105;95m[e[37macquire_threade[95m]e[0m acquire_thread enter...
e[106;96m[e[30mMQTTe[96m]e[0m MQTT Connected...
e[106;96m[e[30mMQTTe[96m]e[0m MQTT Connection established.
e[106;96m[e[30mBasebande[96m]e[0m low pass filter for 250000 Hz at cutoff 50000 Hz, 20.0 us
Still, when I ring the bell, nothing happens… Where am I wrong?
I added a report with log files here. In case you want to help, I would be grateful if you check there…
Did a step forward. This command line on a Windows PC worked:
rtl_433 -f 868M -g 0 -F kv -v -Y autolevel
I put these settings into a config file. I tried
frequency 868M
output kv
gain 0
verbose 5
pulse_detect autolevel
But still I receive no responses.
A second point: The MQTT server settings like this
output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain}
should use HA variables automatically, right? This fails for me.
Yes, that’s right. Are you editing the .template file? That’s what gets read in and has variables substituted. Here’s one of mine:
$ cat rtl_433/doorbell.conf.template
device 0
frequency 916.8M
output mqtt://${host}:${port},user=${username},pass=${password},retain=false
report_meta time:iso:usec:tz
I am editing a config file. The syntax is identical, I just use a different name, rtl_433.conf.
The file is properly read and considered. But the variables are not found. What can I do?