-
Notifications
You must be signed in to change notification settings - Fork 636
RFBRIDGE
RFBRIDGE module (rfbridge.cpp), originally created for the Itead Sonoff RF Bridge.
Since version 1.14.0, combined with RF module and now allows to use standalone ESP8266 board with an external RF receiver / transmitter
Since version 1.15.0, underlying RF transmitter / receiver library was changed to the version used by OpenMQTTGateway in GATEWAY_RF
configuration.
rfin
and rfout
topics are used to receive and send messages.
rfraw
topic allows to send raw binary messages to the EFM8 chip (2)
State topic | Example payload | Notes |
---|---|---|
{root topic}/rfin |
26C0013603CA511451 |
received code |
Command topic | Example payload | Notes |
---|---|---|
{root topic}/rflearn/set |
0,1 |
see note 1 below |
{root topic}/rfout/set |
26C0013603CA511451 |
send code |
{root topic}/rfout/set |
26C0013603CA511451,3 |
send code N times |
{root topic}/rfraw/set |
see note 2 below |
Command | description |
---|---|
rfb.learn <id> | Learn RF code for relay ID |
rfb.forget <id> | Forget previously learned RF code |
rfb.write <id> | Write HEX data as-is to the Serial |
Configuration key | Build flag | Description |
---|---|---|
RFB_PROVIDER |
(default: RFB_PROVIDER_RCSWITCH ) |
|
RFB_DEBOUNCE |
(default: 500 ms) |
|
RFB_LEARN_TIMEOUT |
(default: 15000 ms) |
|
rfbRepeat |
RFB_SEND_REPEATS |
(default: 1 times) Repeat the code as soon as possible, depends on RFB_SEND_DELAY Note: When using RFB_PROVIDER_RCSWITCH , try changing RFB_TRANSMIT_REPEATS instead |
rfbTransmit |
RFB_TRANSMIT_REPEATS |
(default: 5 times)Only when using RFB_PROVIDER_RCSWITCH , configures how much times code is (immediately) repeated when sending (independent of the RFB_SEND_REPEATS queue) |
RFB_SEND_DELAY |
(default: 500 ms)Interval between sending messages |
|
RFB_RECEIVE_DELAY |
(default: 500 ms)Interval between receiving messages |
|
rfbOFF# |
Code to turn OFF the n-th relay | |
rfbON# |
Code to turn ON the n-th relay | |
rfbRX |
RFB_RX_PIN |
(Only when RFB_PROVIDER=RFB_PROVIDER_RCSWITCH , default: GPIO_NONE )RX GPIO |
rfbTX |
RFB_TX_PIN |
(Only when RFB_PROVIDER=RFB_PROVIDER_RCSWITCH , default: GPIO_NONE )TX GPIO |
The RF codes produced by the firmware for the "direct" modified board are different from the ones produced by the "vanilla" bridge for same remote. This was a design choice, due to the different kind of information passed by the EFM8BB1 hardware and the software library.
For example, running mosquitto_sub -v -t "+/rfin"
:
rfbridge-vanilla/rfin 2F260186046ACE9778
rfbridge-direct/rfin C001018418CE9778
Thanks to @pelson, here is an example of how to port basic Arduino sketch code that uses RCSwitch to send messages using MQTT 3:
mySwitch.setProtocol(4);
mySwitch.send(2175276, 24);
Equivalent message for the rfout
would be:
mosquitto_pub -t "rfbridge-direct/rfout/set" -m "C00400001821312C"
-
C0
: The initial byte (always the same) -
04
: Protocol 4. -
0000
: 2 timing bytes (16 bit int?) - I wanted the timing to be defined by the protocol, not overridden. -
18
: Bit length (24 in decimal) -
21312C
: The code to send (2175276 in decimal), exactly 3 bytes.
Notice that we omit the leading zeroes. This might not always be the case and depends on the value of 'Bit length'. For example, in case of Bit lenght
equal to 19
, we would need 4 bytes. Similarly, for 11
we would need only 2.
To configure RFBridge as a sensor.espurna_123456_rfin
sensor entity:
- platform: mqtt
name: "ESPURNA 123456 RFIN"
state_topic: "ESPURNA-123456/rfin"
availability_topic: "ESPURNA-123456/status"
payload_available: "1"
payload_not_available: "0"
force_update: true
expire_after: 1
Most of the time we are only interested in the last 3 bytes. It is possible to modify the incoming data right in the sensor configuration by using the value_template
attribute 4 5
value_template: >
{% if not value %}
"No data"
{% endif %}
{{ value[-6:] }}
Or, with mqttUseJson => "1"
:
state_topic: "ESPURNA-123456/data"
value_template: {{ value_json["rfin"] }}
(1) Triggers a learn action. The index after the "learn" magnitude indicates the relay the code will be linked to. The payload of the message is the relay ID (before the comma) and the action (0
for off, 1
for on).
(2) Raw codes requires a special firmware in the EFM8BB1. See Portisch/RF-Bridge-EFM8BB1 and issue #386 for more information. Full list of commands: https://github.com/Portisch/RF-Bridge-EFM8BB1/wiki/Commands
(3) https://gitter.im/tinkerman-cat/espurna?at=5d39a15be16c666d8967d6c9
(4) https://www.home-assistant.io/docs/configuration/templating/
If you're looking for support:
- Issues: this is the most dynamic channel at the moment, you might find an answer to your question by searching open or closed issues.
- Wiki pages: might not be as up-to-date as we all would like (hey, you can also contribute in the documentation!).
- Gitter channel: you have better chances to get fast answers from project contributors or other ESPurna users. (also available with any Matrix client!)
- Issue a question: as a last resort, you can open new question issue on GitHub. Just remember: the more info you provide the more chances you'll have to get an accurate answer.
- Backup the stock firmware
- Flash a pre-built binary image
- Flash a virgin Itead Sonoff device without opening
- Flash TUYA-based device without opening
- Flash Shelly device without opening
- Using PlatformIO
- from Visual Studio Code
- Using Arduino IDE
- Build the Web Interface
- Over-the-air updates
- Two-step updates
- ESPurna OTA Manager
- NoFUSS
- Troubleshooting
- MQTT
- REST API
- Domoticz
- Home Assistant
- InfluxDB
- Prometheus metrics
- Thingspeak
- Alexa
- Google Home
- Architecture
- 3rd Party Plugins
- Coding style
- Pull Requests