Sonoff RF Bridge. Strategies for receiving data

[ashscott (Ash)]

I’m missing something simple, I’m sure, and my talent is now exhausted.

I’ve been using the demux for ages with great success and have rebuilt my HA instance on a new machine.

And now none of my RF bridges messages are being seen by HA.

I can see the messages in MQTT Explorer and Mosquitto is working fine with other MQTT devices.

Here’s what I have and some examples of my binary sensor configs. None of this has been edited since migrating to the new machine.

- alias: 'rfbridge_demultiplexer'
  trigger:
  - platform: mqtt
    topic: tele/Garage_RF_Bridge/RESULT
  - platform: mqtt
    topic: tele/RF_bridge_west/RESULT
  - platform: mqtt
    topic: tele/RF_bridge_east/RESULT
  - platform: mqtt
    topic: tele/RF_bridge_stable/RESULT
  - platform: mqtt
    topic: tele/RF_bridge_1st_floor/RESULT
  action:
  - service: python_script.rfbridge_demux
    data_template:
      payload: '{{trigger.payload_json.RfReceived.Data}}'

d = { 'D3226E':['garage_motion','ON','false'],
      '51F65A':['telegraph_pole_garage','ON','false'],
      '119B0A':['garage_door','ON','true'],
      '119B0E':['garage_door','OFF','true'],
      '715FFF':['gym_motion','ON','false'],
      '9F150A':['garage_motion_2','ON','false'],
      '49732E':['courtyard_gates','ON','true'],
      '497327':['courtyard_gates','OFF','true'],
      '2479EE':['catflap','ON','true'],
      '2479E7':['catflap','OFF','true'],
      '85D80A':['oskaflap','ON','true'],
      '85D80E':['oskaflap','OFF','true'],
      'F9010A':['back_door','ON','true'],
      'F9010E':['back_door','OFF','true'],
      '91F60A':['gym_door','ON','true'],
      '91F60E':['gym_door','OFF','true'],
      # '545F10':['back_door_motion','ON','false'],
      '71BDEE':['front_door','ON','true'],
      '71BDE7':['front_door','OFF','true'],
      'C5790A':['fridge','ON','true'],
      'C5790E':['fridge','OFF','true'],
      'A68B23':['letterbox','ON','false'],
      '142186':['stable_motion','ON','false'],
      '54F65A':['north_east_pir','ON','false'],
      '45F64A':['north_central_pir','ON','false'],
      '4DF64A':['north_west_pir','ON','false'],
      '49F64A':['garage_north_pir','ON','false'],
      '59F65A':['pergola_pir','ON','false'],
      '6DF66A':['courtyard_pir','ON','false'],
      '61F66A':['south_central_pir','ON','false'],
      'AA0D0A':['south_central_pir_2','ON','false'],
      '850E0A':['south_east_pir','ON','false'],
      '780E0A':['firepit_pir','ON','false'],
      '32F63A':['carpark_pir','ON','false'],
      '64F66A':['driveway_1_pir','ON','false'],
      '42F64A':['driveway_2_pir','ON','false'],
      '545F10':['firepit_2_pir','ON','false'],
      '3EF63A':['garage_west_pir','ON','false'],
      '85E9EE':['gun_cabinet_door','ON','true'],
      '85E9E7':['gun_cabinet_door','OFF','true'],
      '54F65F':['north_east_pir_battery','ON','false'],
      '45F64F':['north_central_pir_battery','ON','false'],
      '4DF64F':['north_west_pir_battery','ON','false'],
      '49F64F':['garage_north_pir_battery','ON','false'],
      '59F65F':['pergola_pir_battery','ON','false'],
      '6DF66F':['courtyard_pir_battery','ON','false'],
      '61F66F':['south_central_pir_battery','ON','false'],
      'AA0D0F':['south_central_pir_2_battery','ON','false'],
      '850E0F':['south_east_pir_battery','ON','false'],
      '780E0F':['firepit_pir_battery','ON','false'],
      '32F63F':['carpark_pir_battery','ON','false'],
      '64F66F':['driveway_1_pir_battery','ON','false'],
      '42F64F':['driveway_2_pir_battery','ON','false'],
      '545F1F':['firepit_2_pir_battery','ON','false'],
      '3EF63F':['garage_west_pir_battery','ON','false'],
      '861B2F':['courtyard_gates_battery','ON','false'],
      '71BDEF':['front_door_battery','ON','false'],
      '85E9EF':['gun_cabinet_door_battery','ON','false'],
      '2479EF':['catflap_battery','ON','false'],
      '85D80F':['oksaflap_battery','ON','false'],
      'A74723':['awning_vibration','ON','false'],
      'A7472F':['awning_vibration_battery','ON','false'],
      '51F65F':['telegraph_pole_garage_battery','ON','false'],
      '9F150F':['garage_motion_2_battery','ON','false'],
      'C5790F':['fridge_battery','ON','false'],
      'D3226F':['garage_motion_battery','ON','false'],
      'F9010F':['back_door_battery','ON','false'],
      'A68B2F':['letterbox_battery','ON','false']
    }

