Add support for Risco PIR RWX95P

[markcs]

I have some Risco PIR devices, model RWX95P that operator on 433.92MHz. Looking through https://github.com/merbanan/rtl_433/issues/1194 gave me some ideas, but I would really like some further suggestions on how to fully decode the signals from these devices.

Attached are some dump files and I'm working if someone can help decoding with me? Risco PIR.zip

Using these options, I can get some output, but I don't think it is 100% correct.
-X "n=Risco_Security,m=OOK_DMC,s=132,l=352,t=508,r=3000,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]"

I do see the Tamper alert, but am not able to get an event on motion detected:

time      : 2024-09-30 14:05:59
model     : Risco_Security                         count     : 1             num_rows  : 1             rows      :
len       : 16           data      : ffff          ID        : 16776960      Trigger   : EVENT         State     : ok            Tamper    : normal
codes     : {16}ffff
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-09-30 14:06:09
model     : Risco_Security                         count     : 1             num_rows  : 1             rows      :
len       : 41           data      : ffffffffff8   ID        : 16777215      Trigger   : supervision   State     : ALERT         Tamper    : ALERT
codes     : {41}ffffffffff8

Help appreciated!

[zuckschwerdt]

DMC would be very unlikely and you should always check with PCM if you have a regular bit pattern for an MC. Try a few of you samples on https://triq.org/pdv/ (maybe compare with https://triq.org/rtl_433/PULSE_FORMATS.html) At a glance the timings are not precise. It could be a clock of around 200 µs.

[pswiatki]

Fix the typo in the title (name of manufacturer), please. I have the same PIR sensor, too. Perhaps I could also try tinkering with it in hopes of decoding something (surely it is appropriately encrypted, but at least the ID would be nice to get).

[markcs]

Thanks for fixing the typo @zuckschwerdt .

Seems that I have moved further away from a solution today. I moved the PIR and SDR closer to each other to hopefully get a better signal, but this just seems to confused me! When running with the '-A' option, i get Guessing modulation: No clue...

I tried looking at the cu8 files in trig.org, but I wasn't really sure what was needed to try to decode the files.

Attached are the latest logs, which I would hope are better as the antenna Risco PIR 20241001.zip

EDIT: I found the device on FCC here: https://fcc.report/FCC-ID/JE4AGILITY. It says The module is a transceiver which consist of a small PCB with an integral helical antenna, which operates in the frequency of 433.92MHz Modulation is On-Off Keying using Manchester code with max bit rate of 2400Bps. This module is installed only in RISCO 2-way wireless units, and it's behavior is determined by the host unit, as tested by ITL.

[zuckschwerdt]

2400 Bps would be a half-bit (MC) length of 208 µs. So rtl_433 -R 0 -X 'n=name,m=OOK_PCM,s=200,l=200,r=600'

The latest signals are clipping too much, try https://triq.org/spectrogram-next/ and (mouse-scroll) zoom in to the max, notice the waveform not being a sine.

Remove the antenna or put much more distance to the sender.

[ProfBoc75]

@markcs : same findings for me, your last samples are clipping, signal is too strong.

From your first samples, I did some flex test but not sure which one is the good one, try:

rtl_433 -X "n=PIR,m=OOK_DMC,s=175,l=400,t=150,r=10000,bits>=110" -Y magest *.cu8
rtl_433 -X "n=PIR,m=OOK_PCM,s=175,l=175,r=1000,bits>=110" -Y magest *.cu8

may be preamble is aaaaab or aaaaad or ?

rtl_433 -X "n=PIR,m=OOK_PCM,s=175,l=175,r=1000,bits>=110,preamble=aaaaab,decode_dm" -Y magest *.cu8

rtl_433 -X "n=PIR,m=OOK_PCM,s=175,l=175,r=1000,bits>=110,preamble=aaaaad,decode_dm" -Y magest *.cu8

Pulse width is not stable along the signal, I have good result with 175, but expected 200 for the 2400 bps. lot of possibilities ...

[markcs]

Thanks @ProfBoc75 .

I seem to be getting okay results with all these options, but I'm still unsure how to determine what is correct and what info is needed to help work that out?

Sorry for the basic question

