Good morning, I would like a help as I do this procedure in Hassio because every time I do it directly in the esphome component when and after compiling I see that the rf_bridge file remains in the wrong way ie I update but when I compile it assumes the wrong again
Sorry, I don’t use that add-on and don’t exactly know what the file structure looks like.
Maybe someone else could help here?
When compiling, the add-on cleans all code as a first step, so any manual changes are reverted. Better to use the command line.
I’ve always found the first time flash to be problematic with ESPHome.
I suggest compiling the binary and then using the flasher utility. After that OTA will work fine.
I have documented the full steps here for how to modify the Sonoff RF Bridge and how to use ESPHome with it, including two state binary sensors, incase anyone gets stuck. Hopefully it will help someone:
5 Likes
Nice write up and very helpful.
I did this a while ago, however, I’ve found that once the number of added devices exceeds around 15, the bridge becomes unstable and constantly connects and disconnects from the HA API.
I currently have 5 Tasmota RF bridges and around 50 sensors. I use this approach to manage the 5 bridges and it works well, but I’d rather have an ESPHome solution.
The API disconnect issue is well known and, as yet, is unsolved in all applications.
Thank you for the feedback and also the heads up! I was not aware of that, I have 14 devices currently would you believe so that’s just a stroke of luck. I’m hoping to add more though soon so I’ll need to find a work around for that.
Hey guys wondering if anyone can help.
Have a sonoff RF bridge that I have loaded tasmota on. I’ve following the instructions and have made the hardware modifications.
I have tried to upload the esp-home binary file I have compiled but I get an error. “Upload Failed, upload buffer miscompare”.
Has anyone else encountered this error? Any ideas about how I proceed from here?
If you are using Tasmota 8+ and get an error after uploading the firmware, go to the console and type SetOption78 1 , then restart the device and try the firmware again.
1 Like
It may well be that the latest dev version of ESPHome fixes it and I’m awaiting the arrival of another bridge so that I can give it a try.
However, the consensus seems to be that it’s a hardware issue with ESPs. Unless someone with more skills than me has found a workaround we may well be stuck, if that is the case.
Thanks, but same error.
Update => Flashed with tasmota-minimal.bin issued the command in the console and re-flashed with the esp binary. Success!!
Thanks for the help, really appreciate it.
Could you help me with the command line?
OK, I have read through the posts here and I am a little confused.
I have done the hardware modifications on the bridge and I have two binary sensors up and running via esp-home. Am I right in understanding I did NOT have to do the hardware modifications after all?
There appears to be two different sets of instructions:
- The RF Bridge component (no hardware modifications); and,
- Setting up RF Devices (hardware modifications required).
I am unsure which method we should be using (I’ve already done the HW mod, so I’m guessing the latter).
My goal is to have bridge receive RF signals from an RF remote, but I don’t see codes consistently when I press the buttons. I did obtain what I thought was a code but it doesn’t work in the transmit mode. It looks like this:
010101011111111111001101000100110101010
I tried the ‘dump all’ option but the log screen is saturated with codes that scroll too quickly to be captured. They look a little like this:
[D][remote.raw] Received Raw: 4088, -1542, 1019, -510, 513, -1019, 510, -509, 511, -510, 1020,
[D][remote.raw] -1020, 1022, -1019, 510, -509, 511, -510, 511, -509, 511, -510,
[D][remote.raw] 1020, -1019, 510, -511, 1020, -510, 512, -508, 510, -1020, 1022
But they scroll though so fast I can’t capture them, let alone know if they are the right codes or not.
Is there a better way to obtain the raw codes? Can the sensitivity be dialed down so the codes don’t scroll so rapidly (where are they coming from anyway?).
PS: I have been told the remote I have is compatible with the Broadlink Pro so I assume they should work here as well.
Would appreciate any pointers you guys may have.
Cheers.
Hi Steven,
I am not expert but I got mine working 
Anyway, your code looks too long,
you probably fetched two merged codes. Try with the first 32 bits
‘01010101111111111100110100010011’
the rest ‘0101010’ looks like the beginning of the first code
And how does your esphome yaml file look like. Especially the transmit part if this is not working.
Any way, please paste the whole of your yaml file then it will be much easier to locate whether something looks wrong/strange.
Cheers
I’ve tried various configurations and I tried the pressing the button several times with the same result.
I have managed to obtain codes for the broadlink bridge. I wonder if I can use them for the Sonoff bridge I have. Is there a particular format ESP home uses for RF remotes that I could convert the code received from the broadlink to?
This is the yaml from the Sonoff RF Bridge:
esphome:
name: rf_bridge
platform: ESP8266
board: esp01_1m
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
captive_portal:
# Enable logging
logger:
# Enable Home Assistant API
api:
password: !secret esp_home_password
ota:
password: !secret esp_home_password
web_server:
port: 80
sensor:
- platform: wifi_signal
name: RF Bridge WIFI Signal
update_interval: 10s
- platform: uptime
name: Bridge Uptime
binary_sensor:
- platform: status
name: RF Bridge Status
- platform: remote_receiver
name: Front Door Motion
device_class: motion
rc_switch_raw:
code: '111111011001010101001110'
protocol: 1
filters:
delayed_off: 300s
# door window sensors
- platform: remote_receiver
id: garage_rf_open
internal: true
rc_switch_raw:
code: '111001001001011100001010'
protocol: 1
filters:
delayed_off: 100ms
- platform: remote_receiver
id: garage_rf_closed
internal: true
rc_switch_raw:
code: '111001001001011100001110'
protocol: 1
filters:
delayed_off: 100ms
- platform: template
name: Garage Door (RF)
device_class: door
lambda: |-
if (id(garage_rf_open).state) {
// door is open
return true;
} else if (id(garage_rf_closed).state) {
// door is closed
return false;
} else {
return {};
}
switch:
- platform: template
name: Blind Down
turn_on_action:
- remote_transmitter.transmit_rc_switch_raw:
code: '001100111111111111001101000100110011001'
protocol: 1
repeat:
times: 10
wait_time: 50ms
- platform: template
name: Blind Up
turn_on_action:
- remote_transmitter.transmit_rc_switch_raw:
code: '000100011111111111001101000100110001000'
protocol: 1
remote_receiver:
pin: 4
dump: rc_switch
tolerance: 50
filter: 4us
idle: 4ms
remote_transmitter:
pin: 5
carrier_duty_percent: 100%
status_led:
pin:
number: GPIO13
inverted: yes
any news on the RF Bridge component?
Has it been included in the standard version of esphome or is it still under development?
Hi Steven,
It was not enough in my case just to write protocol: 1 in the transmit mode, but I had to add several details to the transmit signal before it worked. Here is an example of one of my transmit sensors that works fine:
I also noticed that you have “-” before “remote_transmitter.transmit_rc_switch_raw” while I don’t.
try to remove that
Cheers 
1 Like
Thanks for that, I’ll give that a try.
It’s still only in the dev version of ESPHome, and it still has a bug that prevents you from actually transmitting codes to a device.
1 Like
Have the docs been updated with this yet?
If not, please could you share a config?
I only receive with RF Bridge so would like to give it a try.