So how does that work around get created in more detail, I read that thread and I could not separate the stuff I need to do, and what I don’t need to do to make a custom component.
Is it a case of making or downloading a modified mqtt.py script and then also changing all the binary_sensors in configuration.yaml to use the new custom component ?
Hello to all
I use the RF Bridge Sonoff with Tasmota firmware with 2 door sensors (DW1).
In the MQTT logs I receive only the message of the opening of the door and not of the closure.
What am I doing wrong?
Hello there
Your sensors are not capable of sending close state, that is the source of the problem.
That was the reason I ditched RF door sensors and went with xiaomi zigbee sensors.
You can buy RF sensors that send both open and close codes. I use them on some of my doors and wimdows.
Hello everyone
Today I have proved that you can also generate a switch with the RF so that it can emit.
It is simply to generate a switch with the code to be issued, that simple! regards
switch.yaml
- platform: mqtt
name: “Code 555503 emitting”
state_topic: “tele/sonoffq/RESULT”
command_topic: “cmnd/sonoffq/RfCode”
qos: 1
payload_on: “#555503#”
payload_off: “#555507#”
retain: true
1 Like
great thank you. so switches are not limited to 16, just like sensors…
no, since in each switch you put the code that you want it to emit, although you can also do it through key, but there you are limited to 16
Thank you all for the good work!
I’ve found a way to operate without limitation of sensors:
In automations.yaml:
- alias: what_ever_you_want
trigger:
platform: mqtt
topic: tele/bridge/RESULT
condition:
condition: template
value_template: ‘{{ trigger.payload_json.RfReceived.Data == “5615D4” }}’
action:
…
Perhaps you can use it for your HA.
Peter
2 Likes
I’m doing some research before I buy one of these bridges and wanted to confirm something.
On the itead site it mentions “you can add up to four 1-4 buttons 433.92MHz Wireless RF Remotes or 433.92MHz sensors to the RF Bridge device” and it also says “Support to add max. four 433MHz RF Remote/Curtain Switch/Alarm; Support to control up to sixteen 433MHz RF devices”.
So, then my question is, how many actual door/window/PIR sensors can one bridge support (with Tasmota, if it makes a difference)? It’s not entirely clear to me as they have it described.
Thanks!
Based on SkipperPit’s information, Cheers mate 
I have got my Tasmota Sonoff RF Bridge working with a RF Remote.
Here is what I have for one button (I have 4, but its just a repeat of this code with required changes) - hope it helps somebody.
Base info:
My Sonoff Bridge is set to topic 'sonoff_bridge
I have programed the buttons via learning mode to the bridge. This then gives a Rfkey value to each button, you can then use Rfkey in the code -
example: value_template: “{{ trigger.payload_json.RfReceived.RfKey == 1 }}”
Button 2 would be Rfkey == 2 in example above, and so on.
If you don’t use the learning option, you can still use the data option, replace line above with:
value_template: “{{ trigger.payload_json.RfReceived.Data == ‘7F2381’ }}”
Where ‘7F2381’ - is whatever data is sent when button is pressed.
Spacing is critical 
Code from automations.yaml:
-
alias: RF-Remote Button A
trigger:- platform: mqtt
topic: tele/sonoff_bridge/RESULT
condition: - condition: template
value_template: “{{ trigger.payload_json.RfReceived.RfKey == 1 }}”
action:
- service: notify.Office_LG_TV
data:
message: ‘Remote Button A Pressed’ - service: switch.turn_on
entity_id: switch.sonofftest
- platform: mqtt
P.S. the ‘dot’ is a minus sign or dash, it just doesn’t show correctly here
Rik 
1 Like
Would you know if all RF Fobs have the same data codes? I have mine working, but only have one Fob. thx
I’m new to the whole Tasmota and Sonoff configuration, but I have just flashed my Sonoff RF Bridge successfully. I’ve spent several hours investigating why my payloads weren’t triggering the RF switches I have. In my case the remote for the switches sends:
tele/sonoffrfbr/RESULT = {"RfReceived":{"Sync":5520,"Low":190,"High":520,"Data":"505500","RfKey":"None"}
Whenever I tried RfCode in either Tasmota console or via MQTT, it failed to trigger the device. I then realised that perhaps the other Sync, Low & High values were important and when set them manually in the console before sending the code, the device worked.
Now being an MQTT novice and not great with HA either, how do I configure an MQTT payload to set all of the properties in a single drop? My current config looks like:
- platform: mqtt
name: “Switch4”
state_topic: “tele/sonoffrfbr/RESULT”
command_topic: “cmnd/sonoffrfbr/RfCode”
qos: 1
payload_on: “5266691”
payload_off: “5266700”
retain: false
what’s the correct way to specify a payload_on that looks something like: {"RfSync":5520, "RfLow":190,"RfHigh":520,"RfCode":5266692} ?
If the rfcode is the changing value then in you Eg payload_on: “526692” and if there is no payload_off: just add “526692off” this will let you turn it off in HA then you have to create a automation to turn it off after say 2 sec or what every when I get home I’ll paste my code in here
Im Home
My RF send data
my RF_Bridge console
09:44:52 MQT: tele/RF_Bridge/RESULT = {"RfReceived":{"Sync":7940,"Low":280,"High":740,"Data":"BFFEC2","RfKey":"None"}}
so my binarysensor is
- platform: mqtt
state_topic: "tele/RF_Bridge/RESULT"
name: 'Key FOB - A'
value_template: '{{value_json.RfReceived.Data}}'
payload_on: 'BFFEC2'
payload_off: 'BFFEC2off'
device_class: power
optimistic: false
qos: 1
as it does not have a Off command Ijust send the payload_off: ‘BFFEC2off’
in HA I see
created from
- type: glance
title: Key FOB (433mhz)
entities:
- entity: sensor.last_rf
name : Last
- entity: binary_sensor.key_fob__a
name: A
- entity: binary_sensor.key_fob__b
name: B
- entity: binary_sensor.key_fob__c
name: C
- entity: binary_sensor.key_fob__d
name: D
- entity: binary_sensor.water_alarm
name: WATER
as it does not have a off command
this is the automation to turn it off
- id: Key FOB - A
alias: Key FOB - A
hide_entity: true
initial_state: 'on'
trigger:
- platform: state
entity_id: binary_sensor.key_fob__a
from: 'off'
to: 'on'
for:
seconds: 2
action:
- service: mqtt.publish
data:
topic: tele/RF_Bridge/RESULT
payload: BFFEC2off
That the Logic set up now the fun part
I want when I press the A the garage Lights Toggle ON/OFF
so we need a other automation
- id: 'FOB A Garge Light Toggle'
alias: FOB A Garge Light Toggle
trigger:
- entity_id: binary_sensor.key_fob__a
from: 'off'
platform: state
to: 'on'
condition: []
action:
- data:
entity_id: light.garage_light
service: light.toggle
1 Like
I use the Tasmota code on a Sonoff RF gateway with good success. Here’s an example that might be helpful for you. I have a 433MHz wireless doorbell, and I’ve defined a switch that toggles when someone presses the doorbell button.
This doorbell button doesn’t have an “off”, just a code when it’s pressed. I have similar things in place for PIR motion detectors that just send a code upon motion detection; their configuration is similar to this example.
input_boolean:
doorbell_button:
initial: off
automation:
# {"RfReceived":{"Sync":6060,"Low":210,"High":610,"Data":"739853","RfKey":"None"}}
- alias: doorbell button pressed
initial_state: true
trigger:
- platform: mqtt
topic: "19916/tele/rfbridge/RESULT"
condition:
condition: and
conditions:
- condition: template
value_template: '{{ trigger.payload_json.RfReceived.Data == "AC0AC3" }}'
action:
- service: input_boolean.turn_on
data:
entity_id: input_boolean.doorbell_button
- delay: '00:00:10'
- service: input_boolean.turn_off
data:
entity_id: input_boolean.doorbell_button
The input_boolean entity is turned on for 10 seconds and then turned off. Note that only the Data element in the JSON payload is significant; the other numbers will vary a little bit as the RF gateway tries to measure the RF signaling, and it doesn’t always get quite the same answer each time. This is why I used the template condition and the specified value_template expression to test just that one field.
Of course, you can then trigger an automation based on the state change of the input_boolean entity. Or even just do stuff in this automation and not bother with the input_boolean at all. My preference is to have this other input_boolean entity around because I can then easily look at the history of that entity and see the times when it’s state has changed recently.
Hi - did you get this working? I believe I’m stuck in the same place.
Hi - I did find a way to send all the command to the Sonoff as a single payload. Instead of sending individual commands, use the BACKLOG command as below:
- platform: mqtt
name: "Zap3"
state_topic: "tele/sonoffrfbr/RESULT"
command_topic: "cmnd/sonoffrfbr/Backlog"
qos: 1
payload_on: "RfSync 5520; RfLow 190; RfHigh 520; RfCode 5265155"
payload_off: "RfSync 5520; RfLow 190; RfHigh 520; RfCode 5265164"
retain: false
I was new so hadn’t RTFM properly 
My current problem is that while I can send all the relvant commands into the backlog, the RF Bridge doesn’t trigger the switch with the code, even though the code and associated data has been learned and assigned to a key that works with a corresponding RfKey command. Still under investigation…
Hi lmamakos, I am using a bit simplier way to restore the state, off state on MQTT sensor is virtual one, payload_off: “1005F0off”"
- alias: Gate bell sensor restart
trigger:
- platform: state
entity_id: binary_sensor.gate_bell
from: 'off'
to: 'on'
for:
seconds: 1
action:
service: mqtt.publish
data:
topic: "tele/sonoff/RESULT"
payload: "1005F0off"You generate an extra message and network traffic to your MQTT broker, and other received message to process by Home Assistant. You still have a timer running in there, same as me, but mine is inside the action: of the automation, rather than part of the trigger. I’m not sure its necessarily simpler since the logic to control the entity is split in a couple of different places.
In my case, I have one automation to manipulation the state of an input_boolean entity; in your case, you have a template sensor that responds to an MQTT message and an auxiliary automation and traffic to also poke the template sensor again. I think my approach is more “efficient”, though probably doesn’t matter very much in practice…
But potato / potatoe, both get the job done…
I went through this entire thread thinking, “there has got to be a more elegant solution than this ‘off’ MQTT message,” and there is. See this thread here and my code reference at the end.
No automation needed. Simply reset after a timeout. So simple.