I’ll post the snippet to tomorrow, it’s nearly midnight here and the development computer is off. The iPad isn’t the best tool to use.
This is what I am currently using. I have a Sonoff RF bridge that packs whatever it receives into a JSON object and sends it via MQTT. This is my binary_sensor
- platform: mqtt
name: Hall Motion
payload_on: "D3276E"
payload_off: "D3276Eoff"
sensor_class: motion
state_topic: "sonoffbr/tele/RESULT"
value_template: '{{ value_json.RfReceived.Data }}'
The payload_off is a made up value used to reset the sensor in the automation following. I’m not all that happy with this method, but as yet I haven’t found another way to change the state of the binary sensor.
#turn off hall motion sensor after 5 sec
- alias: Turn off hall motion
hide_entity: true
trigger:
platform: state
entity_id: binary_sensor.hall_motion
to: 'on'
for:
seconds: 5
action:
service: mqtt.publish
data:
topic: "sonoffbr/tele/RESULT"
payload: "D3276Eoff"
retain: "true"
3 Likes
is your RF bridge flashed with Tasmota?
I suspect it must be, like mine is now.
OK, I’ve taken your code snips and successfully used them tonight to create six automatically resetting binary sensors from the six RF devices !
So thank you very much bukurat for taking the time to give me a complete enough set of information based on my probably not very clear questions (at times).
I needed to change some small details to match my own environment, but that was not hard. My MQTT topics were slightly different to yours, and slightly different order also. I also decided to get the RF bridge (Tasmota FW based) to learn the six devices and use the ‘RfKey’ number payload instead of the ‘data’ payload. I think mainly so I can change an RF sensor and only need to relearn it in the RF bridge, the config and automation yaml will remain unchanged that way.
My new configuration.yaml code addition that’s working. Payload_on is the value sent from Sonoff bridge, payload_off is just an arbitrary (but meaningful to me) string, just like you explained with your random codes for that. Seems the RF bridge cares not if it’s Hex or ASCII.
binary_sensor:
- platform: mqtt
name: "RF bridge key 1"
payload_on: "1"
payload_off: "key1_off"
device_class: opening
state_topic: "tele/sonoff_bridge/RESULT"
value_template: '{{ value_json.RfReceived.RfKey }}'
- platform: mqtt
name: "RF bridge key 2"
payload_on: "2"
payload_off: "key2_off"
device_class: opening
state_topic: "tele/sonoff_bridge/RESULT"
value_template: '{{ value_json.RfReceived.RfKey }}'
- platform: mqtt
name: "RF bridge key 3"
payload_on: "3"
payload_off: "key3_off"
device_class: opening
state_topic: "tele/sonoff_bridge/RESULT"
value_template: '{{ value_json.RfReceived.RfKey }}'
- platform: mqtt
name: "RF bridge key 4"
payload_on: "4"
payload_off: "key4_off"
device_class: opening
state_topic: "tele/sonoff_bridge/RESULT"
value_template: '{{ value_json.RfReceived.RfKey }}'
- platform: mqtt
name: "RF bridge key 5"
payload_on: "5"
payload_off: "key5_off"
device_class: opening
state_topic: "tele/sonoff_bridge/RESULT"
value_template: '{{ value_json.RfReceived.RfKey }}'
- platform: mqtt
name: "RF bridge key 6"
payload_on: "6"
payload_off: "key6_off"
device_class: opening
state_topic: "tele/sonoff_bridge/RESULT"
value_template: '{{ value_json.RfReceived.RfKey }}'
and the reset automations
- alias: Reset RF bridge RfKey1
hide_entity: true
trigger:
platform: state
entity_id: binary_sensor.rf_bridge_key_1
to: 'on'
for:
seconds: 5
action:
service: mqtt.publish
data:
topic: tele/sonoff_bridge/RESULT
payload: key1_off
retain: 'true'
- alias: Reset RF bridge RfKey2
hide_entity: true
trigger:
platform: state
entity_id: binary_sensor.rf_bridge_key_2
to: 'on'
for:
seconds: 5
action:
service: mqtt.publish
data:
topic: tele/sonoff_bridge/RESULT
payload: key2_off
retain: 'true'
- alias: Reset RF bridge RfKey3
hide_entity: true
trigger:
platform: state
entity_id: binary_sensor.rf_bridge_key_3
to: 'on'
for:
seconds: 5
action:
service: mqtt.publish
data:
topic: tele/sonoff_bridge/RESULT
payload: key3_off
retain: 'true'
- alias: Reset RF bridge RfKey4
hide_entity: true
trigger:
platform: state
entity_id: binary_sensor.rf_bridge_key_4
to: 'on'
for:
seconds: 5
action:
service: mqtt.publish
data:
topic: tele/sonoff_bridge/RESULT
payload: key4_off
retain: 'true'
- alias: Reset RF bridge RfKey5
hide_entity: true
trigger:
platform: state
entity_id: binary_sensor.rf_bridge_key_5
to: 'on'
for:
seconds: 5
action:
service: mqtt.publish
data:
topic: tele/sonoff_bridge/RESULT
payload: key5_off
retain: 'true'
- alias: Reset RF bridge RfKey6
hide_entity: true
trigger:
platform: state
entity_id: binary_sensor.rf_bridge_key_6
to: 'on'
for:
seconds: 5
action:
service: mqtt.publish
data:
topic: tele/sonoff_bridge/RESULT
payload: key6_off
retain: 'true'
7 Likes
I’m glad it helped you. The bridge doesn’t do anything with the data apart from checking to see if its a command for it to do something. If its not, it just passes it to the RF side to transmit. The various devices listening on the same frequency only react if they hear their own address. PIRs and window sensors just send a “something happened near me” message to the world at large, the bridge hears it and, if it recognises it as something it has learnt
21/03/2018, 14:25:15node: ed292e4.396525
sonoffbr/tele/RESULT : msg.payload : string[75]
"{"RfReceived":{"Sync":6210,"Low":240,"High":580,"Data":"00000F","RfKey":1}}"
orif it can make sense of it, packages it in a JSON object and sends it to the MQTT broker as telemetry
21/03/2018, 14:27:50node: ed292e4.396525
sonoffbr/tele/RESULT : msg.payload : string[82]
"{"RfReceived":{"Sync":12540,"Low":420,"High":1210,"Data":"D3276E","RfKey":"None"}}"
Yes, this all Tasmota
I use node-red to watch the MQTT topics to see what is being sent by the bridge.
Cool. I’ve been using MQTT Snooper on an Android tablet.
I also tested commands back to the RF Bridge using that app, then I’ve used the tested command in an mqtt.publish service call from a time based automation. It locks my car at night if I’ve forgotten…
PS. Ultimately I hope the HA dev’s add a reset variable to the Binary Sensor Component, as it would be much easier for newbies to use.
Just when I thought I’d got an acceptable work around for integrating these 433Mhz RF binary sensors, I get this flood of log errors after any sensor fires now, after I updated HASS a couple of nights ago… FIH.
This was from tripping rfkey1 door sensor after clearing the log first.
No matching payload found for entity: RF bridge key 2 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
Error parsing value: ‘value_json’ is undefined (value: key1_off, template: {{ value_json.RfReceived.RfKey }})
8:59 PM helpers/template.py (ERROR)
No matching payload found for entity: RF bridge key 6 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
Error parsing value: ‘value_json’ is undefined (value: key1_off, template: {{ value_json.RfReceived.RfKey }})
8:59 PM helpers/template.py (ERROR)
No matching payload found for entity: RF bridge key 4 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
Error parsing value: ‘value_json’ is undefined (value: key1_off, template: {{ value_json.RfReceived.RfKey }})
8:59 PM helpers/template.py (ERROR)
No matching payload found for entity: RF bridge key 5 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
Error parsing value: ‘value_json’ is undefined (value: key1_off, template: {{ value_json.RfReceived.RfKey }})
8:59 PM helpers/template.py (ERROR)
No matching payload found for entity: RF bridge key 3 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
Error parsing value: ‘value_json’ is undefined (value: key1_off, template: {{ value_json.RfReceived.RfKey }})
8:59 PM helpers/template.py (ERROR)
Error parsing value: ‘value_json’ is undefined (value: key1_off, template: {{ value_json.RfReceived.RfKey }})
8:59 PM helpers/template.py (ERROR)
No matching payload found for entity: RF bridge key 2 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
No matching payload found for entity: RF bridge key 6 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
No matching payload found for entity: RF bridge key 4 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
No matching payload found for entity: RF bridge key 5 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
No matching payload found for entity: RF bridge key 3 with state_topic: tele/sonoff_bridge/RESULT
8:59 PM components/binary_sensor/mqtt.py (WARNING)
so basically your approach does not work, right? 
No no, not at all, it works.
Sensors still trigger and reset in five seconds fine in hassio, and I now added image capture from an IP camera from one of those binary door sensors too, and that works.
What has changed is that NOW it throws lots of log warning where before there were none, because somebody decided to add new warnings from MQTT topics where the payload does not match the expected one. I think the person who instigated that new warning had no idea that many people were using MQTT topics and payloads in a way they had not considered possible. Somebody correct me if wrong…
that’s a big relief. what IP camera are you using btw?
I think if we are using MQTT within the boundaries it’s designed for, why not? 
It would be interesting to know what’s changed on their side.
I’m still on 0.64.3 partly because of all those new issues the latest versions introduced to the custom alarm panel, and now to MQTT…
I’m using an Edimax IP camera, and I do NOT recommend them. Buy Foscam or something else…
i cannot add any of the reset automations without corrupting the Congiuration.yaml
I went and added two spaces to each line and that didnt work (alignment is off)
Do all these - alias: supposed to go under under the header binary_sensor or should there be a different header I am missing?
Config check of yaml file does not like this:
no problem with adding the sensors
Apparently you put everything in one place, your example does not make sense to me at all.
The bit with payload is mqtt switch description (and should be under switch header), and the bit with trigger should go to automation with appropriate - id in front of it.
Sorry - but I am just lost. Most be missing something obvious.
I got the bridge tasmota’ed and have a PIR sending stuff to it (and on to my MQTT broker) - this is for about 1 minute:
19:28:46 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12540,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
19:28:52 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12560,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
19:28:57 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12560,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
19:29:05 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12550,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
19:29:11 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12540,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
19:29:17 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12550,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
19:29:23 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12570,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
19:29:30 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12540,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
19:29:36 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12490,“Low”:440,“High”:1200,“Data”:“D41ADE”,“RfKey”:“None”}}
19:29:42 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12550,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
19:29:48 MQT: tele/sonoff_bridge/RESULT = {“RfReceived”:{“Sync”:12550,“Low”:420,“High”:1220,“Data”:“D41ADE”,“RfKey”:“None”}}
I have tried to have the PIR facing away from me, but also waving my and and moving it about. Seems to make little difference.
I am puzzled that it keeps sending stuff - I would expect it to send only something when detecting movement. And that the value of Data would have variations, but it is always “D41ADE” - no matter if there is movement or not in front of the PIR.
Do I need to pair them (bridge and PIR) somehow?
No need to pair them.
If you pull the battery from the pir does the data stream stop?
If it does, the pir is either faulty or being continually triggered. If not, then you are receiving a data stream from some other device.
Do you have a user manual?
My SONOFF PIR2 come configured (by jumpers) in test mode - it means they send a signal if detect movement every 5 seconds, and you use that mode during installation to choose the right orientation of the sensor.
When it’s done, you switch it to normal mode, and it will detect movement (and send a signal) once in 2-3 minutes.
If your PIR is sending signals even if there is no movement, is must be faulty, but you need to make sure you are receiving signal from that particular PIR and not from something else.
Thanks, this makes sense - and I looked at the manual.
Now - the sensor only “shoots” when I pass. However, now it is almost too little - if I pass multiple times with like 10 seconds apart, it only fires on the first pass. When will it be “reset”, i.e. fire on next pass.
I have the PIR2 “tasmotaed”.