Sonoff RF Bridge with ESPHOME?

[5310]

Hi
Thanks for the reply.
Yes, there are cuts made to disable the USB on the other side.

I’m testing with a Sonoff CP100s wireless door sensor but am not receiving anything from the logs using code below using EspHome program.

remote_receiver:
  pin:
    number: 4
  dump: rc_switch
  filter: 100us
  tolerance: 50%
  idle: 2ms  
remote_transmitter:
  pin: 
    number: 5
  carrier_duty_percent: 100%

Logs
[07:52:44][C][remote_receiver.esp8266:059]: Remote Receiver:
[07:52:44][C][remote_receiver.esp8266:060]: Pin: GPIO4 (Mode: INPUT)
[07:52:44][W][remote_receiver.esp8266:063]: Remote Receiver Signal starts with a HIGH value. Usually this means you have to invert the signal using ‘inverted: True’ in the pin schema!
[07:52:44][C][remote_receiver.esp8266:065]: Buffer Size: 1000
[07:52:44][C][remote_receiver.esp8266:066]: Tolerance: 50%
[07:52:44][C][remote_receiver.esp8266:067]: Filter out pulses shorter than: 100 us
[07:52:44][C][remote_receiver.esp8266:068]: Signal is done after 2000 us of no changes
[07:52:44][C][web_server:125]: Web Server:

Also not sure that this is telling me?
][W][remote_receiver.esp8266:063]: Remote Receiver Signal starts with a HIGH value. Usually this means you have to invert the signal using ‘inverted: True’ in the pin schema!

It’s acting like the ‘remote receiver’ isn’t working. Nothing gets dumped when I open and close the door sensor. Confirmed that the door sensor is transmitting because I hear it on a near by AM radio. Any ideas? What info can I provide? Otherwise, it’s going in the trash bin.

Thanks, again.

[glmnet (Guillermo Ruffino)]

he is suggesting you do this:

remote_receiver:
  pin:
    number: 4
    inverted: True
  dump: rc_switch
  filter: 100us
  tolerance: 50%
  idle: 2ms  

[5310]

Ok, adding inverted: True - fixed the inverted message but still not dumping any when I activate the door sensor device.

My hardware mods looks correct.

1. Cut trace going to esp.
2. Added 200ohn resistor between GPIO4 and left side of surface-mounted resistor.
3. Added 200ohn resistor between GPIO5 and pin 10 of ESP
4. Cut trace going to USB.

But see nothing in logs. Otherwise device seem to be working.
Again, lost…any ideas???

[Mahko_Mahko]

Sorry. I don’t know. Good luck.

[Mahko_Mahko]

Can anyone help me trouble shoot? I seem to be able to recieve but not send codes.

The reading of codes appears to be pretty reliable, but no luck when I try to transmit them (although I can both see the action in the logs, and when I hit the RF remote, the binary sensors are triggered).

I see the red led on sonoff bridge flash when triggered via hassio switch…

I’m pretty new to this.

What can I try or do to trouble shoot?

Thank you…

Edit: I aslo just noticed that the ‘Up’ codes are the same as the ‘Down’ codes, so maybe it’s not decoding properly?

US $84.8 47% OFF|DM25LE 1.1N.m USB interface Micro charge DOOYA tubular...

esphome:
  name: sonoff_rf_bridge
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: "xxxxxxxxxxxxx"
  password: "xxxxx"
  manual_ip:
    static_ip: xxxxxxxxxx
    gateway: xxxxxxxxxxxxx
    subnet: xxxxxxxxxxxxxxxx

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

remote_receiver:
  pin: 
    number: 4
  dump: rc_switch
  filter: 100us
  tolerance: 50%
  idle: 4ms
  buffer_size: 2kb

remote_transmitter:
  pin: 5
  carrier_duty_percent: 100%
  
switch:
  - platform: template
    name: Gong Remote
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '011010101010110111101111'
          protocol: 6
          repeat: 
            times: 10
            wait_time: 50ms
  - platform: template
    name: Blinds Up
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '00001011100110101011111011001000'
          protocol: 1
          repeat: 
            times: 5
            
##These are variants I was testing with. Occasionally these were decoded..
  - platform: template
    name: Blinds Up5
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '01001011100110101011111011001000'
          protocol: 5
          repeat: 
            times: 5
  - platform: template
    name: Blinds Up3
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '01001011100110101011111011001000'
          protocol: 3
          repeat: 
            times: 5
