If your ESPHome code otherwise compiles fine and you only get an “ERROR - Not compatible” when trying to flash, then this may help: Migrating to ESPHome from Tasmota - #2 by ab0tj
1 Like
My RF bridge (V2 without the hardware hack) is now running ESPHome and I can see RF responses in the console. I copied the same config from the ESPHome site and I’m running ESPHome dev add-on in Home Assistant. My codes appear in the following format:
Received RFBridge Code: sync=0x30E8 low=0x01B8 high=0x04D8 code=0xF4D35E
But I can’t get automations to work at all. I don’t have an esphome service in HA and when I try listening to events I get nothing. What am I missing?
Ok, here is my configuration which gives me 2 services in Home Assistant - learn and send_rf_code. I’m receiving codes, and can use the service to send codes, but either they’re not sent and or not received by my ceiling fan controller.
esphome:
name: rf_controller
platform: ESP8266
board: esp8285
logger:
baud_rate: 0
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
power_save_mode: none
ota:
password: !secret ota_password
web_server:
uart:
tx_pin: GPIO01
rx_pin: GPIO03
baud_rate: 19200
api:
password: !secret api_password
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
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);'
binary_sensor:
- platform: status
name: "RF Controller Status"
on_state:
then:
- light.toggle: wifi_led
- platform: gpio
pin: GPIO00
name: "RF Controller Pairing Button"
light:
- platform: binary
name: "RF Controller WiFi LED"
id: wifi_led
output: output_wifi_led
internal: True
output:
- platform: gpio
pin:
number: GPIO13
inverted: True
id: output_wifi_led
1 Like
Hi exxamalte, I can confirm that the codes are not even sent.
I want to use my Sonoff RF Bridge (R2 v1.0) with ESPHome to replace a breadboard setup with OpenMQTTGateway. So I can use that setup to verify if any codes are sent by ESPHome and it’s not the case.
I’ve been looking into the code and I see the problem. There is a bug in function send_code which does not correctly transmit all data to the efm8bb1 MCU. If you replace the function with following, it works.
void RFBridgeComponent::send_code(RFBridgeData data) {
ESP_LOGD(TAG, "Sending code: sync=0x%04X low=0x%04X high=0x%04X code=0x%06X", data.sync, data.low, data.high,
data.code);
this->write(RF_CODE_START);
this->write(RF_CODE_RFOUT);
this->write((data.sync >> 8) & 0xFF);
this->write(data.sync & 0xFF);
this->write((data.low >> 8) & 0xFF);
this->write(data.low & 0xFF);
this->write((data.high >> 8) & 0xFF);
this->write(data.high & 0xFF);
this->write((data.code >> 16) & 0xFF);
this->write((data.code >> 8) & 0xFF);
this->write(data.code & 0xFF);
this->write(RF_CODE_STOP);
this->flush();
}
And in the log, you can actually see that the efm8bb1 MCU actually acknowledges a correct action, which wasn’t the case before:
[18:26:06][D][rf_bridge:079]: Sending code: sync=0x125C low=0x0092 high=0x01E0 code=0xFFC554
[18:26:06][D][rf_bridge:024]: Action OK
However, for some reason, my transmit range is super low, about 3-4m line of sight…
Can you or someone else try this as well and see if their range is the same?
1 Like
Fantastic, that fix worked for me, too. Thanks very much for your help.
I tested this at about 4 metres distance as well as about 12 metres between the RF Bridge and my ceiling fan, and all commands are received fine.
Great to hear! Thanks for checking the range as well.
Good afternoon, sorry for my ignorance but I put this code inside the EspHome code? If so, could you show me how?
I have installed my ESPHome dev environment on macOS and run it from the command line in a virtual environment. If you are doing it in the same way, then here is what you need to do to add the fixed code:
- In the virtual environment find file
lib/python3.7/site-packages/esphome/components/rf_bridge/rf_bridge.cpp - In that file find the line
void RFBridgeComponent::send_code(RFBridgeData data) { - Remove this line and the next 10 lines up until and including the line that contains
} - Copy above code fix into that file.
- Clean build directory:
esphome your_config.yaml clean - Build and upload OTA:
esphome your_config.yaml run
Thanks, I will do this
Hi, do you have any idea why the RM433 remote from Sonoff does not work well with Sonoff bridge?
It always generate very different codes, so it’s difficult to create automations.
This is the event automation, and this is the event generated:
But I can’t use reliably sync, low, high.
Is this how it is supposed to work?
sync, low, high are nor reliable to use. That’s inherent to RF433.
Thanks, so I can reliably use just “code”? This was not mentioned anywere, it looked strange to me.
Code is reliable. sync, low, high are dependent on a number of things, including how good the reception was, interference of other RF433 devices that were transmitting at the same time, etc, etc…
Can anyone vouch for the consistency of this? I’m the latest ESPHome dev on an RF Bridge with a KERUI D025 door/window sensor and notice that the RF Bridge seems to catch only 60-70% of the sensor’s activity.
I’ve written up how I flashed the RF Bridge with ESPHome to control a ceiling fan:
Special thanks to @JeeCeetje again for finding that bug and providing a fix.
1 Like
ESPurna onto the device. However, all these options require making some hardware changes. Luckily ESPHome recently added support for the Sonoff RF Bridge into its development version and this does not even require any hardware modifications. ESPHome is my preferred custom firmware option due to its great integration in Home Assistant and general ease of use.
ESPurna doesn’t require hardware change to run on an RFBridge, you can do an hardware mod to extend the list of supported protocols but it is not compulsory. As a side note it was the first firmware to support RFBridge and opened the path to all the others.
2 Likes
Lots of great info here, was able to add 7 motion sensors and 3 door sensors (with on and off states) to my RF Bridge!
Been running some custom code on a Raspberry Pi for a year now as Tasmota was too much of a delay as some of you noticed, but this is very quick, no delay that is noticeable so hopefully I can make the switch.
Thanks for the clarification. I’ll amend my blog post.
1 Like