Sonoff RF bridge with Portisch firmware and no hardware hack

ESPHome
1

Has anyone managed to get the Sonoff RF bridge working with the rf_bridge component in esphome?

I initially flashed to Tasmota, updated to Portisch firmware and was able to see codes coming from my remote. Now after flashing to esphome I’m simply not registering anything from remote in logs etc.

I think my remote needs to use the advanced codes from Portisch firmware (it’s an arlec ceiling light/fan remote), but esphome logs show nothing. According to the esphome documentation, there is support using start_advanced_sniffing etc.

config is as follows:

substitutions:
  device_name: master_br_rf_bridge
  friendly_name: "Master BR Sonoff RF Bridge"

esphome:
  name: ${device_name}
  platform: ESP8266
#  board: esp8285
  board: esp01_1m

wifi:
  ssid: !secret ssid
  password: !secret wifi_pwd
  fast_connect: on

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${device_name}
    password: !secret hotspot_pwd

captive_portal:

# Enable logging
logger:
  baud_rate: 0

# Enable Home Assistant API
api:
  password: !secret api_pwd
  services:
    - service: send_rf_code
      variables:
        sync: int
        low: int
        high: int
        code: int
      then:
        - rf_bridge.send_code:
            sync: !lambda 'return sync;'
            low: !lambda 'return low;'
            high: !lambda 'return high;'
            code: !lambda 'return code;'
    - service: learn
      then:
        - rf_bridge.learn
    - service: start_advanced_sniff
      then:
        - rf_bridge.start_advanced_sniffing
    - service: stop_advanced_sniff
      then:
        - rf_bridge.stop_advanced_sniffing

ota:
  password: !secret ota_pwd

web_server:
  port: 80
  auth:
    username: admin
    password: !secret web_pwd

uart:
  tx_pin: GPIO01
  rx_pin: GPIO03
  baud_rate: 19200

sensor:
  - platform: wifi_signal
    name: "${friendly_name} Wifi Signal Strength"
    update_interval: 60s
  - platform: uptime
    name: "${friendly_name} Uptime"

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO00
      inverted: True
    name: "${friendly_name} Pairing Button"

status_led:
  pin:
    number: GPIO13
    inverted: yes

switch:
- platform: restart
  name: "${friendly_name} REBOOT"

rf_bridge:
  on_code_received:
    then:
      - homeassistant.event:
          event: esphome.rf_code_received
          data:
            sync: !lambda 'char buffer [10];return itoa(data.sync,buffer,16);'
            low: !lambda 'char buffer [10];return itoa(data.low,buffer,16);'
            high: !lambda 'char buffer [10];return itoa(data.high,buffer,16);'
            code: !lambda 'char buffer [10];return itoa(data.code,buffer,16);'

  on_advanced_code_received:
  - homeassistant.event:
      event: esphome.rf_advanced_code_received
      data:
        length: !lambda 'char buffer [10];return itoa(data.length,buffer,16);'
        protocol: !lambda 'char buffer [10];return itoa(data.protocol,buffer,16);'
        code: !lambda 'return data.code;'
1 Like
2

Well your board is set to “esp01_1m”

sonoff rf uses an esp8285

thats what I have in mine

3

I managed to resolve this. For anyone who is interested, I ended up following the instructions posted here for the most part. Using a Sonoff RF Bridge with ESPHome & Portiche Firmware with no hardware hacking

I found that I couldn’t sniff codes successfully via esphome using the rf_bridge commands. So I did the following, as outlined in the post above:

  1. Flash to tasmota and join to wifi
  2. flash secondary controller chip to Portisch firmware
  3. change tasmota type to 25- sonoff bridge
  4. at console enter rfraw 177 to enable code sniffing mode
  5. press remote button numerous times
  6. convert codes that appear in log using bit bucket online converter
  7. test each converted code using backlog rfraw <code> to see if device responds correctly
  8. once i have all codes, flash to esphome
  9. esphome config has a bunch of service calls to trigger each rf command
  10. create automations within HA that call service when button pressed at wall.

