Yale 6010 door/window sensors

[Peter Haban]

Good afternoon,

First off, thanks for rtl_433 which has helped me a lot to get this far!

I'm trying to get a number of Yale door/window sensors to work with rtl_433 and was hoping you might be able to help. I've got the following in place already:

- Home Assistant install linked to a variety of other things (MQTT broker running).

- Separate client ready to send messages to HA broker.

- Separate client, Ubuntu 20.04 with NESDR Mini 2+, RTL-SDR and RTL_433 (also got a HackRF One which I used for testing before I got the NESDR).

- Working Yale security system with a number of door/window sensors (they appear to be HSA 6010s).

My obvious aim is to let the client fish out the messages from the HSA 6010 sensors and then feed them into HA via MQTT. It looks like RFLink supports these sensors so hopefully won't be too difficult to implement.

I can listen into traffic with the Ubuntu client and it picks up a neighbours weather station ok but it didn't pick up the Yale door/window sensors. rtl_433 -A does pick up my sensors so I'm hoping you might be able to help get them set up so they work with rtl_433? I get the following from listening into two sensors, they are security sensors so only send "open" (no "close", I can capture the message for pressing the binding button as well if anyone can see a use for this). Copy and past from running rtl_433 -A and opening two different sensors and I'm getting the same output consistently for each sensor trigger, happy to run other commands if you let me know what is needed :)

Satellite-Pro-L500-1D2:~$ rtl_433 -A

rtl_433 version unknown inputs file rtl_tcp RTL-SDR SoapySDR

Use -h for usage help and see https://triq.org/ for documentation.

Trying conf file at "rtl_433.conf"...

Trying conf file at "/home/testy/.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"...

Registered 122 out of 149 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 ]

Found Rafael Micro R820T tuner

Exact sample rate is: 250000.000414 Hz

[R82XX] PLL not locked!

Sample rate set to 250000 S/s.

Tuner gain set to Auto.

Tuned to 433.920MHz.

Detected OOK package 2020-07-16 15:07:05

Analyzing pulses...

Total count:  756,  width: 1599.14 ms (399785 S)

Pulse width distribution:

 [ 0] count:   54,  width: 5372 us [5228;5972] (1343 S)

 [ 1] count:  360,  width: 1456 us [1444;1484] ( 364 S)

 [ 2] count:  342,  width:  844 us [716;876] ( 211 S)

Gap width distribution:

 [ 0] count:  405,  width:  372 us [344;388] (  93 S)

 [ 1] count:  350,  width:  980 us [956;996] ( 245 S)

Pulse period distribution:

 [ 0] count:   54,  width: 5748 us [5608;6356] (1437 S)

 [ 1] count:  225,  width: 2440 us [2428;2452] ( 610 S)

 [ 2] count:  216,  width: 1220 us [1212;1232] ( 305 S)

 [ 3] count:  260,  width: 1824 us [1704;1844] ( 456 S)

Level estimates [high, low]:  15999,     41

RSSI: -0.1 dB SNR: 25.9 dB Noise: -26.0 dB

Frequency offsets [F1, F2]:    7254,      0 (+27.7 kHz, +0.0 kHz)

Guessing modulation: Pulse Width Modulation with sync/delimiter

Attempting demodulation... short_width: 844, long_width: 1456, reset_limit: 1000, sync_width: 5372

Use a flex decoder with -X 'n=name,m=OOK_PWM,s=844,l=1456,r=1000,g=0,t=0,y=5372'

pulse_demod_pwm(): Analyzer Device

bitbuffer:: Number of rows: 25 

[00] {13} 54 f8     : 01010100 11111

[01] {13} 57 b0     : 01010111 10110

[02] {13} 55 60     : 01010101 01100

[03] {13} 50 98     : 01010000 10011

[04] {13} 50 08     : 01010000 00001

[05] {13} 5d 58     : 01011101 01011

[06] {13} 54 f8     : 01010100 11111

[07] {13} 57 b0     : 01010111 10110

[08] {13} 55 60     : 01010101 01100

[09] {13} 50 98     : 01010000 10011

[10] {13} 50 08     : 01010000 00001