binary_sensor:
  - platform: status
    name: "RF Bridge Status" 
  - platform: remote_receiver
    name: "Blinds Up"
    rc_switch_raw:
      code: '00001011100110101011111011001000'
      protocol: 1
    filters:
      - delayed_off: 500ms
  - platform: remote_receiver
    name: "Blinds Up5"
    rc_switch_raw:
      code: '01001011100110101011111011001000'
      protocol: 5
    filters:
      - delayed_off: 500ms
  - platform: remote_receiver
    name: "Blinds Up3"
    rc_switch_raw:
      code: '01001011100110101011111011001000'
      protocol: 3
    filters:
      - delayed_off: 500ms


status_led:
  pin:
    number: GPIO13
    inverted: yes

logs indicate that codes are being transmitted

INFO Reading configuration...
INFO Starting log output from  XX using esphome API
INFO Connecting to XXX  (XXXX
INFO Successfully connected to XXXXXXXXXXX
[14:56:50][I][app:096]: esphome version 1.13.6 compiled on Aug 17 2019, 14:42:53
[14:56:51][C][status_led:019]: Status LED:
[14:56:51][C][status_led:020]:   Pin: GPIO13 (Mode: OUTPUT, INVERTED)
[14:56:51][C][wifi:372]: WiFi:
[14:56:51][C][wifi:254]:   SSID: [redacted]
[14:56:51][C][wifi:255]:   IP Address: XXXXXXXXX
[14:56:51][C][wifi:257]:   BSSID: [redacted]
[14:56:51][C][wifi:258]:   Hostname: 'sonoff_rf_bridge'
[14:56:51][C][wifi:262]:   Signal strength: -56 dB ▂▄▆█
[14:56:51][C][wifi:263]:   Channel: 11
[14:56:51][C][wifi:264]:   Subnet: XXXXXXXXXXX
[14:56:51][C][wifi:265]:   Gateway: XXXXXXXXXXXX
[14:56:51][C][wifi:266]:   DNS1: 0.0.0.0
[14:56:51][C][wifi:267]:   DNS2: 0.0.0.0
[14:56:51][C][template.switch:058]: Template Switch 'Gong Remote'
[14:56:51][C][template.switch:059]:   Restore State: NO
[14:56:51][C][template.switch:060]:   Optimistic: NO
[14:56:51][C][template.switch:058]: Template Switch 'Blinds Up'
[14:56:51][C][template.switch:059]:   Restore State: NO
[14:56:51][C][template.switch:060]:   Optimistic: NO
[14:56:51][C][template.switch:058]: Template Switch 'Blinds Up5'
[14:56:51][C][template.switch:059]:   Restore State: NO
[14:56:51][C][template.switch:060]:   Optimistic: NO
[14:56:51][C][template.switch:058]: Template Switch 'Blinds Up3'
[14:56:51][C][template.switch:059]:   Restore State: NO
[14:56:51][C][template.switch:060]:   Optimistic: NO
[14:56:51][C][logger:137]: Logger:
[14:56:51][C][logger:138]:   Level: DEBUG
[14:56:51][C][logger:139]:   Log Baud Rate: 115200
[14:56:51][C][logger:140]:   Hardware UART: UART0
[14:56:51][C][status:034]: Status Binary Sensor 'RF Bridge Status'
[14:56:51][C][status:034]:   Device Class: 'connectivity'
[14:56:51][C][remote_base:017]: Remote Receiver Binary Sensor 'Blinds Up'
[14:56:51][C][remote_base:017]: Remote Receiver Binary Sensor 'Blinds Up5'
[14:56:51][C][remote_base:017]: Remote Receiver Binary Sensor 'Blinds Up3'
[14:56:51][C][remote_transmitter:018]: Remote Transmitter...
[14:56:51][C][remote_transmitter:019]:   Carrier Duty: 100%
[14:56:51][C][remote_transmitter:020]:   Pin: GPIO5 (Mode: OUTPUT)
[14:56:51][C][remote_receiver.esp8266:059]: Remote Receiver:
[14:56:51][C][remote_receiver.esp8266:060]:   Pin: GPIO4 (Mode: INPUT)
[14:56:51][C][remote_receiver.esp8266:065]:   Buffer Size: 2000
[14:56:51][C][remote_receiver.esp8266:066]:   Tolerance: 50%
[14:56:51][C][remote_receiver.esp8266:067]:   Filter out pulses shorter than: 100 us
[14:56:51][C][remote_receiver.esp8266:068]:   Signal is done after 4000 us of no changes
[14:56:51][C][ota:029]: Over-The-Air Updates:
[14:56:51][C][ota:030]:   Address: XXXXXXXXXXXX
[14:56:51][C][api:103]: API Server:
[14:56:51][C][api:104]:   Address: XXXXXXXXXXXXX
[14:58:06][D][switch:021]: 'Blinds Up' Turning ON.
[14:58:06][D][remote_transmitter:066]: Sending remote code...
[14:58:20][D][switch:021]: 'Blinds Up' Turning ON.
[14:58:20][D][remote_transmitter:066]: Sending remote code...
[14:58:06][D][switch:021]: 'Blinds Up' Turning ON.
[14:58:06][D][remote_transmitter:066]: Sending remote code...
[14:58:20][D][switch:021]: 'Blinds Up' Turning ON.
[14:58:20][D][remote_transmitter:066]: Sending remote code...
[15:01:36][D][binary_sensor:033]: 'Blinds Up': Sending state ON
[15:01:36][D][binary_sensor:033]: 'Blinds Up': Sending state OFF
[15:02:45][D][binary_sensor:033]: 'Blinds Up': Sending state ON
[15:02:45][D][binary_sensor:033]: 'Blinds Up': Sending state OFF
[15:02:50][D][binary_sensor:033]: 'Blinds Up': Sending state ON
[15:02:50][D][binary_sensor:033]: 'Blinds Up': Sending state OFF

[Mahko_Mahko]

So I cracked the shits with this and pulled the pin on a Broadlink RM Pro+.

I’ve got it all learnt and integrated etc, but it turns out the new “RM2 Pro Plus3” are somewhat lacking Home Assistant support and you need to do some work-arounds (see link).

Broadlink Manager - Nicer way to Learn and Send IR/RF commands

I finally got my Dooya RF roller blinds using my “RM2 Pro Plus3”, the method DrZzs outlines, and the below. In scripts: blinds_up: alias: Blinds Up sequence: - service: broadlink.send data: host: 192.168.1.XX packet: "sgBIA5kxCxgLGQsYFg0LGBcMFw0WDQsYCxkWDRYNCxgXDAsYFw0LGBcMFw0WDRYNFwwLGRYNFwwLGAsYFw0LGAsYCxgXDQsYCxgLGRYNCxgLGAsYFwABE5kyCxgLGAsYFwwLGRYNFg0WDgoZCxgXDBcMCxgXDQsYFg0MGBYNFwwXDBcNFg0LGBYNFw0LGAsYFwwLGAsZCxgWDQsZCxgLGBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX…

Anyways, happy it’s all working and it was “fun” to try the hacky-er approach.

[lpt2007]

I already have tasmota on my sonoff rf bridge 433. Can I flash esphome direct from tasmota or I must do some hardware hacking first?

I have this version of sonoff rf device:

[dancem (Dance Macabre)]

Tasmota works with internal integrated RF controller of the bridge, and ESPHome can only control RF transmitter&receiver directly. That is why you need to do the hardware hack, to give direct controls over the modules.

[lpt2007]

Do you know how I can do hardware hack on my device.

My device is different (see pictures)

[ElGranLoky]

@5310 I had the same problem with the door sensor, could you try:

remote_receiver:
  pin: 
    number: 4
    inverted: True
  dump: rc_switch
  filter: 15us
  tolerance: 58%
  idle: 12ms
  buffer_size: 2kb

[francisp (Francis)]

From the back, it looks a lot like Board V1 R2, maybe it is a board V1 R1 ?

xoseperez/espurna

[andreaslindner]

Hi all,

Is anybody currently using the transmitter feature with the modded Sonof RF bridge and the latest version of esphome?

After modding the hardware I played around with esphome and got the receiver to work as expected but the transmitter doesn’t work at all as expected. It’s like @Mahko_Mahko wrote, the red LED flashes each time I try to send a command but the corresponding outlet doesn’t switch accordingly. When I use the espurna image espurna-1.14.1-itead-sonoff-rfbridge-direct.bin, everything works as expected, which should indicate that the hardware is correct and it must be a configuration problem or software bug in the latest version of esphome. I used a NodeMCU and dedicated 433MHz transmitter and receivers with exactly the same result.

The red flashing must indicate that the RF MCU decodes the packet correctly (it is still connected to the receiver after the mod). So it is some kind of encoding the original code on this RF MCU recognizes, but not what I expect and want for switching the plug. I followed essentially the descriptions of the starter of this thread and this is my esphome config:

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

  - platform: remote_receiver
    name: "Remote B On"
    rc_switch_raw:
      code: '010000000101000101010001'
      protocol: 1

  - platform: remote_receiver
    name: "Remote B Off"
    rc_switch_raw:
      code: '010000000101000101010100'
      protocol: 1

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

remote_transmitter:
  pin: 5
  carrier_duty_percent: 100%

status_led:
  pin:
    number: GPIO13
    inverted: yes

switch:
  - platform: template
    name: "Remote Plugs B On"
    turn_on_action:
      remote_transmitter.transmit_rc_switch_raw:
        code: '010000000101000101010001'
        protocol: 1
        repeat:
          times: 10
          wait_time: 50ms
  - platform: template
    name: "Remote Plugs B Off"
    turn_on_action:
      remote_transmitter.transmit_rc_switch_raw:
        code: '010000000101000101010100'
        protocol: 1
        repeat:
          times: 10
          wait_time: 50ms

Maybe somebody can spot an issue in the configuration or knows a way to workaround a possible bug?

BTW. When I run my NodeMCU with the dedicated receiver in parallel, I don’t get any log output for the recognizing an rc_switch encoding. This is weird as well, isn’t it?

[andreaslindner]

I checked with the logic analyzer now and I can see that the frequencies of the signals put on the carrier vary slightly. I compared what the latest version of espurna and esphome send out on the tx pin. Espurna uses 1.518 while esphome uses 1.392 kHz. When I stretch the picture of the signal they match perfectly.

The interesting thing is that an esphome node correctly not recognizes the wrong frequency another esphome node sends. And it correctly recognizes what espurna sends, which does switch the plug as expected. So why is only the transmission frequency off and how to fix it?

[Mahko_Mahko]

I never solved it and went with a Broadlink RM Pro+ for RF transmitting.

But I wound up using my modded Sonoff RF Bridge for recieving/intergating some RF PIRs. Works great for that…very fast.

[andreaslindner]

I played a bit with the raw codes in order to stretch the signal that comes out and it does work somewhat. This works reliable on my sonoff rf bridge for turning on one plug:

  - platform: template
    name: Raw Code Power Button
    turn_on_action:
      - remote_transmitter.transmit_raw:
          code: [315,-945,945,-315,315,-945,315,-945,315,-945,315,-945,315,-945,315,-945,315,-945,
945,-315,315,-945,945,-315,315,-945,315,-945,315,-945,945,-315,315,-945,945,-315,
315,-945,945,-315,315,-945,315,-945,315,-945,945,-315,315]
          repeat: 10

But the above doesn’t work on a NodeMCU. With a little bit of trial and error tweaking, I could get this approach to work a little bit on this one as well but this indicates that the signal that comes out of the two is not so clean. I see also timing fluctuations among pulses. I tried the values I experimented with something I found in this github issue https://github.com/esphome/issues/issues/508:

  - platform: template
    name: RF Power Button
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '010000000101000101010100'
          protocol: 
            pulse_length: 315
            sync: [1,31]
            zero: [1,3]
            one: [3,1]
            inverted: false
          repeat: 10

The pulse length is what is responsible for the stretching but this doesn’t work unfortunately. Is this because of unclean signal generation or something else?! What is the issue here?

[andreaslindner]

Now I seem to have found a somewhat working configuration with shortening the sync pause from 31 to 1. This doesn’t seem clean or correct. It works on both my NodeMCU based custom solution and on my RF Bridge:

  - platform: template
    name: RF Power Button 1 on
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '010000000101000101010001'
          protocol: 
            pulse_length: 312
            sync: [1,10]
            zero: [1,3]
            one: [3,1]
            inverted: false
          repeat: 5

  - platform: template
    name: RF Power Button 1 off
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '010000000101000101010100'
          protocol: 
            pulse_length: 312
            sync: [1,10]
            zero: [1,3]
            one: [3,1]
            inverted: false
          repeat: 5

Is there something slowing down processing and the implementation is sensible to this?

Side note
I also have seemingly unresolvable issues of erratic WiFi connection problems with certain configurations (at least with my NodeMCU clones, but I think I remember I also had it with the RF Bridge). It is desribed in many different places like here:

Bricked Sonoff devices after upgrade to 1.14.2 / 1.14.3 (THE SOLUTION IS TO ROLL BACK TO 1.13.6)

I am using the logger component but it seemed to be the UART that bricked it. I will reflash this weekend and give it another try.

[eses]

Hi Guys,

I do not want to copy/paste so please see my post in the other thread (I probably should post it here).

THIS IS A WARNING MESSAGE:

Sonoff RF Bridge. Strategies for receiving data

@ashscott @AhmadK Hi Guys, THIS IS A WARNING MESSAGE for anyone wanting to play with ESPHome on RF Bridge. I was tempted by you. I spent two days reconfiguring my RF Bridges: First, I used Demux script with my Tasmota based bridge - it works great thanks for this thread… but later… I was tempted to run ESPHome on my second RF Bridge - I wanted better response and range as suggested. I did hardware hack to RF Bridge (it’s easy - the most difficult task is to solder a wire to tiny leg no.…

I can share my automation/definitions. I can also share info how to convert RAW RF message sniffed by TASMOTA+Portish to RAW RF message compatible with ESPHome…
…but probably stop playing with this until ESPHome fix arrives…

Have you faced this issue? Do you have any hints or workarounds?

[Mahko_Mahko]

Thanks. This was kind of useful in a round about way for me.

I was struggling to get one of these integrated with my rm2_pro_plus3 and so thought I’d revist this. I managed to get my Sonoff RF Bridge to send the codes you have above, and for the RF relay to learn them.

US $3.24 16% OFF|433Mhz Universal Wireless Remote Control Switch DC 12V 1CH...

I’m having the “Esphome goes unavailable” issue that is kicking around too.

[Fietspomp]

I hope that someone here can help me.

I’ve used Tasmota on my RF bridge with succes but I hated the delays.

No I’ve done the hardware mods and use ESPhome.
Works fine for my doorsensors for example.

But I have a remote for my lights which worked with Tasmota but now I can’t figure out howto use it.
For Tasmota I used this rfraw code:

mqtt Lights

• platform: mqtt
  name: “Tafellamp”
  command_topic: “cmnd/sonoff_bridge/rfraw”
  #brightness_state_topic: ‘office/light/brightness’
  #brightness_command_topic: ‘office/light/brightness/set’
  qos: 0
  payload_on: “AA B0 21 03 08 00AA 0122 01C2 28181909081808181818190819080808081908181908190909 55”
  payload_off: “AA B0 21 03 08 00AA 0122 01C2 28181909081808181818190819080808081908181908190909 55”
  optimistic: false

• platform: mqtt
  name: “Kamerlamp”
  command_topic: “cmnd/sonoff_bridge/rfraw”
  #brightness_state_topic: ‘office/light/brightness’
  #brightness_command_topic: ‘office/light/brightness/set’
  qos: 0
  payload_on: “AA B0 23 04 08 0078 015E 00FA 01D6 38181A29281A2818181819281A2A2A2A2A2A28181818192929 55”
  payload_off: “AA B0 23 04 08 0078 015E 00FA 01D6 38181A29281A2818181819281A2A2A2A2A2A28181818192929 55”
  optimistic: false

I’ve tried to convert my B0 to ESPhome format, but I can’t get it to work.
Also sniffing the remote isn’t working, the RF signals are going through the roof here!

Any suggestions?

[DoubleAught (Adam Goddard)]

I have a Sonoff RF Bridge R2 V1.0, applied the direct-hack with either 330 ohm or 200 ohm resistors, can not receive any data through the log. Tried dump rc_switch and all, and various filter and idle values, S2 off and on. The RF_LED lights up when a code is received by the EFM microcontroller still from my Sonoff iFan03 RF emitter. Any ideas?

Here is the relevant config:

remote_receiver:
  pin: 4
  dump: rc_switch
  filter: 4us
  idle: 4ms
remote_transmitter:
  pin: 5
  carrier_duty_percent: 100%