p = 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])}
  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)

    - platform: mqtt
      name: 'Garage Door'
      state_topic: 'home/garage_door'
      device_class: Door

    - platform: mqtt
      name: 'Gym Door'
      state_topic: 'home/gym_door'
      device_class: Door

    - platform: mqtt
      name: 'Gym Motion'
      state_topic: 'home/gym_motion'
      off_delay: 3
      device_class: Motion

MQTT settings have been appropriately changed in the Tasmota configs.

I’d appreciate any advice on where to look to fix this.

[123 (Taras)]

@ashscott

rebuilt my HA instance on a new machine.

And now none of my RF bridges messages are being seen by HA.

I assume you have used MQTT Explorer to confirm that your RF bridges are publishing to their respective topics:

tele/Garage_RF_Bridge/RESULT
tele/RF_bridge_west/RESULT
tele/RF_bridge_east/RESULT
tele/RF_bridge_stable/RESULT
tele/RF_bridge_1st_floor/RESULT

I suggest you:

1. Use Developer Tools > States to confirm the state of automation.rfbridge_demultiplexer is on. Turn it on if is currently off.
2. Use Developer Tools > Services to confirm python_script.rfbridge_demux is an available service. If it’s not present, double-check that you have installed the python_script integration correctly.

[ashscott (Ash)]

@123

Use Developer Tools > Services to confirm python_script.rfbridge_demux is an available service. If it’s not present, double-check that you have installed the python_script integration correctly

I just knew it had to be something obvious that wasn’t obvious to me. Installing it now.

Thank you so much.

[123 (Taras)]

Yeah, that would’ve been an easy thing to overlook to do when you switched to a complete new machine.

---

EDIT

Thanks for mentioning that you had created a new machine. Had you left out that detail, it would’ve taken more time and effort to debug the problem.

[ashscott (Ash)]

All working now. Thanks again.

[lombardoalex (Alex L)]

Thanks!!! Works great and really easy to follow instructions.

[myle (StePhan McKillen (Other kiwi Here))]

added some more python to it

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])}
 else:
   bla_bla = "'{}':['-+-+-+-+','ON','true/false'],".format(p)
   b_sensor = "binary_sensors \n - platform: mqtt \n name: 'new  binary sensor Name'\n state_topic: 'home/-+-+-+-+' \n device_class: door \n off_delay: 1".format(p)
   hass.services.call('persistent_notification', 'create',{'message':'{} \n\n copy above code \n paste it into the rfbridge_demux.py \n \n {}'.format(bla_bla,b_sensor), 'title':'NEW RF CODE'})
   service_data = {'topic':'home/unknown', 'payload':'{}'.format(p), 'qos':0, 'retain':'false'}
 hass.services.call('mqtt', 'publish', service_data, False)

if does not know the RF code it create a notification for you
in right sh format so you can just copy/paste it.

hope it help someone

just had a BRAIN FART if you have a tasmota IR

and just change the topic and it payload

to the IR protocol

- alias: 'IR_Bridge Data'
  trigger:
  - platform: mqtt
    topic: tele/IR/RESULT
  action:
  - service: python_script.rfbridge_demux
    data_template:
      payload: '{{trigger.payload_json.IrReceived}}'

