alecapu80 commented 4 years ago

Hi All I'm looking for someone to help me to decode RISCO 868.64M OOK wireless alarm sensors. It seems very simple, but I'm not able to identify the correct parameters for the decoder to have stable results.

I attached some dump, there is someone that has fun in decoding that can help me? RISCO OOK Dump.zip

Thank you very much. Dump is captured with: ./rtl_433 -A -R 0 -f 868.64M -S all

zuckschwerdt commented 4 years ago

@merbanan can you check this out? The new demod sees a level for the whole frame, i.e. the "silent" parts are seen as 1.

merbanan commented 4 years ago

What does the old pulse detector see? -Y 0.

zuckschwerdt commented 4 years ago

Heads up: I've just now changed the -Y option to guard against missing argument and make it a bit more flexible. Current master now has:

  [-Y auto | classic | minmax] FSK pulse detector mode.

So on latest master you want -Y classic.

alecapu80 commented 4 years ago

I've tried with git master. No better. Some file seems to be decoded quite well other not.... but the capture seems to be good.

merbanan commented 4 years ago

@zuckschwerdt this is not a FSK modulated sample, not sure what I am supposed to look at.

merbanan commented 4 years ago

build/src/rtl_433 -r g00*_868.64M_250k.cu8 -X 'n=name,m=OOK_PWM,s=1300,l=2000,r=8044,g=1,t=212,y=0' give quite stable readings. The signal is more like ASK so the pulse decoding is of low quality.

zuckschwerdt commented 4 years ago

My bad. I was just surprised to see the Pulseview show a level in the noise. E.g. this part:

signal

Looks like there is just noise around the signal, but that's not what Pulseview shows:

pulseview

The OOK looks clean enough. Not sure what's causing the level in the whole frame?

zuckschwerdt commented 4 years ago

It sure decodes like ASK, but I don't see any carrier there?

alecapu80 commented 4 years ago

The signal is generated with an ASK Transmitter - 868/915 MHz TH72032 https://www.melexis.com/en/product/TH72032/ASK-Transmitter

With a fref = 27.145Mhz quartz.

So the fc = fref*32 = 868,64Mhz

merbanan commented 4 years ago

@zuckschwerdt what file? I dont have that in my output.

zuckschwerdt commented 4 years ago

That's g001_868.64M_250k.cu8. Did I break my Sigrok/Pulseview?

merbanan commented 4 years ago

There are 2 different signals in the sample files. g001 and g002 are different ones IIRC. I'll check when I get home.

alecapu80 commented 4 years ago

oh strange, probably I've captured something else on the same band. I'll try to do other capture later. Thank you

merbanan commented 4 years ago

@zuckschwerdt somehow your version inverted everything, it looks good on my system.

klohner commented 4 years ago

Seems like ASK, 752μs symbol length, and I see what looks like a weird pseudo-FSK decaying noise after each ASK symbol. I found only 3 unique messages across these sample files.

Here's my stab at a decoding: bitbench

Erwin1989 commented 3 years ago

Hi all,

I have also a Risco Alarm system.

