Sonoff RF Bridge. Strategies for receiving data

dave122 · October 31, 2020, 2:53am

Can the Sonoff RFBridge send and receive 433mhz or only send?

123 · October 31, 2020, 3:50am

This question is off-topic. The answer is here (both). If wish to discuss its capabilities, please start a separate thread. Thank you for your cooperation.

dave122 · October 31, 2020, 5:37am

Thank you and my apologies.

Marcel900 · November 2, 2020, 2:35pm

Hello,

I have a Sonoff Bridge 433 MHz (Tasmota / Portisch) running via MQTT on the HA. I want to use it to switch my shutters. If I set option RfRaw 166 I get the following code:

tele / tasmota_C3B1F5 / RESULT = {“Time”: “2020-11-02T09: 15: 30”, “RfRaw”: {“Data”: “AAA606012CFF86713355”}}

How can I send that now? If I copy it into the command line, nothing happens.

If I set the RfRaw 177 option, I unfortunately don’t receive anything …

I have already received several other codes with the RfRaw 177 option and have also converted them, so they can be switched with Home Assistant without any problems.

I hope you can help me…

123 · November 2, 2020, 2:43pm

Which one of the two strategies that I have presented are you using to receive the data from tele/tasmota_C3B1F5/RESULT?

Marcel900 · November 2, 2020, 2:56pm

Hello,

I go to the console in the Tasmota software and set the option RfRaw 166, then I send the commands up / down / stop with my old house control and receive the above-mentioned data.
Now I would like to integrate this data into HA.

I currently have the following command:

cover:

- platform: "mqtt"

name: "Rolladen HWR"

command_topic: "cmnd/tasmota_C3B1F5/Backlog"

payload_open: "RfRaw AAA420F80110033001232355; RfRaw 0"

payload_close: "RfRaw AAA606012CFF86711155; RfRaw 0"

payload_stop: "RfRaw AAA606012CFF86715555; RfRaw 0"

But unfortunately it doesn’t work !!!

123 · November 2, 2020, 3:00pm

This entire topic is about the two strategies I presented to receive data (see the first post). It is not a general topic for configuration problems with Tasmota software. Please create a separate topic to discuss it. Thank you.

ernt · November 3, 2020, 12:29pm

This is great, thanks for sharing! I also added a IR tx/rx to my bridge and trying to make the second strategy to work when receiving both types of payload, RfReceived.Data and IrReceived.Data. But I am struggling to do this… is there a way to use a OR condition in the service data field of the automation so I could pass the data from both payload types to the script?

123 · November 3, 2020, 2:40pm

If you mean the payload can contain RfReceived.Data or IrReceived.Data then try this:

- alias: 'rfbridge_demultiplexer'
  trigger:
  - platform: mqtt
    topic: tele/RF_Bridge/RESULT
  action:
  - service: python_script.rfbridge_demux
    data_template:
      payload: >
        {{ trigger.payload_json.IrReceived.Data 
            if trigger.payload_json.IrReceived is defined
            else trigger.payload_json.RfReceived.Data }}

ernt · November 3, 2020, 3:05pm

Thank you so much, this is exactly what I was looking for!

ernt · November 11, 2020, 10:10pm

Off topic, sorry.

123 · November 11, 2020, 10:37pm

Your question is about how to interpret battery levels and is not what this topic is all about. Please create a separate topic. Thank you.

ashscott · November 13, 2020, 12:44pm

Hi Taras.

I can hardly believe that I’ve been using this since May 19, without issue. Such an excellent contribution to HA.

Are we any nearer to understanding the issue with 0.117? I’m itching to upgrade but the demux is too valuable to me to risk it breaking.

francisp · November 13, 2020, 4:17pm

I’m on 0.117.6, and the demux still works flawless ?

123 · November 13, 2020, 5:05pm

Glad to hear it.

I have no idea why some users are experiencing unusual behavior with python 3.9. Given that Home Assistant is not yet using version 3.9, I have not invested much time in investigating the issue.

What I have done is explore how to incorporate the recent automation enhancements to eliminate the need for a python_script. In other words, the goal is to create a single “rfbridge_demultiplexer” automation that operates without the use of the python_script integration.

Based on a few tests, I believe this achieves the goal:

- alias: 'rfbridge_demultiplexer'
  mode: parallel
  variables:
    data: { '2C8D0A':['sensor1','ON','true'],
            '2C8D0E':['sensor1','OFF','true'],
            'E5D30E':['sensor2','ON','false'],
            '30D8A0':['sensor3','ON','false'] }
  trigger:
  - platform: mqtt
    topic: tele/RF_Bridge/RESULT
  condition: '{{ trigger.payload_json is defined }}'
  action:
  - choose:
    - conditions: '{{ trigger.payload_json.RfReceived.Data in data.keys() }}'
      sequence:
      - service: mqtt.publish
        data:
          topic: 'home/{{ data[trigger.payload_json.RfReceived.Data][0] }}'
          payload: '{{ data[trigger.payload_json.RfReceived.Data][1] }}'
          qos: 0
          retain: '{{ data[trigger.payload_json.RfReceived.Data][2] }}'
    default:
    - service: mqtt.publish
      data:
        topic: 'home/unknown'
        payload: '{{ trigger.payload_json.RfReceived.Data }}'
        qos: 0
        retain: false
    - service: persistent_notification.create
      data:
        title: '<rfbridge_demux> Unknown RF code: {{ trigger.payload_json.RfReceived.Data }}'
        message: '{{ now().timestamp()|timestamp_local() }}'

