I reviewed the information you provided more closely and found the error … and it’s so simple.
There’s a mistake in your rfbridge_demultiplexer. Use data_template: not data:
It was never passing the RF code to the python_script. It was passing the literal template to it.
Thanks for looking into this. I appreciate the time you put in.
I’m running 0.92.1
i’m going to wait a few days before i upgrade to 0.93 and will see if i get different results.
Thanks again!
See my latest post above. Your rfbridge_demultiplexer contains an error which is responsible for this mess.
Genius …
Thank you very much… I’ll give it a try when i get home…
All good, everything is working the way it should. I apologize for my oversight, NICE CATCH!
Thanks a lot.
This is brilliant!
I’m going to give this a go, however, it’s complicated by the fact that I have 5 RF bridges. This is due to the area that I need to cover.
So, do I just need 5 versions of this automation…
- alias: 'rfbridge_demultiplexer'
trigger:
- platform: mqtt
topic: tele/RF_Bridge/RESULT
action:
- service: python_script.rfbridge_demux
data_template:
payload: '{{trigger.payload_json.RfReceived.Data}}'
…with tele/RF_Bridge/RESULT altered in each to reflect the config of each bridge, abd a different name for each automation (obviously)?
Will the python script remain the same?
You can have one automation triggered by five different MQTT topics.
- alias: 'rfbridge_demultiplexer'
trigger:
- platform: mqtt
topic: tele/RF_Bridge1/RESULT
- platform: mqtt
topic: tele/RF_Bridge1/RESULT
- platform: mqtt
topic: tele/RF_Bridge3/RESULT
- platform: mqtt
topic: tele/RF_Bridge4/RESULT
- platform: mqtt
topic: tele/RF_Bridge5/RESULT
action:
- service: python_script.rfbridge_demux
data_template:
payload: '{{trigger.payload_json.RfReceived.Data}}'
OK, thank you. I’ll give it a whirl.
I have 3 RF Bridges, they have the same topic name “topic: tele/RF_Bridge/RESULT”.
Is it better if I change them to RF_Bridge1, 2, 3 instead of same topic name?
It’s your choice.
Using a unique topic for each RF bridge allows you to easily identify the origin of a given payload. If all three RF bridges use the same topic, you won’t know which RF bridge published a given payload. However, if that’s unimportant to you then make all three bridges publish to the same topic.
This is a fantastic idea and have successfully implemented it in my system.
I as well tried a different method with my Tasmota-tized devices from Digiblur.
https://www.youtube.com/watch?v=w_CchtI-oK0&t=438s
That worked well but would only do about 12 or 13 devices due to running out of room in the Tasmota rule buffers. I needed to find something that would hold much more than that.
Here is my implementation of your script. Notice that I have HA sending codes out to some devices as well, and in order to capture those changes I needed to capture another json code and then cause the script to ignore blank packets. Also I saw no reason to send failed packets to mqtt as they cannot help anything there. I elected to instead send those only to the HA log because I can safely ignore distorted/garbled/unmonitored codes, but having them show in the HA log allows me to troubleshoot new and troubled devices with ease. This is the changes I made to the python.
I do believe I could eliminate the ‘blank’ codes sent within the de-mux automation and a clever json if/then statement, but that befuddled me, so I did it this way…
d = { '00550C':['SideDoorBell','ON','false'],
'E9B03E':['BackDoorPIR','ON','false'],
'E9A63E':['BasementWayUPIR','ON','false'],
'EA284E':['BasementWayDPIR','ON','false'],
'1145C0':['DustCollectorButton1','ON','false'],
'11450C':['DustCollectorButton2','ON','false'],
'8D63A4':['MomsButton1','ON','false'],
'8D63A1':['MomsButton2','ON','false'],
'2B200A':['Mailbox','ON','true'],
'2B200E':['Mailbox','OFF','true'],
'2B2006':['BatteryLowMailbox','ON','false'],
'CB8887':['KitchenDownLights','ON','true'],
'CB8886':['KitchenDownLights','OFF','true'],
'#CB8887':['KitchenDownLights','ON','true'],
'#CB8886':['KitchenDownLights','OFF','true'],
'472083':['Chromecast','ON','true'],
'472082':['Chromecast','OFF','true'],
'#472083':['Chromecast','ON','true'],
'#472082':['Chromecast','OFF','true'],
'E8B087':['E3','ON','true'],
'E8B086':['E3','OFF','true'],
'#E8B087':['E3','ON','true'],
'#E8B086':['E3','OFF','true']
}
p = data.get('payload')
if p is not None:
if p in d.keys():
service_data = {'topic':'rf433/{}'.format(d[p][0]), 'payload':'{}'.format(d[p][1]), 'qos':0, 'retain':'{}'.format(d[p][2])}
# logger.warning('<rfbridge2_demux> Received RF command: {}'.format(p))
hass.services.call('mqtt', 'publish', service_data, False)
elif p == "":
service_data = {'topic':'rf433/blank', 'payload':'{}'.format(p), 'qos':0, 'retain':'false'}
# hass.services.call('mqtt', 'publish', service_data, False)
# logger.warning('<rfbridge2_demux> Received blank RF command: {}'.format(p))
else:
service_data = {'topic':'rf433/unknown', 'payload':'{}'.format(p), 'qos':0, 'retain':'false'}
# hass.services.call('mqtt', 'publish', service_data, False)
logger.warning('<rfbridge2_demux> Received unknown RF command: {}'.format(p))
####################################################
# Sonoff Bridge Demultiplexer Automations.yaml #
####################################################
- id: bridge_2a_breaker
initial_state: 'on'
alias: rfbridge2a_demultiplexer
trigger:
platform: mqtt
topic: RF_Bridge2/tele/RESULT
action:
service: python_script.rfbridge2_demux
data_template:
payload: '{{trigger.payload_json.RfReceived.Data}}'
- id: bridge_2b_breaker
initial_state: 'on'
alias: rfbridge2b_demultiplexer
trigger:
platform: mqtt
topic: RF_Bridge2/stat/RESULT
action:
service: python_script.rfbridge2_demux
data_template:
payload: '{{trigger.payload_json.RfCode}}'
#####################################################
# Door Switches (433mhz) Binary_Sensors.yaml #
#####################################################
- platform: mqtt
name: "Mailbox"
device_class: opening
state_topic: rf433/Mailbox
payload_on: 'ON'
payload_off: 'OFF'
force_update: false
availability_topic: RF_Bridge2/tele/LWT
payload_available: Online
payload_not_available: Offline
#########################################################
## 3 ## Switch.yaml Control Dumb RF wall plugs. #
#########################################################
- platform: mqtt
name: "Kitchen Down Lights"
command_topic: "RF_Bridge2/cmnd/Backlog"
payload_on: "RfSync 9540; RfLow 310; RfHigh 920; RfCode #CB8887"
payload_off: "RfSync 9540; RfLow 310; RfHigh 920; RfCode #CB8886"
state_topic: rf433/KitchenDownLights
state_on: 'ON'
state_off: 'OFF'
availability_topic: "RF_Bridge2/tele/LWT"
payload_available: "Online"
payload_not_available: "Offline"
- platform: mqtt
name: "Chromecast"
command_topic: "RF_Bridge2/cmnd/Backlog"
payload_on: "RfSync 9540; RfLow 310; RfHigh 920; RfCode #472083"
payload_off: "RfSync 9540; RfLow 310; RfHigh 920; RfCode #472082"
state_topic: rf433/Chromecast
state_on: 'ON'
state_off: 'OFF'
availability_topic: "RF_Bridge2/tele/LWT"
payload_available: "Online"
payload_not_available: "Offline"Does anyone know what the approximate magnitude the performance penalty is for Strategy 1, in time per entity perhaps or CPU% hit ?
Just asking as I have 11 binary sensors in use via a Sonoff Bridge with Tasmota, but will not be adding more if possible (trying to move everything to ESPhome for all sensors).
Strategy 1 does seem to be working fine for two test sensors…
Yes, all that’s needed is a template condition.
- alias: 'rfbridge_demultiplexer'
trigger:
- platform: mqtt
topic: tele/RF_Bridge/RESULT
condition:
condition: template
value_template: '{{trigger.payload_json.RfReceived.Data | length > 0}}'
action:
- service: python_script.rfbridge_demux
data_template:
payload: '{{trigger.payload_json.RfReceived.Data}}'
I don’t have that data because the effort to create the test environment requires more effort than I’m willing to invest. Plus a first-order approximation of the performance difference easily shows Strategy #2 requires only two processing steps for each received payload whereas Strategy #1 has as many processing steps as there are sensors.
I explained the two strategies to someone else using the example of a conveyor belt in a distribution center. In strategy #2, packages are shuttled down the belt to a dispatcher who examines the address on each box and forwards it one of several waiting trucks. Each truck is destined to a specific city.
In strategy#1, packages are shuttled down the belt where all the truck drivers inspect each package’s address and keep the ones destined for their city.
If you only have two sensors then strategy 1 is fine.
Just got some door sensors and followed this and had them setup up pretty quickly.
Thanks very much, great work.
I have 11 sensors in use on the bridge. I’ll try Strategy 1 anyway then for my own interest, and note the CPU load when I activate a sensor pre and post. If it doesn’t change at all then I’ve done it the easy way I reckon.
ESPhome has thankfully obsoleted MQTT for all but one of eight devices I had used MQTT on (which is the Sonoff bridge). When a good solution exists for that device (not bypassing the RF decoder) then no more MQTT for me and ‘hallelujah’ that will be !
All 11 of the Strategy 1’s types are done, and have done the job, no warnings.
CPU still at 1%, and I guess this won’t create any more IP network traffic as the extra work load is internal to the HA server.
Thanks heaps for your work on this BTW, I know you did it much for yourself, but you could have sat back and not shared and supported it. So well done on the best and probably last solution for guys like me who just want to smash their heads on the table when they come up against these tedious but tricky issues time and time again.
Thanks again.
Unless you have an ancient CPU, you’re not going to observe the performance difference by monitoring CPU load.
No. I don’t even own a Sonoff RF Bridge.
I did this for the community because of the ‘No matching payload’ error message many were receiving due to the way they were configuring their sensors.
To each his own. For my purposes, I prefer to have devices and systems communicate via a common protocol (MQTT) as opposed to being tied to a specific one.
I’m trying to convert from strategy 1 to strategy 2 as my 433 MHz units are increasing in numbers.
I would very much like to use the lovelase GUI as much as possible, so how do I enter a data_template instead of just data?
So far I’ve just written it directly in the automations.yaml, but if I view it in the automations editor, it kind of barfs on it 
The Automation Editor doesn’t offer the ability to define a data_template.
https://community.home-assistant.io/search?q=automation%20editor%20data_template
I use Microsoft Visual Code for creating automations and all configurations.