snippet from yaml.

api:
  password: !secret api_pwd
  services:
    - service: toggle_light
      then:
        - rf_bridge.send_raw:
            raw: "<bit bucket code>"
    - service: toggle_fan
      then:
        - rf_bridge.send_raw:
            raw: "<bit bucket code>"
    - service: fan_speed_1
      then:
        - rf_bridge.send_raw:
            raw: "<bit bucket code>"

I found with my device that the code shifted a little bit with each press and I was getting a double trigger of the action, i.e. the light would toggle on , then off from the single captured code, when sent via console. It just took quite a few trial and error until I captured a code that worked correctly.

1 Like
4

glad my experience was able to help you out

5

Using Sonoff RF bridge to listen/receive from a Sainlogic WS020T weather station. Running Tasmota, loaded Portisch firmware to the EMF chip, issued rfraw 177 console comand, captured several data messages, with ultimate goal to decode/parse them. Found robopenguins web page which led to their message parsing Python code.

With the RF bridge successfully receiving codes, and robopenguin’s Python parsing code as a guide, I flashed ESPhome to the bridge. Now, I come here seeking a small bit of guidance and direction. I would like to parse the received 433 MHz hex data into several ESPHome template sensor values. I presume using lambdas and short bits of C code is the method to do this. Could anyone please offer an example/suggestion?

Here is the basic rf_bridge YAML

rf_bridge:
  id: sonoff_rf_bridge
  on_code_received:
    then:
      - homeassistant.event:
          event: esphome.rf_code_received
          data:
            sync: !lambda 'char buffer [10];return itoa(data.sync, buffer, 16);'
            low:  !lambda 'char buffer [10];return itoa(data.low,  buffer, 16);'
            high: !lambda 'char buffer [10];return itoa(data.high, buffer, 16);'
            code: !lambda 'char buffer [10];return itoa(data.code, buffer, 16);'

  on_advanced_code_received:
  - homeassistant.event:
      event: esphome.rf_advanced_code_received
      data:
        length:   !lambda 'char buffer [10];return itoa(data.length,  buffer, 16);'
        protocol: !lambda 'char buffer [10];return itoa(data.protocol,buffer, 16);'
        code:     !lambda 'return data.code;'

The simplest example would be bytes 4 and 5:

# Get average wind speed in m/s
def get_avr_wind_speed(msg):
    return msg[4] / 10.

# Get gust wind speed in m/s
def get_gust_wind_speed(msg):
    return msg[5] / 10.

Thank you!

6

Hi @FredTheFrog, I don’t know about the weather station, but I’ve been playing around a bit with rf_bridge lately and can share what I’ve found.

I’m not sure to understand your use case, but if what you what is to receive codes, a prior condition is that the protocol used by your device is understood by Portisch. Otherwise no events will be fired in ESPHome, nor std nor advanced.