It was successfully tested with 0.117.5 with the default setting (true) for the legacy_templates option.

If at least two other people confirm it works for them, I will amend this thread’s first post and recommend using this automation (and deprecate the references to use a python_script).

EDIT 1

Added a Template Condition to reject received payloads that are not in JSON format.

EDIT 2

Inspired by Sag’s post below, added mode: queued

EDIT 3

Changed to mode: parallel based on Sag’s post below.

Sag · November 14, 2020, 12:09pm

Hi Taras,

Thanks indeed for your work. We really appreciate it.
Some of us use Espurna firmware on our RF Bridges. It works flawlessly. In spite Espurna can publish JSON messages, integration with Home Assistant is done using “MQTT platform”, not “MQTT-JSON platform”. Each message is sent to it’s own topic.
Your python script is working great with Espurna using a light “rfbridge_demultiplexer” automation adaptation. Ie:

- id: '1586546570081'
  alias: RF Topic MQTT desmultiplexación
  description: Distribuye MQTT recibidos de Espurna RF Bridge en varios topics
  trigger:
  - platform: mqtt
    topic: home/Sonoff-RF-Bridge-1/rfin
  - platform: mqtt
    topic: home/Sonoff-RF-Bridge-2/rfin
  condition: []
  action:
  - data_template:
      payload: '{{ trigger.payload[-6:] }}'
    service: python_script.rfbridge_demux
  mode: queued
  max: 10

What do you think would be our best adaptation to your new script?

123 · November 14, 2020, 2:04pm

I believe you should change the condition so that it ensures the length of the payload is greater than a minimum amount (otherwise the slice [-6:] may fail).

Other than that, I think wherever you see trigger.payload_json.RfReceived.Data used in the automation, it should be replaced by trigger.payload[-6:].

BTW, your usage of mode: queued is a good precaution so I’ve added it to my example (above).

juan11perez · November 14, 2020, 4:01pm

@123

Taras, im now using your automation and confirm it works well for me.

Sag · November 14, 2020, 5:41pm

Do you mean something like that?

condition: ‘{{ trigger.payload | string | length > 5 }}’

Edit:

IMHO this automation system is less responsive than python script. I tried quite a lot and when some sensors are activated in a short space of time, only first or two first really do. I changed queued mode to parallel and achieved better results.

If someone use Espurna software on RF bridge (not JSON), maybe my working automation could be useful:

- id: '1586546570081'
  alias: RF Topic MQTT desmultiplexación
  description: Distribuye MQTT recibidos de Espurna RF Bridge en varios topics
  trigger:
  - platform: mqtt
    topic: home/Sonoff-RF-Bridge-1/rfin
  - platform: mqtt
    topic: home/Sonoff-RF-Bridge-2/rfin
  condition:
  - condition: template
    value_template: '{{ trigger.payload | string | length > 5 }}'
  action:
  - choose:
    - conditions:
      - condition: template
        value_template: '{{ trigger.payload[-6:] in data.keys() }}'
      sequence:
      - service: mqtt.publish
        data:
          topic: home/{{ data[trigger.payload[-6:]][0] }}
          payload: '{{ data[trigger.payload[-6:]][1] }}'
          qos: 0
          retain: '{{ data[trigger.payload[-6:]][2] }}'
    default:
    - service: mqtt.publish
      data:
        topic: home/unknown
        payload: '{{ trigger.payload }}'
        qos: 0
        retain: false
    - service: persistent_notification.create
      data:
        title: '<rfbridge_demux> Unknown RF code: {{ trigger.payload }}'
        message: '{{ now().timestamp()|timestamp_local() }}'
  variables:
    data:
      234567:
      - Puerta_entrada
      - 'ON'
      - 'true'
      123456:
      - Puerta_entrada
      - 'OFF'
      - 'true'
      987654:
      - Batt_Puerta_entrada
      - 'ON'
      - 'true'
      456789:
      - PIR_hacia_entrada
      - 'ON'
      - 'false'
      285683:
      - PIR_hacia_cocina
      - 'ON'
      - 'false'
      194628:
      - PIR_pasillo
      - 'ON'
      - 'false'
      394555:
      - Detector_humo_cocina
      - 'ON'
      - 'false'
      297634:
      - Detector_humo_salon
      - 'ON'
      - 'false'
      671299:
      - Detector_humo_despacho
      - 'ON'
      - 'false'
      999988:
      - Detector_humo_dormitorio
      - 'ON'
      - 'false'
  mode: parallel
  max: 10

123 · November 16, 2020, 4:07pm

If just one more person confirms the new demultiplexer automation works, I’ll proceed to update the first post.