It’s an unfortunate reality these days that if you see a cheap piece of consumer electronics, there’s a good chance its only cheap because it’s designed to lock you into some ecosystem where you’ll either end up paying a subscription, or worse, have your personal information sold behind your back. One of the best tools we have against these sort of anti-consumer practices is the development of open source firmware replacements that put control of the device into the hands of the community, rather than a corporation.
Now, thanks to the work of [Jonathan Armstrong] we have such a firmware for the 433 MHz magnetic door and window sensors that you can pick up on AliExpress for $4 USD a piece. The new firmware not only ensures you can use these sensors with a wide array of receivers, but adds a number of new features over their stock configuration.
In addition to tweaking the transmission protocol so it can be picked up with existing open source projects such as the popular rc_switch library, [Jonathan] has also added a periodic heartbeat signal that can be used to verify the sensor is still online. The new firmware will also transmit the status of the sensor’s internal tamper switch, alerting you to the possibility that somebody is trying to physically manipulate the sensor.
He’s got more ideas for features, but tells us he could use some assistance from folks experienced with the 8051 architecture. [Jonathan] says the development tools [Vincent Defert] put together for the STC15 microcontroller used in the sensors got him on the right track, but he’s struggling to use emulated EEPROM as code space. If he could figure that out, it would pave the way for more capabilities such as connecting additional sensors to the board.
Replacement firmware projects can not only free a device from the proprietary ecosystem it was designed for, but open up a whole new world of possibilities. One of our favorite examples is the custom firmware [Aaron Christophel] developed for Xiaomi’s Bluetooth thermometers, which took a cheap vendor-locked gadget and turned it into a smart home powerhouse.
Popping in just to mention one of the features of the alternative fw for those BLE thermometers is support for a reed contact so that they can additionally act as a door sensor…
using those BLE’s in each room as temp sensors to now drive the home heating system.
using the reed input as window sensors which helps the system to notice why some might be colder as they are mounted on the window sills.
Is there a suggested source to buy these? The last time I tried I bought a bunch of similar but not quite compatible thermometers from AliExpress.
is there a path to connect this to my Home Assistant, zigbee/zwave system?
the longer wavelength would probably help a lot in one challenge i have.
Sonoff RF gateway, flashed with tasmota. Capture rf messages, publish to mqtt and use automations or node red to filter/parse/push resulting mqtt actions to binary sensors in home assistant
If you wanted to nickel and dime you could make the same thing with an esp8266 module and a 433mhz receiver module.
Any RTL_SDR receiver (many open options available) coupled with RTL_SDR software. Push the data to MQTT and call it done.
This is by FAR an easier and much better option than flashing these things with custom firmware.
Or openmqttgateway which is made for sending and receiving between mqtt and 433 or ir. It runs on a esp and is quite easy to setup
This is excellent. I have long used these as cheap light switches – with the standard firmware I was limited to one switch and a push button. Now I will have to have a play and build a 2 switch model…
The addition of a heartbeat is also a good idea. Something that 433 Mhz sensor builders should always make an option.
Not sure if I can post a link but here is the old write-up of the light switch build: https://community.home-assistant.io/t/budget-priced-wife-friendly-wireless-wall-switch-using-433mhz-and-mqtt/88281
Nice hack!
My main concern with simple RF door sensors is how easy it is to jam their frequency. Simple sensors only send the change of state once, no matter if the message was received or not, so it is easy to jam, open them close again.
A good sensor should keep a local message queue, if ever jammed, at least the messages will be queued and re send as soon as the jamming ends. If jammed for too long, absent a keep alive signal the system should detect the irregularities.
In the internet of things, the S stands for security
Yep – but as long as you understand the limitations and do not treat these as “security” devices, they are still useful. Like as battery powered switches, checking states of doors and windows when doing climate control action, a mailbox sensor, as reminder sensors for gates left open or closed.
If it’s “non critical”, it is a valid use case.
You can effectively mitigate this jamming with the “heartbeat” mode included with the alternative firmware. I’m not sure if a message queue is useful but again it could be implemented as well as retransmission. The key would be that the receiver sounds an alarm if nothing is received after X time. Could you be a little more detailed about what you think a queue would benefit?
I think if the door was opened and then closed while the signal was jammed, it would only ever be recorded as being closed.
Got it, fair point.
To (partially) protect against this you could use blockchain: every packet includes a hash of the previous one and a hash of a nonce that will be included in the next, to authenticate it.
But you can’t make a one-way protocol really secure. And battery gets drained way faster.
The heartbeat just needs to include a counter of number of openings since boot.
I do now store an array of events, along with an option to send a packet count.
This was added mainly for debugging/troubleshooting reliability of sending packets but could be considered a sort of jamming detection I think.
Anyway, thanks for describing the concern and commenting.
Firmware author here, very cool modification. Thanks for reporting the low battery code in your post…I forgot to record it for my firmware but have now added in the functionality. Do you know what is the behavior of the low battery code on stock firmware? Does it start sending out codes repeatedly on low battery or only when another switch is triggered (i.e., woken up from sleep)? On my unit the circuit presents a low on P3_5 when battery voltage is about 1 volt.
As far as I can determine it only sends out one code when the low voltage threshold is passed. This effectively means it will send it a few times as the battery recovers after transmission or due to temperature change. I change the battery straight away so I really can’t be sure.
I’ll drag a couple out of the parts drawer and do the low battery test myself with a bench supply before I load this new firmware.
Link works, letting me to a nice and useful hack. Thnx, mate!
The most important questions before investing time and money into these sensors:
How many years is the standby life?
How far does the transmission reach indoors approximately?
Range is good – a rf bridge and sdr dongle both pick up the signal throughout my 4 bed house. I have had sensors for a year and none have needed a replacement battery. Use std aaa batteries. I suppose lithium ones would last longer…
Cold might be a problem.
https://youtu.be/AOQ95empLzg
As far as battery life is concerned – I installed some of these in Jan 2019. Of the 13 or so units installed only two have had their battery replaced more than once. A couple of units converted to run on AA batteries have never had the battery replaced.
I have quite a few 433MHz sensors in a 5000+ sq ft house as well as outside. The furthest sensor is about 287′ at the back fence. It reports data once every 15 seconds and has had the same lithium batteries for about three years now. 433MHz is king when it comes to both battery life and range in a smart home sensor. The issue is always cool down times from last report and lack of two way reporting (ie, you can’t ping the state of a 433MHz sensor like you can with Zigbee and ZWave).
Probably not legal as the band is for human triggered devices no more than 2 seconds per hour for unattended operation
https://www.law.cornell.edu/cfr/text/47/15.231
Hi, a bit late, but thanks for this link.
I will need to modify heart beat mode to comply.
One drawback of simple ISM-band RF communications should not be left unmentioned. All of these can easily be jammed, recorded, intercepted, and spoofed. There is no authentication or encryption involved.
I’d consider RF433 a technical debt.
You’re right as per:
https://www.youtube.com/watch?v=UlNkQJzw4oA
I was hoping to mitigate this issue somewhat by offering the option of a heartbeat mode – at the expense of battery life.
Oh I should mention one more thing…given that there’s now this open source firmware a rolling code could be implemented [https://en.wikipedia.org/wiki/Rolling_code]. There are attacks on such a scheme however. For more security a transceiver would be needed [https://learn.sparkfun.com/tutorials/secure-diy-garage-door-opener].
Would this work with RFLink? Would make it easy to integrate in Domoticz.
I’m not sure, you might leave an Issue on the github and hopefully someone could respond if they try it.
Nice hack, was surprised seeing Tasmota referenced in source docu.
Greetings from Tasmota team
Jason2866
Greetings Tasmota team!
Great project, I’ve used 433mhz door monitoring but I have a local issue with random interference that kills 433mhz so I moved to WiFi and made my own low power sensor https://github.com/gadjet/Window-Door-sensor-Version-5
Admittedly the range isn’t as good but battery life is fantastic
Cool!