[11] {13} 5d 58     : 01011101 01011

[12] {13} 54 f8     : 01010100 11111

[13] {13} 57 b0     : 01010111 10110

[14] {13} 55 60     : 01010101 01100

[15] {13} 50 98     : 01010000 10011

[16] {13} 50 08     : 01010000 00001

[17] {13} 5d 58     : 01011101 01011

[18] {13} 54 f8     : 01010100 11111

[19] {13} 57 b0     : 01010111 10110

[20] {13} 55 60     : 01010101 01100

[21] {13} 50 98     : 01010000 10011

[22] {13} 50 08     : 01010000 00001

[23] {13} 5d 58     : 01011101 01011

[24] {13} 5f f8     : 01011111 11111

... Maximum number of rows reached. Message is likely truncated.

Detected OOK package 2020-07-16 15:10:40

Analyzing pulses...

Total count:  756,  width: 1599.47 ms (399868 S)

Pulse width distribution:

 [ 0] count:   54,  width: 5356 us [5208;5948] (1339 S)

 [ 1] count:  441,  width: 1428 us [1304;1444] ( 357 S)

 [ 2] count:  261,  width:  820 us [816;836] ( 205 S)

Gap width distribution:

 [ 0] count:  486,  width:  396 us [388;412] (  99 S)

 [ 1] count:  269,  width: 1004 us [996;1016] ( 251 S)

Pulse period distribution:

 [ 0] count:   54,  width: 5752 us [5608;6356] (1438 S)

 [ 1] count:  233,  width: 2436 us [2316;2456] ( 609 S)

 [ 2] count:  225,  width: 1220 us [1208;1236] ( 305 S)

 [ 3] count:  243,  width: 1828 us [1816;1848] ( 457 S)

Level estimates [high, low]:  15936,     11

RSSI: -0.1 dB SNR: 31.6 dB Noise: -31.7 dB

Frequency offsets [F1, F2]:   13159,      0 (+50.2 kHz, +0.0 kHz)

Guessing modulation: Pulse Width Modulation with sync/delimiter

Attempting demodulation... short_width: 820, long_width: 1428, reset_limit: 1020, sync_width: 5356

Use a flex decoder with -X 'n=name,m=OOK_PWM,s=820,l=1428,r=1020,g=0,t=0,y=5356'

pulse_demod_pwm(): Analyzer Device

bitbuffer:: Number of rows: 25 

[00] {13} 54 88     : 01010100 10001

[01] {13} 50 28     : 01010000 00101

[02] {13} 55 68     : 01010101 01101

[03] {13} 50 80     : 01010000 10000

[04] {13} 50 08     : 01010000 00001

[05] {13} 5d 60     : 01011101 01100

[06] {13} 54 88     : 01010100 10001

[07] {13} 50 28     : 01010000 00101

[08] {13} 55 68     : 01010101 01101

[09] {13} 50 80     : 01010000 10000

[10] {13} 50 08     : 01010000 00001

[11] {13} 5d 60     : 01011101 01100

[12] {13} 54 88     : 01010100 10001

[13] {13} 50 28     : 01010000 00101

[14] {13} 55 68     : 01010101 01101

[15] {13} 50 80     : 01010000 10000

[16] {13} 50 08     : 01010000 00001

[17] {13} 5d 60     : 01011101 01100

[18] {13} 54 88     : 01010100 10001

[19] {13} 50 28     : 01010000 00101

[20] {13} 55 68     : 01010101 01101

[21] {13} 50 80     : 01010000 10000

[22] {13} 50 08     : 01010000 00001

[23] {13} 5d 60     : 01011101 01100

[24] {13} 5d e8     : 01011101 11101

... Maximum number of rows reached. Message is likely truncated.

[Christian Z.]

The guessed protocol looks plausible but the data length (13 bits) and the random payload doesn't.

Best to grab some samples (rtl_433 -S all) and look at them. https://triq.org/iqs/ for the .cu8 to see if the transmission looks ok.

Then rtl_433 -w FILE.ook FILE.cu8 and check with https://triq.org/pdv/ how the pulses are organized. Also post the .cu8 and .ook here if you like.

[Peter Haban]

