move the jumper on the usb ttl adapter to 3.3v first. then measure the vcc voltage and tx voltage with respect to gnd. if both are 3.3v the drawing looks ok
1 Like
Getting myself a bit confused (deleted my last post to clean up), I’ve found a few good links now so I’ll just research and follow them in the first instance, then ask for help if I get stuck. Thanks.
Hi
Did mods and installed esphome but nothing appears in logs.
Can anyone see something wrong with my mods? Or have any ideas what I can check?
So I seem to have been able to fumble my way through it all and my hacked Sonoff RF Bridge with esphome seems to be reading codes with this:
remote_receiver:
pin:
number: 4
dump: rc_switch
filter: 100us
tolerance: 50%
idle: 2ms
I can’t fully test yet as my Rf devices are on thier way. I have one RF remote that i used to test, but I don’t actually have a device for it…
I’ll report back later…
Bit hard to see. I assume you made the cuts on the other side of the board too?
Hi
Thanks for the reply.
Yes, there are cuts made to disable the USB on the other side.
I’m testing with a Sonoff CP100s wireless door sensor but am not receiving anything from the logs using code below using EspHome program.
remote_receiver:
pin:
number: 4
dump: rc_switch
filter: 100us
tolerance: 50%
idle: 2ms
remote_transmitter:
pin:
number: 5
carrier_duty_percent: 100%
Logs
[07:52:44][C][remote_receiver.esp8266:059]: Remote Receiver:
[07:52:44][C][remote_receiver.esp8266:060]: Pin: GPIO4 (Mode: INPUT)
[07:52:44][W][remote_receiver.esp8266:063]: Remote Receiver Signal starts with a HIGH value. Usually this means you have to invert the signal using ‘inverted: True’ in the pin schema!
[07:52:44][C][remote_receiver.esp8266:065]: Buffer Size: 1000
[07:52:44][C][remote_receiver.esp8266:066]: Tolerance: 50%
[07:52:44][C][remote_receiver.esp8266:067]: Filter out pulses shorter than: 100 us
[07:52:44][C][remote_receiver.esp8266:068]: Signal is done after 2000 us of no changes
[07:52:44][C][web_server:125]: Web Server:
Also not sure that this is telling me?
][W][remote_receiver.esp8266:063]: Remote Receiver Signal starts with a HIGH value. Usually this means you have to invert the signal using ‘inverted: True’ in the pin schema!
It’s acting like the ‘remote receiver’ isn’t working. Nothing gets dumped when I open and close the door sensor. Confirmed that the door sensor is transmitting because I hear it on a near by AM radio. Any ideas? What info can I provide? Otherwise, it’s going in the trash bin.
Thanks, again.
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?