Sonoff RF Bridge with ESPHOME?

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

[Fietspomp]

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%

[bsd (Bruno de SAINT DENIS)]

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

[gt4020 (Giovanni)]

Hi, wich rf transceiver did you use?

[andreaslindner]

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

US $1.98 |433 Mhz Superheterodyne RF Receiver Module and Transmitter Module...

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.

[gt4020 (Giovanni)]

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

[jcwillox (Josh Willox)]

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.

RF Bridge Component

[andreaslindner]

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 .

[andreaslindner]

That would be nice. But also a bummer that we invested work into the hw fix . 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.

[Klagio]

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

[iannecj (Chris Iannello)]

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

[gt4020 (Giovanni)]

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

[Cristiano_Maia]

@dancem

switch: - platform: remote_transmitter name: “Remote Fan Control” rc_switch_raw: code: ‘100000000001010000000010’ protocol: 1 repeat: 3

Quando digito esta configuração no ESPHome está dando erro. O que pode ser?