rtl_433 -R 0 -X "n=PIR,m=OOK_PCM,s=175,l=175,r=1000,bits>=110,preamble=aaaaad,decode_dm"
rtl_433 version 23.11-163-ge25cfc0f branch master at 202409200913 inputs file rtl_tcp RTL-SDR
Disabling all device decoders.
Detached kernel driver
Found Fitipower FC0012 tuner
[SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 250000.000414 Hz
Allocating 15 zero-copy buffers
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-10-01 21:23:42
model     : PIR          count     : 1             num_rows  : 1             rows      :
len       : 128          data      : ff6001e0e35e0174fe280c60a001b494
codes     : {128}ff6001e0e35e0174fe280c60a001b494
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-10-01 21:23:44
model     : PIR          count     : 1             num_rows  : 1             rows      :
len       : 128          data      : ff6001e0435e0174fe280c60a001bc9c
codes     : {128}ff6001e0435e0174fe280c60a001bc9c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-10-01 21:23:44
model     : PIR          count     : 1             num_rows  : 1             rows      :
len       : 128          data      : ff6001e1c35e0174fe280c60a0002379
codes     : {128}ff6001e1c35e0174fe280c60a0002379
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-10-01 21:23:45
model     : PIR          count     : 1             num_rows  : 1             rows      :
len       : 128          data      : ff6001e0835e0174fe280c60a0003369
codes     : {128}ff6001e0835e0174fe280c60a0003369
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

A second PIR

Allocating 15 zero-copy buffers
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-10-01 21:26:31
model     : PIR          count     : 1             num_rows  : 1             rows      :
len       : 128          data      : ff6001e0c25e0174fe280c6060005622        ID        : 267780126
codes     : {128}ff6001e0c25e0174fe280c6060005622
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-10-01 21:26:32
model     : PIR          count     : 1             num_rows  : 1             rows      :
len       : 128          data      : ff6001e1425e0174fe280c606001c9c7        ID        : 267780126
codes     : {128}ff6001e1425e0174fe280c606001c9c7

Attached file moving PIR away from receiver PIR_20241001_1.zip

[zuckschwerdt]

There is still clipping except for g002_433.92M_250k.cu8. Overall very noisy signals. rtl_433 -R 0 -X 'n=name,m=OOK_PCM,s=200,l=200,r=2000,preamble=555a,decode_dm' works to produce

ff6001e1ca5e0174fe280c606001c3cd
ff6001e08a5e0174fe280c606001d3dd
ff6001e10a5e0174fe280c6060004c38
ff6001e00e5e0174fe280c606000592d
ff6001e18e5e0174fe280c606001c6c8
ff6001e19ea001ac89280c6063015421
ff6001e0dea001ac89280c6063014431

Which also has a CRC-16, poly 0x8005 init 0x8181 at the end to confirm things :)

Though using preamble=aaad and MC also works and produces

552000a0b9ca00d3aa1804202000bebb
552000a079ca00d3aa1804202000b14b
552000a0f9ca00d3aa18042020003be8
552000a005ca00d3aa1804202000371b
552000a085ca00d3aa1804202000bdb8
552000a08a60009b871804202100cc1f
552000a04a60009b871804202100c3ef

which checks nicely too: CRC-16 poly 0x8005 init0x7f7f. No way to tell which might be correct.

[ProfBoc75]

@markcs:

You have the ID written behind the sensor on the sticker with QR code, this could help to identify the good code as the ID should be transmitted into the signal.

[markcs]

I'm not sure which sensor those clean signals came from, so I've attached the two I've been playing around with

Converting the IDs and decoded signals to binary, I couldn't match the IDs. But I'm likely missing something!

[markcs]

The packets below are captured on other PIR devices in the house, so the id's likely won't match anything from the picture (unless they were triggered while I was recording). There is definitely a pattern emerging:

Removing the common hex ff6001e from the start of the messages, to make it easier below,

ff6001e0c44500f410280c60a0010111 becomes 0c44500f410280c60a0010111

Could the middle group (ie 280c60) be the device id ? Then the first digit of the next block ("a" or "6") may represent either a detection or tamper?

Just not sure how to determine when those triggers turn off or detection is not seen any longer

