It’s described in the first post. There’s an example of the python_script containing a dictionary and its format explained as follows:
Given that the explanation wasn’t clear to you, can you suggest how I can improve it?
Thank you, I don’t know what I was thinking. I appreciate the help.
Thank you! it makes sense now. It’s clear as day, no need to improve it, I just missed this part.
1 Like
Hi; I am using Strategy 2.
Home Assistant 2022.10.5 Supervisor 2022.10.2 Operating System 9.3 Frontend 20221010.0 - latest
running haos_generic-aarch64-9.3.qcow2 virtual machine under ubuntu-aarch64 (Cheap TV box). Host mqtt.
Newly flashed tasmota RF bridge, including RF. Attempting to integrate two four button RF pendants.
getting this error (have spent a week debugging, researching and reading this thread for clues), to no avail:
“Invalid config for [automation]: Unable to determine action @ data[‘action’][1]. Got None Unable to determine action @ data[‘action’][2]. Got None Unable to determine action @ data[‘action’][3]. Got None Unable to determine action @ data[‘action’][4]. Got None. (See /config/configuration.yaml, line 19).”
I suspect hass version has changed something.
configuration.yaml: automation: “!include_dir_merge_list automations” plus “python_script:”
python_scripts/rfbridge_demux.py (codes are correct from tasmota console, XX’s replace actual codes):
# From: https://community.home-assistant.io/t/sonoff-rf-bridge-strategies-for-receiving-data/108181
# 433Mhz 4 button pendants. Buttons on both pendants maps to same event
d = { 'XXCE21':['button_a','ON','false'],
'XXF161':['button_a','ON','false'],
'XXCE22':['button_b','ON','false'],
'XXF162':['button_b','ON','false'],
'XXCE28':['button_c','ON','false'],
'XXF168':['button_c','ON','false'],
'XXCE24':['button_d','ON','false'],
'XXF164':['button_d','ON','false']
}
p = str(data.get('payload'))
if p is not None:
if p in d.keys():
service_data = {'topic':'home/{}'.format(d[p][0]), 'payload':'{}'.format(d[p][1]), 'qos':0, 'retain':'{}'.format(d[p][2])}
logger.info('<rfbridge_demux> Received RF command: {}'.format(p))
else:
service_data = {'topic':'home/unknown', 'payload':'{}'.format(p), 'qos':0, 'retain':'false'}
logger.warning('<rfbridge_demux> Received unknown RF command: {}'.format(p))
hass.services.call('mqtt', 'publish', service_data, False)
automations/pendant.yaml:
- id: rfbridge_demultiplexer
alias: 'rfbridge_demultiplexer'
trigger:
- platform: mqtt
topic: tele/sonoff-rfbridge-1/RESULT
action:
- service: python_script.rfbridge_demux
data_template:
payload: '{{trigger.payload_json.RfReceived.Data}}'
- platform: mqtt
name: 'Button_A'
state_topic: 'home/button_a'
off_delay: 1
- platform: mqtt
name: 'Button1_B'
state_topic: 'home/button_b'
off_delay: 1
- platform: mqtt
name: 'Button_C'
state_topic: 'home/button_c'
off_delay: 1
- platform: mqtt
name: 'Button_D'
state_topic: 'home/button_d'
off_delay: 1
I suspect the issue is in the Button_X definitions which are somehow incorrect.
Need some more experienced eyes on this…
Thanks; Bill
Your suspicion is correct; those definitions don’t belong in the rfbridge_demultiplexer automation so that’s why you got the following error message:
Invalid config for [automation]:
Refer to the MQTT Button documentation.
@123, do you have two or more RF Bridge devices? I ask because I had two black ones (original version) that I used for a long time, maybe more than a year. One of them died a few months ago so I bought an RF Bridge R2 (which is white).
I installed it in my network and I found that it periodically reported slightly incorrect messages from some of my sensors. Some of the incorrect bits lined up just right to be other entities (mostly the battery-low entities). So, it manifested as a few of the sensors complaining that their batteries were low when they weren’t actually low.
As you might imagine this took me a while to figure out. I spent the first couple of months changing batteries until I realized that those were brand new. More sleuthing eventually exposed good and bad device tasmota logs:
From old device (good transmission):
12:47:06.917 MQT: tele/sonoff-bridge-a/RESULT = {"Time":"2022-09-30T12:47:06","RfReceived":{"Sync":14150,"Low":500,"High":1370,"Data":"30060A","RfKey":"None"}}
12:48:07.877 MQT: tele/sonoff-bridge-a/RESULT = {"Time":"2022-09-30T12:48:07","RfReceived":{"Sync":14140,"Low":500,"High":1370,"Data":"30060E","RfKey":"None"}}
17:00:54.535 MQT: tele/sonoff-bridge-a/RESULT = {"Time":"2022-09-30T17:00:54","RfReceived":{"Sync":14090,"Low":480,"High":1400,"Data":"5F2B0A","RfKey":"None"}}
17:00:59.258 MQT: tele/sonoff-bridge-a/RESULT = {"Time":"2022-09-30T17:00:59","RfReceived":{"Sync":14120,"Low":490,"High":1390,"Data":"5F2B0E","RfKey":"None"}}
19:33:49.525 MQT: tele/sonoff-bridge-a/RESULT = {"Time":"2022-09-30T19:33:49","RfReceived":{"Sync":14200,"Low":480,"High":1380,"Data":"332D0E","RfKey":"None"}}
19:47:16.243 MQT: tele/sonoff-bridge-a/RESULT = {"Time":"2022-09-30T19:47:16","RfReceived":{"Sync":14060,"Low":510,"High":1360,"Data":"30060A","RfKey":"None"}}
From new device (bad transmission):
12:47:07.533 MQT: tele/sonoff-bridge-b/RESULT = {"Time":"2022-09-30T12:47:07","RfReceived":{"Sync":27930,"Low":888,"High":2688,"Data":"30060A","RfKey":"None"}}
12:48:08.629 MQT: tele/sonoff-bridge-b/RESULT = {"Time":"2022-09-30T12:48:08","RfReceived":{"Sync":27930,"Low":894,"High":2686,"Data":"30060E","RfKey":"None"}}
17:00:55.022 MQT: tele/sonoff-bridge-b/RESULT = {"Time":"2022-09-30T17:00:55","RfReceived":{"Sync":26794,"Low":982,"High":2622,"Data":"572B08","RfKey":"None"}}
17:00:59.823 MQT: tele/sonoff-bridge-b/RESULT = {"Time":"2022-09-30T17:00:59","RfReceived":{"Sync":26268,"Low":952,"High":2650,"Data":"5F2B06","RfKey":"None"}}
19:33:50.923 MQT: tele/sonoff-bridge-b/RESULT = {"Time":"2022-09-30T19:33:50","RfReceived":{"Sync":26270,"Low":914,"High":2666,"Data":"33250A","RfKey":"None"}}
19:47:17.094 MQT: tele/sonoff-bridge-b/RESULT = {"Time":"2022-09-30T19:47:17","RfReceived":{"Sync":26104,"Low":894,"High":2688,"Data":"30060A","RfKey":"None"}}
I made a post about it here: Do I need two Sonoff RF Bridges? - #8 by SpikeyGG but there were no further responses. I’m left wondering: did I just get a “lemon” unit or is this something that other people are seeing too? I bought this R2 device from AliExpress and I contacted the vendor and they didn’t want to have anything to do with me, as I’d expect.
The funny thing is, I expected that the errors would be coming from the device that is further away from the sensors but it’s actually the “more centralized unit”!! It’s closer to all the sensors that it is reporting incorrectly! Anyway, at the moment, the device is unplugged so I’m running from a single RF Bridge but I did like the added redundancy so I’d like to get a replacement if I can avoid getting these erroneous transmissions.
I have none.
@ashscott, have you compared your 5 logs to see if any of them report slightly incorrect transmission? I just made this post and I’m trying to find others who use multiple Sonoff RF Bridges in their house. Are yours all black, all white (R2 version), or some black and some white? I’m wondering: did I just get a “lemon” unit or is this something that other people are seeing too?
Mine are all black and have been in and working without attention for about 3 years.
Very occasionally, when adding a new device, I will look at the console and notice the odd code being received but it just gets ignored by the demux.
They are all running Tasmota 10.1.0.
The referenced “MQTT Button” seems to be a virtual button, intended for dashboard / UI. I cannot believe the button definitions in this howto are incorrect. I just need to know where to put the button code (if in configurqation.yaml - config error) and, how to specify them correctly. It baffles me how many people report success and yet, literally following this HowTo fails for me.
Removing the Button_X definitions gets me this:
2022-11-23 12:45:00.506 DEBUG (MainThread) [homeassistant.components.mqtt.client] Received message on tele/sonoff-rfbridge-1/RESULT: b'{"Time":"2022-11-23T18:45:00","RfReceived":{"Sync":10400,"Low":340,"High":1030,"Data":"XXF161","RfKey":"None"}}'
2022-11-23 12:45:00.517 INFO (MainThread) [homeassistant.components.automation.rfbridge_demultiplexer] rfbridge_demultiplexer: Running automation actions
2022-11-23 12:45:00.518 INFO (MainThread) [homeassistant.components.automation.rfbridge_demultiplexer] rfbridge_demultiplexer: Executing step call service
2022-11-23 12:45:00.552 INFO (SyncWorker_2) [homeassistant.components.python_script] Executing rfbridge_demux.py: {'payload': 'XXF161'}
2022-11-23 12:45:00.553 INFO (SyncWorker_2) [homeassistant.components.python_script.rfbridge_demux.py] <rfbridge_demux> Received RF command: XXF161
2022-11-23 12:45:00.572 DEBUG (MainThread) [homeassistant.components.mqtt.client] Transmitting message on home/button_a: 'ON', mid: 52
So, at least I have home/button_x messages to use to control stuff. Clearly “more learning” required.
If by “How to” you mean the first post in this topic then you are mistaken.
The first post in this topic contains no information about configuring MQTT Buttons. The examples that it provides are for binary_sensors and they are not part of the rfbridge_demultiplexer automation; you have misinterpreted it.
Here’s an annotated screenshot of the information in the first post.
Yep; It is proper config of the binary sensor buttons that was baffling me: Where to put the button code? I think I need it for the “off_delay”, otherwise, once triggered, state will remain on from mqtt broker perspective (I think).
Looked into this further. It was MQTT Binary Sensor - Home Assistant that was required to “fix” this howto for buttons. As I suspected, HA evolution changed the required syntax (see link). Proper entries (in configuration.yaml) are:
# Pendant buttons via sonoff RF bridge
mqtt:
binary_sensor:
- name: 'Button_A'
state_topic: 'home/button_a'
off_delay: 1
- name: 'Button_B'
state_topic: 'home/button_b'
off_delay: 1
- name: 'Button_C'
state_topic: 'home/button_c'
off_delay: 1
- name: 'Button_D'
state_topic: 'home/button_d'
off_delay: 1
Developer Tools / States now show buttons:
Not a big issue: until button pushed, state remains “unknown” - from startup. I have seen a few ways to address this.
Perhaps update this HowTo (buttons) to reflect current HA code?
There’s no such thing as “binary sensor buttons” in Home Assistant. Button and Binary Sensor are two completely different integrations:
This is a “howto” about receiving multiplexed data, like the kind transmitted by a Sonoff RF Bridge (but not limited to it) . The examples contain the configuration of MQTT Binary Sensors (not buttons) as they were done when this topic was created 3.5 years ago.
A lot has changed in Home Assistant since then. Most recently, the configuration of MQTT-based entities, like sensor, binary_sensor, button, light, etc, are consolidated under an mqtt key. It’s left to the user to stay on top of changes. After all, the focus of this topic isn’t about configuring MQTT Binary Sensors, it’s about demultiplexing multiplexed data.
Even if I had updated the examples, with the latest style of MQTT Binary Sensor configuration, it would not have prevented the error you initially encountered because that was due to you misreading the instructions and mistakenly combining the rfbridge_demultiplexer automation with the binary_sensor configuration.
@Taras Thanks for your help. Don’t get me wrong, I was not criticizing. Demux is excellent. The net is full of obsolete, confusing info. I think making this HowTo current / complete is a good thing and, if / when I get around to implementing MQTT button (as opposed to binary sensor), will post code here.
Enhancement to Strategy 2
I have made a small change to allow the identification of codes that are a close match to known existing ones. Most cheap Chinese sensors aren’t documented and I never know if I have correctly identified the code for the battery warnings.
So here is my version that checks for the code having the same first or last 5 characters as an existing one.
p = str(data.get('payload'))
service_data = ''
if p in d.keys():
service_data = {'topic':'433/{}'.format(d[p][0]), 'payload':'{}'.format(d[p][1]), 'qos':0, 'retain':'{}'.format(d[p][2])}
else:
for string in d:
if string[:5] == p[:5] or string[-5:] == p[-5:]:
matching_p = string
service_data = {'topic':'433/Close_Match_Code', 'payload':'{}'.format(d[string][0]) + ' - ' + p, 'qos':0, 'retain':'false'}
break
if service_data == '':
service_data = {'topic':'433/Unknown_RF_Code', 'payload':p, 'qos':0, 'retain':'false'}
hass.services.call('mqtt', 'publish', service_data, False)
I am no Python programmer so by all means, please make this code ‘nicer’.
I adapted this a bit. I was annoyed that on HA reboot the sensors say “Unknown”. I use an off_delay for my sensors (no explicit “off” RF signal). Fortunately my sensors continuously send updates (Govee Water Sensors) if they’re wet, so I was able to make some assumptions setting an initial state.
Thanks!!!
A brilliant solution to my HA restarts losing the state of the window/door sensors for my alarm!
Well, my battery guess was wrong. I had a bunch of dead batteries, and HA never showed them as bad. Any options?
I believe that this Sonoff RF Bridge Easy Setup with Tasmota Rules and the trigBoard - YouTube is a rather straightforward implementation that also deserves consideration. This abstraction allows you to have separate MQTT topics and values for each of the received RF codes, all managed by some rules on the RF Bridge.
The command publish2 inside the rules posts a “retained” value (“open” or “close”) to the sensor-specific custom topic. That way, even after restarting Home Assistant, it will use the previous value for each sensor that had a corresponding rule.
rule1
ON RfReceived#Data=B9A30A DO publish2 stat/rf-bridge/kitchen_door open ENDON
ON RfReceived#Data=B9A30E DO publish2 stat/rf-bridge/kitchen_door close ENDON
rule2
ON RfReceived#Data=B33FEE DO publish2 stat/placeholderexample/back_door open ENDON
ON RfReceived#Data=B33FEA DO publish2 stat/placeholderexample/back_door close ENDON
In Home Assistant configuration.yaml, you can then create binary sensors and subscribe to the sensor-specific topic that you chose in the rules above (on the RF Bridge). You can replace the topic “stat/rf-bridge/kitchen_door” with whatever you prefer, as long as you make sure that you use that same topic in both the rule on the RF bridge and the configuration.yaml!
mqtt:
binary_sensor:
- name: "Front door"
state_topic: "stat/rf-bridge/kitchen_door"
unique_id: "kitchen-door"
payload_on: "open"
payload_off: "close"
device_class: door
qos: 1
binary_sensor:
- name: "Back door"
state_topic: "stat/placeholderexample/back_door"
unique_id: "back-door"
payload_on: "open"
payload_off: "close"
device_class: door
qos: 1