search

milaq / rpi-rf

Sending and receiving 433MHz signals with cheap GPIO RF modules on a Raspberry Pi
BSD 3-Clause "New" or "Revised" License
498 stars 178 forks source link

Reading results not interpretable and always different #47

Open andreaj8 opened 4 years ago

andreaj8 commented 4 years ago

I'm using this library to listen to my remote, but I can't get a single code, the output is always different:

(this is a long press)

2019-12-19 23:17:34 - [INFO] receive: Listening for codes on GPIO 27
2019-12-19 23:17:39 - [INFO] receive: 992 [pulselength 454, protocol 3]
2019-12-19 23:17:44 - [INFO] receive: 512 [pulselength 375, protocol 1]
2019-12-19 23:17:44 - [INFO] receive: 64 [pulselength 384, protocol 1]
2019-12-19 23:17:44 - [INFO] receive: 256 [pulselength 379, protocol 1]
2019-12-19 23:17:44 - [INFO] receive: 128 [pulselength 376, protocol 1]
2019-12-19 23:17:44 - [INFO] receive: 64 [pulselength 379, protocol 1]
2019-12-19 23:17:44 - [INFO] receive: 512 [pulselength 1180, protocol 2]
2019-12-19 23:17:44 - [INFO] receive: 514 [pulselength 382, protocol 1]
2019-12-19 23:17:44 - [INFO] receive: 128 [pulselength 380, protocol 1]
2019-12-19 23:17:45 - [INFO] receive: 1540 [pulselength 380, protocol 1]
2019-12-19 23:17:45 - [INFO] receive: 1990 [pulselength 380, protocol 1]
2019-12-19 23:17:45 - [INFO] receive: 2082 [pulselength 381, protocol 1]
2019-12-19 23:17:45 - [INFO] receive: 4 [pulselength 530, protocol 1]
2019-12-19 23:17:45 - [INFO] receive: 1152 [pulselength 381, protocol 1]
2019-12-19 23:17:45 - [INFO] receive: 130 [pulselength 380, protocol 1]
2019-12-19 23:17:45 - [INFO] receive: 2 [pulselength 378, protocol 1]
2019-12-19 23:17:45 - [INFO] receive: 256 [pulselength 380, protocol 1]
2019-12-19 23:17:45 - [INFO] receive: 64 [pulselength 1323, protocol 2]
2019-12-19 23:17:45 - [INFO] receive: 32 [pulselength 381, protocol 1]
2019-12-19 23:17:46 - [INFO] receive: 512 [pulselength 1187, protocol 2]
2019-12-19 23:17:46 - [INFO] receive: 1088 [pulselength 382, protocol 1]
2019-12-19 23:17:46 - [INFO] receive: 221 [pulselength 384, protocol 1]
2019-12-19 23:17:46 - [INFO] receive: 4096 [pulselength 2069, protocol 4]
2019-12-19 23:17:46 - [INFO] receive: 4 [pulselength 382, protocol 1]
2019-12-19 23:17:46 - [INFO] receive: 1 [pulselength 1214, protocol 2]
2019-12-19 23:17:47 - [INFO] receive: 2 [pulselength 389, protocol 1]
2019-12-19 23:17:47 - [INFO] receive: 546 [pulselength 383, protocol 1]
2019-12-19 23:17:47 - [INFO] receive: 1280 [pulselength 382, protocol 1]
2019-12-19 23:17:47 - [INFO] receive: 8 [pulselength 391, protocol 1]
2019-12-19 23:17:47 - [INFO] receive: 256 [pulselength 382, protocol 1]
2019-12-19 23:17:47 - [INFO] receive: 1024 [pulselength 382, protocol 1]
2019-12-19 23:17:48 - [INFO] receive: 384 [pulselength 382, protocol 1]
2019-12-19 23:17:48 - [INFO] receive: 2048 [pulselength 382, protocol 1]
2019-12-19 23:17:48 - [INFO] receive: 32 [pulselength 386, protocol 1]
2019-12-19 23:17:48 - [INFO] receive: 1152 [pulselength 381, protocol 1]
2019-12-19 23:17:48 - [INFO] receive: 4 [pulselength 383, protocol 1]
2019-12-19 23:17:48 - [INFO] receive: 642 [pulselength 385, protocol 1]
2019-12-19 23:17:48 - [INFO] receive: 512 [pulselength 384, protocol 1]
2019-12-19 23:17:49 - [INFO] receive: 512 [pulselength 383, protocol 1]
2019-12-19 23:17:49 - [INFO] receive: 1 [pulselength 1977, protocol 4]
2019-12-19 23:17:49 - [INFO] receive: 576 [pulselength 168, protocol 3]
2019-12-19 23:17:49 - [INFO] receive: 2 [pulselength 1197, protocol 2]
2019-12-19 23:17:49 - [INFO] receive: 226 [pulselength 381, protocol 1]
2019-12-19 23:17:49 - [INFO] receive: 804 [pulselength 378, protocol 1]
2019-12-19 23:17:49 - [INFO] receive: 256 [pulselength 397, protocol 1]
2019-12-19 23:17:49 - [INFO] receive: 64 [pulselength 437, protocol 1]
2019-12-19 23:17:49 - [INFO] receive: 2 [pulselength 382, protocol 1]
2019-12-19 23:17:49 - [INFO] receive: 2084 [pulselength 384, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 128 [pulselength 384, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 256 [pulselength 384, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 4 [pulselength 384, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 128 [pulselength 393, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 1284 [pulselength 384, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 64 [pulselength 385, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 258 [pulselength 384, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 512 [pulselength 386, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 1092 [pulselength 384, protocol 1]
2019-12-19 23:17:50 - [INFO] receive: 8 [pulselength 848, protocol 5]
2019-12-19 23:17:50 - [INFO] receive: 4 [pulselength 378, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 1058 [pulselength 386, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 770 [pulselength 380, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 256 [pulselength 385, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 768 [pulselength 392, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 64 [pulselength 385, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 64 [pulselength 385, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 584 [pulselength 384, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 64 [pulselength 385, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 2 [pulselength 384, protocol 1]
2019-12-19 23:17:51 - [INFO] receive: 5 [pulselength 167, protocol 3]
2019-12-19 23:17:52 - [INFO] receive: 4 [pulselength 389, protocol 1]
2019-12-19 23:17:52 - [INFO] receive: 8 [pulselength 852, protocol 5]
2019-12-19 23:17:52 - [INFO] receive: 1284 [pulselength 385, protocol 1]
2019-12-19 23:17:52 - [INFO] receive: 128 [pulselength 386, protocol 1]
2019-12-19 23:17:52 - [INFO] receive: 546 [pulselength 402, protocol 1]
2019-12-19 23:17:52 - [INFO] receive: 576 [pulselength 381, protocol 1]
2019-12-19 23:17:52 - [INFO] receive: 34 [pulselength 378, protocol 1]
2019-12-19 23:17:52 - [INFO] receive: 64 [pulselength 968, protocol 5]
2019-12-19 23:17:53 - [INFO] receive: 256 [pulselength 383, protocol 1]
2019-12-19 23:17:53 - [INFO] receive: 770 [pulselength 380, protocol 1]
2019-12-19 23:17:54 - [INFO] receive: 8 [pulselength 382, protocol 1]
2019-12-19 23:17:54 - [INFO] receive: 64 [pulselength 186, protocol 3]
2019-12-19 23:17:54 - [INFO] receive: 32 [pulselength 403, protocol 1]
2019-12-19 23:17:54 - [INFO] receive: 192 [pulselength 386, protocol 1]
2019-12-19 23:17:54 - [INFO] receive: 512 [pulselength 167, protocol 3]
2019-12-19 23:17:54 - [INFO] receive: 66 [pulselength 385, protocol 1]
2019-12-19 23:17:54 - [INFO] receive: 64 [pulselength 855, protocol 5]
2019-12-19 23:17:54 - [INFO] receive: 256 [pulselength 386, protocol 1]
2019-12-19 23:17:54 - [INFO] receive: 64 [pulselength 383, protocol 1]
2019-12-19 23:17:55 - [INFO] receive: 512 [pulselength 1191, protocol 2]
2019-12-19 23:17:55 - [INFO] receive: 1024 [pulselength 387, protocol 1]
2019-12-19 23:17:55 - [INFO] receive: 128 [pulselength 1998, protocol 4]
2019-12-19 23:17:55 - [INFO] receive: 16 [pulselength 932, protocol 5]
2019-12-19 23:17:55 - [INFO] receive: 1024 [pulselength 386, protocol 1]
2019-12-19 23:17:55 - [INFO] receive: 1536 [pulselength 385, protocol 1]
2019-12-19 23:17:55 - [INFO] receive: 1280 [pulselength 386, protocol 1]
2019-12-19 23:17:55 - [INFO] receive: 1568 [pulselength 387, protocol 1]
2019-12-19 23:17:56 - [INFO] receive: 32 [pulselength 382, protocol 1]
2019-12-19 23:17:56 - [INFO] receive: 832 [pulselength 381, protocol 1]
2019-12-19 23:17:57 - [INFO] receive: 512 [pulselength 382, protocol 1]
2019-12-19 23:17:57 - [INFO] receive: 1024 [pulselength 380, protocol 1]
2019-12-19 23:17:57 - [INFO] receive: 32 [pulselength 385, protocol 1]
2019-12-19 23:17:57 - [INFO] receive: 1540 [pulselength 383, protocol 1]
2019-12-19 23:17:57 - [INFO] receive: 34 [pulselength 384, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 10 [pulselength 386, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 770 [pulselength 385, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 64 [pulselength 415, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 1024 [pulselength 386, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 832 [pulselength 386, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 1024 [pulselength 387, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 1056 [pulselength 387, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 46 [pulselength 387, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 64 [pulselength 387, protocol 1]
2019-12-19 23:17:58 - [INFO] receive: 32 [pulselength 857, protocol 5]
2019-12-19 23:17:59 - [INFO] receive: 4 [pulselength 386, protocol 1]
2019-12-19 23:17:59 - [INFO] receive: 256 [pulselength 856, protocol 5]
2019-12-19 23:17:59 - [INFO] receive: 256 [pulselength 170, protocol 3]
2019-12-19 23:17:59 - [INFO] receive: 512 [pulselength 387, protocol 1]
2019-12-19 23:17:59 - [INFO] receive: 10 [pulselength 387, protocol 1]
2019-12-19 23:17:59 - [INFO] receive: 64 [pulselength 386, protocol 1]
2019-12-19 23:17:59 - [INFO] receive: 128 [pulselength 166, protocol 3]

With RFSniffer included with 433Utils I don't get anything, empty results.

How do I interpret these answers?

a1studmuffin commented 4 years ago

I'm experiencing the same issue with rpi-rf 0.9.7. I'm testing on an original Raspberry Pi Model B, using latest Raspbian Lite, a cheap set of RF power points + remote (https://www.amazon.com.au/MRC03V2-DOSS-Outlet-Controller-Maximum/dp/B077LJD5HH), and cheapie 433 transmitters/receivers (https://www.banggood.com/433Mhz-RF-Transmitter-With-Receiver-Kit-For-Arduino-ARM-MCU-Wireless-p-74102.html). I followed the wiring diagram (5V power, GPIO 27) and can receive data while holding down any of the remote buttons, but there is no discernable pattern to the codes/pulse lengths/protocol, which all seem different. I also see intermittent signals being received (with random values) while I'm not pressing any buttons, though they are less frequent. I'd be surprised if the RF power points were using some kind of rolling code/encryption, but who knows. Perhaps the issue is occuring because I'm using an older (slower) model of Pi?

Edit: I tried on a Raspberry Pi 4 and had the same results. Also tried a few other things, including switching to a second 433 receiver (same model), connecting VCC to 3.3V instead of 5V, putting a 5V->3.3V voltage divider on the data pin, and holding the 433 transmitter very close to the 433 receiver antenna (this did improve things slightly, but I still couldn't get a repeatable number). I suspect I'm seeing too much RF noise... perhaps I need a better antenna, or a better receiver. Or perhaps it's possible to add some basic signal filtering to rpi-rf before interpreting the results? It feels like the signal is coming through but there are some erroneous 0s and 1s about the place confusing rpi-rf. I'll continue poking around as this is interesting.

a1studmuffin commented 4 years ago

I grabbed a raw capture of the GPIO pin state (0/1) over a few seconds while momentarily pressing a remote button. I can confirm there is a clear and repeating sequence of pulses with little to no noise most of the time, and the signal was received very clearly even 50-100cm away from the device. I also tried decoding with https://github.com/ninjablocks/433Utils but had no luck. So I'm fairly sure this is just a protocol issue. I'm pretty sure if I transmitted the raw GPIO recording I received, it would work, though I was hoping to integrate this into a home automation system in a more elegant way. Time to reverse engineer the protocol and make a pull request I suppose! :)

a1studmuffin commented 4 years ago

Success, I managed to decipher the protocol for my remote-controlled outlets. It turns out there were two problems:

1) The rc-switch submodule needed to be replaced with a fork that supports 64-bit codes (eg. https://github.com/atsage/rc-switch), as the protocol my outlets use have 33 bits of data. 2) A new protocol needed to be added to rc-switch: { 275, { 38, 1 }, { 1, 3 }, { 3, 1 }, false }, // protocol 8 (used in RCS-19AS receivers)

The other thing that helped significantly with noise/range was adding an external antenna to the transmitter/receiver modules... literally just a wire: https://www.youtube.com/watch?v=OVsqGX0iBOM

Hope that's helpful for anyone else suffering the same pain... this took me a full day of experimenting and hacking the rc-switch code to figure out what was going on.

107208579 commented 4 years ago

I too experience the same issues with rpi-rf version 0.9.7. I've tried several different 433Mhz receiver modules and could replicate the issues with different remote controls. Here is an example for a single button of a remote control:

2020-04-06 17:19:07 - [INFO] receive: 10440993 [pulselength 275, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 278, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 279, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 280, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 280, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 283, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 122, protocol 3] 2020-04-06 17:19:08 - [INFO] receive: 262144 [pulselength 621, protocol 5] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 122, protocol 3] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 122, protocol 3] 2020-04-06 17:19:08 - [INFO] receive: 10440993 [pulselength 121, protocol 3] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 122, protocol 3] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 279, protocol 1] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:09 - [INFO] receive: 65536 [pulselength 621, protocol 5] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 122, protocol 3] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 284, protocol 1] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:09 - [INFO] receive: 256 [pulselength 623, protocol 5] 2020-04-06 17:19:09 - [INFO] receive: 10440993 [pulselength 123, protocol 3] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 282, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 282, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 278, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 282, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 282, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 282, protocol 1] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 121, protocol 3] 2020-04-06 17:19:10 - [INFO] receive: 10440993 [pulselength 282, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 283, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 278, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 278, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 282, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 282, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 281, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 282, protocol 1] 2020-04-06 17:19:11 - [INFO] receive: 10440993 [pulselength 282, protocol 1]

Host: Raspberry Pi Zero W 1.1 Host OS: Raspbian Buster Lite (Release Date 2020-02-13) Receivers tested: 2x RXB6 433Hz Receiver, 1x Grove - 433MHz Simple RF Link Remote Controls: 7 different 433Hz transmitters

18rrs commented 4 years ago

Success, I managed to decipher the protocol for my remote-controlled outlets. It turns out there were two problems:

1. The rc-switch submodule needed to be replaced with a fork that supports 64-bit codes (eg.  https://github.com/atsage/rc-switch), as the protocol my outlets use have 33 bits of data.

2. A new protocol needed to be added to rc-switch:
   `{ 275, { 38,  1 }, {  1,  3 }, {  3,  1 }, false },     // protocol 8 (used in RCS-19AS receivers)`

The other thing that helped significantly with noise/range was adding an external antenna to the transmitter/receiver modules... literally just a wire: https://www.youtube.com/watch?v=OVsqGX0iBOM

Hope that's helpful for anyone else suffering the same pain... this took me a full day of experimenting and hacking the rc-switch code to figure out what was going on.

Can you please give some instructions? I don't know what file to replace.

a1studmuffin commented 4 years ago

If you're working with an rc-switch fork that has 64-bit code support such as the one I linked above, you can just add a new protocol definition to the proto[] array in RCSwitch.cpp, such as the one I added for my power switches. However you'll need to identify the actual protocol first, which can take quite a bit of fiddling/hacking with raw data dumps and an understanding of how rc-switch encodes its protocols. If you're not confident with C++ or coding in general I think it may be too difficult for you.

It would be cool if someone wrote a "dumb" 433mhz tx/rx capture/replay system that didn't use a protocol but just raw-captured a signal recording and played it back. You wouldn't end up with a nice short signal ID like rc-switch, but it would be more flexible with odd 433 switch protocols. It may already exist out there somewhere.

iDaoU commented 4 years ago

Whoever is having this issue, take note of a few things that will help:

  1. Attaching an antenna onto the receiver helps with its sensitivity. Though it doesn't eliminate the background noise.
  2. If you are trying to sniff the codes from a remote, hold down the button so that you can see the repeated pattern over the background noise.
  3. You can use piscope to see the digital signal being received. This helps understand what is going on.
JuliAn50M commented 2 years ago

Success, I managed to decipher the protocol for my remote-controlled outlets. It turns out there were two problems:

  1. The rc-switch submodule needed to be replaced with a fork that supports 64-bit codes (eg. https://github.com/atsage/rc-switch), as the protocol my outlets use have 33 bits of data.
  2. A new protocol needed to be added to rc-switch: { 275, { 38, 1 }, { 1, 3 }, { 3, 1 }, false }, // protocol 8 (used in RCS-19AS receivers)

The other thing that helped significantly with noise/range was adding an external antenna to the transmitter/receiver modules... literally just a wire: https://www.youtube.com/watch?v=OVsqGX0iBOM

Hope that's helpful for anyone else suffering the same pain... this took me a full day of experimenting and hacking the rc-switch code to figure out what was going on.

@a1studmuffin I'm facing same problem. Could you explain how to do please:

  1. Where is this file on RPI ? Or how to replace this sub module.
  2. how to add this protocol ? where is this file Thank you
a1studmuffin commented 2 years ago

@JuliAn50M It's very likely the RF signals you're trying to decode are completely different to mine, so I wouldn't worry too much about the 64-bit code hackery yet, that might be a red herring. I've learned a bit more about RF since I wrote that post a few years ago, and I can see now looking back that I should have done what @iDaoU suggested, which is to get an oscilloscope onto the digital signal being received. (I think a cheap DSO will suffice if you're on a budget.)

Once you can verify you're receiving a clean digital signal that repeats a pattern without too much interference, you can start to reverse-engineer the protocol based on the on/off pulse lengths observed in the signal. The oscilloscope path would have saved me a lot of time, rather than finding the solution through experimentation with the rf-switch output data.

I will also say that the RF modules I bought (https://www.banggood.com/433Mhz-RF-Transmitter-With-Receiver-Kit-For-Arduino-ARM-MCU-Wireless-p-74102.html) worked very well for transmitting signals (using a ~17.3cm straight wire antenna), but were absolutely hopeless for receiving signals over any useful distance. Not such an issue if you're only using the receiver to reverse-engineer protocols, but if you'd like to react to real-world RF signals, I'd recommend a superheterodyne RF receiver instead.

I bought a generic "RXB6 433Mhz Superheterodyne Wireless Receiver" module from AliExpress and ended up building a 1/4 wave monopole antenna for it (https://community.element14.com/challenges-projects/project14/rf/b/blog/posts/building-a-poor-man-s-quarter-wave-433mhz-antenna-antenna-s-construction), and now I can receive RF signals from door sensors, motion sensors and 433 buttons all around my house and yard without issues, even through multiple exterior and interior walls.