detection
0c4 4500f410 280c60 a0010111 -> 0000 1100 0100 01000101000000001111010000010000001010000000110001100000 101000000000 00010000000100010001
144 4500f410 280c60 a0009ef4 -> 0001 0100 0100 01000101000000001111010000010000001010000000110001100000 101000000000 00001001111011110100
064 4500f410 280c60 a0010919 -> 0000 0110 0100 01000101000000001111010000010000001010000000110001100000 101000000000 00010000100100011001
1e4 4500f410 280c60 a00096fc -> 0001 1110 0100 01000101000000001111010000010000001010000000110001100000 101000000000 00001001011011111100
0a4 4500f410 280c60 a00086ec -> 0000 1010 0100 01000101000000001111010000010000001010000000110001100000 101000000000 00001000011011101100
124 4500f410 280c60 a0011909 -> 0001 0010 0100 01000101000000001111010000010000001010000000110001100000 101000000000 00010001100100001001
034 4500f410 280c60 a0010d1d -> 0000 0011 0100 01000101000000001111010000010000001010000000110001100000 101000000000 00010000110100011101
1b4 4500f410 280c60 a00092f8 -> 0001 1011 0100 01000101000000001111010000010000001010000000110001100000 101000000000 00001001001011111000

tamper switch
0d6 4500f410 280c60 60004067 -> 0000 1101 0110 01000101000000001111010000010000001010000000110001100000 011000000000 00000100000001100111
156 4500f410 280c60 6001df82 -> 0001 0101 0110 01000101000000001111010000010000001010000000110001100000 011000000000 00011101111110000010
076 4500f410 280c60 6000486f -> 0000 0111 0110 01000101000000001111010000010000001010000000110001100000 011000000000 00000100100001101111
1f6 4500f410 280c60 6001d78a -> 0001 1111 0110 01000101000000001111010000010000001010000000110001100000 011000000000 00011101011110001010
0b6 4500f410 280c60 6001c79a -> 0000 1011 0110 01000101000000001111010000010000001010000000110001100000 011000000000 00011100011110011010
136 4500f410 280c60 6000587f -> 0001 0011 0110 01000101000000001111010000010000001010000000110001100000 011000000000 00000101100001111111
026 4500f410 280c60 60004c6b -> 0000 0010 0110 01000101000000001111010000010000001010000000110001100000 011000000000 00000100110001101011
1a6 4500f410 280c60 6001d38e -> 0001 1010 0110 01000101000000001111010000010000001010000000110001100000 011000000000 00011101001110001110

[ProfBoc75]

@markcs : the best is to play with https://triq.net/bitbench , this will let you arrange the data layout along your findings.

Here Hexa bitbench Here binary bitbench

[ProfBoc75]

This module is installed only in RISCO 2-way wireless units,

Just a little guidance that can help you. Because of 2-way protocol you may captured the sensor and the Risco central station/panel frames and other Risco Agility sensors.

In such protocol, what I already saw for other device sensors into the frame:

• Source ID (the sensor), Target ID (the station), and/or Network ID created during the pairing phase (all sensors using the same network ID): 2 x 5 bytes
• A message counter: 1 byte ?
• A Command type: like send or acknowledge, 1 nibble or 1 byte ?
• The Sensor type (pir, temp, window, door, smoke, station/panel or ... ?? ) 1 byte ?
• Some data / sensor state. 1 or more bytes ? (length data could be required)
• CRC - 16 bits / 2 bytes

Here the message is 16 bytes and could contain all such information.

[markcs]

This module is installed only in RISCO 2-way wireless units,

Just a little guidance that can help you. Because of 2-way protocol you may captured the sensor and the Risco central station/panel frames and other Risco Agility sensors.

In such protocol, what I already saw for other device sensors into the frame:

Thanks for the information. My Risco panel is switched off, so I'm pretty sure I'm only capturing messages from the PIRs.

Was the frame structure you mentioned for Risco devices, or similar devices?

[markcs]

Looking at this today, I also notice that randomly I see a much longer string with length of 264:

fef801d1ba1801ac89280ca00301e0a31901060000c0c000df3e2fa5f41e00821b fef801d0fa1801ac89280ca00301e0a31901060000c0c000df3e2fa5f41e01033e fef801d17a1801ac89280ca00301e0a31901060000c0c000df3e2fa5f41e0182fd fef801d05a1801ac89280ca00301e0a31901060000c0c000df3e2fa5f41e0083ab fef801d1da1801ac89280ca00301e0a31901060000c0c000df3e2fa5f41e000268

The first part 'decodes', but what I call the SENSOR_TYPE value is different. So I'm guessing there must be a length indicator in there somewhere ....

