Sonoff RF Bridge with ESPHOME?

ESPHome
83

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?

1 Like
84

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?

2 Likes
85

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.

86

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?

87

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:

2 Likes
88

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:

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?

1 Like
89

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.

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

90

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?

91

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%
92

Strange, you should see something I guess, this is my remote_receiver/transmitter settings:

#RF bridge settings
remote_receiver:
  pin: 4
  dump: rc_switch
  #dump: all
  tolerance: 50
  filter: 1us
  idle: 1ms

remote_transmitter:
  pin: 5
  carrier_duty_percent: 100%
93

Hi all.
I flashed my Sonoff RF Bridge V2 with Esphome/hack hardware and it works very well in reception with remote controls and motion sensors or door sensors.
I cannot issue a DI.O code. (Protocol 8)
Do you have a solution?
Do you also know if it is possible to receive Oregon temperature probes.
Thank you for your help.
Best regards.
Bruno from France

94

Hi, wich rf transceiver did you use?

95

The modules are like these (433 Mhz Superheterodyne RF):

I wanted to try this with ESP32 modules because I was suspecting the software pulse generation with the ESP8266 to be the reason - avoiding to dig into the home assistant source code to see why it could be off. But I didn’t get around to this yet, unfortunately. And it wouldn’t help much for the sonoff RF bridge where there is an ESP8266 inside. The RF chips in there are probably very similar, if not even the same.

1 Like
96

Ok, i bought it two days ago, well. I tried your ESP home firmware mods but unfortunately i could receive but not send codes. So i reverted my rfbridge to previous state and reinstalled Tasmota. With it it works.
When i will get my rf modules i will try again with esphome… Let me know if you can do this before me :sweat_smile:

97

Thought this might be interesting, looks like their implementing an official rf_bridge component in the next version of ESPHome. It doesn’t appear to, but I really hope they add support for the rfraw command from Tasmota when using the Portisch firmware.

2 Likes
98

But these modules will not make a difference. They are just kindof putting in the air what coming from the signal lines of the ESP8266. The problem is that the signal that the ESP8266 generates (with the esphome software) is not “clear enough”. It’s for some reason skewed on the time axis and this may be different for different boards and that may be the reason why these hacks are not working for you, you need another unskew factor.

Another factor may be how tolerant the receiving devices are to this skew. Ours are probably less tolerant than the ones of the people that don’t write here about these problems :slight_smile:.

99

That would be nice. But also a bummer that we invested work into the hw fix :smiley:. I’m considering to use the espurna firmware because this worked flawlessly. But there I don’t know how to get more inputs/outputs than the downloadable firmware supports. And how to get a GPIO as controllable output (I connected the buzzer to one). What a mess haha.

100

that’s cool, I ESPhomed all my ESP8266 devices, left out just 2 rf bridge

1 Like
101

Did you ever learn more on this? I too wonder. Thanks

102

Ok but i can do experiments with a wemos + rf modules while Rfbridge Tasmota do his work.