Cheap RF plugs + Sonoff Bridge

Configuration
1

So I’ve been controlling these cheap RF plugs with my RPi3 via @bruhautomation’s video which has worked well, but I’m getting my big girl pants on and graduating to running HA in Docker/Linux. I was kind of stumped how to integrate RF devices into HA until @DrZzs suggested the Sonoff RF Bridge. I now have the Bridge flashed with Tasmota and all is well. Well, sort of. I’m trying to integrate the Bridge into Home Assistant. I basically want the plugs to run as they do now (basically on and off by the use of slider switches). I keep digging around trying to find the answer to this, but I’m just getting frustrated because I don’t really speak MQTT (though I’m trying to learn). Basically, I’ve read this and THINK I sort of understand how this is working. I’m going to use the example given on the post mentioned:

binary_sensor:
  - platform: mqtt
    state_topic: "tele/RF_Bridge/RESULT"
    value_template: '{{value_json.RfReceived.Data}}'
    payload_on: '323234'
    payload_off: '323234off'
    name: "Button_A"
    alias: "Button_A"
    off_delay: 1

The state topic of the binary sensor is what is published from the bridge module when I press a button on my RF remote. The value template extracts the “Data” from this response that shows on the Tasmota console on the Bridge:

09:18:03 MQT: tele/sonoff/RESULT = {"RfReceived":{"Sync":13570,"Low":460,"High":1320,"Data":"515557","RfKey":"None"}}

When I turn on the remote, I can see the binary sensor turn on, then back off. So far so good. This is how home assistant can see what the RF remote is sending.

The second bit is the MQTT switch:

switch:
platform: mqtt
name: "Sonoff_Switch_01"
command_topic: "cmnd/sonoff_basic_1/power"
state_topic: "stat/sonoff_basic_1/POWER"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
retain: true

and lastly the automation that ties them together (if I’m understanding this right:

- id: change_switch_01_state
    alias: "Change switch 01 state"
    trigger:
      platform: state
      entity_id: binary_sensor.Button_A
      to: 'on'
    action:
     - service: switch.toggle
       data:
        entity_id: switch.Sonoff_Switch_01

With my information switched out of these examples, I’m running into a few problems. There are 4 buttons on my RF remote that seem to be giving the same codes off. This wasn’t an issue with the rpi_rf platform, as it gave me longer codes for both on and off. I’m wondering if the “Sync”,“Low”,“High” categories the Sonoff Bridge puts out can be included in the value template?

I’m also getting a strange thing in the logs:

2019-03-22 00:03:37 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: bed lamp with state_topic: tele/sonoff/RESULT

I’m not sure why I’m getting this warning, but I’m wondering if it’s just from the “off” bit.

2

Please post the configs of your binary_sensor, switch, and automation (as opposed to the configs from the example in the other thread).

Have you used an MQTT client to examine the payload and confirm all four buttons send the same Data? For example, you’ve confirmed they all send 515557off?

3

> Please post the configs of your binary_sensor, switch, and automation (as opposed to the configs from the example in the other thread).

Ok here’s mine:

binary_sensor:

  - platform: mqtt
    state_topic: "tele/sonoff/RESULT"
    value_template: '{{value_json.RfReceived.Data}}'
    payload_on: '515557'
    payload_off: '515557off'
    name: "bed lamp"
    off_delay: 1

and the switch:

  - platform: mqtt
    name: "Lamp button"
    command_topic: "cmnd/sonoff/power"
    state_topic: "stat/sonoff/POWER"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    retain: false

and the automation:

- id: '1553177104355'
  alias: turn switch on
  trigger:
  - entity_id: binary_sensor.bed_lamp
    from: 'off'
    platform: state
    to: 'on'
  condition:
    condition: state
    entity_id: switch.lamp_button
    state: 'off'
  action:
  - data:
      entity_id: switch.lamp_button
    service: switch.turn_on
4

> Have you used an MQTT client to examine the payload and confirm all four buttons send the same Data ? For example, you’ve confirmed they all send 515557off ?

This is from the Sonoff Bridge (which I looked on CloudMqtt websocket and it says the same:

41
where I hit the buttons 1 time (4 buttons, 1 off-1 on, 8 buttons all together).

5

Thanks, that helps me a lot!

I see a couple of interesting things in the log dump.

  • The topic stat/sonoff/RESULT can have this payload: {"Command":"Unknown"}. Your value_template is not going to like that at all! EDIT: There are 2 topics in the log! Should be using tele/sonoff/RESULT.
  • Unless I’m mistaken, you said you carried out the test by turning each button on then off. Yet Data is mostly 515557. Shouldn’t we see a few 515557off in there?
  • Any idea why the payload at 18:17:00 is unique and has Data as 511557?
  • What does Sync represent? It contains one of three values: 13550, 13560, and 13570. Anything here that can be used to identify the button?
6

Yeah, that’s puzzling to me because it would seem that’s referenced in the “state topic” and the “command topic” of the MQTT switch reference it. I’m not sure why it comes up with the {“Command”:“Unknown”}` result.

Well, that’s what the other post did, and @DrZzs did as well when there was no off command.

Honestly, I have no clue. I do wonder how the codes are deciphered by the Bridge vs how they are by the rpi_rf component. The codes there are unique and are longer. I’m wondering if in the json value template you could use a combination of Sync, Low, High, and Data categories.

7

OK, I watched Dr. Zzzs video and now understand the hack behind appending off to the value in payload_off (sensors don’t report their off state so a timed automation is used to reset the sensor’s state). I believe the timed automation is not required and its function can be easily duplicated by an MQTT Binary Sensor’s off_delay option (like you’ve done).

It definitely can. However, it’s design is complicated by the fact the payload can also be in the form of {"Command":"Unknown"}. I believe the template will need to first check if the payload contain Sync (or Data) before proceeding to extract values. Otherwise it is making an assumption they are always present and will fail when they aren’t. I need to improve my reading skills! That log shows two different topics!

  • stat/sonoff_bridge1/RESULT
  • tele/sonoff_bridge1/RESULT

The one you want to use is tele/sonoff_bridge1/RESULT.

I ask that you carry out a few more experiments to determine if Sync represents which button is pressed. Without something to differentiate them, all 4 buttons will appear as being just one button to Home Assistant.

8

For now, I’ll assume Sync identifies the button. The log shows 13550, 13560, 13570. I’ll assume there’s also a 13580. If I’m wrong then we can circle back and revise everything.

I offer you two different strategies.

The first one uses an automation to receive the payload and assign it to one of four separate MQTT topics (i.e. one unique topic per button). Four binary_sensors subscribe to their own unique topics.

This is a fairly efficient system because a single automation processes the received payload and each binary_sensor only processes its own topic (if and when it contains a payload).

Here’s the automation subscribed to the sonoff bridge and dividing the payload into one of four unique topics:

automation:

  - alias: 'sonoff bridge demultiplexer'
    hide_entity: true
    trigger:
      platform: mqtt
      topic: tele/sonoff/RESULT
    action:
      service: mqtt.publish
      data_template:
        topic: "home/button/{{trigger.payload_json.RfReceived.Sync|string }}"
        payload: 'ON'

here are the four binary_sensors subscribed to their own unique topic:

binary_sensor:

  - platform: mqtt
    name: "Button 1"
    state_topic: "home/button/13550"
    off_delay: 1

  - platform: mqtt
    name: "Button 2"
    state_topic: "home/button/13560"
    off_delay: 1

  - platform: mqtt
    name: "Button 3"
    state_topic: "home/button/13570"
    off_delay: 1

  - platform: mqtt
    name: "Button 4"
    state_topic: "home/button/13580"
    off_delay: 1

The second strategy uses a sensor to receive the payload. Four template binary_sensors check the sensor’s state and determine who it belongs to.

This is slightly less efficient than the first strategy. Every time the sensor receives a payload, all four binary_sensors process it.

here’s the sensor subscribed to the sonoff bridge:

sensor:

  - platform: mqtt
    name: "sonoff bridge"
    state_topic: tele/sonoff/RESULT
    value_template: '{{value_json.RfReceived.Sync}}'
    expire_after: 1

Here are the four template binary sensors all listening to the sensor’s state-changes:

binary_sensor:

  - platform: template
    sensors:
      button_1:
        friendly_name: "Button 1"
        value_template: '{{ is_state("sensor.sonoff_bridge", 13550) }}'
        delay_off: '00:00:01'

      button_2:
        friendly_name: "Button 2"
        value_template: '{{ is_state("sensor.sonoff_bridge", 13560) }}'
        delay_off: '00:00:01'

      button_3:
        friendly_name: "Button 3"
        value_template: '{{ is_state("sensor.sonoff_bridge", 13570) }}'
        delay_off: '00:00:01'

      button_4:
        friendly_name: "Button 4"
        value_template: '{{ is_state("sensor.sonoff_bridge", 13580) }}'
        delay_off: '00:00:01'
9

So I recorded 10 pushes per button (1 off, 1 on, x 4) and found NO distinct pattern. I was researching because the codes of the RPI-RF switch were longer and I was confused as to why. During my search, I found Espurna. Since I have two RF BRIDGE devices, I decided to try flashing one with Espurna.

It couldn’t have been easier. I flashed it from Tosmota, and had it running in minutes. It even gives you the HA code for the switches:

30
301012×550 55.9 KB

and has a way to learn the codes by simply pointing at the bridge and holding the button until it learns it:
35
35953×745 93.3 KB

Works like a charm.

10

Good for you.

Waste of time for me.

Useful for all choosing between Tasmota/Espurna firmware.

11

Hey there all,

I’ve tried everything to get it working with the uni-com plugs but no luck. tried tasmota, tried espurna. Nothing works.