20170721_163903s

Hacking the Sonoff RF Bridge 433

Itead Studio has been releasing interesting gadgets for the Home Automation community based on a low price tag and extreme hackability. You can google “sonoff” (the main brand for Itead Studio home automation devices) to get more than a million hits, including official pages, reviews and lots of hacks. The ubiquitous ESP8266 (or its sibling ESP8285) is the core of all those devices, using WiFi instead of the traditional RF messages, replacing a remote with mobile apps or voice commands. But also, using custom firmwares like ESPurna, technologies and solutions like MQTT, Node-RED or Home Assistant. But one of the latests devices from the chinese firm tries to bridge the gap between those two technologies: the Sonoff RF Bridge 433.

Itead Studio was kind enough to send me an engineer sample before holidays but I have had very few time to work on it. I should have written this post a month ago. Anyway you can buy one from the Itead Studio webshop or in the usual online markets looking for Sonoff RF Bridge [Aliexpress].

Out of the box

If you had read me before you might know that I have critisized the eWeLink app. It’s not that I didn’t like it. I just couldn’t make it work. With every new Sonoff device I gave it a chance and the outcome was always the same. Until now. Last month I tried it with the RF Bridge and the 4CH Pro and it worked like charm. Don’t know what was wrong. Maybe an uncompatibility with some other service or app in my phone. At some point the problem has been addressed and I could finally test it.

screenshot4s

 

It works, you can discover the device, force pair mode for any of the 4 available buttons and use them. it also work with Alexa and eWeLink custom skill. Nice. But I just don’t want to use it. I will not go (I have never gone) much into the app, the user experience, the use cases,… because this is about hacking it with he aim of really own the device and have the freedom to choose what 3rd party services you will use with it, if any at all.

The device

Outside

The Sonoff RF Bridge 433 is a small black box with a microUSB port for power, a recessed reset button and three LEDs for notifications (power, custom and radio). The button is connected to GPIO0 on the ESP8266 so it doubles as flash mode button. In the original firmware it sets the device into “discoverable” mode, so you can use the eWeLink app to discover it.

20170721_163918s

MicroUSB and reset button.

20170721_163940s

The three LEDs in the front of the device are used in the original firmware to notify radio usage (red), wifi connection (blue) and power (green)

Short section, right. There is really not much more about it. A sticker with a QR linking to the eWeLink user guide.

Inside

Opening the box is quite easy with the help of a couple of plastic opening tools. Inside the box there is a single PCB with all the components.

20170721_164300s

A single PCB holds all the components

On one of the corners you can spot the PCB WiFi antenna and the ESP8285 (an ESP8266 with a 1Mbyte flash memory embedded) along with the required header to flash it (3V3, RX, TX and GND). You also have access to GPIO2 (labelled SDA) on the same header.

20170810_130816s

In the center of the board you can see the EFM8BB1. An 8-bit microcontroller by SiLabs that manages the radio communication. This is the same microcontroller IteadStudio has used for the Slampher and the Sonoff RF. Moving the real-time encoding and decoding out of the ESP8285 has benefits since those are very time-picky functionalities that could interfere with the WiFi communications.

20170721_164240s

The EFM8BB1 microcontroller is responsible for encoding and decoding radio messages

But the EFM8BB1 is not alone. There is a SYN470R ASK superhet receiver decoding the messages. You might have also noticed two quarter-wavelength wire antennae, one close to the receiver and the opposite one for transmitting.

20170810_130851s

The SYN470R ASK decoder and the receiving wire antenna

20170721_164317s

You can also spot a buzzer for pairing notifications and the ASM1117 regulator.

Finally, a SPDT switch that controlls the communications between the ESP8285 and the EFM8BB1. The communication is done via serial (RX and TX) and that could be a problem when trying to flash a new firmware. Moving the switch to the OFF position you effectively disconnect the communication between both microcontrollers.

20170810_130943s

The back of the board is empty, all the components are on the front

Enough about the PCB. You can check the schematics for the Sonoff RF Bridge 433 yourself at the IteadStudio wiki.

ESPurna

Flashing it

As we have seen the board has all the connections to allow anyone to flash a custom firmware on the ESP8285 (and on the EFM8BB1, but I will focus on the Espressif chip). All you have to do is:

  • Connect the ESP8286 header to your USB2UART programmer (RX to TX, TX to RX and GND to GND)
  • Place the switch in the OFF position
  • Press and hold the reset button
  • And power the device either via the microUSB port or via the 3V3 pin on the same programming header

20170810_130927s

