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.
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
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:
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…
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
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
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!
You most likely have enabled dump: all. That’s not meant to be kept enabled. Try enabling less noisy damps until you find your device and then disable dumping completely
I have used a lot of time to read this thread, but cannot seem to understand or find the answer that I am looking for.
So far, I have gotten a hold of the latest Sonoff RF 433 Bridge R2 (with the V2.2 printboard i think)
I have succesfully flashed Tasmota on it, paired it with my wifi, and setup MQTT which seems to be able to send commands to the bridge.
To be able to send RF commands to my blinds, do I need to do anything else ? ( I have not cut the print , only flashed with Tasmota )
The console in Tasmota is giving me this, when i press the buttons on the remote:
// Blinds up button:
11:47:16.040 MQT: tele/rf-bridge/RESULT = {"Time":"2023-02-09T11:47:16","RfReceived":{"Sync":10676,"Low":702,"High":1418,"Data":"48E257","RfKey":"None"}}
// Binds down button:
11:47:09.480 MQT: tele/rf-bridge/RESULT = {"Time":"2023-02-09T11:47:09","RfReceived":{"Sync":10602,"Low":702,"High":1418,"Data":"48E257","RfKey":"None"}}
With RFraw output
// Blinds up button:
11:50:16.498 MQT: tele/rf-bridge/RESULT = {"Time":"2023-02-09T11:50:16","RfRaw":{"Data":"AAA429CC02C0058848E25755"}}
// Binds down button:
11:50:20.023 MQT: tele/rf-bridge/RESULT = {"Time":"2023-02-09T11:50:20","RfRaw":{"Data":"AAA429C802C0058848E25755"}}
It looks to me, as if the payload for “up” and “down” is identical when looking at the “none raw” version. But the remote works fine using the buttons.
I tried to send the command with the payload from the console, but nothing happends.
What am I missing here?
Do I need to send more than just the “Data” field for this to work?
Or do I need to do some cutting to the board itself? flashing the RF chip (which seems not possible as this is the new version or…) ?
Bonus info:
I also tried to set it into “learning mode” by running the command: RfKey1 2
The device beeps one time and starts to listen. But it does not end the learning mode.
Don’t use Sonoff Bridge(25) as template… you need to use Sonoff Bridge (0) i.e. with this template… {"NAME":"Sonoff Bridge","GPIO":[32,0,0,0,1152,1120,0,0,0,320,0,0,0,0],"FLAG":0,"BASE":25}
@schmurtz thank you for the direct hack instructions.
I followed them exactly and didn’t run into any issues until the end. All I get in homeassistant is a connection refused errors.
RF Link is set in the config.yaml as:
rflink:
host: 192.168.0.134
port: 1234
Is the port number arbitrary?
Also can someone clarify, following the direct hack and Flash_SonoffRF.bat, is it possible to switch to tasmota/esphome and still learn RF commands from remotes?
I just wanted to say a thank you to everyone involved in this and the other threads about the v2.2 RF Bridge. I’ve been a HA user for about 7 or 8 months and wanted to see if I could get my Byron BY home doorbell hooked up to HA. I bought the RF Bridge (v2.2) and my first ever soldering iron, serial programmer etc.
Managed the direct hack on about my third attempt (struggled with the solder connection to the little 6 pin chip), flashed all sorts of firmware (Tasmota, custom RFLink and today ESPHome) and have at last made progress. Using the raw logging from ESPHome (I love how easy the HA integration is for uploading new firmware) I managed to find my doorbell (which wasn’t being picked up - or at least easily for me to see - by tasmota or RFLink) and have added a sensor for it. The bridge is now hidden away and I’m getting mobile phone notifications from the doorbell.
Hi,
I’ve been following this threat for a while now and I noticed that you seem to be using the same Gumax shading as I am.
With the older version (R1) it should work, but so far I have not found a solution for the version R2, with which firmware this must be flashed to control the Gumax motors.
Have you managed in the meantime to control the shading with the Sonoff RF Bridge R2?
I’ve been trying to flash my RF Bridge 2.2 for days now but I just can’t get a connection with my FTDI adapter.
RX and TX are swapped and when I plug in the FTDI adapter with the RF Bridge connected, I hold the button down for 5 seconds. I also tried to hold it down the whole time but neither with Tasmotizer nor with the ESPHome Web Flasher I get a connection. 3,3V are also selected on the FTDI adapter.
Should anything light up on the RF Bridge when the connection is successful?
I have disconnected all lines as in the instructions. Can also upload photos again.
Anybody have an idea what the problem is?
I solve the Problem. It was the soldering I did not do correctly the first tim
I am also from Germany and I am trying to control my projector screen which has a 433Mhz remote control.
I have also first had many lines and then my YAML file like yours adapted again and again.
Currently I have managed to break down the values to the following results:
Hoch:
Received RCSwitch Raw: protocol=1 data=‘101000110011011100000110110010100000000100000000101100010011’
Runter:
Received RCSwitch Raw: protocol=1 data=‘1010001100110111000001101101000010000000100001101001011’
Stop:
Received RCSwitch Raw: protocol=1 data=‘1010001100110111000001101101000010000001000110001101011’
How do I proceed now? What do I have to set now to be able to send the stuff to the screen as well? Thanks in advance and I hope you got your control working in the meantime.
). 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!