Some updates for Door Windows sensors

[gedger]

After testing 2 door / window sensors type HS3MAG1S I have decoded some additional flags, see captures/decode below. Will be looking to modify rtl_433 to include these additional fields.

May be of use.

Raw data from capturing 2 door windows sensors, unfortunately only got tamper from one sensor.

                        |----- DEVICE ID ------|   ????   |DT|   ???? ???? ???? ?COT R?LP                         
Tamper - 933690500011 = 1001 0011 0011 0110 1001 / 0000 / 0101 / 0000 0000 0000 0001 0001
Close -  933690500041 = 1001 0011 0011 0110 1001 / 0000 / 0101 / 0000 0000 0000 0100 0001
Open -   933690500021 = 1001 0011 0011 0110 1001 / 0000 / 0101 / 0000 0000 0000 0010 0001

Close -  8f45b0500049 = 1000 1111 0100 0101 1011 / 0000 / 0101 / 0000 0000 0000 0100 1001
Open -   8f45b0500020 = 1000 1111 0100 0101 1011 / 0000 / 0101 / 0000 0000 0000 0010 0000

? = UNKNOWN
DT = Device Type
C = Sensor closed
O = Sensor Opened
T = Sensor Tampered
R = Relay
L = Low battery
P = Parity

Decoding into similar format used here.

# Frame bits used in Honeywell RCWL300A, RCWL330A, Series 3, 5, 9 and all Decor Series Wireless Chimes
# 0000 0000 1111 1111 2222 2222 3333 3333 4444 4444 5555 5555
# 7654 3210 7654 3210 7654 3210 7654 3210 7654 3210 7654 3210
# XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XX.. XXX. .... KEY DATA (any change and receiver doesn't seem to recognize signal)
# XXXX XXXX XXXX XXXX XXXX .... .... .... .... .... .... .... KEY ID (different for each transmitter)
# .... .... .... .... .... 0000 0... 0000 0000 00.. 0... .... KEY UNKNOWN 0 (always 0 in devices I've tested)
# .... .... .... .... .... .... .XXX .... .... .... .... .... DEVICE TYPE (10 = doorbell, 01 = PIR Motion sensor, 101 = door/window)
# .... .... .... .... .... .... .... .... .... ..XX .XXX XXX. FLAG DATA (may be modified for possible effects on receiver)
# .... .... .... .... .... .... .... .... .... ..XX .... .... ALERT (00 = normal, 01 or 10 = right-left halo light pattern, 11 = full volume alarm)
# .... .... .... .... .... .... .... .... .... .... .XX. .... DOOR/WINDOW (10 = Closed, 01 = Opened)
# .... .... .... .... .... .... .... .... .... .... ...X .... SECRET KNOCK (0 = default, 1 if doorbell is pressed 3x rapidly or door/window tamper)
# .... .... .... .... .... .... .... .... .... .... .... X... RELAY (1 if signal is a retransmission of a received transmission, only some models)
# .... .... .... .... .... .... .... .... .... .... .... .X.. FLAG UNKNOWN (0 = default, but 1 is accepted and I don't observe any effects)
# .... .... .... .... .... .... .... .... .... .... .... ..X. LOWBAT (1 if battery is low, receiver gives low battery alert)
# .... .... .... .... .... .... .... .... .... .... .... ...X PARITY (LSB of count of set bits in previous 47 bits)

[klohner]

Thank you, great info. I'll integrate into documentation.

[gedger]

Great. One question if you can remember from your testing? From my monitoring the bell push sends the same 48 bit data packet 24 times. When a doorbell with a repeat function receives it does it resend the 48 bit data immediately it receives it or does it wait until its received all 24 packets before repeating the same data 24 times with the relay bit set?

Packet1, Repeated Packet1, Packet2, Repeated Packet2....
Packet1, Packet1, Packet3...24 - Repeated Packet 1, 2, 3...

Thanks

[klohner]

From what I remember, a receiver with a relay function only needs to receive a small number of the original data packets from a transmitter to recognize the signal. Once seen, it waits a short time before transmitting a full relay signal of 24 repetitions with the relay bit set. This delay typically seems to be long enough that a transmitter would have typically stopped transmitting.

I believe I spoofed very short signals (maybe 5 repetitions of the packet) and the repeater would still do a normal full relay signal.
And if spoofing a much longer signal, and the repeater would start to transmit its relay signal on top of it, so it wasn't based on sensing that a transmitter had stopped transmitting.

So, I believe your "Packet1, Packet1, Packet3...24" from the original transmitter, then the "Repeated Packet 1, 2, 3...24" (with relay bit set) from the receiver/relay device is accurate.

[gedger]

Thanks for the info. For some reason rtl_433 is often failing to receive the relayed messages. I'll have to debug....I'm wondering if it's because the default bitbuffer is 25 rows and the 24 rows of ActivLink is filling it up and then rtl_433 is busy trying to decode this whilst the relayed message is being transmitted so it misses it but that's just a guess...

…

On Tue, 4 Aug 2020 at 00:37, Karl ***@***.***> wrote: From what I remember, a receiver with a relay function only needs to receive a small number of the original data packets from a transmitter to recognize the signal. Once seen, it waits a short time before transmitting a full relay signal of 24 repetitions with the relay bit set. This delay typically seems to be long enough that a transmitter would have typically stopped transmitting. I believe I spoofed very short signals (maybe 5 repetitions of the packet) and the repeater would still do a normal full relay signal. And if spoofing a much longer signal, and the repeater would start to transmit its relay signal on top of it, so it wasn't based on sensing that a transmitter had stopped transmitting. So, I believe your "Packet1, Packet1, Packet3...24" from the original transmitter, then the "Repeated Packet 1, 2, 3...24" (with relay bit set) from the receiver/relay device is accurate. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBOFJ42S2UE2BCHXSTXMN3R65C3RANCNFSM4PRUKDJA> .