he is suggesting you do this:
remote_receiver:
pin:
number: 4
inverted: True
dump: rc_switch
filter: 100us
tolerance: 50%
idle: 2ms
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.
- Cut trace going to esp.
- Added 200ohn resistor between GPIO4 and left side of surface-mounted resistor.
- Added 200ohn resistor between GPIO5 and pin 10 of ESP
- Cut trace going to USB.
But see nothing in logs. Otherwise device seem to be working.
Again, lost…any ideas???
Sorry. I don’t know. Good luck.
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?
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
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).
Anyways, happy it’s all working and it was “fun” to try the hacky-er approach.
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:
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.
1 Like
Do you know how I can do hardware hack on my device.
My device is different (see pictures)
@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
From the back, it looks a lot like Board V1 R2, maybe it is a board V1 R1 ?
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
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
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.
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?
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
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
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.
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: falseplatform: 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?
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%
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%