There’s a huge market for 433 MHz alarm system hardware out there, from PIR motion detectors to door and window sensors. If you want to put them to work, all you need is a receiver, a network-enabled microcontroller, and some code. In his latest video, [Aaron Christophel] shows how easy it can be.
In essence, you connect a common 433 MHz receiver module to an ESP32 or ESP8266 microcontroller, and have it wait until a specific device squawks out. From there, the code on the ESP can fire off using whatever API works for your purposes. In this case [Aaron] is using the Telegram API to send out messages that will pop up with a notification on his phone when a door or window is opened. But you could just as easily use something like MQTT, or if you want to go old-school, have it toggle a relay hooked up to a loud siren.
Even if you aren’t looking to make your own makeshift alarm system, the code and video after the break are a great example to follow if you want to get started with 433 MHz hardware. Specifically, [Aaron] walks the viewer through the process of scanning for new 433 MHz devices and adding their unique IDs to the list the code will listen out for. If you ever wondered how quickly you could get up and running with this stuff, now you’ve got your answer.
In the past we’ve seen the Raspberry Pi fill in as an RF to WiFi gateway for these type of sensors, as well as projects that pulled them all together into a complete home automation system on the cheap.
If you’re thinking of playing around in the 433MHz range, be aware of the FCC regulations for that band:
1) Polling transmissions of no more than 2 seconds per HOUR.
2) More frequent polling allowed only if the duration is <1 second, and the silent period between transmissions is at least 30x longer than the transmission period.
3) Effective range must be under roughly 300 feet under outdoor line-of-sight conditions, significantly less indoors.
By all means, have fun experiment with interesting 433MHz applications! Just don't piss off the FCC in the process.
I guess it’s fortunate nobody’s transmitting in that band in this hack then. At least that’s what it sounds like.
Except for the radio amateurs using the 70cm band quite legally…….
I worked on a research project within a large company that makes security sensors to make a WiFi enabled security sensor a few years ago, just before the ESP8266 was a thing. At that time, it was very questionable if we could get two years out of two AAs. We managed to succeed with some interesting hacks, and then the business decided that they didn’t want to cannibalize their existing 433 MHz products, so they killed our project before it went into product development. I still think that was a missed opportunity.
Hello Capt McAllister, We are working towards productizing this and looking forward 1 yr life time at least for the door and motion sensors with two AA battery. If any specific inputs you have welcome. Also I am looking for the best receiver and transmitter combo, where one receiver can connect to at least 20 transmitters. Any pointers to the right receiver and transmitters which will work on 433.92 MHZ frequency? Looking forward to your response..
Thank you Tom Nardi for the write up!
Thank You for the demonstration.
Would you like to help me on a project I am building???
I Like it, But i think it could be better if it did MQTT. (should be fairly trivial after getting the codes/ids of the 433mhz devices)
If you DL a NodeMCU build that has the “rfswitch” and MQTT modules built-in:
m = mqtt.Client("rf433-bridge", 60)m:on("connect", function() print("mqtt connected") client:subscribe(command_topic, 0, subscribed(command_topic)) end )
m:on("message", function(client, topic, data) code=tonumber(data); rfswitch.send(1,300,5,4,code,24) end)
m:connect(mqtt_address)
This is the core of a system that’s been running in my house for 3 years now. The actual version has some debug stuff on a separate MQTT topic (recommended), sets up a last will, etc. But this is what it takes to get the job done.
It just takes in the 433 MHz codes over MQTT, as their decimal values, and plays them out over the radio. The rest is server-side mapping, where it’s most easily configurable / schedulable / etc.
You can also buy a Sonoff RF which is just a more advanced version of this and flash it with Tasmota, that supports this stock. I have multiple smoke detectors, multiple PIRs and the doorbell all connected to this. It is surprisingly reliable. The only addition that I could not find a part for was a wifi controlled sound maker. I ended up using a I2S with amplifier module, speaker and an esp32 in a 3d printed box with the PSU ripped from a USB plug pack to make a unit that accepts a local network URL to play an mp3 from for alerts and the door bell.
A most timely post, associate has been going down a sort of similar track wrestling with RF comms collision issues re timing & update rates…
Thanks for post and thanks to commenters offering insights :-)
Forget about trashy 433 MHz for anything you want to be secure. Anyone can listen to the codes and replay them. Want to fuck with your neighbour? “open and close” all doors all the time.
Sure, it is most likely a simple repeating code. It *could* also be Keeloq/rolling code, but integration becomes a LOT harder!
Agreed. It probably isn’t a great idea to use 433 MHz if there isn’t any encryption to the radio message. Of course, the odds that your neighbor or some malicious actor will figure out that your house is susceptible to replay attacks is rather low. Someone listening with a HackRF could certainly see the 433 MHz blips, but I imagine they would have to be fairly close by and have perfect timing to capture a transmission when it happened. I doubt anyone over 500 ft away would even see a barely visible peak on the waterfall.