Rtl_433: Trying to read the button press of a cheapo doorbell

[BenWoodford]

I've seen a few queries about doorbells and I've been trying to follow the processes in the comments without much success.

Could someone lend a hand on how to parse this? I'm using the gdecode generic device for testing purposes which is found here

Output with -a:

*** signal_start = 125939, signal_end = 631179
signal_len = 505240,  pulses = 1783
Iteration 1. t: 105    min: 53 (480)    max: 158 (520)    delta 40
Iteration 2. t: 105    min: 53 (480)    max: 158 (520)    delta 0
Pulse coding: Short pulse length 53 - Long pulse length 158

Short distance: 48, long distance: 147, packet distance: 1529

p_limit: 105
bitbuffer:: Number of rows: 25
[00] {1} 00 : 0
[01] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[02] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[03] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[04] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[05] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[06] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[07] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[08] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[09] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[10] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[11] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[12] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[13] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[14] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[15] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[16] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[17] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[18] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[19] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[20] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[21] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[22] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[23] {25} 56 78 73 00 : 01010110 01111000 01110011 0
[24] {24} 56 78 73 : 01010110 01111000 01110011
... Maximum number of rows reached. Message is likely truncated.

And -A:

Detected OOK package    @ 2017-12-22 15:37:53
Analyzing pulses...
Total count:  599,  width: 180217               (720.9 ms)
Pulse width distribution:
 [ 0] count:  265,  width:    59 [52;72]        ( 236 us)
 [ 1] count:  285,  width:   177 [147;219]      ( 708 us)
 [ 2] count:   13,  width:   257 [223;308]      (1028 us)
 [ 3] count:    6,  width:    90 [78;106]       ( 360 us)
 [ 4] count:   12,  width:   477 [366;563]      (1908 us)
 [ 5] count:    5,  width:   128 [114;138]      ( 512 us)
 [ 6] count:    8,  width:   678 [591;815]      (2712 us)
 [ 7] count:    3,  width:  1003 [895;1123]     (4012 us)
 [ 8] count:    2,  width:  1355 [1255;1456]    (5420 us)
Gap width distribution:
 [ 0] count:  260,  width:   150 [145;180]      ( 600 us)
 [ 1] count:  305,  width:    51 [47;63]        ( 204 us)
 [ 2] count:   24,  width:  1529 [1526;1551]    (6116 us)
 [ 3] count:    4,  width:    68 [65;72]        ( 272 us)
 [ 4] count:    3,  width:   199 [197;202]      ( 796 us)
 [ 5] count:    1,  width:    20 [20;20]        (  80 us)
 [ 6] count:    1,  width:    13 [13;13]        (  52 us)
Pulse period distribution:
 [ 0] count:  524,  width:   219 [203;270]      ( 876 us)
 [ 1] count:   26,  width:  1582 [1325;1741]    (6328 us)
 [ 2] count:   20,  width:   311 [276;367]      (1244 us)
 [ 3] count:   13,  width:   549 [425;679]      (2196 us)
 [ 4] count:    8,  width:   789 [701;958]      (3156 us)
 [ 5] count:    3,  width:   411 [391;432]      (1644 us)
 [ 6] count:    2,  width:  1123 [1057;1190]    (4492 us)
 [ 7] count:    1,  width:   175 [175;175]      ( 700 us)
 [ 8] count:    1,  width:    65 [65;65]        ( 260 us)
Level estimates [high, low]:   6059,     11
Frequency offsets [F1, F2]:    2297,      0     (+8.8 kHz, +0.0 kHz)
Guessing modulation: No clue...

As you can see, the signal itself is incredibly simple. Perhaps I can just check for 56 78 73 00 and leave it at that...

Any suggestions on how best to tackle this?

[zuckschwerdt]

This looks like the typical x1527 OTP encoder output (http://sc-tech.cn/en/hs1527.pdf). The only way to distinguish these devices is to get the precise timing (i.e. OOK_PULSE_PWM_PRECISE).

[BenWoodford]

For my own purposes I only really need to identify the one output and notify my automation server that the doorbell was pressed.

Realistically all I want to do is get the same output of bytes into the device callback, maybe double check the values, then do something in response. But from what I’ve seen so far if I modify the limits and modulation it modifies what is passed to the callback. How can I get the exact same output as the analyser gives?

[zuckschwerdt]

It isn't feasible right now to add decoders for those doorbell-style devices as the main check on the data would be the individual code. There would be rather much false positives otherwise.
The general purpose decoder would perhaps be a good solution to this. I need to integrate it better, add JSON output and perhaps a filter option for a given known code.
If you upload a sample (preferably a single verified good signal) I can give you an example configuration for gdecode.

[zuckschwerdt]

I have added structured JSON output to the gdecode now. You should be able to test with consumers now.

[BenWoodford]

Shall upload a signal or two once I’m back at my desk, thanks for updating it with JSON output. 👍

[BenWoodford]

https://www.dropbox.com/s/qts0402cxymhxne/g001_433.92M_250k.cu8?dl=0

[zuckschwerdt]

It's 800 us per bit
with either 600 us pulse + 200 us gap
or 200 us pulse + 600 us gap.
with a packet spacing of ~6000 us (actually thats the preamble of the next packet...).

So rtl_433 -q -F json -X doorbell:OOK_PWM_RAW:400:800:7000
will give you the whole transmission in one JSON,
or rtl_433 -q -F json -X doorbell:OOK_PWM_RAW:400:800:800
will give you individual JSON per packet.

Enabling a filter on the minimum bit length might be good:
rtl_433 -q -F json -X doorbell:OOK_PWM_RAW:400:800:7000:0:24
or
rtl_433 -q -F json -X doorbell:OOK_PWM_RAW:400:800:800:0:24

This might be a good example to add more filters to gdecode :)
But I need to come up with a good syntax, all : is a mess.