You can you use the same logic in python script

this is a IR code

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

I have found this tread and the python code from @123 karas amazing helpful. But while pointing it out to a YAML guru, he showed me this. I am using the python strategy #2 and don’t plan on changing, BUT if you what YAML code that will work for this, I think this will and won’t trigger the log spam. This appears to be the way HA is intended to work for things like this.

- platform: mqtt
  name: this_door
  state_topic: tele/RF_Bridge/RESULT
  value_template: >
    {%- if value_json['RfReceived'].Data is defined and value_json['RfReceived'].Data['E4180!'] is defined -%}
      {%- if value_json['RfReceived'].Data == 'E4180E' -%}
      ON
      {%- elif value_json['RfReceived'].Data == 'E4180A' -%}
      OFF
    {% endif %}
    {% else %}
      {{ states('binary_sensor.this_door') }}
    {% endif %}
  availability_topic: "tele//RF_Bridge/LWT"
  payload_available: "Online"
  payload_not_available: "Offline"
  device_class: door
  qos: 1

It specifically looks for your code base, the common digits in the data that are the same and this can be used as the device identifier. If it doesn’t see it, it just sends back the current state. This should not trigger the warnings.
I did not plug this code in and test it, so if it needs touch-up let’s fix it, vut I took what he had and plugged in rfbridge stuff (instead of zigbee bridge stuff) and you see the principal. It gives the sensotr an out if the value revieved is not one of these.

[123 (Taras)]

Effectively, that’s Strategy #1 except the template takes the additional precaution of confirming the payload contains the variable value_json.RfReceived.Data prior to using it.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

The important part is that it verifies that the data recieved is from the sensor that you are looking for, IE the common part of the data that makes this code unique to this sensor. If it’s not, it just returns the current state, so HA will not care or see you as having multiple answers for the same (as opposed to ON/OFF)
The important part is that it verifies that the data received is from the sensor that you are looking for, IE the common part of the data that makes this code unique to this sensor. If it’s not, it just returns the current state, so HA will not care or see you as having multiple answers for the same (as opposed to ON/OFF)
@blakadder showed me this on stuff from his zigbee bridge, so I did the same here as an example

[123 (Taras)]

You may wish to review the first post in this thread because you literally described how “Strategy 1: value_template” operates. It works exactly as you just explained.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

Hmm. I guess so. Apparently 2 years ago when i read that I didn’t understand it, and loved strategy 2 so much I never gave another thought about it (until called on it). Oh, well, this is a little different, bit more efficient when not the device called as it aborts in 1 -if- instead of 2. It might help someone…

[123 (Taras)]

I’m glad to hear you now understand it uses the same approach presented in Strategy 1.

@Sir_Goodenough

bit more efficient when not the device called as it aborts in 1 -if- instead of 2

Have you tested it? I have and it’s not more efficient, in fact, it doesn’t even work.

Aside from this minor syntax error in the availability_topic

availability_topic: "tele//RF_Bridge/LWT"
                         ^

the real problem is this error in the second test:

and value_json['RfReceived'].Data['E4180!'] is defined
                                 ^^^^^^^^^^

in dot notation, the template expects a JSON path like this:

value_json.RfReceived.Data.E4180!

The payload’s JSON structure looks something like this:

{ "RfReceived":{ "Data":"E4180E" } }

However, the template’s JSON path expects the payload to look something like this:

{ "RfReceived":{ "Data":{"E4180!": "??" } } }

It will never have that structure so the second test in the template always evaluates to false. That means the result returned is always this:

{{ states('binary_sensor.this_door') }}

That template is also incorrect because of the reason explained in the first post. The state of a binary_sensor is lower case on or off and that’s what the states() function will report. However, it should be supplying upper case ON or OFF because that’s the default payload expected by an MQTT Binary Sensor.

payload_on
(string)(Optional)

The string that represents the on state. It will be compared to the message in the state_topic (see value_template for details)

Default value:

ON

---

EDIT
You can prove it to yourself using the Template Editor.

This reports NO because the payload’s JSON structure doesn’t match the template’s JSON path.