Still not getting to the final solution. I've been splitting the messages up like below:

ff6001e1beb500f410280c60c0019070; ID: 15994920; CMD: 12; SENSOR_TYPE: 96; ALARM_1: 12; ALARM_2: 0; ALARM_3: 1

I'm pretty sure the alarm bytes are not correct, but they do remain relatively consistent. I need to work out how they should be groups and then what they identify ....

decoder {
        name        = Risco_Security_PIR,
        modulation  = OOK_PCM,
        short       = 200,
        long        = 200,
        reset       = 2000,
        preamble    = 555a,
        decode_dm,
        get=ID:@38:{42},
        get=CMD:@80:{8},
        get=SENSOR_TYPE:@88:{8},
        get=ALARM_1:@96:{4},
        get=ALARM_2:@100:{4},
        get=ALARM_3:@104:{8},
}

[ProfBoc75]

@markcs:

Was the frame structure you mentioned for Risco devices, or similar devices?

Similar devices, I had recently work on Bresser Smarthome Garden, the PR 3005 is still opened and related to a 2-way protocol. For this protocol the message length is always the same, but inside the message there is a sub-message with a variable length. Another similar 2 ways protocol for French Frisquet boiler, here the message length depends on the message itself, may be like yours with 264 bits. Cross check the ID at the panel level, I guess you have also here a QR code with a Wxxxxxxx number.

[ProfBoc75]

@markcs

Looking at this today, I also notice that randomly I see a much longer string with length of 264:

It's clearly related to the same protocol, as the CRC-16 is the same poly=0x8005, init=0x8181:

reveng -w 16 -s fef801d1ba1801ac89280ca00301e0a31901060000c0c000df3e2fa5f41e00821b fef801d0fa1801ac89280ca00301e0a31901060000c0c000df3e2fa5f41e01033e fef801d17a1801ac89280ca00301e0a31901060000c0c000df3e2fa5f41e0182fd fef801d05a1801ac89280ca00301e0a31901060000c0c000df3e2fa5f41e0083ab
width=16  poly=0x8005  init=0x8181  refin=false  refout=false  xorout=0x0000  check=0x5bb7  residue=0x0000  name=(none)

[markcs]

Is there any way I can adjust the mqtt topic from within the flex decoder? I use rtl_433 for other devices towards Home Assistant, so do not want to affect the current output

The decoder below gives me topics like 'rtl_433/RT-AC68U-7008/devices/Risco_Security/rows/0/' but it would be nice to have this as per other devices 'rtl_433/RT-AC68U-7008/devices/Risco_Security/{id}'

decoder {
        name        = Risco_Security,
        modulation  = OOK_PCM,
        short       = 200,
        long        = 200,
        reset       = 2000,
        preamble    = 555a,
        bits>=260,
        bits<=512,
        decode_dm,
        get=id:@38:{42}:[9787944:Entry_9787944 28084520:Dining_28084520 15994920:Living_15994920 3414312:Upstairs_Living_3414312],
        get=CMD:@80:{8},
        get=SENSOR_TYPE:@88:{8}:[96:PIR],
        get=ALARM_TYPEA:@96:{4}:[10:tampered_motion 12:motion 6:tampered],
        get=ALARM_TYPEB:@100:{4},
        get=ALARM_STATE:@104:{8},
}

[ProfBoc75]

@markcs : Little remark about your flex decoder, your ID can't be {42} as the flex limit is 32 bits. You need a decoder to get ID {42}. The other benefits of the decoder is to validate the CRC and doing some sanity checks.

[markcs]

@ProfBoc75 oh, I didn't realise there was a limit. Thanks.
So are you saying that 32 bits is the limit for each individual flex decoder element? {EDIT} so only the lower of the 32 bits are decoded. I actually hadn't checked against the decoding!

When you say I need a decoder to get id {42}, what exactly do you mean? Do you mean a proper decoder built into rtl_433? Could I divide that up into id1 and id2, each with 21 bits and then somehow combine them?

I'm not sure it will be possible to properly identify all the elements and coding

[ProfBoc75]

@markcs yes combine id1 and id2.

To create a decoder we need some work and we can help you, I can draft it and commit into a specific rtl_433 branch to let you test it. This requires to get more samples to be sure about the data layout, as I proposed to enrich the bitbench. And step by step may be pr the decoder to add this Risco protocol.

