Sonoff RF Bridge with ESPHOME?

Has anyone gotten ESPHome to work with the Sonoff RF bridge? I see that ESPHome has the “Remote Transmitter” and “Remote Reciever” modules, but can’t find any complete examples on setting it up. All the Sonoff RF bridge videos I’ve found use Tasmota. I can go that route, but I’d rather use ESPHome…

6 Likes

I’m very interested in this as well. I have to devices that should work for this… 1. is an EACHEN RF BRIDGE. 2. is a HELTEC Wifi LORA 32 v2

Photos of the EACHEN RF BRIDGE without its cover.

The heltec wifi lora32 V2 is working with oled but I can’t seem to find a way to view the logs of mqtt or what pin to use for the dump all, or transmitter pin.


My story with Sonoff RF Bridge and ESPHome.

Intro.
I have a lot of different Sonoff switches (all flashed with ESPHome) and use Home Assistant to control everything. Lights are controlled by Sonoff switches, 1ch, 2ch, 4ch PRO. I tried to use Sonoff Touch to control lights (and as the wall switch), but I don’t have enough wiring going to light switches in the walls to be able to use Sonoff Touch everywhere. My solution was is to use cheap Chinise RF433 wall switches and Sonoff 4ch PRO (with RF). It work perfect! Next goal was to add more wall switches to control bathroom fan (with Sonoff TH10) and to be able to use two or more RF wall switches for one light. I tried to add RF receiver module manually to Sonoff, but without luck - I saw some codes but there was a lot of noise and nothing works (maybe later I will dig in this direction more).

So that is how I got Sonoff RF bridge (R2 v1.0). I did not try it with default firmware, it make no sense for me at all, as I need direct connection to Home Assistant, and I saw, that ESPHome is not fully supports Sonoff RF bridge and some hardware hacking needed, so I started with TASMOTA firmware.

Well, it works with TASMOTA. I connected it through MQTT to Home Assistant, read the codes from RF wall switch, make automation script to turn the lights on switch press. But, it works… slow. There is big delay between button press and HA script reaction after and sometimes it lost fast button pushes. I tried to play with TASMOTA configuration after to reduce this delay but without luck.

I decided to go back and try it with ESPHome, as it never fail. I used this guide to modify RF Bridge: https://github.com/xoseperez/espurna/wiki/Hardware-Itead-Sonoff-RF-Bridge---Direct-Hack
Actually, it was pretty easy to do, even with my poor soldering skills - only add two resistors (I took 200 Ohms 1/8W) and cut three tracks on the board.

Next the firmware and YAML configuration. Short description is here: https://esphome.io/components/binary_sensor/remote_receiver.html

  • so I flash ESPHome with proper remote_receiver (& remote_transmitter) setup. Also I used dump: rc_switch in remote_receiver to hide garbage signals in the logs
  • read the logs
  • press the RF button, got RF signal binary number (and it was exactly the same code as I read with TASMOTA, just not in HEX but in BIN format, ‘1011 1110 1011 1101 0001?’ instead of ‘0BEBD1’)
  • write received RF signal number into RF Bridge config to create “remote_receiver” binary sensor
  • flash RF Bridge with new config
  • add RF Bridge to HA
  • make automation script to turn lights when RF Bridge binary sensor become active (receive the signal from button)
  • done!

Now it works as any other ESPHome device, RF button turn the lights fast and without fails. The only thing, I had to increase filter value to avoid ghost button presses (cheap button, I know).

Also, I tried to send RF signals with the bridge and no problems:

  • read the logs
  • press the RF button, got RF signal binary number
  • write received RF signal number into RF Bridge config to create “remote_transmitter” switch
  • flash RF Bridge with new config
  • make automation script to turn on RF Bridge switch, and RF signal will be sent

And final config for Sonoff RF Bridge looks like this:

esphome:
  name: sonoff_rf_bridge01
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: 'xxxxxxxxxx'
  password: 'xxxxxxxxxx'
  manual_ip:
    static_ip: xxx.xxx.xxx.xxx
    gateway: xxx.xxx.xxx.xxx
    subnet: xxx.xxx.xxx.xxx

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

web_server:
  port: 80

binary_sensor:
  - platform: status
    name: "RF Bridge Status"

  - platform: remote_receiver
    name: "Remote Input Test L"
    rc_switch_raw:
      code: '000010111110101111010100'
      protocol: 1

  - platform: remote_receiver
    name: "Remote Input Test R"
    rc_switch_raw:
      code: '000010111110101111010001'
      protocol: 1

  - platform: remote_receiver
    name: "Remote Input Door Sensor"
    rc_switch_raw:
      code: '000001101001110011000110'
      protocol: 4

