Sonoff RF Bridge. Strategies for receiving data

Share your Projects!
434

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

435

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.

436

@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.

437

I have none.

438

@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?

439

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.

440

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.

441

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.

442

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.

Screenshot 2022-11-23 125617
Screenshot 2022-11-23 125617727×645 25.9 KB

443

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:

image
image962×254 15.5 KB

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?

444

There’s no such thing as “binary sensor buttons” in Home Assistant. Button and Binary Sensor are two completely different integrations:

  1. Binary Sensor
  2. Button

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.

445

@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.

446

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’.

447

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.

448

Thanks!!!
A brilliant solution to my HA restarts losing the state of the window/door sensors for my alarm!

449

Well, my battery guess was wrong. I had a bunch of dead batteries, and HA never showed them as bad. Any options?

450

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
451

Hi,
as far as I know, Tasmota doesn’t directly support user-configurable identifiers or aliases for individual connected sensors, through its web interface. The identification of individual sensors is usually based on the unique RF codes they transmit, and Tasmota doesn’t inherently provide a way to assign human-readable names or identifiers to each sensor.
So how did you manage to use the syntax stat/rf-bridge/kitchen_door in your rule?
I have a number of 433MHz door sensors and the only way I’ve found to distinguish between them is to parse the long hexadecimal string they send as part of the JSON object. This is utterly non-human friendly and I’d very much like to know how you managed to assign human readable names to RF devices?

452

Would it be possible for you to update your howto to use the latest HA features?

Regards

453

Like what exactly?