New Sonoff RF Bridge Board - Need Flashing Help

[sophof]

Thanks, I will definitely give it a try! So with raw it’ll just log any ‘signal’ no matter those other settings?

[rossco555]

Hi Expello, did you get any response from the manufacturer. The images of your remote look very similar to mine, again re-badged.

[reedy]

I wonder has anyone flashed the r2 v2.2 sonoff rf bridge successfully and got it working yet with tasmota/esphome acceptably.

I’m still running the standard ewelink sonoff login. It works but it continually reconnects to wifi as it’s packet filtered from accessing external networks. It still does this even though the mode is set to local in the HA config. see:

sonoff:
username: [email protected]
password: !secret sonoff
mode: local

some of these cheap chinese iot devices do the job but have some really shitty quirks.

[reedy]

doesn’t look like it…

New Sonoff RF Bridge Board Layout (R2 v2.2) · Discussion #13283 ·...

[zain1144]

Last week I got my sonoff bridge rf. At first, I ran it with the sonoff integration but I noticed a delay for about 1 - 1.5 sec until the device recognize any code.

I flashed the bridge with tasmota but the delay still there, I only need the bridge to responded to my rf remote and I need immediate response.

luckly I saw @mateine post about the direct hack and I modified the bridge.

I installed the tasmota-sensors.bin and configured GPIO4 to RFrecv and GPIO5 to RFSend

On the home assistant side, I used automation with MQTT triggers

platform: mqtt
topic: tele/rf/RESULT
value_template: "{{value_json.RfReceived.Data}}"
payload: "Rf Code"

So far it works fast and the delay disappeared.

[SaschaMuehl]

Dear @Mateine and @schmurtz,
thanks for your nice and easy understandable documentation! I do have a struggle question with ESPHome.

I’ve successfully flashed RFLink32-For-Sonoff-RF-Bridge according to (schmurtz).
The Sonoff RF bridge is successfully integrated in my Wifi by static IP 192.168.178.42 and is accessible via the web browser in my local WLAN.

Now I’m struggling with the Homeassistant Integration ESPHome.

Trying to install your configuration wirelessily with slightly different parts I get an Error:

> ERROR Connecting to 192.168.178.42:8266 failed: [Errno 111] Connection refused
Why is it refused? Do I need to configure a special port or a special password for it

My sonoffrfbridge.yaml look like:

#credits @ https://community.home-assistant.io/t/new-sonoff-rf-bridge-board-need-flashing-help/344326/17?u=saschamuehl

esphome:
  name: sonoffrfbridge
  #platform: ESP8266  #the compiler says it's not necessary anymore
  #board: esp8285        #the compiler says it's not necessary anymore
  build_path: ./build/sonoffrfbridge

esp8266:
  board: esp01_1m

# Enable logging
logger: 

# Enable Home Assistant API
api:
#  encryption:
#    key: "+Uba/lSQfch3jm6lOJVHD/EqWmpOs0EfJxDpKZErpGo="

ota:
  #password: "2c24e942d13ac5a4cebdef6eebc7171a"
   #->where integrated automatically, I decommented it
  #password: !secret ota_password
  # ->is this the PSW for mqtt?
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: true
  #use_address: 192.168.178.42
  
  manual_ip:
    static_ip: 192.168.178.42
    gateway: 192.168.178.1
    subnet: 255.255.255.0

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Sonoffrfbridge Fallback Hotspot"
    password: "xyz"
   #->where integrated automatically
captive_portal:

web_server:

status_led:
  pin:
    number: GPIO13
    inverted: yes

# USBRX = GPIO4 ---> receiver
# USBTX = GPIO5 ---> transmitter

# receiver = pin 5 of the 8-legged chip (the one closer to the wifi antenna)
# transmitter = pin 4 of the 6-legged chip (closest to r12)


remote_receiver:
  pin: GPIO04
  dump: all
#  dump: raw        #for raw-Code recieving

remote_transmitter:
  pin: GPIO05
  carrier_duty_percent: 100%

