Add support for Risco PIR RWX95P #3062
Comments
|
DMC would be very unlikely and you should always check with PCM if you have a regular bit pattern for an MC. |
|
Fix the typo in the title (name of manufacturer), please. |
|
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 EDIT: |
|
2400 Bps would be a half-bit (MC) length of 208 µs. So 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. |
|
@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: may be preamble is aaaaab or aaaaad or ? Pulse width is not stable along the signal, I have good result with 175, but expected 200 for the 2400 bps. |
|
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 A second PIR Attached file moving PIR away from receiver PIR_20241001_1.zip |
|
There is still clipping except for Which also has a CRC-16, poly 0x8005 init 0x8181 at the end to confirm things :) Though using which checks nicely too: CRC-16 poly 0x8005 init0x7f7f. No way to tell which might be correct. |
|
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. |
|
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! |
|
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 ? Just not sure how to determine when those triggers turn off or detection is not seen any longer |
|
@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 |
Just a little guidance that can help you. In such protocol, what I already saw for other device sensors into the frame:
Here the message is 16 bytes and could contain all such information. |
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? |
|
Looking at this today, I also notice that randomly I see a much longer string with length of 264:
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:
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 .... |
Similar devices, I had recently work on Bresser Smarthome Garden, the PR 3005 is still opened and related to a 2-way protocol. |
It's clearly related to the same protocol, as the CRC-16 is the same poly=0x8005, init=0x8181: |
|
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}' |
|
@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}. |
|
@ProfBoc75 oh, I didn't realise there was a limit. Thanks. 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 |
|
@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. |
Thanks. Please let me know how you would like those samples collected and for how long? |
|
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. |
Did you manage to get any samples @pswiatki ? It would be interesting to compare ... |
|
While I'm drafting the decoder, can you please capture codes with this command: 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. |
|
@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.
The panel has ID W88072350010 Attached are some samples I took. Likely too early to mention, but I see the following behavour using the decoder that I had above:
|
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. |
|
@markcs 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. |
|
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). 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? |
|
ProfBoc75
added
the
feedback
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). |
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 |
|
@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 ... |
|
I did some updates into my pr. Let me know if needs some correction. |
|
Here is a table from the csv output doing a quick walk test:
|
|
Ahh.... dammit, a typo. I meant |
|
Is there any way to actually disable all protocols except those given explicitly in the command line? Or, in addition to frequency, I shall comment out all protocols in the |
By default, when a protocol number is provided all others are disabled. But on the same line, protocols can be cumulated, Protocols 1 , 2 & 3 are allowed. You can also disable only one or few protocols: All protocols are allowed except 4, 5 & 6
I was not able to decode. At data layout, the ID field is 3 bytes, my guess, but the Wxxxx number requires 5 bytes to be coded, I'm not able to find such information from the message, may be within the longer message, but missing samples here to get the figures. Another possibility, a short ID could be created at the initial pairing phase between the Sensor and the Panel. Again, need to capture the message to get the figures.
Probably not enough, but all captures, samples are helpful/welcome , at least to start with a "minimum viable product" (mvp), like I did with my pr, not all the 2 way protocol is yet decoded, step by step, we have some findings, we add them into the decoder which is improving each time (Agility approach) |
Well... I have a different experience here. Although, it may be what you describe. If the commando line and
Understood. I shall take as many captures as I can in all possible scenarios (motion, tamper A & B, low battery, good battery...). Will try to arrange so that no service mode is active.
Got it. Good approach! |
|
It is good for me. I guess tweaks will be needed to fully decode some of the bits when we understand more, but all good for now |
I have some Risco PIR devices, model RWX95P that operator on 433.92MHz. Looking through #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:
Help appreciated!
The text was updated successfully, but these errors were encountered: