Sonoff RF Bridge. Strategies for receiving data

Hi,

I have problem with my Sonoff motion sensor and RF bridge and this script and Home Assistant.
So if receive motion on the sensor the HA turn on one light. My problem is sometime not turning on the light.
In the sonoff bridge have a log which is receive the code but nothing happend only the second move turn the light on. Sometime need more move to turn on the light.

10:01:43.632 MQT: tele/sonoff_rf/RESULT = {"Time":"2021-08-04T10:01:43","RfReceived":{"Sync":11940,"Low":430,"High":1220,"Data":"F61C4E","RfKey":"None"}}
10:01:52.037 MQT: tele/sonoff_rf/RESULT = {"Time":"2021-08-04T10:01:52","RfReceived":{"Sync":12530,"Low":390,"High":1180,"Data":"F61C4E","RfKey":"None"}}

why do this and how to fix it? Very annoying and useless. :frowning:
The connection not poor so that is not problem.

You can start by stating which of the two strategies you are using. If itā€™s strategy 1, post the relevant configuration.

If you are using strategy 2, post the contents of your python_scriptā€™s dictionary. Point out which entry in the dictionary represents the RF codes used to control the light. If you have made any significant modifications to the python_script or the demultiplexer automation, post them as well.

I used strategy 2
The second code what is my motion sensor:

d = { '2D530A':['boltajto','ON','true'],
      'F61C4E':['pincemozgas','ON','false'],
      '30E10A':['konyhaablak','ON','true'],
      '30E10E':['konyhaablak','OFF','true'],
      '2E180A':['zuhanyablak','ON','true'],
      '2E180E':['zuhanyablak','OFF','true']
      
    }

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

here is my automation:

alias: rfbridge_demultiplexer RF1
trigger:
  - platform: mqtt
    topic: tele/sonoff_rf/RESULT
action:
  - service: python_script.rfbridge_demux
    data_template:
      payload: '{{trigger.payload_json.RfReceived.Data}}'
mode: single

Please post the configuration for the MQTT Binary Sensor representing the motion sensor.

Please post the automation that is responsible for monitoring the motion sensor and the light that you said ā€œsometime not turning on the lightā€.

No problem here it is:

- platform: mqtt
  name: 'Pince mozgas'
  state_topic: 'home/pincemozgas'
  off_delay: 120
  device_class: motion
alias: Pince mozgƔsra lƔmpa felkapcsol
description: ''
trigger:
  - entity_id: binary_sensor.pince_mozgas
    from: 'off'
    platform: state
    to: 'on'
condition:
  - condition: device
    type: is_off
    device_id: 93df76251d4c41a799985a45550c2b29
    entity_id: light.ikeabulb2
    domain: light
  - condition: device
    device_id: 09d64a03227c415e9b24129c543a74fe
    domain: light
    entity_id: light.ikeabulb_light
    type: is_off
action:
  - brightness_pct: 100
    device_id: 09d64a03227c415e9b24129c543a74fe
    domain: light
    entity_id: light.ikeabulb_light
    type: turn_on
  - type: turn_on
    device_id: 93df76251d4c41a799985a45550c2b29
    entity_id: light.ikeabulb2
    domain: light
    brightness_pct: 100
mode: single

I donā€™t see anything wrong with the configuration of the MQTT Binary Sensor. Itā€™s set to on when F61C4E is detected and itā€™s set to off 2 minutes later (by expire_after).

You said the problem is that itā€™s used to control a light and sometimes the light fails to turn on. That may be due to a problem with the automation (however this thread is not for debugging general automations).

What I suggest is that you check the binary sensorā€™s history and confirm it always turns on when it should. If it turns on at the moment the light failed to turn on then the fault lies entirely with the automation (and possibly in its condition).

A post was split to a new topic: Sonoff Bridge Configuration

Hi @123
I recently figured out my 433mhz alarm panel also sends out codes if set to disarm, home, stay or sos. This happens if you touch them on the panel, or use the app, it will still do it. I now recorded these codes.

But iā€™m wondering how to express this in sensors. Currently it just works as motion detector, and of course i want it to show what the current state is. Should i use true for retain? Iā€™ll have to check how to use this with leak sensors and if there is a on or off.

Also, a disarm can change state to off by going to home, away or sos. And the same is ofcourse true for these other states. Do i define 3 extra OFF states for each code ?

'B9D672':['security_system_1_disarm','ON','false'],
'B9D674':['security_system_1_home','ON','false'],
'B9D671':['security_system_1_away','ON','false'],
'B9D678':['security_system_1_sos','ON','false']
    }

Appreciate your help. Already used strategy 2, many thanks.

PS maybe i need to use a different sensor class as well? Currently set to motion.
I will use alarm panel card to set this up properly and integrate but still would be cool to see what the current state is of a sensor between these 4.

Have you considered using the MQTT Alarm Control Panel integration to model your alarm panel?

1 Like

@123 Iā€™m considering it now :-). Not entirely sure what the difference is with the regular alarm panel.

For now i hooked up the regular alarm panel, and it changes status whenever a MQTT topic is received from the sonoff rf bridge so it sync up with the real alarm panel.

now i just need to do the other way around, i setup an automation to trigger on the alarm panel state and then publish a mqtt topic but so far itā€™s not working. must be doing something wrong still.

service: mqtt.publish
data:
  topic: cmd/tasmota_5AF452/CMD
  payload: B9D671

i donā€™t think the topic is correct, but i couldnā€™t find any information on what the syntax should be. I also used the home/security_system_1 topic as set by your python script.

the automation runs, i just donā€™t see any code receive on the tasmota console.

try:

  topic: cmnd/tasmota_5AF452/RfCode

Many thanks,
So that seemed to work. I used that topic and put in a payload of #B9D671

Me sending from homeassistant yet alarm doesnā€™t go into ARM.

13:04:21.839 CMD: cmnd/tasmota_5AF452/RfCode #B9D671
13:04:21.852 MQT: stat/tasmota_5AF452/RESULT = {"RfCode":"#B9D671"}

Me sending from app/physical remote or display and going into ARM.

{"Sync":12380,"Low":410,"High":1210,"Data":"B9D672","RfKey":"None"}}
13:05:35.770 MQT: tele/tasmota_5AF452/RESULT = {"Time":"2021-12-09T13:05:35","RfReceived":{"Sync":13170,"Low":430,"High":1220,"Data":"D8242C","RfKey":"None"}}

For some reason it doesnā€™t go into ARM even though i send the same code. Could it be that the code itā€™s sending is the announcement and not the command to put the alarm into arm? I donā€™t think thatā€™s the case however because if i use my cheap 433 remote that came with the alarm this is the only code it sends.

Maybe i need to do something with: RfSync, Rflow and RfHigh ?
ā€˜ā€™ā€™
RfCode Show last sent 24-bit user code
1..8388607 = send 24-bit user code
#1..#7FFFFF = send 24-bit hexadecimal user code using RfSync, RfLow and RfHigh timing
ā€˜ā€™ā€™

I tried mapping to a Rfkey but it says itā€™s learning, but then nothing happens when the learned key is sent (data is also 000000)

14:21:20.434 MQT: stat/tasmota_5AF452/RESULT = {"RfKey1":"Start learning"}
14:21:25.411 MQT: stat/tasmota_5AF452/RESULT = {"RfKey1":"Learned"}
14:21:25.795 MQT: tele/tasmota_5AF452/RESULT = {"Time":"2021-12-09T14:21:25","RfReceived":{"Sync":0,"Low":410,"High":1210,"Data":"000000","RfKey":"None"}}

I tried to use the backlog topic and add this as payload:
backlog rfsync 12370; rflow 410; rfhigh 1210; rfcode #B9D671

I tried adding this to the console:
backlog rfsync 12370; rflow 410; rfhigh 1210; rfcode #B9D671; rfkey1 4

It maps but when the code is sent still nothing happens

14:28:33.892 CMD: backlog rfsync 12370; rflow 410; rfhigh 1210; rfcode #B9D671; rfkey1 4
14:28:33.918 MQT: stat/tasmota_5AF452/RESULT = {"RfSync":12370}
14:28:34.141 MQT: stat/tasmota_5AF452/RESULT = {"RfLow":410}
14:28:34.391 MQT: stat/tasmota_5AF452/RESULT = {"RfHigh":1210}
14:28:34.647 MQT: stat/tasmota_5AF452/RESULT = {"RfCode":"#B9D671"}
14:28:34.890 MQT: stat/tasmota_5AF452/RESULT = {"RfKey1":"Saved"}
14:28:46.739 CMD: RFKey1
14:28:46.752 MQT: stat/tasmota_5AF452/RESULT = {"RfKey1":"Learned sent"}

Iā€™m going to move the sonoff bridge i have a feeling it needs line of sight. I had this issue before when still using ewe link.

update nope that didnā€™t work either. Itā€™s seeing all the RF codes but for some reason doesnā€™t learn any codes and subsequently also doesnā€™t do anything when posting them on the console.

Iā€™ve been running this very useful strategy for almost three years now and it works superbly with my 5 RF Bridge devices.

Iā€™m now moving to another hardware option for HA and not all of my RF devices are available in the front end.

My rfbridge_demux.py file is as below:

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'],
      'F9010A':['back_door','ON','true'],
      'F9010E':['back_door','OFF','true'],
      '91F60A':['gym_door','ON','true'],
      '91F60E':['gym_door','OFF','true'],
      '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'],#
      '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'],
      'D7159F':['gun_cabinet_door_battery','ON','false'],
      '2479EF':['catflap_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 = 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])}
  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)

All of the devices with a ā€˜#ā€™ at the end of the line are showing up - but no others.

The automation is as below:

- 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}}"

What could be the reason for this?

1 Like

End of what line? Do you mean these two devices?

garage_motion_2
south_central_pir_2

Or do you mean every device whose RF code ends with a decimal number (as opposed to a letter in a hex value)?

Thanks for the help, Taras.

I mean the ones in the file shown that I have marked with a ā€˜#ā€™ at the EoL to indicate which ones are showing up.

What I find odd is that they are all grouped in the middle.

I should add that both files are just straight copies from my current HA server where all are working fine.

Doh! :man_facepalming:

You appear to have more than one RF bridge. Is it possible that all of the tagged entities are handled by one (or two) specific bridge(s)?

:man_facepalming::man_facepalming::man_facepalming:

Itā€™s been a long day!

Turns out, they also have to be added to the binary_sensor.yaml!!! Who knew!!! :roll_eyes:

:man_facepalming::man_facepalming::man_facepalming:

I appreciate your time.

1 Like