Perfect, thank you!
edit: now received a lot of message like this: <rfbridge_demux> Received unknown RF command: 347343
That means exactly what it says, it received an unknown RF command: it received 347343 and couldnāt find it in the dictionary you defined.
Sorry to hijack this thread but I am considering purchasing a Sonoff RF Bridge and I am curious if this is still a recommended option for things like motion sensors and door / window switches.
No need to be sorry, just start a new topic. This one is dedicated to strategies for receiving multiplexed data, like from a Sonoff RF bridge (but applicable to any device that multiplexes data via one MQTT topic). If you want to discuss the pros and cons of the actual device, a new topic is preferable.
1 Like
Great. Excellent solution. Thanks
Hi, I tested your config and works well, thanks you
I donĀ“t know how implement this with more than one sonoff rf bridge
Thanks!
To use more than one bridge you give them all the same topic in mqtt config.
The closest one will pick up the signal without duplication problems.
I have 3 set up like this with this solution since it was released and works well.
Hmm, I have 3 bridges as well but I have separate topics for each. I was concerned that the buttons I have located throughout the property would be detected as two pushes if I configured them your way. As most of them toggle something I expected that this would translate as on then off as two or more MQTT messages were received. Does that not happen?
I only use the bridge for sensors. and in my case itās not a problem at all.
I suggest you try it.
You would think I would have more time to play with HA, stuck at home, but it just means 12 hr work days. Thanks for the suggestion, will try on the weekend.
My two bridges have different topics, but they use the same demux-script.
thanks you!
1 Like
Hay I gave mine the same topic I have 3 of then in my house it make coding a bit smaller
Glad itās working for you!
I only have the one bridge, but if they all point to the same output topic as others have noted, it should just work, Iād think.
Alternatively, with different bridge topics, doing something like this for each of your bridges should work:
self.mqtt_bridge1_topic = "tele/tasmota_rf_bridge1"
self.mqtt_bridge2_topic = "tele/tasmota_rf_bridge2"
self.bridge1_name = "rf_bridge1"
self.bridge2_name = "rf_bridge2"
# create discovery topic for tasmota sonoff rf bridge
self.call_service("mqtt/publish", topic='homeassistant/sensor/' + self.bridge1_name + '/config', payload='{"name": "' + self.bridge1_name + '", "state_topic": "' + self.mqtt_bridge1_topic + '/LWT", "json_attributes_topic": "' + self.mqtt_bridge1_topic + '/RESULT"}', retain=True)
self.call_service("mqtt/publish", topic='homeassistant/sensor/' + self.bridge2_name + '/config', payload='{"name": "' + self.bridge2_name + '", "state_topic": "' + self.mqtt_bridge2_topic + '/LWT", "json_attributes_topic": "' + self.mqtt_bridge2_topic + '/RESULT"}', retain=True)
# Listen for each bridge Sensor
self.listen_state(self.on_code_received, "sensor." + self.bridge1_name, attribute="all" )
self.listen_state(self.on_code_received, "sensor." + self.bridge2_name, attribute="all" )
The code already rejects inputs with the same time, but Iām not sure if the time will be slightly off between the various bridges or not. If not, adding a bit more smarts there wouldnāt be too tough.
ok, thanks. I will try. Now I am testing the other config.
I found your strategy 2 very interesting so based on your work I created a version that use native Home Assistant Scripts instead of python_script.
The automation part is almost the same as yours. You need to put this code in automations.yaml or in your automation sectiont:
- alias: rfbridge_demultiplexer
trigger:
- platform: mqtt
topic: tele/sonoffrf/RESULT
condition:
- condition: template
value_template: "{{ (trigger.payload_json is defined) and (trigger.payload_json.RfReceived is defined) and (trigger.payload_json.RfReceived.Data is defined) }}"
action:
- service: script.rf_mqtt_publish
data_template:
code: "{{ trigger.payload_json.RfReceived.Data }}"
topic_base: 'home/'
list: >-
{{ '{ "AAAAAA": {"topic": "sensor1", "payload": "ON", "retain": true}
,"BBBBBB": {"topic": "sensor1", "payload": "OFF", "retain": true}
,"CCCCCC": {"topic": "sensor2", "payload": "ON", "retain": false}
,"DDDDDD": {"topic": "sensor3", "payload": "ON", "retain": false}
}' }}
Instead of calling your python script, it calls a native Home Assistant script name rf_mqtt_publish and use fields to pass the configuration. Here is the script part to put in scripts.yaml or in your script section:
rf_mqtt_publish:
alias: rf_mqtt_publish
fields: {"code":{},"topic_base":{},"list":{}}
sequence:
- service: mqtt.publish
data_template:
topic: >-
{%- set l = list | from_json -%}
{{ topic_base~l[code].topic if ((l[code] is defined) and (l[code].topic is defined)) else topic_base~'unknown' }}
payload: >-
{%- set l = list | from_json -%}
{{ l[code].payload if ((l[code] is defined) and (l[code].payload is defined)) else code }}
retain: >-
{%- set l = list | from_json -%}
{{ l[code].retain if ((l[code] is defined) and (l[code].retain is defined)) else false }}
qos: 0
Then you can define binary sensors exactly like yours:
binary_sensor:
- platform: mqtt
name: 'Bathroom Door'
state_topic: 'home/sensor1'
device_class: door
- platform: mqtt
name: 'Hallway Motion'
state_topic: 'home/sensor2'
off_delay: 5
device_class: motion
Of course you need to adapt this code with your own topics and configuration.
1 Like
Thanks for sharing.
Itās always great to have options.
Could you tell us what is the advantage of your approach?
I find python_script approach great comparing to script because a) youāre less limited and can write more compact and readable code and b) there is no need to reload anything if you change it, itās picked up automatically.
Thank you for posting your version.
I wish to clarify the use of the qualifying adjective ānativeā. A python_script is as ānativeā to Home Assistant as a script. In fact, the python_script integration offers the advantage that if you modify a python_script, unlike a script, you donāt have to use āReload Scriptsā (one could argue that makes it āmore nativeā).
Nevertheless, itās good to have alternatives and, once again, that you for taking the time to share it here.
1 Like
Like you said, it is just to give people another option. There is also an educative part in this example to show people how to use script and fields.
a) I know, but for some people who donāt program in python, it may be easier to modify a Home Assistant script to meet there needs than a python script. Also the python script setup may be confusing for some people.
b) Usually when you change you RF configuration you usually need also to create a binary sensor or something else in configuration file. So you will have to restart your Home Assistant server anyway. Also you can reload automation and script configuration without restarting the Home Assistant server.
One advantage of my approach is to keep the configuration simple with what exists by default in Home Assistant without the need to create the python_script configuration and sub-directory.
I agree with you that native may not be the appropriate term to use. Maybe something like default configuration file may be more appropriate.
The main goal of my approach was to do something without adding a configuration setup that is not in the default setup (i.e. python_script). I agree that your approach is more native.