Thanks for the quick reply, very much appreciated :)

I've run rtl_433 -S all which seems to create a separate file for each thing it captures? By triggering the sensor a few times I got several files of equal size and two of smaller size which are likely other devices (neighbour has a chatty weather station). I've taken one of those files and fed it into the next step, resulting ook and cu8 attached.

I'm somewhat new to this so not sure how to work triq.org but happy to keep getting more files/run commands if you can guide me as to what I need to do...

[Christian Z.]

Good clean signal in the .cu8 with one unusual quirk: the idle level is "pulse" and the data is in the gaps. Doesn't matter to the PWM demod, the .ook looks clean and the guess in the pulse viewer works (matches the flex decoder guess above).

So this really is the data sent. The question now, why so many different codes and is there something in the sequence? Perhaps you can make a dictionary of those codes (e.g. 5488 = A, 5028 = B,...) and try to find a pattern?

To make the output more reliable you can use: rtl_433 -R 0  -X 'n=name,m=OOK_PWM,s=820,l=1428,y=5356,r=1020'

[Benjamin Larsson]

r should be 10000 or so.

/Benjamin

[Christian Z.]

r should be 10000 or so.

The longest gap actually is shorter than 1000 µs. Gaps and pulses are swapped so to speak. So 1100 or the 1020 from the guess are good.

[Greg Troxel]

Security devices that are sound will be paired and have cyrpto.
That may or may not apply to these :-)

[Peter Haban]

Two hours of capturing and detective work later... think I've got the pattern, it's consistent across the sensors I've got and hopefully another step in the right direction.

I've captured messages for "trigger <- contact opened", "binding <- press button on sensor" and tamper "<- spring on the back of sensor which is set off but taking sensor cover off". Results attached but what I'm seeing is the following:

[00] - [02] are consistently the same for each sensor for each message : ID

[03]: No obvious use

[04] : "50 80 = trigger", "50 18 = binding", "50 20 = tamper"

[05]: No obvious use

In other words it looks like the first three are the unique sensor ID, the last three are the message where the actual information sits in the middle and is unique for each message type and then gets surrounded by some sort of packaging on the outside ones.

Hope that makes sense, the only other message I think there would be is "low battery" but so I'll have a look for a half empty battery... also got a PIR for this and a remote fob but let's see if we can get this to work first...

Is this enough or do we need anything else?

[Peter Haban]

Found my spare PIR, messages follow the same pattern. Having said that this seems to reveal another bit of the pattern, the device type.

All the door/window sensors have [03] {13} 50 XX and the PIR has [03] {13} 51 XX so I'd suspect 50=door/window and 51=PIR.

PIR binding

[00] {13} 57 f0     : 01010111 11110

[01] {13} 52 18     : 01010010 00011

[02] {13} 50 a8     : 01010000 10101

[03] {13} 51 90     : 01010001 10010

[04] {13} 50 18     : 01010000 00011

[05] {13} 5b a8     : 01011011 10101

PIR trigger

[00] {13} 57 f0     : 01010111 11110

[01] {13} 52 18     : 01010010 00011

[02] {13} 50 a8     : 01010000 10101

[03] {13} 51 90     : 01010001 10010

[04] {13} 50 08     : 01010000 00001

[05] {13} 5b b8     : 01011011 10111

PIR tamper

[17] {13} 57 f0     : 01010111 11110

[18] {13} 52 18     : 01010010 00011

[19] {13} 50 a8     : 01010000 10101

[20] {13} 51 90     : 01010001 10010

[21] {13} 50 20     : 01010000 00100

[22] {13} 5b a0     : 01011011 10100

[Benjamin Larsson]

g021_433.92M_250k.cu8

in https://github.com/merbanan/rtl_433/issues/1435


gives this output:

[00] {13} 55 50 : 01010101 01010
[01] {13} 55 e8 : 01010101 11101
[02] {13} 50 48 : 01010000 01001
[03] {13} 51 80 : 01010001 10000

[04] {13} 50 08 : 01010000 00001

[05] {13} 5a f8 : 01011010 11111

Looks very very similar to this pattern.

MvH
Benjamin Larsson

[Christian Z.]