[markcs]

@markcs yes combine id1 and id2.

To create a decoder we need some work and we can help you, I can draft it and commit into a specific rtl_433 branch to let you test it. This requires to get more samples to be sure about the data layout, as I proposed to enrich the bitbench. And step by step may be pr the decoder to add this Risco protocol.

Thanks. Please let me know how you would like those samples collected and for how long?

[ProfBoc75]

@markcs

I just created a new branch feat-risco_pir_rwx95p to commit a new decoder, I need some time to draft it and let you know if I need more samples later.

[markcs]

Fix the typo in the title (name of manufacturer), please. I have the same PIR sensor, too. Perhaps I could also try tinkering with it in hopes of decoding something (surely it is appropriately encrypted, but at least the ID would be nice to get).

Did you manage to get any samples @pswiatki ? It would be interesting to compare ...

[ProfBoc75]

@markcs , @pswiatki:

While I'm drafting the decoder, can you please capture codes with this command:

rtl_433 -R 0 -X 'n=risco2way,m=OOK_PCM,s=175,l=175,r=2000,preamble=555a,decode_dm'

And share the results, whatever the size of the codes is 128 or 264 bits or ??? bits, as it's a 2 way protocol we want as much use cases as possible. Share also the ID Wxxxxxxx from the sensors and the control panel to let us identify the source and the target into the frame.

From previous cu8 samples the pulse width is around 175 us and we have better result than with 200.

My first version of the decoder is done and able to do the crc check for the moment. I will commit later with the tamper / motion status and so on.

[markcs]

@ProfBoc75 I do not have a panel transmitting or receiving, as it is broken. But I do have the panel id that the PIR units were paired with.

PIR ID's that I've recorded. One or two other PIRs may have transmitted during that time, but unlikely and not that I could see in the logs.

• W88647360332
• W88224190055
• W88224190019
• W88224190023

The panel has ID W88072350010

Attached are some samples I took. risco-20241007_112826.txt

Likely too early to mention, but I see the following behavour using the decoder that I had above:

1. device with id W88647360332 always sends a 3 for ALARM_TYPEB while the others send 0
2. if no motion is detected for a while, the devices send a 0 for ALARM_TYPEA. Likely a status update or something
3. ALARM_STATE is not correct, doesn't toggle and doesn't seem to follow a pattern, so likely incorrect!

[ProfBoc75]

@markcs

1.device with id W88647360332 always sends a 3 for ALARM_TYPEB while the others send 0

Could be battery low flag ?

If your panel is broken, this means also that the 2-way is not working and only your sensors are sending the frame without acknowledgement. So we need someone with a fully operational system to get the 2-way figures/behavior.

[ProfBoc75]

@markcs Thanks to your last file, I have some findings around the ID.

ID data layout is not good, and I confirm that we have counters, reflected values, with incremental values until 255 then decreasing until 0, one bit change at a time (Gray code or reflected binary code). Here filtered with one sensor, I kept the sequence order.

bitbench

[pswiatki]