A couple of days ago I sent a PR (#1819) so that you can sniff raw codes directly with ESPHome, equivalent to Tasmota’s rfraw 177.

But this will only allow to get all raw codes in the log, but won’t fire any events if protocol is not supported. This is mainly to learn codes to later use for sending (and replace some remote).

As you said you had to get the codes that way I assume they are not being decoded.
So, are you seeing the decoded codes in the log? If not, have you activated advanced sniffing?
If yes, the triggers with lambdas should work.
If after that you are still not seeing decoded codes I fear it will be uphill.

Some further changes and a new PR would allow to add a trigger on raw codes and then decode in HA, but I don’t think it’ll work well, as raw sniffing is unstable and the mode stops pretty soon.
So the alternative would be to add the new protocol to Portisch (or fix raw sniffing also in Portisch)

2 Likes
7

The weather station does transmit “B1” style messages, which I captured from Tasmota. A sample of some messages are shown below:

21:11:04.564 RSL: RESULT = {"Time":"2021-05-23T21:11:04","RfRaw":{"Data":"AA B1 03 0406 021C 03A2 A808091819091919 55"}}
21:12:24.554 RSL: RESULT = {"Time":"2021-05-23T21:12:24","RfRaw":{"Data":"AA B1 03 0410 0226 041A A808091819091919 55"}}
21:12:40.554 RSL: RESULT = {"Time":"2021-05-23T21:12:40","RfRaw":{"Data":"AA B1 03 03FC 0230 0370 A808091819091919 55"}}
21:14:16.555 RSL: RESULT = {"Time":"2021-05-23T21:14:16","RfRaw":{"Data":"AA B1 03 0410 0226 047E A808091819091919 55"}}
21:14:32.557 RSL: RESULT = {"Time":"2021-05-23T21:14:32","RfRaw":{"Data":"AA B1 03 0406 0226 03CA 2808091819091919 55"}}
21:14:48.653 RSL: RESULT = {"Time":"2021-05-23T21:14:48","RfRaw":{"Data":"AA B1 04 0352 014A 0230 0384 3809090928 55"}}
21:15:20.555 RSL: RESULT = {"Time":"2021-05-23T21:15:20","RfRaw":{"Data":"AA B1 03 0406 0230 0348 A8080918190919 55"}}

I added a couple of template switches to call start_advanced_sniffing and stop_advanced_sniffing and now I see their actions in the Very_Verbose log. Unfortunately, I still don’t see any recognition of the B1 messages I know are originating from the weather station which should be heard by the RF Bridge.

Being the impatient person I am, I downloaded your changes into a custom_component folder and attempted to build them. Had to change to the ESPHome dev version to get them compiled, but it’s now bucket sniffing and I’m seeing the WS020T data messages:

[04:07:09][D][switch:021]: 'Bucket Sniffing ON' Turning ON.
[04:07:09][D][rf_bridge:205]: Raw Bucket Sniffing on
[04:07:09][D][rf_bridge:036]: Action OK
[04:07:18][D][rf_bridge:100]: Received RFBridge Bucket: AA B1 03 01FE 03E8 03B6 A08191 55
[04:20:56][D][rf_bridge:100]: Received RFBridge Bucket: AA B1 04 01CC 0078 00E6 0190 B092A1 55

Being away from work for a few days, I tried adding a trigger and return of the data to @ianchi 's code mods this morning. Apparently, there’s some very special little nit-pick of code I’m missing, because my addition of a trigger for “on_bucket_received” just refuses to be recognized in the ESPHome GUI :frowning:

8

I saw there were some recent changes/fixes in Tasmota and/or Portisch to resolve the issue of reading raw codes stopping after some time. Apparently there were a couple of memory leaks that caused this failure, and someone submitted patches for them. So there’s hope, yet. One thing I noticed about the raw messages coming back from the WS020T weather station. The RF Bridge frequently adds a series of repeating bytes to the end of the message before the closing ‘55’ byte. In my mind, these extra bytes can very safely be ignored. My thought was to simply ignore the complete message when the byte count was not the correct length or did not start with the bytes AA B1.

9

Yes, I saw that fork with the work on memory leak fixes, but there are a bunch of other changes also. And no PR to send them upstream.
On the other hand, the Portisch repo has been idle for a while.

I couldn’t find any reference or comments on how that fork’s firmware was performing.

I didn’t understand your comment on strange B1 codes. Can you post some examples?

10

I noticed them while recording messages using Tasmota:

21:07:58.946 RSL: RESULT = {"Time":"2021-05-23T21:07:58","RfRaw":{"Data":"AA B1 04 00A0 023A 006E 0258 38180A 55"}}
21:08:03.386 RSL: RESULT = {"Time":"2021-05-23T21:08:03","RfRaw":{"Data":"AA B1 04 0104 00BE 0078 01C2 381929 55"}}
21:08:14.150 RSL: RESULT = {"Time":"2021-05-23T21:08:14","RfRaw":{"Data":"AA B1 04 0078 0186 0802 0190 B090A0 55"}}
21:08:24.787 RSL: RESULT = {"Time":"2021-05-23T21:08:24","RfRaw":{"Data":"AA B1 03 03C0 01F4 03CA A8191919191919081919191919 55"}}
21:08:46.856 RSL: RESULT = {"Time":"2021-05-23T21:08:46","RfRaw":{"Data":"AA B1 05 021C 00B4 006E 037A 037A 481A1B 55"}}
21:10:16.653 RSL: RESULT = {"Time":"2021-05-23T21:10:16","RfRaw":{"Data":"AA B1 04 0366 0262 015E 0442 381A1A 55"}}
21:11:04.564 RSL: RESULT = {"Time":"2021-05-23T21:11:04","RfRaw":{"Data":"AA B1 03 0406 021C 03A2 A808091819091919 55"}}
21:12:24.554 RSL: RESULT = {"Time":"2021-05-23T21:12:24","RfRaw":{"Data":"AA B1 03 0410 0226 041A A808091819091919 55"}}
21:12:40.554 RSL: RESULT = {"Time":"2021-05-23T21:12:40","RfRaw":{"Data":"AA B1 03 03FC 0230 0370 A808091819091919 55"}}
21:14:16.555 RSL: RESULT = {"Time":"2021-05-23T21:14:16","RfRaw":{"Data":"AA B1 03 0410 0226 047E A808091819091919 55"}}
21:14:32.557 RSL: RESULT = {"Time":"2021-05-23T21:14:32","RfRaw":{"Data":"AA B1 03 0406 0226 03CA 280809181909191918 55"}}

Notice the extra ‘18’ and repeating ‘19’ bytes in several messages? I considered this may simply be an artifact from decoding the 433 MHz data stream? Here are two messages from ESPHome and RFBridge that show the same data pattern:

[09:09:18][D][rf_bridge:100]: Received RFBridge Bucket: AA B1 02 0366 04C4 908080 55
[09:17:37][D][rf_bridge:100]: Received RFBridge Bucket: AA B1 03 03FC 021C 037A A80809 55
11

Newbie here, i got pretty much where you got, but have no clue where to go next:
I can see the messages from my WS-6147 Weather Station via a enhanced Sonoff RF Bridge as follows:


15:12:46.841 MQT: tele/RFBridge/RESULT = {"Time":"2021-09-19T15:12:46","RfRaw":{"Data":"AA B1 02 03D4 05AA 90808080 55"}}
15:13:34.840 MQT: tele/RFBridge/RESULT = {"Time":"2021-09-19T15:13:34","RfRaw":{"Data":"AA B1 02 03CA 05AA 90808080 55"}}
15:14:22.838 MQT: tele/RFBridge/RESULT = {"Time":"2021-09-19T15:14:22","RfRaw":{"Data":"AA B1 02 03D4 05A0 90808080 55"}}
15:15:10.840 MQT: tele/RFBridge/RESULT = {"Time":"2021-09-19T15:15:10","RfRaw":{"Data":"AA B1 02 03D4 05AA 90808080 55"}}
15:15:58.835 MQT: tele/RFBridge/RESULT = {"Time":"2021-09-19T15:15:58","RfRaw":{"Data":"AA B1 02 03DE 05AA 90808080 55"}}
15:16:46.835 MQT: tele/RFBridge/RESULT = {"Time":"2021-09-19T15:16:46","RfRaw":{"Data":"AA B1 02 03D4 05AA 90808080 55"}}

I then tried https://bbconv.hrbl.pl/ without really knowing what I was doing…And without gaining any insight.
Can someone point me in the right direction where to decode the data into something i can use in Homeassistant?

12

Does someone made the RFbridge work on Advanced mode or bucket sniffing? I’ve an RFBridge working with ESPHome, but only for standard codes (Sonoff PIR and door sensors).

Advanced mode does not seem to work at all, and bucket sniffing not even compiles.

I was able to read RAW codes with tasmota without issue, but would like to use ESPHome.

Regards.

13

Hi to all,

I am in a weird situation where it seems I can read RF codes with Tasmota but not ESPHome.

I did the following steps :

Stock RF Bridge (No hardware hack)
Flashed Tasmota with FTDI usb adapter
Flashed RF chip with success
At this point I can execute “rfraw 177” in console and receive codes from an RF remote.

Frome there, I upload my ESPHOME again using the FTDI usb adapter.
It gets an IP, the API connect to HomeAssistant … but I cannot read any codes !
I press buttons on my remote and the RF red led does not come up and I don’t receive any events.

Anything I forgot ?

Thanks !

14

@jmbinette
which version of sonoff rf bridge do you have?
Black one?
White one with a led which you had to bend?
White one without led but with a button?
Withe one without led and without button?
I have the last one version 2.2 which I am not sure I can flash the rf chip

15

I can see codes with rf_bridge.start_bucket_sniffing

Here’s the exert from YAML for bucket sniffer, sending the raw command and beep.

api:
  services:
    - service: send_raw
      variables:
        raw: string    
      then:
        - rf_bridge.send_raw:
            raw: !lambda 'return raw;'     
    - service: start_bucket_sniffing
      then:
        - rf_bridge.start_bucket_sniffing  
    - service: beep
      then:
        - rf_bridge.beep:
            duration: 100

Once you’ve sniffed a code then use BitBucket Converter to convert for raw sending.

The input will be as follows, replacing the data string with your own code.

{{"RfRaw":{"Data":"AA B1 03 019A 042E 0BD6 281809090918091818181818180909090918181818 55"}}

You will then use the response (without spaces!) as the send_raw input.

See the docs for more information.

Full YAML 
substitutions:
  device_name: sonoff-rf-bridge01
  friendly_name: "Hallway Sonoff RF Bridge"

esphome:
  name: ${device_name}
  platform: ESP8266
  board: esp01_1m
  
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${device_name}
    password: !secret wifi_ap_password 

captive_portal:  

ota:
  password: !secret ota_password

logger:
  baud_rate: 0

api:
  services:
    - service: send_raw
      variables:
        raw: string    
      then:
        - rf_bridge.send_raw:
            raw: !lambda 'return raw;'
    - service: start_bucket_sniffing
      then:
        - rf_bridge.start_bucket_sniffing  
    - service: beep
      then:
        - rf_bridge.beep:
            duration: 100         
  encryption:
    key: !secret api_encryption_key
    
web_server:
  port: 80
  auth:
    username: admin
    password: !secret web_server_auth_password

sensor:
  - platform: wifi_signal
    name: "${friendly_name} Wifi Signal Strength"
    update_interval: 60s
  - platform: uptime
    name: "${friendly_name} Uptime"

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO00
      inverted: True
    name: "${friendly_name} Pairing Button"
  
status_led:
  pin:
    number: GPIO13
    inverted: yes
    
switch:
- platform: restart
  name: "${friendly_name} REBOOT"    
    
uart:
  tx_pin: GPIO01
  rx_pin: GPIO03
  baud_rate: 19200 
    
rf_bridge:
  on_code_received:
    then:
      - homeassistant.event:
          event: esphome.rf_code_received
          data:
            sync: !lambda 'return format_hex(data.sync);'
            low: !lambda 'return format_hex(data.low);'
            high: !lambda 'return format_hex(data.high);'
            code: !lambda 'return format_hex(data.code);'
  on_advanced_code_received:
    - homeassistant.event:
        event: esphome.rf_advanced_code_received
        data:
          length: !lambda 'return format_hex(data.length);'
          protocol: !lambda 'return format_hex(data.protocol);'
          code: !lambda 'return data.code;'