This reports YES because the payload’s JSON structure does match the template’s JSON path. However, a Sonoff RF Bridge doesn’t transmit its payload with that structure.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

Being an RF signal, when 2 broadcast in the same time the brodcast is garbles and the codes are not correct. I have a PIR and a door reed sensor very close, so often I open the door and the door movements triggers the PIR, so I will get garble…

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

@123 The more I learn the more I find I need to learn. Thanks, I will re-look at this. In the end, Strategy 2 is still awesome and I’m not planning on changing it in my system…

[lostprophet (Vlad Chiriloiu)]

Hi - awesome work.

I have an issue with the second setup - Demultiplexer. I have HA .112.1 in Docker. I have SonoffTasmota 8.3.1. From 6 sensors, 1 of them does not want to change the status.
.py script:

d = { '068B23':['balcony_door','ON','true'],
      '068B29':['balcony_door','OFF','true'],
      '058703':['livingroom_window','ON','true'],
      '058709':['livingroom_window','OFF','true'],
      '025683':['kids_window','ON','true'],
      '025689':['kids_window','OFF','true'],
      '01BD09':['kitchen_window','ON','true'],
      '058709':['kitchen_window','OFF','true'],
      '001B33':['bedroom_window','ON','true'],
      '001B39':['bedroom_window','OFF','true'],
      '012073':['balcony_window','ON','true'],
      '012079':['balcony_window','OFF','true'],
      'F2A0E6':['kitchen_presence','ON','false']
    }

p = 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])}
  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)

sensors:

  - platform: mqtt
    state_topic: 'home/balcony_door'
    name: "Balcony Door"
    device_class: door

  - platform: mqtt
    state_topic: 'home/livingroom_window'
    name: "Livingroom Window"
    device_class: window

automation:

  alias: rfbridge_demultiplexer
  description: ''
  trigger:
  - platform: mqtt
    topic: tele/sonoff/RESULT
  condition: []
  action:
  - service: python_script.rfbridge_demux
    data_template:
      payload: '{{trigger.payload_json.RfReceived.Data}}'

I cannot understand where the issue might be - the Livingroom Window does not change it’s status from open to close and vice-a-versa, although Sononff Console reports the codes - On and Off:

14:05:33 MQT: tele/sonoff/RESULT = {"Time":"2020-07-03T14:05:33","RfReceived":{"Sync":12880,"Low":450,"High":1250,"Data":"058703","RfKey":"None"}}
14:05:36 MQT: tele/sonoff/RESULT = {"Time":"2020-07-03T14:05:36","RfReceived":{"Sync":12900,"Low":450,"High":1240,"Data":"058709","RfKey":"None"}}

[123 (Taras)]

I don’t see anything wrong with the python_script, the dictionary entries for the window’s two states, or with the binary_sensor’s configuration. It works for the other sensors just not this one window sensor.

I suggest you use an MQTT client to subscribe to home/livingroom_window then open/close the window and confirm you receive payloads ON and OFF.

[lostprophet (Vlad Chiriloiu)]

@123 - I got it - it was my mistake - stupid mistake - I copy-pasted in the py code to make the entries - and duplicated one of the codes:

'058709':['livingroom_window','OFF','true'],

'058709':['kitchen_window','OFF','true'],

My mistake completly - got it working perfectly now. Sorry for the waisted time.

[Gerardo_Bastidas]

I think something has changed in the lastest version of home assistant. when i restart home assistant all my buttons and motion sensors are “unavailable”

Did not have this problem before 0.112

[123 (Taras)]

Others have reported the same issue but I have not experienced it after upgrading from 0.111 to 0.112.

I carried out experiments to detect behavioral difference between the two versions that might explain why some people are reporting binary_sensors have unavailable states on startup. I performed three experiments and none were able to detect a difference. Therefore the people who are experiencing the issue will have to determine the cause.

Questions for you:

1. Does it only affect binary_sensor or also sensor? Is any other type of entity affected?
2. Are the affected entities configured manually, as YAML definitions, or are they configured automatically via MQTT Discovery?
3. Do the affected devices publish their state as retained messages?