My situation is as follows: I currently have limited access to the RWX95PA sensor - this will change on Friday. I will also have access to several RWT92 (1-way!) sensors and could experiment with those (just not sure if this is the proper place for the results from these sensors, or it would be better to create a separate issue and refer to this one). Also, since the batteries are past due for a replacement (I think - it's been over 3 years and I am pretty sure the status should be Low Batt by now) it could manifest for RWT92 and when I put two of such depleted batteries in the 2-way RWX95PA it should also report Low Batt. As it is right now, however, I am confident the flag is cleared as the unit (and batteries) are brand new. Moreover, I have one old sensor (RWT92) that kept failing (false alarms - movement detection, I think) and got replaced - it would be exciting to find out if it sends out any special status to indicate a possible failure mode (HW unreliable, etc.). I could power it up again and capture packets from that sensor as a separate experiment. By the way: for whatever reason my sensors have 868 MHz selected on their PCB, but it should make no difference, right?

Side question (unrelated to the above): what would you recommend to capture RF samples in a way that would always keep the last ~30 minutes or so? Something similar to log files rotation, would be the best (several files covering that past ~30 minutes in case a single file gets too big to handle with ease). Are there any ready-to-use solutions for that? This is for LoRa transmission capture.

[ProfBoc75]

@pswiatki

• About the RWT92, you have already an issue opened #1194 with a flex decoder proposition.
• About the RF samples for 30 mn for LoRa, you can open a New Discussion for that, or look into the issues / discussions history may be already discussed. At rtl_433 level you can specify the duration with -T 00:30 couple with -S all option, you can capture files during that time, not sure if you can overwrite the files with -S option as the files are automatically incremented based on the existing files into the current folder.
• And for the RWX94PA, you're welcome in this issue to share any findings/captures.

[ProfBoc75]

@markcs @pswiatki , can you please test my PR #3066 and let me know.

[pswiatki]

@pswiatki

• About the RWT92, you have already an issue opened Help to decode RISCO alarm sensor #1194 with a flex decoder proposition.
• About the RF samples for 30 mn for LoRa, you can open a New Discussion for that, or look into the issues / discussions history may be already discussed. At rtl_433 level you can specify the duration with -T 00:30 couple with -S all option, you can capture files during that time, not sure if you can overwrite the files with -S option as the files are automatically incremented based on the existing files into the current folder.
• And for the RWX94PA, you're welcome in this issue to share any findings/captures.

Thank you much for your answer @ProfBoc75. I shall proceed as instructed.

Just to avoid any possible confusion in the future (for those who might search for Risco here): it is RXW95P[A] (not 94). Maybe your positing above is still editable, so that you could actually correct the name of the sensor.

[markcs]

@markcs @pswiatki , can you please test my PR #3066 and let me know.

I compiled and ran with the "-R 265" option (which was [265] Risco 2 Way Agility protocol, Risco PIR/PET Sensor RWX95PA). The output to CSV looks like the following and looks good I think. I need to do some more testing, but it won't be until next week

time,msg,codes,model,id,counter,tamper,motion,battery_ok,mic
2024-10-10 16:32:27,,,Risco-PIR,95486,20949,1,,1,CRC
2024-10-10 16:32:27,,,Risco-PIR,95486,20948,1,,1,CRC
2024-10-10 16:32:28,,,Risco-PIR,95486,20947,1,,1,CRC
2024-10-10 16:32:29,,,Risco-PIR,95486,20946,1,,1,CRC
2024-10-10 16:32:30,,,Risco-PIR,95486,20945,1,,1,CRC
2024-10-10 16:32:32,,,Risco-PIR,95486,20944,1,,1,CRC
2024-10-10 16:32:32,,,Risco-PIR,95486,20960,1,,1,CRC
2024-10-10 16:32:32,,,Risco-PIR,62480,53660,,1,1,CRC
2024-10-10 16:32:33,,,Risco-PIR,62480,53659,,1,1,CRC
2024-10-10 16:32:33,,,Risco-PIR,95486,20961,1,,1,CRC
2024-10-10 16:32:35,,,Risco-PIR,95486,20963,1,,1,CRC
2024-10-10 16:32:35,,,Risco-PIR,62480,53656,,1,1,CRC
2024-10-10 16:32:36,,,Risco-PIR,95486,20964,1,,1,CRC
2024-10-10 16:32:36,,,Risco-PIR,95486,20965,1,,1,CRC
2024-10-10 16:32:37,,,Risco-PIR,95486,20966,1,,1,CRC
2024-10-10 16:32:43,,,Risco-PIR,95486,20967,1,1,1,CRC
2024-10-10 16:33:06,,,Risco-PIR,95486,20982,1,1,1,CRC
2024-10-10 16:33:07,,,Risco-PIR,95486,20981,1,1,1,CRC
2024-10-10 16:33:09,,,Risco-PIR,95486,20979,1,1,1,CRC
2024-10-10 16:33:10,,,Risco-PIR,95486,20978,1,1,1,CRC
2024-10-10 16:33:11,,,Risco-PIR,95486,20977,1,1,1,CRC
2024-10-10 16:33:42,,,Risco-PIR,95486,20713,1,,1,CRC

[ProfBoc75]

@markcs : The counter needs to be reviewed a little, not linear with some jump values. I did the Gray decoded on nibble (4 bit) using a map table, may be I need to do it at byte or double byte level... not critical as it's just an information. But need some work/time to achieve that ...

[ProfBoc75]

I did some updates into my pr. The counter is now well Gray decoded. I changed the ID and Counter format to decimal instead of Hexa values.

Let me know if needs some correction.