Low-Cost 433 MHz Door Sensors Get Open Firmware

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.

Connecting to the programming header is easy.

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.

38 thoughts on “Low-Cost 433 MHz Door Sensors Get Open Firmware

    1. 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.

  1. 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

    1. 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

      1. 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.

      2. 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?

          1. 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.

      3. 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.

    2. 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.

      1. 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.

  2. 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?

    1. 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…

    2. 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.

    3. 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).

  3. 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.

    1. 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].

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.