How many different codes (the 13 bit patterns) did you find? I'm wondering if those 13 bit chunks are something like a 4-to-13 encoding, i.e. each data nibble is transmitted as a 13 bit pattern?

[Benjamin Larsson]

Complete output.

Test mode active. Reading samples from file: g021_433.92M_250k.cu8
Detected OOK package @0.080596s
Analyzing pulses...
Total count: 756, width: 1629.35 ms (407338 S)
Pulse width distribution:
[ 0] count: 54, width: 5900 us [5676;5952] (1475 S)
[ 1] count: 396, width: 1428 us [1404;1440] ( 357 S)
[ 2] count: 306, width: 804 us [668;828] ( 201 S)
Gap width distribution:
[ 0] count: 441, width: 400 us [392;428] ( 100 S)
[ 1] count: 314, width: 1020 us [1004;1044] ( 255 S)
Pulse period distribution:
[ 0] count: 54, width: 6300 us [6072;6352] (1575 S)
[ 1] count: 225, width: 2448 us [2436;2472] ( 612 S)
[ 2] count: 216, width: 1212 us [1192;1228] ( 303 S)
[ 3] count: 260, width: 1824 us [1700;1860] ( 456 S)
Level estimates [high, low]: 2246, 69
RSSI: -8.6 dB SNR: 15.1 dB Noise: -23.8 dB
Frequency offsets [F1, F2]: 5642, 0 (+21.5 kHz, +0.0 kHz)

Guessing modulation: Pulse Width Modulation with sync/delimiter

Attempting demodulation... short_width: 804, long_width: 1428,
reset_limit: 1048, sync_width: 5900

Use a flex decoder with -X

'n=name,m=OOK_PWM,s=804,l=1428,r=1048,g=0,t=0,y=5900'

pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 25

[00] {13} 55 50 : 01010101 01010
[01] {13} 55 e8 : 01010101 11101
[02] {13} 50 48 : 01010000 01001

[03] {13} 51 80 : 01010001 10000

[04] {13} 50 08 : 01010000 00001

[05] {13} 5a f8 : 01011010 11111
[06] {13} 55 50 : 01010101 01010
[07] {13} 55 e8 : 01010101 11101
[08] {13} 50 48 : 01010000 01001
[09] {13} 51 80 : 01010001 10000

[10] {13} 50 08 : 01010000 00001

[11] {13} 5a f8 : 01011010 11111
[12] {13} 55 50 : 01010101 01010
[13] {13} 55 e8 : 01010101 11101
[14] {13} 50 48 : 01010000 01001
[15] {13} 51 80 : 01010001 10000

[16] {13} 50 08 : 01010000 00001

[17] {13} 5a f8 : 01011010 11111
[18] {13} 55 50 : 01010101 01010
[19] {13} 55 e8 : 01010101 11101
[20] {13} 50 48 : 01010000 01001
[21] {13} 51 80 : 01010001 10000

[22] {13} 50 08 : 01010000 00001

[23] {13} 5a f8 : 01011010 11111

[24] {13} 5f f8 : 01011111 11111
... Maximum number of rows reached. Message is likely truncated.

MvH
Benjamin Larsson

[Peter Haban]

I've played with my captured data in Excel, spreadsheet attached. Short summary:

Number of Messages: 252

Number of distinct Messages: 74

Eight messages come up more than 10 times and seem specific to either a specific position in the message ([00]-[05]) or type of message (Binding, trigger, tamper).

Does that make sense?

Kind Regards,

Peter

[Christian Z.]

Thanks! That's far more distinct messages than expected. If you remove the common 0101 (0x5) prefix you're left with 9 bits, 512 possible codes. With already 74 distinct codes seen (needs at least 7 bits) that leaves room for one or two bits of parity or such 7-to-9 encoding.

I'll need to take a deeper look at the codes to figure that out, doesn't look like parity (you'd expect only even or only odd count of bits).

[Christian Z.]

Peter,

due to being nudged again by another user I took a deeper dive in the data you prepared so well.

See the results here https://github.com/merbanan/rtl_433/issues/1929#issuecomment-1007570553

TL;DR yes, messages of 6 byte-size packets, not encrypted at all.