# this will log received commands, and can also transmit. Read up here:
# https://esphome.io/components/remote_transmitter.html#remote-setting-up-rf

Credits @mateine

New Sonoff RF Bridge Board - Need Flashing Help

New direct hack It is the equivalent of Hardware Itead Sonoff RF Bridge Direct Hack to get super wide protocol support, but for the new R2 v2.2 board (not a way to flash Portisch.) Tutorial 1. Cut the usb data lines Exactly as in the original mod for older versions, these traces are connected with GPIOs we’ll use to connect the receiver and transmitter directly to the ESP8285. If left conected, usb chargers may bridge them and nothing will work (or worse). [image] 2. Connect the transmit…

Credits @schmurtz

New Sonoff RF Bridge Board - Need Flashing Help

Good to know, mine works since few days in continue but let’s make it more securely : we replace the wires by resistors, as Tinkerman from espurna said : " resistor : anything in the range 180-680 ohms, 1/4 or 1/8 W will do. The advantage of using a resistor is that if you inadvertently solder the wrong pins, the resistor will prevent any damage to the semiconductors." Then we isolate the en/decoder chip by cutting these lines : The emitter at the back : [image] The receiver near the “RST” …

[mateine]

Here’s my yaml:

substitutions:
  devicename: sonoff-rf-gateway
  upper_devicename: Sonoff RF Gateway

esphome:
  name: ${devicename}
  comment: Hacked sonoff rf gateway
  platform: ESP8266
  board: esp8285

wifi:
  ssid: !secret wifi_name
  password: !secret wifi_pass
  fast_connect: true
  power_save_mode: HIGH

# Enable Home Assistant API
api:

logger:

#USBRX = GPIO4 ---> receiver
#USBTX = GPIO5 ---> trasmitter

# receiver = pin 5 big 8leg chip (the one closer to the wifi antena, )
# transmitter = pin 4 small chip (closest to r12)

ota:

web_server:
  port: 80

############################################## RECEIVER ###############################################
remote_receiver:
  pin: GPIO04
  dump:
    - rc_switch
  # Settings to optimize recognition of RF devices
  tolerance: 50%
  filter: 35us
  idle: 3ms
  buffer_size: 1kb

############################################## TRANSMITTER ###############################################
remote_transmitter:
  pin: GPIO05
  carrier_duty_percent: 100%

############################################## RECEIVE ###############################################
binary_sensor:
    - platform: template
      id: door_1
      name: door_1
      device_class: door
    - platform: remote_receiver
      id: door_1_off
      name: ""
      internal: true
      filters:
        - delayed_off: 100ms
      on_press:
        - binary_sensor.template.publish:
            id: door_1
            state: off
      raw:
        code: [471,-1413,.....,-471,471]
    - platform: remote_receiver
      id: door_1_on
      name: ""
      internal: true
      filters:
        - delayed_off: 100ms
      on_press:
        - binary_sensor.template.publish:
            id: door_1
            state: on
      raw:
        code: [471,-1413,.....,-471,471]    

In your place, I would:

