Sonoff RF Bridge 433 - RTurala/Sonoff-Tasmota GitHub Wiki
- Itead Product Page: http://sonoff.itead.cc/en/products/appliances/sonoff-rf-bridge-433
- Itead Shop: https://www.itead.cc/sonoff-rf-bridge-433.html
- Itead Wiki: https://www.itead.cc/wiki/Sonoff_RF_Bridge_433
- Flash Guide: How to Flash the RF Bridge
- RF Bridge 433 R2 Information: https://github.com/arendst/Sonoff-Tasmota/issues/1916
Attention ⚠️️⚠️️⚠️️
On R2 V1.0 Boards, GPIO4 and GPIO5 are swapped!
Serial Connection
Please see the Hardware Preparation page for general instructions.
As always, you need to access the serial interface. The four serial pins (3V3, Rx, Tx, GND) connected to the ESP8285 are available on the 5-pin header just next to the switch as can be seen in the image to the right.
Move the switch towards the 5-pin header, keep the button on the edge pressed and connect the serial programmer.
After programming make sure to move the switch away from the 5-pin header to restore connection to the RF microcontroller. Select device Sonoff Bridge in configuration page!!!
Operation
During normal operation the serial interface is used at 19200 baud to communicate with the RF microcontroller. It is therefore wise to disable serial logging (seriallog 0
).
The bridge is able to learn up to 16 different remote control commands of fixed code 433 MHz frequency as provided by PT2260, PT2262, PT2264 and EV1527 Transmitters. I was not able to recognize the latest Klik Aan Klik Uit (KaKu) remote control signals but some people managed to use the fixed code KaKu devices like PAR-1000 receiver and PAT-103 transmitter.
Tasmota provides default remote control commands to all 16 keys so you can start using the bridge with a Sonoff 4CH Pro or Sonoff RF device without having the bridge to learn remote control commands.
See Supported Commands for available specific Sonoff RF Bridge 433 commands.
Rf chip firmware upgrade
By updating the firmware of the Rf chip (or co-processor, microcontroller) EFM8BB1 new possibilities become available. Starting with Tasmota v6.0.0a the Rf chip firmware upgrade is easily done using Web Gui Upgrade by File Upload. Tasmota currently support the Portisch (https://github.com/Portisch/RF-Bridge-EFM8BB1) firmware only.
A hardware preparation is needed (only for R2!) if you want to use USB for powering the device during EFM flash process. Shown picture is the Bridge R2 version where two not used copper traces need to be cut if you want to use the current power connector during updating and connect two wires between GPIO4 and C2Ck and GPIO5 and C2D. These changes can be permanent as they do not interfere with the normal Bridge functionality and it also allows for easy changing of firmware in the future.
You dont have to cut wires to upgrade the firmware of R2!!!! If you dont like the idea cutting something in your bridge there is no need for! In that case DONT use USB to power the bridge. Power the bridge over a pin in the bridge labeled 3.3V. Just the same way as flashing the ESP. However you still need to connect GPIO4 & GPIO5 as described above. After flash process is done the bridge can be powered over USB for normal use.
Once the hardware changes have been made or the Bridge is powered via a 3.3V pin and the correct Tasmota firmware has been uploaded select the desired RF_Bridge.hex firmware file from the tools/fw_efm8bb1 folder and Start upgrade. This will replace the current Rf chip firmware within 60 seconds.
IMPORTANT: In the Module configuration GPIO4 and GPIO5 must be left as 00 None
B1 to B0 helping tool.
After learning how bit bucket works from here #23 this is a python script to help calculate the right 'B0' message to send using 'RfRaw' command in Tasmota from the received 'B1' sniffing message (rename file from 'BitBucketConverter.txt' to 'BitBucketConverter.py'.
In the command line give the 'B1' message string and the retries value (in decimal): i.e. BitBucketConverter.py "AA B1 04 07EB 0157 00FD 3EBC 010101010101101001010101101010100103 55" 20
Command Line : "AA B1 04 07EB 0157 00FD 3EBC 010101010101101001010101101010100103 55" 20 Result: 'RfRaw AAB01C041407EB015700FD3EBC01010101010110100101010110101010010355'
'Raw sniffing' procedure.
With Portisch suggestions I did the following: In Tasmota console I sent
22:58:44 CMD: RfRaw AAB155
I then received two consecutive messages.
The first one tells you that you are using one of the new firmware commands
22:58:44 MQT: gvf/cega/bridge1/stat/RESULT = {"RfRaw":"ON"}
The second one tells that the EFM8BB1 RF chip new firmware accepts the command and enters raw sniffing mode ('A0' means 'ACK')
22:58:44 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AAA055"}}
After that I kept pushing one of the buttons in the remote.
22:58:44 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AAA055"}}
22:58:49 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 04 07F0 0128 00F2 3822 010101010101101001010101101010100103 55"}}
22:58:49 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F9 0124 37DC 010101010101101001010101101010100102 55"}}
22:58:50 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F9 0124 37DC 010101010101101001010101101010100102 55"}}
22:58:50 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F4 0126 37D2 010101010101101001010101101010100102 55"}}
22:58:51 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F5 0127 37D2 010101010101101001010101101010100102 55"}}
22:58:52 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F7 0125 37DC 010101010101101001010101101010100102 55"}}
22:58:52 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F9 0125 37D2 010101010101101001010101101010100102 55"}}
22:58:52 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F4 0123 37C8 010101010101101001010101101010100102 55"}}
22:58:53 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F9 0124 37D2 010101010101101001010101101010100102 55"}}
22:58:53 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07FC 011E 37D2 010101010101101001010101101010100102 55"}}
22:58:54 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F8 0125 37D2 010101010101101001010101101010100102 55"}}
22:58:54 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F8 0124 37D2 010101010101101001010101101010100102 55"}}
22:58:55 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F9 0125 37D2 010101010101101001010101101010100102 55"}}
22:58:55 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F8 0122 37C8 010101010101101001010101101010100102 55"}}
22:58:56 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F1 012D 37D2 010101010101101001010101101010100102 55"}}
22:58:57 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F4 0123 37C8 010101010101101001010101101010100102 55"}}
22:58:57 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F8 0128 37C8 010101010101101001010101101010100102 55"}}
22:58:58 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F9 0124 37D2 010101010101101001010101101010100102 55"}}
22:58:58 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F4 0124 37C8 010101010101101001010101101010100102 55"}}
22:58:59 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F9 0124 37C8 010101010101101001010101101010100102 55"}}
22:58:59 MQT: gvf/cega/bridge1/tele/RESULT = {"RfRaw":{"Data":"AA B1 03 07F4 0123 37D2 010101010101101001010101101010100102 55"}}
I received a sequence of messages. All starting with 'AA' then 'B1' and the last byte '55'
The reason for pushing the remote button for several seconds is to get enough 'AA B1 ...... 55' sequences to select the best one to be transmitted back.
Then I discarded the sequences with 'data values' not equal.
In the example 'data values' are the '010101010101101001010101101010100102' string.
Notice that before that 'data values' string there are several 2 byte values (they are called 'buckets'); they are time values in microseconds. The number of 'buckets' is indicated in a previous byte (in the example a 3 or a 4).
In the example I discarded the first message (it contains 4 buckets, whereas the rest have only 3 buckets). I then examined the values on the buckets in order to choose the message where more buckets where 'similar'.
For example messages with '37D2' in the third bucket are good candidates. Messages with '0124' in the second bucket are also good candidates. First bucket values are very similar; '07F8' can be a good one.