At that moment the ESP8285 will boot into flash mode, ready to get a new firmware. If you are using PlatformIO (recommended), just checkouot the ESPurna repository, browse or open the Atom IDE on the code folder and build and flash the itead-sonoff-rfbridge environment. From the console it would be something like:

pio run -e itead-sonoff-rfbridge -t upload

Done. If you are using Arduino IDE instead check out the instructions from the Arduino IDE page in the ESPurna wiki to configure the environment and flash the board.

Since 1.9.0 ESPurna fully supports Sonoff RF Bridge 433 but the approach the firmware uses is quite different from that on the official app.ç

The ESPurna firmware is released as free open software and can be checked out at my Espurna repository on Bitbucket.

Public API

It turns out that the API between the ESP8285 and the EFM8BB1 is public under the serious name of RF Universal Transceive Module Serial Protocol. The document is spare, has one or two typos and misses some basic information, but it’s good enough to interface the EDM8BB1 from you own ESP8285 firmware.

The key points in the API is that:

  • You can set the device in “listen mode” which basically beeps the buzzer to provide some user interaction
  • Any code the SYN470R decodes the EFM8BB1 will report it to the ESP8285
  • The ESP8285 can send raw codes to the EFM8BB1 and it will forward them

So we have a good enough API to work with. The ESP8285 handles the user interaction, stores codes (there is room for more than a 100 different codes in the emulated EEPROM) and commands the 8-bit microcontroller.

From the ESPurna web UI you can manage the stored codes. By default you have 6 ON/OFF pairs but you can change that in the configuration files, anyway it way more than the 4 codes the official app can handle. Once “learnt”, you can use them from the main status page, like you would with any other switch.

screenshot1s

screenshot2s

 

Once you have the codes assigned to a certain “virtual” switch you can manage the from MQTT easily by switching the false “relay” on and off:

mosquitto_pub -t /test/rfbridge/relay/0/set -m 1

or using the REST API so you can do that from outside your home too. Check my post about secure access to your IoT devices from the intenet, also with Google Home.

MQTT power

But the firmware also exposes direct access to the Receive Key and Transmit Key Value entry points. That means you can sniff RF messages from Node-RED, for instance, and send them by simply copy paste the codes. Here you have a screenshot of a fully functional interface for the Sonoff RF Bridge 433 in Node-RED. That’s all it takes.

screenshot3s

You can sniff and store as many codes as you want or use other apps or services to send them via MQTT. The Sonoff RF Bridge 433 as a true, transparent, MQTT-433MHz-MQTT bridge.

Will it work with any RF device?

I have a couple of old RF switches sets at home. I have used them in the past and time has come to give them a second life. These have slightly different implementations based on the Manchester encoding but since the code does not matter about the message structure itself it shouldn’t matter, right?

Well, as it turns out one of the remotes (branded Noru) works flawlessly but with the other one (Avidsen) the RF Bridge struggles to understand the messages and often requires several tries before they got learnt. So what’s the difference?

My only guess at the moment is the timing. The code structure is simple:

  • Sync time (2 bytes)
  • Low level time (2 bytes)
  • High level time (2 bytes)
  • Data (3 bytes)

So this is what a Noru message looks like: “24E0 0140 0384 D00358”. That means: 9440us sync time, 320us low time and 900us high time. Data is “D00358”, this identifies the button in the remote. The timing is not necessarily strict, but you can see the high time is 3 times longer than the low time and the sync time is 10 times longer than the high time. And the minimum pulse length is around 320us and that’s about 3KHz. The SYN470R datasheet talks about a max frequency of 5KHz when in sweeping mode. The pulses in the Avidsen look like being faster than that… but more investigation is needed here.

RF relays

But apart from the Avidesen remotes all the other devices I have tested have been a success. All the RF enabled products by IteadStudio, of course but I have also bought some extremely cheap RF relays to play with.

The ones I bought are 1 channel 433MHz enabled relays [Aliexpress]. You can buy them alone, with a remote, with an enclosure and they come also in multiple channels [Aliexpress]. They work best in interlock mode, with two different commands to switch them on and off. This way ESPurna will transmit each code several times to ensure the relay has been switched, otherwise it will only transmit it once.

20170830_174255s 20170830_174320s 20170830_174310s

Anyway it’s a really cheap solution for home automation and start controlling your assets with MQTT, Alexa, Google Home or a bunch of other solutions.

Overall this is an enabling device. If you are still using 433MHz devices at home, or if you decided to stop using them because, you know, you never find the remote when you need it, now it may be time to make them talk MQTT (somewhat).

CC BY-SA 4.0 Hacking the Sonoff RF Bridge 433 by Tinkerman is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

