Added support for Honeywell Wireless Doorbell

[merbanan]

No description provided.

[merbanan]

The code is fairly simple any amendments can be added later.

[klohner]

Works great for my devices! Thank you.

[Bond246]

Hello @klohner
could you tell me how you get your doorbell-system to work?
I try to get the button-signals via MQTT but i don't see anything...

Thanks

[klohner]

Are you able to receive the doorbell signals without MQTT? In North America, rtl_433 -f 916800000 should receive the signals. Elsewhere, rtl_433 -f 868300000 should work.

[Bond246]

Without specifying the any decoder with -X ?
I will try.

[klohner]

-X is to let you specify a custom specified decoder. The Honeywell Activlink doorbells (which I assume you're looking to receive) have been built into rtl_433 for a while now, so you don't need -X to help rtl_433 recognize this signal.

What is the model number for the doorbell you are using?

[Bond246]

it's a Friedland Libra+ D915S Doorbell.
Hopefully i will find some minutes on next weekend to give feedback.

Thanks!

[Bond246]

Hi,

looks i can't find that signal.
Even without MQTT nothing is "in the air". I only see some Lacross Devices. I checked the european and the North American frequency and also checked some Hz between 868.300 but everything is empty.

rtl_433 version 20.11-117-g445ddda5 branch master at 202104251151 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"...
New defaults active, use "-Y classic -s 250k" for the old defaults!

Registered 157 out of 186 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-186 ]

Detached kernel driver
Found Rafael Micro R820T tuner
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Sample rate set to 1000000 S/s.
Tuner gain set to Auto.
Tuned to 868.300MHz.
Allocating 15 zero-copy buffers
baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 200000 Hz, 5.0 us`

[ZenixineZ]

Hello @klohner,
I am also having trouble receiving/decoding a doorbell signal with rtl_433
I am in America using a Honeywell RDWL311A2000 doorbell and the command rtl_433 -f 916800000, but I get no output. I have verified that the doorbell is sending an FSK signal and that it is at the expected frequency of 916.8MHz. Were you able to decode the signal at 916.8MHz or only 868Mhz?

[klohner]

I don't see anything obvious why it shouldn't work. I'd need to see the cu8 signal from your doorbell. Record one with rtl_433 -f 916800000 -S all and attach it here and I'll take a look.

[ZenixineZ]

Seems like Github doesn't like the .cu8 file format so here's a Gdrive link: https://drive.google.com/file/d/14WrqQX1nq1HMYg5jBzMOGjpbA7VNNDeF/view?usp=sharing

[klohner]

@ZenixineZ This sample seems to decode properly when I feed it directly to rtl_433. Are you not able to reproduce this? What version of rtl_433 are you using?

C:\> rtl_433 -r g001_916.8M_1000k.cu8
rtl_433 version 21.12 branch  at 202112141644 inputs file rtl_tcp RTL-SDR
[...]
Test mode active. Reading samples from file: g001_916.8M_1000k.cu8
baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 100000 Hz, 10.0 us
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.071539s
model     : Honeywell-ActivLink                    Class     : Doorbell      Id        : 4c0d0
Battery   : 1            Alert     : Normal        Secret Knock: 0           Relay     : 0             Integrity : PARITY

However, I did notice a bug in my code. Your doorbell is sending {48}4C0D60200001 and so your Device ID should be reported as 4C0D6, not 4C0D0. The last nibble is not being reported correctly.

@merbanan The issue is that my driver code is picking out the wrong nibble for the end of the device id.

rtl_433/src/devices/honeywell_wdb.c

Line 80 in 631f9f8

device = bytes[0] << 12 | bytes[1] << 4 | (bytes[2]&0xF);

Off the top of my head, this should probably be:

device = bytes[0] << 12 | bytes[1] << 4 | bytes[2] >> 4;

I suppose I'd need to open a new issue for this change?

[ZenixineZ]

@klohner I am using version 21.12-113-g631f9f85.

Reading the file with the same command you used worked, and I get the same output. But still nothing when I run it with rtl_433 -f 916800000

[zuckschwerdt]

device = bytes[0] << 12 | bytes[1] << 4 | bytes[2] >> 4;
I suppose I'd need to open a new issue for this change?

Open a PR if you like, but I can just commit that small change now if you like?

[klohner]

@ZenixineZ - My thought is that if rtl_433 is able to decode your .cu8 file okay but not when run live, the issue is with some level setting difference between when rtl_433 is run live versus when run on a sample file. I'm not familiar with the intricacies of this behavior, though.

A few ideas:

• Your signal seems maybe a bit weak. Try moving the doorbell button and SDR closer together or replace the battery in the doorbell button. Another test is to remove the antenna from the SDR and press the button when held right next to it.

• Adjust the frequency to be just above or below the signal. For example, rtl_433 -f 916900000 or rtl_433 -f 916700000

• You might try rtl_433 -f 916800000 -Y autolevel to have rtl_433 adjust the minimum detection level. This seemed to work for me to have it decode a very weak signal from my doorbell.

==

@zuckschwerdt - Yes, please commit that change if you don't mind. I have another low-priority change in mind to write for this driver, but I'll do a PR for that someday. (I'd like to get the -y <code> working with just a single row specified -- It also bothers me that rtl_433 -y {48}4C0D60200001,{48}4C0D60200001,{48}4C0D60200001,{48}4C0D60200001 decodes twice because it decodes at both -R 115 & -R 116, and that it decodes the inverse of the specified <code> due to the indiscriminate bitbuffer_invert(bitbuffer); I'd used for live signals.)

[zuckschwerdt]

@klohner ID fixed with 835cfd4.
The -y "test code" feature is really meant to be a raw bitbuffer, so repeats and invert are intended. That we can't distinguish between OOK and FSK could be fixed perhaps.

[ZenixineZ]

@klohner After some playing around I got rtl_433 to properly decode the live Honeywell signal by running the command rtl_433 -f 916800000 -Y classic, seems like the new minmax mode doesn't detect the signal but will be used automatically for freqs over 800MHz

[klohner]

Glad you got it working! I'm unable to replicate the issue, though. My Nooelec NESDR is able to reliably pick up the signal from my North American Honeywell RDWL311A2000 with any of these commands:

rtl_433 -f 916800000
rtl_433 -f 916800000 -Y minmax -s 1M
rtl_433 -f 916800000 -Y minmax -s 250k
rtl_433 -f 916800000 -Y classic -s 1M
rtl_433 -f 916800000 -Y classic -s 250k

[ZenixineZ]

I just managed to to catch the signal with minmax as well, thinking the issue is just that the pulse was too weak like you mentioned before. In any case thank you for the help!