[BenWoodford]

Maybe -X "name=doorbell;modulation=OOK_PWM_RAW;etc..."?

Shall try those out, thanks :)

[BenWoodford]

Perfect! Just tried the one with the minimum bit length and 99.99% of the time I only get one message per button press.

There's not a way to have say, an x second delay between detections in rtl_433 is there? Just so it doesn't ping more than once in a period of time.

[BenWoodford]

Oh uh, slight issue actually

My car keys fire the same event. Any ideas how I can avoid that?

[zuckschwerdt]

I doubt that there will be significant overlap. Car keys will have a long rolling code. The signal will have much more bits and always be different.

[BenWoodford]

When I say they fire the same event, I mean they do actually get picked up by rtl_433 -q -F json -X doorbell:OOK_PWM_RAW:400:800:7000:0:24 and sent over MQTT. Had do disable it for now as next door was ringing our doorbell with their car keys.

[zuckschwerdt]

Ok, yes. You should filter on {"len" : 24, "data" : "a9878c"}, mostly reported as {"len" : 25, "data" : "a9878c80"}. I.e. require len>=24 and data.startsWith("a9878c") :)

[zuckschwerdt]

Use something like https://github.com/zuckschwerdt/rtl_433_relay/blob/master/rtl_433_mqtt_relay.py with the JSON-UDP feature from https://github.com/zuckschwerdt/rtl_433/tree/develop -- we need to improve the MQTT output or include the raw JSON-UDP someday.
The gdecode should have filters like match=a9878c some time soon!

[BenWoodford]

Awesome thanks, shall give this a go at some point :)

[zuckschwerdt]

the gdecode feature now supports row matching:

rtl_433 -q -F json -X "doorbell:OOK_PWM_RAW:400:800:800,match={24}0xa9878c"

has you covered! (Or

rtl_433 -q -F json -X "doorbell:OOK_PWM_RAW:400:800:7000,match={24}0xa9878c,minrepeats=3,minbits=24"

if you prefer to get a single event and filter flukes.)

[BenWoodford]

You are awesome! Shall try this out and let you know

[BenWoodford]

Seems to have done it! It now identifies my key as a ford remote rather than a doorbell.

Looks like it still falls back to checking other devices if the generic decoder doesn't work, which is also great. Means I might be able to listen in on my Loop Energy Monitor...

[zuckschwerdt]

If you use -R 0 all other decoders will be diabled. Best to use -R n for all decoders you are interested in. Long term all decoders with false positives will be deactivated by default. Ford-remote, Generic-remote, Smoke-detector, … those.

[zuckschwerdt]

Also there is now an countonly-option to shorten the JSON output when you use matches.

rtl_433 -q -F json -R 0 -X "pir:OOK_PWM_RAW:800:2000:13000,match={24}0x5a1ea6,minrepeats=3,countonly" -r gfile005.data

{"time" : "@1.048576s", "model" : "pir", "count" : 24}

instead of

rtl_433 -q -F json -R 0 -X "pir:OOK_PWM_RAW:800:2000:13000,match={24}0x5a1ea6,minrepeats=3" -r gfile005.data

{"time" : "@1.048576s", "model" : "pir", "count" : 24, "num_rows" : 25, "rows" : [{"len" : 25, "data" : "5a1ea680"},
 {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"},
 {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"},
 {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"},
 {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"},
 {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"},
 {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 25, "data" : "5a1ea680"}, {"len" : 16, "data" : "5a1f"}]}

[macropin]

Hey all,

Found my way here trying to capture a HPM doorbell (for integration with Home Assistant). It uses a CIR2262BM encoder with a fixed code.

Through trial and error I have ascertained that rtl_433 -q -F json -X doorbell:OOK_PPM_RAW:400:800:8000 works to capture all doorbells in the neighbourhood, or rtl_433 -q -F json -X doorbell:OOK_PPM_RAW:400:800:8000,match={24}0x******,repeats=2,bits=24 to capture my specific doorbell.

May I suggest that we document these settings, along with a basic process for reverse engineering? I think this would be of immense benefit for those unfamiliar with this project.

Cheers!

[zuckschwerdt]

Yes, a HOWTO would be great for these doorbell-style devices as each one likely needs it's own timing and filter/match.
@rp3tya is working on something (machine parseable even) in #683 -- maybe you can join forces.
Maybe a HOWTO.md with all the steps (finding the signal, frequency, getting a sample (-a -t), getting the timings (-A) and writing a deocder(-X) would be useful alongside a parseable reference likle @rp3tya is doing. PR or a simple text here welcome!

[merbanan]

This issue and the follow up issues have all been resolved. Closing issue.