If you are using Tasmota 8+ and get an error after uploading the firmware, go to the console and type SetOption78 1
, then restart the device and try the firmware again.
It may well be that the latest dev version of ESPHome fixes it and I’m awaiting the arrival of another bridge so that I can give it a try.
However, the consensus seems to be that it’s a hardware issue with ESPs. Unless someone with more skills than me has found a workaround we may well be stuck, if that is the case.
Thanks, but same error.
Update => Flashed with tasmota-minimal.bin issued the command in the console and re-flashed with the esp binary. Success!!
Thanks for the help, really appreciate it.
Could you help me with the command line?
OK, I have read through the posts here and I am a little confused.
I have done the hardware modifications on the bridge and I have two binary sensors up and running via esp-home. Am I right in understanding I did NOT have to do the hardware modifications after all?
There appears to be two different sets of instructions:
- The RF Bridge component (no hardware modifications); and,
- Setting up RF Devices (hardware modifications required).
I am unsure which method we should be using (I’ve already done the HW mod, so I’m guessing the latter).
My goal is to have bridge receive RF signals from an RF remote, but I don’t see codes consistently when I press the buttons. I did obtain what I thought was a code but it doesn’t work in the transmit mode. It looks like this:
010101011111111111001101000100110101010
I tried the ‘dump all’ option but the log screen is saturated with codes that scroll too quickly to be captured. They look a little like this:
[D][remote.raw] Received Raw: 4088, -1542, 1019, -510, 513, -1019, 510, -509, 511, -510, 1020,
[D][remote.raw] -1020, 1022, -1019, 510, -509, 511, -510, 511, -509, 511, -510,
[D][remote.raw] 1020, -1019, 510, -511, 1020, -510, 512, -508, 510, -1020, 1022
But they scroll though so fast I can’t capture them, let alone know if they are the right codes or not.
Is there a better way to obtain the raw codes? Can the sensitivity be dialed down so the codes don’t scroll so rapidly (where are they coming from anyway?).
PS: I have been told the remote I have is compatible with the Broadlink Pro so I assume they should work here as well.
Would appreciate any pointers you guys may have.
Cheers.
Hi Steven,
I am not expert but I got mine working
Anyway, your code looks too long,
you probably fetched two merged codes. Try with the first 32 bits
‘01010101111111111100110100010011’
the rest ‘0101010’ looks like the beginning of the first code
And how does your esphome yaml file look like. Especially the transmit part if this is not working.
Any way, please paste the whole of your yaml file then it will be much easier to locate whether something looks wrong/strange.
Cheers
I’ve tried various configurations and I tried the pressing the button several times with the same result.
I have managed to obtain codes for the broadlink bridge. I wonder if I can use them for the Sonoff bridge I have. Is there a particular format ESP home uses for RF remotes that I could convert the code received from the broadlink to?
This is the yaml from the Sonoff RF Bridge:
esphome:
name: rf_bridge
platform: ESP8266
board: esp01_1m
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
captive_portal:
# Enable logging
logger:
# Enable Home Assistant API
api:
password: !secret esp_home_password
ota:
password: !secret esp_home_password
web_server:
port: 80
sensor:
- platform: wifi_signal
name: RF Bridge WIFI Signal
update_interval: 10s
- platform: uptime
name: Bridge Uptime
binary_sensor:
- platform: status
name: RF Bridge Status
- platform: remote_receiver
name: Front Door Motion
device_class: motion
rc_switch_raw:
code: '111111011001010101001110'
protocol: 1
filters:
delayed_off: 300s
# door window sensors
- platform: remote_receiver
id: garage_rf_open
internal: true
rc_switch_raw:
code: '111001001001011100001010'
protocol: 1
filters:
delayed_off: 100ms
- platform: remote_receiver
id: garage_rf_closed
internal: true
rc_switch_raw:
code: '111001001001011100001110'
protocol: 1
filters:
delayed_off: 100ms
- platform: template
name: Garage Door (RF)
device_class: door
lambda: |-
if (id(garage_rf_open).state) {
// door is open
return true;
} else if (id(garage_rf_closed).state) {
// door is closed
return false;
} else {
return {};
}
switch:
- platform: template
name: Blind Down
turn_on_action:
- remote_transmitter.transmit_rc_switch_raw:
code: '001100111111111111001101000100110011001'
protocol: 1
repeat:
times: 10
wait_time: 50ms
- platform: template
name: Blind Up
turn_on_action:
- remote_transmitter.transmit_rc_switch_raw:
code: '000100011111111111001101000100110001000'
protocol: 1
remote_receiver:
pin: 4
dump: rc_switch
tolerance: 50
filter: 4us
idle: 4ms
remote_transmitter:
pin: 5
carrier_duty_percent: 100%
status_led:
pin:
number: GPIO13
inverted: yes
any news on the RF Bridge component?
Has it been included in the standard version of esphome or is it still under development?
Hi Steven,
It was not enough in my case just to write protocol: 1 in the transmit mode, but I had to add several details to the transmit signal before it worked. Here is an example of one of my transmit sensors that works fine:
I also noticed that you have “-” before “remote_transmitter.transmit_rc_switch_raw” while I don’t.
try to remove that
Cheers
Thanks for that, I’ll give that a try.
It’s still only in the dev version of ESPHome, and it still has a bug that prevents you from actually transmitting codes to a device.
Have the docs been updated with this yet?
If not, please could you share a config?
I only receive with RF Bridge so would like to give it a try.
Offical documentation is here: RF Bridge Component — ESPHome
And here is where I am describing my recent setup for controlling a ceiling fan: RF Bridge the Gap to make another Ceiling Fan smart – neon.ninja
My project is to create a binary sensor inside esphome which will evaluate the incoming RF code.
If the incoming rf code is ADAF0E then the binary sensor state becomes ON and after 8000ms becomes off (door sensor)
I’ve created a global variable:
globals:
- id: rf_code
type: char[10]
and then under rf_bridge , on_code_receive:
then:
- globals.set:
id: rf_code
value: !lambda 'char buffer [10];return itoa(data.code,buffer,16);'
and finally
binary_sensor:
- platform: template
device_class: door
filters:
- delayed_on_off: 8000ms
- lambda: |-
if (id(rf_code) == 'ADAF0E') {
return true;
}
with the hopes that through hassio integration the binary sensor will be visible in home assistant and turn on each time it receives the rf code.
But i get errors during compile.
Any ideas?
What are the errors you are getting?
Can you post the whole config?
I’m using it this way:
binary_sensor:
- platform: remote_receiver
name: RF Remote
rc_switch_raw:
code: '100011011011111010110010'
protocol: 1
filters:
delayed_off: 500ms
But this is with the modified rf bridge.
I’ll try to recompile it again and copy paste the errors.
Forgot to mention that my rf bridge is not modified.
Here’s my yaml file:
esphome:
name: sonoff_rf_bridge_1
platform: ESP8266
board: esp01_1m
wifi:
networks:
- ssid: !secret ssid_name
password: !secret wifi_pwd
- ssid: !secret ssid_name1
password: !secret wifi_pwd
domain: .lan
ap:
ssid: "Sonoff RF Bridge 1"
password: !secret wifi_pwd
captive_portal:
ota:
password: !secret wifi_pwd
# Enable Home Assistant API
api:
password: !secret wifi_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
uart:
tx_pin: 1
rx_pin: 3
baud_rate: 19200
logger:
baud_rate: 0
globals:
- id: rf_code
type: char[10]
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);'
- globals.set:
id: rf_code
value: !lambda 'char buffer [10];return itoa(data.code,buffer,16);'
binary_sensor:
platform: template
name: 'Door 1'
device_class: door
filters:
- delayed_on_off: 8000ms
- lambda: |-
if (id(rf_code) == '0xAED0FF') {
return true ;
} else {
return {};
}
and here’s the result of the compile:
Compiling /data/sonoff_rf_bridge_1/.pioenvs/sonoff_rf_bridge_1/src/main.cpp.o
src/main.cpp:278:31: warning: character constant too long for its type [enabled by default]
if (rf_code->value() == '0xAED0FF') {
^
Compiling /data/sonoff_rf_bridge_1/.pioenvs/sonoff_rf_bridge_1/libced/ESPAsyncWebServer-esphome_ID6758/WebAuthentication.cpp.o
Compiling /data/sonoff_rf_bridge_1/.pioenvs/sonoff_rf_bridge_1/libced/ESPAsyncWebServer-esphome_ID6758/WebHandlers.cpp.o
Compiling /data/sonoff_rf_bridge_1/.pioenvs/sonoff_rf_bridge_1/libced/ESPAsyncWebServer-esphome_ID6758/WebRequest.cpp.o
In file included from src/esphome/core/application.h:8:0,
from src/esphome/components/api/api_connection.h:4,
from src/esphome.h:2,
from src/main.cpp:3:
src/esphome/core/helpers.h: In instantiation of 'class esphome::TemplatableValue<char [10], esphome::rf_bridge::RFBridgeData>':
src/esphome/components/globals/globals_component.h:60:3: required from 'class esphome::globals::GlobalVarSetAction<esphome::globals::GlobalsComponent<char [10]>, esphome::rf_bridge::RFBridgeData>'
src/main.cpp:276:133: required from here
src/esphome/core/helpers.h:239:5: error: function returning an array
T value(X... x) {
^
src/esphome/core/helpers.h:254:5: error: function returning an array
T value_or(X... x, T default_value) {
^
src/esphome/core/helpers.h:269:26: error: function returning an array
std::function<T(X...)> f_;
^
src/main.cpp: In lambda function:
src/main.cpp:278:31: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
if (rf_code->value() == '0xAED0FF') {
^
In file included from src/esphome/core/application.h:8:0,
from src/esphome/components/api/api_connection.h:4,
from src/esphome.h:2,
from src/main.cpp:3:
src/esphome/core/helpers.h: In instantiation of 'esphome::TemplatableValue<T, X>::TemplatableValue(F) [with F = setup()::__lambda21; typename std::enable_if<esphome::is_callable<F, X ...>::value, int>::type <anonymous> = 0; T = char [10]; X = {esphome::rf_bridge::RFBridgeData}]':
src/esphome/components/globals/globals_component.h:60:3: required from 'void esphome::globals::GlobalVarSetAction<C, Ts>::set_value(V) [with V = setup()::__lambda21; C = esphome::globals::GlobalsComponent<char [10]>; Ts = {esphome::rf_bridge::RFBridgeData}]'
src/main.cpp:286:4: required from here
src/esphome/core/helpers.h:235:46: error: using invalid field 'esphome::TemplatableValue<T, X>::f_'
TemplatableValue(F f) : type_(LAMBDA), f_(f) {}
^
In file included from src/esphome.h:17:0,
from src/main.cpp:3:
src/esphome/components/globals/globals_component.h: In instantiation of 'void esphome::globals::GlobalVarSetAction<C, Ts>::play(Ts ...) [with C = esphome::globals::GlobalsComponent<char [10]>; Ts = {esphome::rf_bridge::RFBridgeData}]':
src/main.cpp:296:1: required from here
src/esphome/components/globals/globals_component.h:62:56: error: 'class esphome::TemplatableValue<char [10], esphome::rf_bridge::RFBridgeData>' has no member named 'value'
void play(Ts... x) override { this->parent_->value() = this->value_.value(x...); }
^
Compiling /data/sonoff_rf_bridge_1/.pioenvs/sonoff_rf_bridge_1/libced/ESPAsyncWebServer-esphome_ID6758/WebResponses.cpp.o
*** [/data/sonoff_rf_bridge_1/.pioenvs/sonoff_rf_bridge_1/src/main.cpp.o] Error 1
========================= [FAILED] Took 62.21 seconds =========================
something’s wrong with the definition of the global variable of type char[10] and the evaluation of the rf_code…
Good morning @filippos you managed to progress in your code above, because I have the same problem and I can’t see the solution, did you get it?
unfortunately i couldnt find any help so i dropped this project for the moment.
But I have it pending and will resume once they publish beginner-friendly documentation on that matter.