• Try removing the manual_ip
• Or at least trying a different ip (just in case some other device took x.x.x.42.
• Add a web_server so you can test that too
• Use ping sonoffrfbridge.local or ping 192.168.178.42 to check that there is at least a device on that ip

Note also that the board is not the right one in your yaml.

Wish you luck!

[SaschaMuehl]

Thank you @mateine,
what I did wrong was trying to flash wirelessly for the first time.

Flashing an ESP Over-The-Air isn’t possible for the first time says another forum. Just flash via Serial and FTDI or equivalent

After downloading the *.bin-File and flashing via USB-Serial adapter it worked out.

[zain1144]

I noticed that the bridge sometimes doesn’t give the same code for the same button

These 4 codes are for the same button, the first and the second are not the usual decoded button. The third and fourth are correct.

Any idea why is that happening? I tried different RF remotes and sometimes I don’t get consistent readings.

[jetatomic (Andrew)]

Not sure if this might help anyone, as it may be particular to the device I’m controlling. For whatever reason, I can’t get switches to work at all without adding a repeat and specifying a wait time of 0s.

switch:
  - platform: template
    name: Generator
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx'
          protocol: 1
          repeat:
            times: 10
            wait_time: 0s

This workaround is discussed in an old issue a couple places:

Remote transmitter is not working after update [1.15.3]->[1.16.0]

[zain1144]

Just to follow up on my issues with the false readings.

I tried diffrent versions of Tasmota but it still gives me false readings. Also, I tried ESPurna and it did give me false readings. Then I tried RFLink but I didn’t know how to set it up.

Currently I’m running the brigde on ESPHome and it has been working very well. However it does give me false readings from time to time but not like Tasmota.
ESPHome is also faster than Tasmota

Here is the code I’m using for ESPHome

esphome:
  name: sonoff_rf_bridge
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

web_server:
  port: 80
  
sensor:
  - platform: wifi_signal
    name: Sonoff RF Bridge Wifi Signal
    update_interval: 10s
  - platform: uptime
    name: Sonoff RF Bridge Uptime

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

  - platform: remote_receiver
    name: "RF Button A"
    rc_switch_raw:
      code: '001011100011001000010010'
      protocol: 1
    filters:
      delayed_off: 100ms

  - platform: remote_receiver
    name: "RF Button B"
    rc_switch_raw:
      code: '001011100011001000011000'
      protocol: 1
    filters:
      delayed_off: 100ms


remote_receiver:
  pin: 4
  dump: rc_switch
  tolerance: 35
  filter: 4us
  idle: 4ms

remote_transmitter:
  pin: 5
  carrier_duty_percent: 100%

status_led:
  pin:
    number: GPIO13
    inverted: yes

[VladStar (Vladislav Staroselskiy)]

@jasebob OMG, thanks a lot for the hint!!!

I’ve been struggling to see any RF packets in Tasmota console until now. Sadly, no one clearly mentioned that you have to issue the following command to activate the RF protocols:

RFprotocol a

[deep126]

did you use 4.7k ohm resistors?

[vyruz1986]

I’ve read through this thread and have seen at least a couple of mentions of people flashing the R2 V2.2 bridge with tasmota, without performing the hardware mod or flashing custom firmware to the RF chip. However I can’t get this to work

I’ve got an RTL-USB SDR and am using Airspy to monitor the actual airwaves for 433MHz transmissions.
When pressing buttons on my RF remote I can see them in Airspy, but Tasmota reports nothing in the console.

Alternatively I’ve tried transmitting RF data from the bridge using the RfSend 0x7028DC, 24, 1, 10, 238 command (from the docs), however the console responds with RSL: RESULT = {"Command":"Unknown"}

So am I using the wrong binary? I tried both the default one and the sensors one, both don’t seem to do anything with RF data…

[Fred5]

Ik I transmit your command ( RfSend 0x7028DC, 24, 1, 10, 238) from my rfbridge I also receive RESULT = {"Command":"Unknown"}from the console.
Btw my bridge is working.
see also

Trying to send RF Codes, how do I do that with the Sonoff RFBridge?

Hi All I have a light that is operated via RF, I have a SONOF RFBridge that is tazmotized. I’ve used the RFBridge only for receiving codes so far, so I’m a little lost here. I can see the code the remote sends to the light directly in the console. So it seems to be able to do this. But how do I: Enter a command directly in the RF Bridge console to send the RF code (for testing) Create an MQTT command that will send this code through the RF Bridge. I’ve tried searching for this, but I can…

[judges]

Thanks a lot for all your valuable input here @mateine! I applied the direct hack to my Sonoff RF Bridge, made some raw readings of my garage door opener and pasted the result into your online remote receiver oscilloscope. It helped me tremendously to differentiate the bad signals and noise from the good stuff. Then I created a switch from the raw data and (still can’t believe it) it worked on the first try!

Awesome work, I really appreciate it!

Here’s my yaml:

esphome:
  name: sonoff-rf-bridge
  platform: ESP8266
  board: esp8285
  build_path: ./build/sonoff-rf

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

api:
logger: 
ota:
web_server:

text_sensor:
  - platform: template
    name: Sonoff RF Bridge Uptime
    id: uptime_human
    icon: mdi:clock-start

sensor:
  - platform: wifi_signal
    name: Sonoff RF Bridge Wifi Signal
    update_interval: 60s
  - platform: uptime
    name: Sonoff RF Bridge Uptime (raw)
    id: uptime_sensor
    update_interval: 60s
    on_raw_value:
      then:
        - text_sensor.template.publish:
            id: uptime_human
            state: !lambda |-
              int seconds = round(id(uptime_sensor).raw_state);
              int days = seconds / (24 * 3600);
              seconds = seconds % (24 * 3600);
              int hours = seconds / 3600;
              seconds = seconds % 3600;
              int minutes = seconds /  60;
              seconds = seconds % 60;
              return (
                (days ? to_string(days) + "d " : "") +
                (hours ? to_string(hours) + "h " : "") +
                (minutes ? to_string(minutes) + "m " : "") +
                (to_string(seconds) + "s")
              ).c_str();

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

status_led:
  pin:
    number: GPIO13
    inverted: yes

# USBRX = GPIO4 ---> receiver
# USBTX = GPIO5 ---> transmitter

# receiver = pin 5 of the 8-legged chip (the one closer to the wifi antenna)
# transmitter = pin 4 of the 6-legged chip (closest to r12)

remote_receiver:
  pin: GPIO04
  dump: raw       # all
  # tolerance: 50%
  # filter: 35us  # default 50us
  # idle: 2ms     # default 10ms

remote_transmitter:
  pin: GPIO05
  carrier_duty_percent: 100%

switch:
  - platform: template
    name: garage-door
    turn_on_action:
      - remote_transmitter.transmit_raw:
          code: [356, -377, 380, ... , 749, -377, 399]

# this will log received commands, and can also transmit. Read up here:
# https://esphome.io/components/remote_transmitter.html#remote-setting-up-rf

[kdani (Kiss Dániel)]

Hi, after you runing the tasmotizer button hold the paring button

[Espen_Overbye (Espen Øverbye)]

Hi

I have a R2 V2.2 with direct hack and using rflink2mqtt in HA
I got some new door window sensors that I can not read with this board.

I got another rflink from Nodo shop that reads the new sensors without any problem. Anyone knows a solution for this?

[theRoboticist]

Bit of a shot in the dark here but I was wondering if anyone has seen a case with incredibly spammy raw data after doing this mod: [21:30:15][D][remote.raw:041]: Received Raw: -245, 148[21:30:15][D][remote.raw - Pastebin.com? This is even without pressing any buttons on my remote. I’ve tried moving the board to different locations in case I had some weird RF noise in one room or something, but that didn’t change anything.

I’m guessing this means I somehow messed up the mod and am just getting garbage data, but it looks like all my solder joints are fine I’m able to flash ESPHome just fine (so I haven’t completely fried the board… at least yet ). So I’m at a bit of a loss as to what might be wrong here. Could this be from not getting one of the traces fully cut or something? Any suggestions welcome!

[abrsti]

I have flashed Sonoff RF R2 v2.2 with your ESPHome configuration. But get flooded with “Received Pronto” messages:

[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000C 0035 0065 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0003 0000 000B 008B 000E 0059 0009 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0003 0000 000B 000C 0012 000C 000E 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000D 0014 0063 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0004 0000 0022 0052 000E 0029 000F 0076 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0003 0000 0018 000F 0011 001E 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000A 002D 0023 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000D 0017 0065 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000D 0016 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0001 0000 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0001 0000 000D 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0001 0000 0013 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0003 0000 0015 0018 0063 0014 0012 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 0009 000B 0072 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000C 0017 0092 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000B 0095 003C 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0003 0000 000C 0016 005B 007C 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 0028 0023 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 0012 0044 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000B 004A 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000C 002E 000F 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000C 0015 0073 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0002 0000 000B 0018 06C3
[11:15:23][D][remote.pronto:238]: Received Pronto: data=0000 006D 0001 0000 06C3