Paradox Wireless Reed Switch

Each Paradox Wireless reed has its own Serial Number, once the Alarm panel has the serial added, it will listen for 5 static signals from the W Reed. Open/Close/Monitor/Tamper/no tamper. the Main ones i want are open/close as you can program a relay in the panel to activate whenever it receives a signal.
if i could get this protocol added, i would like to be able to create my own unique serial, and add it to the programming to activate a relay on my alarm panel. i currently have a few raw files that ive tested with success and have labeled them with their assigned Serial Number# 117236
they are 433MHz at AM650

Dct10_117236_close_2.sub (16.0 KB)
Dct10_117236_opn_2.sub (10.8 KB)
Dct10_117236_Tamper.sub (52.0 KB)
Dct10_117236_opn.sub (5.7 KB)


how did you press the button on the remote when recording the signal?
make at least a non-normal recording so that I can determine the transmission parameters, namely, record 1 button with failures 10+ times with pressing the button pressed 3+ seconds each time

also I need records of all events
Open/Close/Control/Intervention/No intervention.
so that I can find differences in gears and add support from them. where is a photo of the insides of the console with wet circuits, perhaps we can get more information

sorry as a new user, i was restricted in how many files i can upload
Dct10_117236_Tampr_off.sub (9.9 KB)



ill get some extra raw signals asap

so when i remove the magnet from the Reed switch, it auto sends a signal, when i replace the magnate, it sends another signal, i will record a long file of moving the magnet multiple times, i should also be able to repeat this with a different device and serial number

???

ive triggered the close>Open signals about 10x each in the attached file


SN-117236 Close-Open-Close RPT.sub (60.5 KB)

good

i have a second reed with a different serial number, i will upload those as well



SN236078 close-open-etc.sub (101.2 KB)

and this is even better

I have another capture, it’s of a relay on the first module. It’s abit more dumb, as it purely sends an open / closed signal. It’s serial number is also 1 digit higher than the primary transmitter so it should be unique but only a little.

SN117237_Close_open_close_etc.sub (299.0 KB)

Sorry it’s taken a while to upload these also, had to modify the reeds to get a steady signal on the relays, so this signal is 1 digit higher than the 2nd transmitter.

Sn236079_clos_opn_clos_etc.sub (634.9 KB)

so if anyone is interested, we follow the hands … we have an unknown protocol in an unknown encoding … we collect as many records from the consoles as possible and just paint, insert 1 parcel in the scale under the other


looking for similarities and differences… trying to figure out how the transmission is encoded… my first guess was that it was Manchester. but if you look closely at the levels, you can see that there is no clear 2 short in a row (this is mandatory in Manchester)

We also know that the last 2 parcels have serial numbers that differ by only one. that is, the signals should be similar. but the serial number must differ by 1 bit. what we see…
that is, if you look carefully, we see that the bits are encoded 3t and since the penultimate sending is less than the last by 1, then the different bit should be (in theory) 0 (2t up 1t low =0), (1t up 2t low =1). let’s stop there for now and write a decoder for this waveform

3 Likes

we continue our research. we wrote a decoder that decodes the package. received parcels from different consoles. we know which button we pressed and sometimes the serial number of the remote control is written on the key fob itself. we have a set of decoded parcels. we translate it into BIN and start looking for similarities and differences

we notice that parcels from key fobs with serial numbers with similar serial numbers almost do not differ at the beginning.
the penultimate byte of the send is repeated in different sends when you press the same button (maybe this is the button code). the last byte is always different, but the same when the button is pressed again. so this is (presumably) the CRC of the send, so this is 1 byte, again assume that this is CRC-8 (maybe this is not so, maybe just the sum of all bytes with overflow or something else). we run the CRC-8 brute over the entire range of the polynomial and the start bit. and O miracle!!!

2 Likes

Wow SkorP, Impressive Work. Being quite new to subGhz, everytime you reply I have a ton of research I’m doing to try and keep up. I’m supposed to be learning Dynet at the same time so really appreciating all the work your putting in mate :+1:t2: having access to this protocol will help heaps debugging at work.

serial number encoding assumptions.

## Mommy Ali͎na *—* Сегодня, в 13:23

236 dec = 11101100; reversed 00110111 … now see where you can spot that sequence in the serials. maybe they're encoded in packets of 3 decimal digits. Let's test the theory serial is 117:236 117 dec = 1110101; reversed that's 1010111(0) right padded to 8 places 236 dec = 11101100; reversed that's 00110111 00110111 : 10101110 there's your first serial, let's try with the last one serial is 236:079 236 dec = 11101100; reversed that's 00110111 079 dec = 1001111; reversed that's 1111001(0) right padded to 8 places 11110010 : 00110111 bam
2 Likes

and so we see. that the serial number is “encoded” simply as a 2-byte number with bits reversed.

2 Likes

Way to go ‘mommy alina’ great pickup

as a result, for the correct decoding of the signal, we need

  1. correctly receive the signal and check its checksum (last byte)
  2. bitwise reverse the first 3 bytes and parse the values
  3. display all values ​​on the screen
1 Like

@Russell_Coight
please check the reception and most importantly tell me what button numbers are displayed on the screen and what do they mean? in the torii, the numbers of buttons with the same functions must match on different remotes