30 thoughts on “Hacking the Sonoff RF Bridge 433

  1. Gilbert Brault

    Thanks for this good article!

    I did the same on my side and get some issue sending RF codes out, here is my code, any idea?

    void sonoff::TransmitKey(uint16_t Tsyn, uint16_t Tlow, uint16_t Thigh,uint32_t key ){
    Serial.write(0xAA); // Start of Text
    Serial.write(‘0XA5’); // TransmitKey
    Serial.write((char)((Tsyn&0xFF00)>>8));
    Serial.write((char)(Tsyn&0x00FF));
    Serial.write((char)(Tlow&0xFF00)>>8);
    Serial.write((char)(Tlow&0x00FF));
    Serial.write((char)(Thigh&0xFF00)>>8);
    Serial.write((char)(Thigh&0x00FF));
    Serial.write((char)((key&0x00FF0000)>>16));
    Serial.write((char)((key&0x0000FF00)>>8));
    Serial.write((char)((key&0x000000FF)));
    Serial.write(0x55); // End of Text
    Serial.flush();
    Serial.println();
    }

    Reply
    1. Xose Pérez Post author

      Those quotes around the transmit ket code (‘0xA5’) shouldn’t be there. Maybe that’s the reason…

      Reply
  2. Maarten

    Would it be possible to also read weather stations working on 433 mHz and report to eg Domoticz (or alternatives)?

    Reply
    1. Xose Pérez Post author

      That would require a completely different approach. I very much doubt it would work. The weather station should be transmitting data in 24bits packets using Manchester…

      Reply
  3. 0xFelix

    Hey Xose,

    I tried ESPurna with my newly acquired RF Bridge but I cannot get it to work properly.

    When trying to learn a new code the RF Bridge beeps once, then I press the button on my original 433 remote and shortly after the RF Bridge beeps twice but nothing happens in the webinterface and the code is not learned. If I press the button on my remote again the RF Bridge beeps twice again without repressing the learning button. After approximately three tries the RF Bridge stays quiet.

    Do you have any idea? I noticed my board looks a bit different than yours. Instead of two 4 pin headers in the middle of the board it has one long 8 pin header. Maybe a hardware problem?

    Greetings,
    Felix

    Reply
    1. Xose Pérez Post author

      Mine is an engineering sample so it could be that they changed the design before the final release. Anyway what you describe looks like an “incompatible” code for the RFBridge. It beeps when signal is received but the signal doesn’t match the expected protocol/structure. That’s the problem I had with Avidsen remotes, only seldom they are truly “learnt”.

      Reply
      1. 0xFelix

        I took a peek at the insides of my remote, it uses a HX2262 chip. This chip should be compatible with the 2262 series chips (PT2262), maybe it needs a special kind of configuration. I’ve found a good source of information, there is only one catch: it is german, so maybe not much of use for you.

        https://wiki.fhem.de/wiki/Intertechno_Code_Berechnung

        I will tinker a bit with these DIP switches and codes… will let you know if I figure something out.

        Thank you for your nice firmware, I really want to use this nice web interface. 😉

        Reply
          1. 0xFelix

            Hey Xose,

            I’ve taken a different path… I tried to figure out how to calculate codes for my sockets. I have Brennenstuhl RCS 1000 N sockets that use the same protocol as sockets by Elro. There is a library called rfcontroljs which implements this protocol. rfcontroljs calls it ‘switch2’.

            I adapted a bit and had success! I am able to calculate codes for my sockets by hand!

            I put my findings into a Gist:

            https://gist.github.com/0xFelix/2151e4d1c4c4ff75dccaef1dd14e26fb

            I think with a further bit of work a lot of the rfcontroljs protocols could be ported to the Sonoff RF Bridge 433 / ESPurna. Possibly the web interface could also be enhanced, so codes could be calculated automatically according to the used protocol.

            Greetings,
            Felix

          2. Xose Pérez Post author

            Great job Felix!
            I’m glad to see that the choice I made to be able to paste codes was a good idea. I guess the calculations could be done on the client side (javascript), what do you think?

          3. 0xFelix

            Indeed, that was a good idea! Sure, I think a client should be easily able to calculate codes in javascript. My only concern is the limited size of the flash. Do you think several protocols would fit into it? I’d be glad to help implement this feature, if you could guide me in the right direction. Never had much to do with javascript. I suppose an extensible design similar to rfcontroljs would be the best way.

            Also, do you think it would be possible to modify the firmware of the decoder/encoder? Currently only protocols with 2 different pulse lenghts (Tlow & Thigh) and a footer (Tsyn) are supported. Some protocols use more than 3 pulse lenghts, for example KlikAanKlikUit uses 4 different pulses: header, low, high and footer. I think the hardware could support it, but the software is the limiting factor. The ability to send more than 3 different pulse lengths would be great, learning codes could stay as it is. What’s your guess on that?

          4. Xose Pérez Post author

            There is still room in the firmware, after all I don’t it will take more than 2-3K in javascript. My only concern is that, contrary to the C code, everything is included -always- in the javascript code, even thou the device does not use it. I think I will need more preprocessing to the JS and HTML files to only include required functionalities. But there is still enough room for now.

            About flashing a new firmware in the SiLabs micro, well that’s a completely different project… but it will probably allow for greater suppoprt for other remotes…

  4. Göran

    Good article, thanks.

    Any general feeling for what range can be expected?
    Both wifi and 433 MHz range of course depend on antennas, for example.

    I am thinking that maybe two bridges would be needed in a house… which could be set up nicely using mqtt messages sent to any bridge subscribing to the topic in question.

    Reply
    1. Xose Pérez Post author

      Don’t expect a great range. I live in a two-story house and the signal hardly (not always) reaches 10 meters with 3 walls in between. 433 Remotes use to use a 12V battery to get more transmitting power, the RF Bridge only has a 5V input.

      About the topics, each device has its own topics, if you want them to subscribe to the same topic you will have to do some (slight) changes to the code, or send the message to two different topics…

      Reply
  5. Roland

    Would be fine if RCS 1000 N with HX2262 will be supported by a new relase. I noticed that I have only Remotes with HX2262 at my home.

    Reply
  6. Gamester17

    @Xose, do you know anyone with influense over Sonoff products at Itead? If so could you maybe ask them to make a new version of this Sonoff RF Bridge with a much more powerful EFM that is also reprogrammable?

    See all the comments by Stuntteam here => https://www.letscontrolit.com/forum/viewtopic.php?f=9&t=3507

    If only the Sonoff RF Bridge had a much more powerful EFM chip that was also reprogrammable then it could be made to handle many more protocols.

    Stuntteam (developers of the RFLink firmware) wrote in the attatched link that they might even be able to make the full RFLink work on it if it only had a much more powerful EFM chip.

    Perhaps you could convice someone with influense over Sonoff products at Itead to make a “Pro” version of the Sonoff RF Bridge with ESP32 and a much more powerful EFM chip?

    Reply
    1. Xose Pérez Post author

      I have the contact of a tech guy there. Can ask him if there is any chance they would open the EFM code.

      Reply
    1. Xose Pérez Post author

      Yes! I’ve also thought about it. Hardware-wise there is a free GPIO on the ESP header, labelled SDA it’s actually GPIO2. I would connect it to a transistor to drive the IR LED from 5V from one of the regulator legs. You won’t be able to do learning so you will need a separate device to sniff codes from your IR remote, and then copy them to the RFBridge.

      Reply
    1. Xose Pérez Post author

      I agree with him, you are limited to what the EFM can do. Maybe it’s not a “piece of junk” but certainly it could be a plus to reprogram the EFM. Unfortunately that falls outside my skills at the moment…

      Reply
  7. mark harding

    HI,

    is it possible to use this as just a received unit without the learning that will then forward the relevant codes over to node-red for example. i have a number of 433 door switches so would like them to just be picked up by the rfbrige and then transmit the code to somewhere be it mqtt or something that i can then interpret to the door is open for example. no need to learn it just forward it!!

    Reply
    1. Xose Pérez Post author

      Yes, learning helps with the user feedback but you can send or receive raw codes via MQTT to and from Node-RED without having to learn them previously.

      Reply
      1. mark harding

        in which case i’m off to open it up and flash it!!! that’s the main reason i needed the unit to go in a room with a few 433mhz switches so saves running cabling everywhere for window states!!

        Reply
  8. mark harding

    any suggestions

    [WIFI] Connecting to BSSID FF:3F:44:04:00:00 – CH 00 – SSID **chubz**
    [RELAY] Saving mask: 0
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [RF] Disabled
    [WIFI] Could not connect to **chubz**
    [WIFI] Creating access point
    [WIFI] MODE AP ————————————–
    [WIFI] SSID SONOFF_RFBRIDGE_8B6

    Reply
    1. Xose Pérez Post author

      All those “[RF] Disabled” messages mean you have enabled the RF module which is not meant for the RFBridge, but for a custom RFlink module. Custom, hand-made, codes should be written in the web UI tab for the RFBridge.

      Reply

Leave a Reply (all comments are moderated, be patient)