remote_receiver:
  pin: 4
  dump: rc_switch
  #filter: 200us
  # I found, that smaller values works much better, so...
    filter: 4us
    idle: 4ms

remote_transmitter:
  pin: 5
  carrier_duty_percent: 100%

status_led:
  pin:
    number: GPIO13
    inverted: yes

switch:
  - platform: remote_transmitter
    name: "Remote Fan Control"
    rc_switch_raw:
      code: '100000000001010000000010'
      protocol: 1
    repeat: 3
17 Likes

Sorry, according to forum limits I cannot putt all photos into the post, so here is a link to the album:

4 Likes

Thank you! This is exactly the info I was looking for!

Interesting! I’m looking for a solution like this.

I thought of a battery powered 433mhz ‘wall switch’ button like in your picture (coin cell & long living) with a 433mhz bridge (esphome using a esp32 and some cheap 433mhz module). On the other end a sonoff basic (for sure with esphome super skills!).

Your setup looks the same (despite little hardware difference). Could you confirm? And how fast is fast? Would it work to enter a dark room, push the 433 ‘wall switch’ button and get light in a proper time frame?

My other thought was to use a sonoff basic with RF. This way it would even work when the WiFi is down when I’m right (Actually I don’t know how the RF part works when I flash esphome?)… But for hardware invests - just one 433 bridge is cheaper :smile:

Also you use 433 door reed contacts? Do they have two different states (open and close?) could you suggest them? Great idea by the way :wink:

I also have a RF Bridge working with Tasmota, but wish to bring everything under ESPHome.
Currently I use it for door sensor (receiving), alarm siren (sending)

Will I need this hack? Or I just upload your code?

From the supplied ‘Direct Hack’ link:

This upgrade provides for the recognition of a wider set of remote control codes than those natively handled by the EFM8BB1 auxiliary microcontroller inside the sonoff bridge. The EFM8BB1 microcontroller is entirely bypassed, allowing the ESP8266 to take care of decoding and decoding the RC pulses in a more flexible way.

Thanks. Currently my devices work well with RF Bridge and Tasmota, I guess I not need it then

Is this a requirement to get ESPHome running on a Sonoff RF Bridge?

I don’t want to hack the hardware just change the software and use as is.

Short answer: I don’t know.

The modification disables the EFM8BB1 auxiliary microcontroller (isolates its circuitry) so only the ESP8266 is functional. My guess is that the firmware (whether its ESPHome or Espurna) would not work well (or at all) if the EFM8BB1 continued to be part of the equation.

I think it’s reasonable to assume that if the firmware could function with both the EFM8BB1 and ESP80266 activated, then there would be no need to disable the EFM8BB1.

The codes are in the log of ESpHome?

Some code I can recreate (PIR sensors, door sensors), but for example I lost my Alarm Siren button (a sending code) , so now I do not know how to recreate the code, I know the code is “9987857”, since I have it programmed from the past.
Is there a way to convert the above format with the format required by ESPhome?

I guess from Decimal to … .what binary?

Like 9987857 to 100110000110011100010001 from this website?

https://www.rapidtables.com/convert/number/decimal-to-binary.html

I also don’t know, but if it works with Tasmota I doubt is not working with ESPHome, no?

I guess the hack is needed for those remotes that do not work with tasmota either … but I am not sure about it.

The original question was whether the hardware modification, shown in Espurna’s documentation, is required for ESPHome to work with the RF Bridge. I replied to that question.

Espurna’s documentation states that, if using the hardware modification, the firmware must be compiled with a different software setting.

This upgrade requires ESPurna to be compiled using the setting RFB_DIRECT=1 (available since 1.12.6), so that the firmware is aware that we have to encode/decode the signals in software rather than talk to the EFM8BB1 microcontroller.

Tasmota’s documentation doesn’t mention the hardware modification shown in Espurna’s documentation. This may mean Tasmota either:

  1. Uses the EFM8BB1 microcontroller by default and has no alternate version that works without it.
  2. Doesn’t use the EFM8BB1 microcontroller and doesn’t require it to be electrically isolated.

I don’t know which one of the two is the correct answer. If it’s #1 and you disable the EFM8BB1, then I doubt Tasmota will work. If it’s #2, then Tasmota works regardless of the state of the EFM8BB1.