I am trying to decode the signal (im 'm new at this so maby I say or understand something wrong).

I have 3 sensors were I made recordings off. When I use rtl_433 g00*_868.64M_250k.cu8 -s 250k -X 'n=name,m=OOK_MC_ZEROBIT,s=804,l=0,r=1456' i have some results (that are every time the same) that I can read like:

Type sensor? | ID? | State? Sensor1 549 | 15d | 12a (open) 549 | 15d | 1558 (closed)

Sensor 2 549 | d52 | 44d58 (closed) 549 | d52 | 44aa (open)

Sensor 3 549 | a70 | acaa (open) 549 | a70 | acd58 (closed)

Is this the right way to go? I want to use it later on in Home assistant or Domoticz.

merbanan commented 3 years ago

I think lots of alarm systems scramble their messages. Most likely by the id and some secret algorithm. But if they don't include a counter the messages can be uniquely mapped to a state. That is what you are doing here and what will work fine. If someone can dump the firmware for the sensor we can implement a complete decoder but without that a flex configuration decoder is what can be used.

merbanan commented 3 years ago

@Erwin1989 can you post some signal samples ?

Erwin1989 commented 3 years ago

Thanx for the fast response!

Here are de samples: Risco dump 28-3-2021.zip

Sensor 1 (G002/G004/G005/G007) Sensor 2 (G008/G009/G010/G011)

A dump from the firmware of the sensor is dificult i guess?

Erwin1989 commented 3 years ago

Hi Merbanan,

What can i do to help or how can i make a flex decoder?

I also have a spare sensor where i can solder off chips to read the nand flash to get de firmware dump but i need some help/instruction because i bever did something like this 😊

merbanan commented 3 years ago

Can you take a photo of the sensor pcb and identify the chips ? I'll try to look into the sensor signals later.

Erwin1989 commented 3 years ago

Here are some pictures:

Sensor 1 (spare sensor) - kopie.pdf Sensor 2.pdf

Sensor 1 (spare sensor not in use and can be used fore getting information)

TH72032.2 = transmitter, see https://datasheetspdf.com/pdf/860676/Melexis/TH72032/1.
PIC16F690 = Looks like this https://www.microchip.com/wwwproducts/en/PIC16F690.
3202v pecd = can find much about this one.

The other sensors that are in use are slightly diffrent but worning also on this system, see sensor 2

SI4432 = transmitter, see https://www.silabs.com/documents/public/data-sheets/Si4430-31-32.pdf.
PIC16F690 = Looks like this https://www.microchip.com/wwwproducts/en/PIC16F690.
VGCHNY = looks like this https://datasheet.lcsc.com/szlcsc/1809192240_STMicroelectronics-STM8L151G6U6TR_C85325.pdf

merbanan commented 3 years ago

Ok, the PIC16F690 can be read protected. I'm almost 100% sure it is. You can look at the base station to see if it is more easy to read out the firmware for that device.

Erwin1989 commented 3 years ago

The main panel has a RS-232 connection, see http://www.webwayworld.com/panel-guides/risco-lightsys-rs232 Is this a possible way to extract information?

Else I will make some pictures of the main panel and the connecting antenna panel (this part is additional and connected with 4 cables, see https://en-shop.sysaway.com/products/rp432ew8000a).

I will also try to get a export of the compleet firmware but that's also not something that is easy accessible for end-users.

merbanan commented 3 years ago

This is quite advanced hardware hacking. I could guide you but the time investment is significant (you need a little bit of hardware also). Think months of work time and even longer lead time. This is more of a task for someone who wants to reverse engineer the security system completely. Just buying something else or setup a flex-mapping is so much less painful. You would be ready in a few days vs maybe never. Not saying it's impossible just that its a lot of work.

Erwin1989 commented 3 years ago

I like to learn some new thing and investing in some hardware is also not a problem but maby this is for the longer term.

I want to try making the flex-mapping so if you have a guide or something that i can follow i can start doing that. Sideways i found the firmware of a other mainpanel (AgilytyV3) that is working with the same sensors. Maby we can get somthing of it. Im trying to open it with binwalk.

This is the file:

cpcp.zip

alecapu80 commented 3 years ago

Hi all, I have multiple same sensors and in the past, I have a bit reverted them. They use an ASK OOK raw modulator driven by a signal pin. I can try to recover my information asap. If you want, I can provide the SDR dump of some sensors plus the modulator's logic signal to decode correctly the ASK OOK modulation. But the protocol coding does not seem to be something standard.

Il giorno ven 2 apr 2021 alle ore 17:35 Erwin1989 @.***> ha scritto:

I like to learn some new thing and investing in some hardware is also not a problem but maby this is for the longer term.

I want to try making the flex-mapping so if you have a guide or something that i can follow i can start doing that. Sideways i found the firmware of a other mainpanel (AgilytyV3) that is working with the same sensors. Maby we can get somthing of it. Im trying to open it with binwalk.

This is the file:

cpcp.zip https://github.com/merbanan/rtl_433/files/6250193/cpcp.zip

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/1194#issuecomment-812581353, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFADZ3IYZ6VQDVJ2OBLVJXLTGXP2ZANCNFSM4JIZF3PA .

Erwin1989 commented 3 years ago

@alecapu80, I think all the information we can get will help :).

I am trying to decode the signal with Universal Radio Hacker. I connect the sensor with the configuration software from Risco and see the serialnumber that belong to the sensors so I know what information is send and trying to find out how its encoded. I saw that the receivermodule uses the SI4432 (https://www.silabs.com/documents/public/data-sheets/Si4430-31-32.pdf). I am figuring out what mode is being used, it can be encoded with manchester. ASK (OOK) gives me stable reading, also the product sheet tells us its 868.65 mhz and ASK modulated, see doc.pdf

pswiatki commented 2 years ago

@alecapu80 Do you have any additional info on that? I have several of those RISCO motion sensors (remote, battery powered of course) and would like to detect motion by sniffing packets from those devices.

kvdveer commented 1 year ago

I'm playing around with the same RWT72M door sensor, also with the intention of including it in my home automation. I did quite a bit of work before I was aware of this thread, so there was some duplicate effort

OSINT

fcc operation description is a goldmine. I specifies:

666bps, OOK, manchester, using 39-bit frames.
In normal mode, the frame consists of preamble, start bits, the transmitter ID, and some bits about transmitter status.
In learn mode, the frame consists of preable, start bits, transmitter id, and some indication of capabilities.
Communication is one-way: the door sensor cannot receive data.

The manual is less helpfull:

There are 3 messages that can be sent from the device: ALARM, RESTORAL and WRITE.
There may also be an intermittent status message, that is not explicitly named.

Captured data

In my captures, the radio introduces quite a lot of noise. (this might be because I'm incompetent, I'm new to SDR). I managed to find a testpoint (tp18) that seems to be the signal sent to the ratio. I've been able to capture this signal, and I've been trying to decode it. My decodings are still a bit sketchy, I need to hold my testprobe on the testpad while manipulating both tamper switches and the reed switch.

my decoded captures

Observations:

The manual suggests that there is a 24-bit unique identifier which is randomly generated. In my captures, this ID does indeed seem to be present: the first 24 bits after the preamble are different between devices, but the same within a device.
My captures are all 40 bits, not 39.
The first 6 bits are always 101010 (preamble & start bits?)
The following 24 bits are probably the device id. There is high correlation between bits, I think they are assigned sequentially, not random as the FCC docs suggest.
Then there's 1 bit that's always high
The following 8 bits seem to contain a message (or capability in case of the write message)
- 0x15 = door opened, tamper triggered
- 0x6a = door closed, while tampered
- 0x2a = door opened
- 0x55 = door closed
- 0xd5 = capabilities/write
Then there's 1 bit that's always high

zuckschwerdt commented 1 year ago

@kvdveer a preamble must terminate with some sync to be useful. I.e. you need to able to read a partial preamble and still be able to find the start of data. With Manchester this is usually done with a desync, i.e. a pattern that is not valid MC. But here it's plain 40 bits of data, so maybe the first ID bit (a zero in captures above) is that sync? In other words: is the actual ID maybe one bit to the right?

kvdveer commented 1 year ago

In other words: is the actual ID maybe one bit to the right?

That's a valid theory. We have this unvarying high bit at the end, so it might indeed be part of the id. Interestingly, all of the serial numbers on my units are odd, if the transmitted ID somehow encodes (part of) the serial#, that would match the trailing high bit.

I'm still having trouble getting good over-the-air captures. It seems that there is some interference (a much shorter pulse) somewhere, which leads to the frame being split up. This might be due to my setup though, I literally got into SDR to decode these sensors, and I have only done minimal work to the antenna (removing a short between antenna and ground). From what I understand, the stock antenna is crap, but I haven't quite figured out what I should do to improve it.

Here's two traces i made. I noticed that the background noise has a curved bias to the center tuned frequency, it is not as flat as other traces i've seen. This is true, regardless of the frequency I tune it to.

zuckschwerdt commented 1 year ago

The signal you captured is right on DC and also clipping. You must offset by around 25kHz and use more distance or remove the antenna.

kvdveer commented 1 year ago

I've detuned my sdr by 25kHz, and moved the antenna 1m away from my desk. results. This yields better results when using rtl_433 -f 868625000 -X modulation=OOK_MC_ZEROBIT,name=foo,short=750,l=1500,reset=1500,preamble={4}A.

I still see some problems:

Of the 8 frames that are sent, only one or two are successfully decoded.
On the close message, I seem to be missing the trailing bit. The open message does seem to have it. Might this be a parity problem? The trailing bit felt like padding to me anyway, so maybe this isn't an issue.
I seem to be missing the first 6 bits. Is this preamble&sync, and is this to be expected?
I can't seem to detect anything when using the -r parameter. My command is rtl_433 -r 11202373559_close.cu8 -X modulation=OOK_MC_ZEROBIT,name=foo,short=750,l=1500,reset=1500,preamble={4}A. Obviously I'm doing something wrong, but I can't figure out what.

Also: how did you spot that the signal was clipping? How can I check this for myself? (sorry, I'm still learning this stuff, thanks a lot for your time so far)

zuckschwerdt commented 1 year ago

For MC short and long need to be the same (NRZ) and reset should be 2.5x to 3x the half-bit length (i.e. short) as MC will regularly have 2 consecutive 0's.

zuckschwerdt commented 1 year ago

For -r you need -Y minmax to match the live -f 868.25M autoselection ("new defaults")

klohner commented 1 year ago

Please try this decoder and see how well it works for you:

# -X "n=Risco,m=OOK_PCM,s=760,l=760,r=2000,preamble={13}cccb2,symbol_one={2}8,symbol_zero={2}4,get=ID:[@0](https://github.com/0):{24},get=State:[@24](https://github.com/24):{2}:[0:UNKNOWN 1:NORMAL_01 2:NORMAL_02 3:WRITE_MESSAGE],get=Event:[@26](https://github.com/26):{2}:[0:OPEN+TAMPER 1:OPEN 2:CLOSED 3:CLOSED+TAMPER],get=UNKNOWN:[@28](https://github.com/28):{5}"
decoder {
    name=Risco_868Mhz,
    modulation=OOK_PCM,
    short=768,
    long=768,
    reset=2000,
    preamble={13}cccb2,
    symbol_one={2}8,
    symbol_zero={2}4,
    get=ID:[@0](https://github.com/0):{24},
    get=State:[@24](https://github.com/24):{2}:[0:UNKNOWN 1:NORMAL_01 2:NORMAL_02 3:WRITE_MESSAGE],
    get=Event:[@26](https://github.com/26):{2}:[0:OPEN+TAMPER 1:OPEN 2:CLOSED 3:CLOSED+TAMPER],
    get=UNKNOWN:[@28](https://github.com/28):{5}:,
}

kvdveer commented 1 year ago

I tried your latest suggestions (the earlier ones were mangled by github, unfortunately). I had to compile rtl433 myself, as the stock Ubuntu version doesn't understand symbol_one.

Your decoder captures some frames (1 in 10, I guess), but the data is not quite right. This might still be due to my setup, though.

My starting point is a non-tamper closed sensor (the way you'd normally find it in a home).

Opening the sensor gives:

time      : 2023-04-14 23:25:09
model     : Risco_868Mhz count     : 1             num_rows  : 1             rows      : 
len       : 0            data      :                         : 43828                   : UNKNOWN                 : OPEN+TAMPER             : @28
codes     : {0}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-04-14 23:25:09
model     : Risco_868Mhz count     : 1             num_rows  : 1             rows      : 
len       : 33           data      : 4c8167950               : 5013863                 : NORMAL_01               : OPEN                    : 9
codes     : {33}4c8167950

The zero-length frame is repeated several times, the 33 length frame is usually present (but not always). It seems to me that the 33-length frame is correct, although I can't quite understand where the 0-length frame reads its data from. I'd expect all-zeroes.

Closing the sensor gives:

time      : 2023-04-14 23:30:45
model     : Risco_868Mhz count     : 1             num_rows  : 1             rows      : 
len       : 2            data      : c                       : 12583122                : WRITE_MESSAGE           : CLOSED+TAMPER           : 24
codes     : {2}c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-04-14 23:30:45
model     : Risco_868Mhz count     : 1             num_rows  : 1             rows      : 
len       : 34           data      : 4c8167aac               : 5013863                 : NORMAL_01               : OPEN                    : 9
codes     : {34}4c8167aac

Here, the 2-length frame is repeated several time, but the 34-length frame is there once or twice. (if it's there at all). Also it seems to interpret this as an open event, even though it's a close event. In general, I think we're missing part of the frame, even for the bigger frames.

I'm not very familiar with the flex syntax, but I get the impression that you're sorta building manchester encoding on top of PCM. I'm quite convinced that the data is manchester-encoded, as there's never a state longer than 1500us (high or low), which if I remember my modulation protocols correctly is quite typical for manchester encoding.

klohner commented 1 year ago

The Operational Description says that the 39-bit signal is "bi-phase mark signaling" aka BMC. This is essentially a Differential Manchester flavor where a 1 is represented with a transition within the 1.5ms bit period, and a 0 is represented without a transition within the bit period. There is always a transition between bit periods.

After experimenting, it seems that decoding as OOK_PCM and using the "decode_dm" option results in IEEE Differential Manchester decoding, where the resulting logical bits are the inverse of what a BMC decode would be. The "inverse" option doesn't help here because that gets applied before the "decode_dm", and DM only cares about transitions, so there's no practical effect.

However, it seems the OOK_DMC decoding results in a BMC DM decoding, so we can use that.

I took all the samples found in the .zip files in this thread and decoded their raw bits. I also took the bitbench provided by @kvdveer and re-encoded the data into regular Manchester Encoding to get back to raw bits and put this all into one place:

bitbench

There doesn't seem to be a way to do a BMC Differential Manchester decoding in bitbench, so we'll have to settle for IEEE DM decoding for now. I took that DM decoding and fed that back into a new bitbench and was able to invert and figure out what the bits probably mean.

A clue that the ID field is likely correct is observed for the devices @kvdveer identified as "11202373988" and "11202373991". They get decoded as "02373988" and "02373991". However, device "11202373559" gets decoded as "02784343" so something is amiss.

I would surmise that the "WRITE" event on the device is essentially just a way to force a single "supervisory" message instead of waiting 65 minutes for this to happen in normal operation.

I then used this to create a flex decoder for the signal:

# -X "n=Risco_868_Security,m=OOK_DMC,s=750,l=1500,t=400,r=3000,preamble={6}04,bits>=37,bits<=42,get=ID:@0:{24},get=Trigger:@24:{1}:[0:EVENT 1:supervision],get=State:@25:{1}:[0:ok 1:ALERT],get=Tamper:@26:{1}:[0:normal 1:ALERT]"
decoder {
    name=Risco_868_Security,
    modulation=OOK_DMC,
    short=750,
    long=1500,
    tolerance=400,
    reset=3000,
    preamble={6}04,
    bits>=37,
    bits<=42,
    get=ID:@0:{24},
    get=Trigger:@24:{1}:[0:EVENT 1:supervision],
    get=State:@25:{1}:[0:ok 1:ALERT],
    get=Tamper:@26:{1}:[0:normal 1:ALERT],
}

Please give this a try and see how it works for you.

kvdveer commented 1 year ago

I'm seeing really good results with @klohner 's proposed decoder.

State and tamper are correctly detected.
Trigger is inverted, I think (EVENT is now decoded from a pairing message, supervisory is decoded during normal operation).
The IDs look correct too. For 7 of the 8 units I have, the ID matches the serial number on the back. One does not match, so I guess maybe the case was swapped during installation?

I believe there are still more bits to be decoded, though. I'm guessing from the manual and FCC docs that there's also:

Low-battery signal.
External sensor
Secondary reed switch.

I'll continue investigation into these bits. That won't be soon, though, as I'll be traveling for some time.

The name "Risco_868_Security" might be misleading. My units are of the WT71V2 variety. I also have one motion sensor (RWT92), two camera modules (no modelno no the device) and a keypad (no modelno on the device). All of these are advertised to operate on 868Mhz, but I doubt they will follow the same protocol. I haven't actually investigated them yet, but I plan to do that some time in the future.

kvdveer commented 1 year ago

I have confirmed that @klohner 's decoder also works correctly for the model RWT92 (a motion sensor), although the supervisory bit seems flipped there, too.

klohner commented 1 year ago

Good to hear you're getting positive results so far, @kvdveer. Would you please let me know which Trigger code is correct in your testing? Should it be [0:EVENT 1:supervision] or [0:supervision 1:EVENT]?

alecapu80 commented 1 year ago

Very interesting! You have made a lot of progress! @kvdveer witch SDR HW module are you using? Can you paste the rtl_433 parameters you used?

gdt commented 9 months ago

What's the status and path forward?

kvdveer commented 9 months ago

Sorry for going dark for a bit. Due to the nature of my employment, I have periods of substantial downtime, followed by periods of very little downtime. I haven't been working on the project, although the latest proposed flex-config seemed to work quite well for me. I've only flipped the supervisory bit:

decoder {
    name=Risco_868_Security,
    modulation=OOK_DMC,
    short=750,
    long=1500,
    tolerance=400,
    reset=3000,
    preamble={6}04,
    bits>=37,
    bits<=42,
    get=ID:@0:{24},
    get=Trigger:@24:{1}:[1:EVENT 0:supervision],
    get=State:@25:{1}:[0:ok 1:ALERT],
    get=Tamper:@26:{1}:[0:normal 1:ALERT],
}

To answer @alecapu80 's question, I'm using one of the generic blue SDR dongles, based on RTL2832, just like this one.

gdt commented 9 months ago

Pending #2654, we should store that decoder someplace, but I am going to hold off on closing until we do, so we don't lose it.

Separately, are there really frames with 37-42 bits? What are the rest of the bits? Is there really no CRC or checksum? Does this only decode valid frames, or does it fire on noise?

kvdveer commented 9 months ago

No, I don't think there are any odd-length frames. I only saw those before I had tuned in the timings.

Op zo 1 okt. 2023 17:05 schreef Greg Troxel @.***>:

Pending #2654 https://github.com/merbanan/rtl_433/issues/2654, we should store that decoder someplace, but I am going to hold off on closing until we do, so we don't lose it.

Separately, are there really frames with 37-42 bits? What are the rest of the bits? Is there really no CRC or checksum? Does this only decode valid frames, or does it fire on noise?

— Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/1194#issuecomment-1742109239, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADGM2KF6QVAMQFEJWGMDGDX5GBCRANCNFSM4JIZF3PA . You are receiving this because you were mentioned.Message ID: @.***>

gdt commented 9 months ago

The decoder accepts them. My point is that the decoder should only decode valid frames, so that the odds of a false decode are minimized. I am accepting as obvious -- even though others may disagree -- that the goal is to get to a decoder that can run for everyone, even those who don't know they have this device, like all the default-enabled decoders.

kvdveer commented 9 months ago

The only valid frames I've seen were 40 bits long. (again, after the timings were correct).

It's probably best to set the frame length to a fixed 40 bits, but that won't fully solve the false positive problem, given that there is no checksum and there are no identifying bits. The frequency might be identifying, but afaik that's not taken into consideration right now.

gdt commented 9 months ago

Probably then you should amend your flex decoder and try to tighten it up as much as you can and repost. And also figure out if there is truly no checksum.

It is unlikely that a frequency rule will be at all useful. Devices are on nominal shared freqs and individual devices vary a bit.

merbanan / rtl_433

Help to decode RISCO alarm sensor #1194

OSINT

Captured data