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:
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.
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.
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.
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.
Please correct your post. It incorrectly attributes the question posed by eRadix to me. I never asked the question.
Here’s your post, incorrectly attributing the question to me (probably as a result of ‘quoting a quotation’):
Here’s elRadix’s post with the question:
For me it was critical (one of my lights change light mode after quick turn-off-turn-on). With ESPHome I have immediate reaction.
Okay, maybe my MQTT broker on HA was not configured properly, maybe there some settings which can speed up responses. But now I have no need in MQTT, as I use only ESPHome devices.
I found, that ESPHome RF protocol need to be adjusted to work with some of my RF keyfobs. When I did this, I got instant response, at least from the remotes I have.
If TASMOTA works for you and you have no problems - good, no need to change it while it works. I just was unhappy with slow response and with MQTT broker that was running only for one device in HA network.
FYI, I make heavy use of MQTT for other integrations with Home Assistant,and use mosquitto running in a Docker container, alongside of Home Assistant. I believe it has higher performance than the built-in MQTT broker. I also find it handy to use MQTT rather than the newer Home Assistant direct integration in ESPhome because I can easily monitor what’s going on with a simple MQTT client subscribing to a relevant topic.
Glad the ESPhome solution is working great for you! I’m really pleased with Home Assistant having so many options available to solve these problems as they come up, and based on your circumstances.
Who made this rules? Your post is very informative - thank’s a lot! Can’t image it with more photos illustrated! 
EDIT: Never mind - catched the link you posted to the photos 
I noticed that you have pin number 5 connected to ground on the back on the PCB, haven’t seen that referenced anywhere. Am I missing something?
Wow! Eagle eye!
Naah, it just looks like soldered on the photo, there is no actually the connection (and should not be), wire end is floating above the hole.
But thanks for pointing on that, I removed it 
Have you used this approach with sensors that send multiple codes? Like a door sensor that sends one code when open and one when closed? Can they be “merged” into one binary sensor at the esphome level, or do they have to be treated as two separate sensors and merged in HA?
I did not find a way how to merge several codes into one sensor, I don’t think that is it possible. So door sensor with two states, open/close, will require to binary sensors and automation in HA (and I don’t think that it is a big problem).
I have one remove, where each button (4 pairs) send 4 different codes, cycling them on each next button press. So to you this remote, as example, to control 4 sockets with separate buttons for ON and OFF, I will had to create… 32 binary sensors… for 4 sockets. And I have TWO such remotes
First of all, I used 3.3V before for RF receiver. Looks like it need 5V, so I connected it VU pin on NodeMCU (it have 5V there). Next, in my early NodeMCU config there was error, pin: 4 is NOT the same as pin: D4. So as it connected to D4 on the board, it should be pin: D4. I got first signals after this, but only from one of the remotes. So I began to play with config and found, that signals can be read with this settings in device config:
remote_receiver:
pin: D4
dump: rc_switch
filter: 100us
idle: 2ms
tolerance: 50%
And here is how binary sensor looks like for remote buttons:
binary_sensor:
- platform: remote_receiver
name: "Keyfob Remote Button A"
rc_switch_raw:
code: '110010010111000010100010'
protocol: 1
filters:
- delayed_off: 500ms
Now I have the signals from all the remotes. In compare to Sonoff RF Bridge (I make all changes on it to see the difference in performance between Sonoff Bridge and NodeMCU + RF), cheap RF receiver get more errors in signal recognition and really poor distance. So I made simple antenna for RF receiver. It increased distance a little, maybe even reduce errors count, but it still works poor. At end I can say, that Sonoff RF Bridge much more precise in recognition and have really good receiver sensitivity than separate RF module. But both can work with ESPHome if needed, without almost any difference in configs. At least, from what I saw on practice.
Also, the same approach should work for non-RF Sonoff devices, it is possible to connect cheap RF receiver there and read the signals (maybe I day I will test this too).
It should work easily with a template Sensor directly in esphome. If you don’t expose the to binary ones you build the template sensor from to home assistant everything is clean and tidy!