Tasmota does show a hardware modification but it’s for R2 boards and for a completely different purpose.

Yes, it will be almost the same, if you will get RF module work on esp32. Config will be the same (except other pins for RF).

With TASMOTA it was near 1 second delay between button press and light on.
With modified RF Bridge & ESPHome I have almost immediate response, I can switch light on and off three or four times per second.

If it have the same logic, as Sonoff 4ch PRO, then it will work with RF button directly, but without reading actual RF codes in ESPHome (RF module is controlled by separate chip with own logic). Sonoff will switch light on RF button press and smart home will only see, that Sonoff switch was turned.

Nope, this device can only send single signal on open (or on button press). That is bad, useless, so I ordered another that should send three states.

1 Like

Yes, it is required. As it was mentioned before, ESP8266 on Sonoff RF Bridge actually don’t have RF modules connected. So you cannot control them with ESPHome as they are absent. WIth this hack you are manually connecting the RF components to ESP8266.

TASMOTA works with RF through EFM8BB1 microcontroler, so no modifications needed. I heard, that EFM8BB1 firmware is pretty limited, don’t see some remotes, and in such case you cannot change this.
With ESPHome (and the hack) I also modified RF protocol later to get it working with on of the remotes (which ESPHome don’t support).
Here how it was:

I use Sonoff RF Bridge and I have RF remote (standard Sonoff 4 buttons portable remote) which use 256us pulse length with {1, 31}, {1, 3}, {3, 1} pattern, so remote_receiver don’t see signals from it. Actually, it can see signals if tolerance is 40% or higher (when 350us and tolerance 40% the error cover 256us range, as I found), but then there are a lot of garbage signals.

I tried to modify rc_switch_protocol.cpp & rc_switch_protocol.h and add additional protocol pattern to array with 256us pulse length and works good, clean signals and immediate response (also in rc_switch.cpp: RCSwitchDumper array length should be adjusted too, i < sizeof(rc_switch_protocols); )

Also, I found, that default values for remote_receiver: filter: 10us and idle: 10ms or higher works really bad - logs are overloaded with “Data is coming in too fast!” and device not recognize most of the codes. With filter: 1us and idle: 1ms all works fine, a lot of correct signals. And to debounce the buttons I use binary_sensor: filters: - delayed_off: 100ms.

PS: filter: 4us and idle: 4ms even better, more signals can be read from different remotes.

4 Likes

Yes, that is right. Convert DEC or HEX to BIN (Windows Calc may help also) and you are ready to send it with ESPHOME. TASMOTA use HEX format for this, so DEC > HEX.

@OttoWinter

SO maybe in future release of ESPhome this chip will be supported

I don’t understand the long delay using the Tasmota code? I have two “Sonoff RF bridge 433” devices, each running the Tasmota code and with the modification performed on the https://github.com/arendst/Sonoff-Tasmota/wiki/Sonoff-RF-Bridge-433 page to load the fancy new firmware on the EFM8BB1 microcontroller. I’m not using the extended “raw” mode that it allows.

I get pretty quick response from motion and door/window sensors triggering to turning on some Z-Wave lights, maybe closer to half a second or less. And that’s after first running through a small Node RED thing that subscribes and republishes MQTT messages to Home Assistant. (I do this because I have two RF Bridge devices at either end of the house, each publishing to a different topic. The Node RED thing de-duplicates the events as both bridges seem to hear most all of the messages from the various sensors…)

My gut feeling is that you’re going to get a more reliable detection having the EFM8BB1 decoding the message since I’m guessing there’s going to be a lot more timing jitter having the ESP8266 try to time the signal transitions.

I’d love to get a ESPHome solution that targets the RF Bridge device… at some point, I want to convert a number of other Sonoff devices that I have from Tasmota to ESPHome to simplify things a bit.

One thing that I did discover in doing testing of various 433MHz remote keyfobs is that they generally suck! These things must have some wake-up latency because they are not nearly as response as trigging a motion sensor or similar. And trying to do multiple keypresses in quick succession is also a bit of a crapshoot, too. I’ve tried a couple different versions, though I’m sure its the same basic single-chip solution inside each of them.

Anyway, just another point of view to note that using the Sonoff RF Bridge device successfully with the Tasmota firmware is actually possible. I don’t know where the long delays others are seeing might be coming from; it’s not an inherit property of the Tasmota code on that device.