Sonoff Slampher and Sonoff PIR Integration

I recently bought a couple of Sonoff Slamphers and Sonoff PIR’s. I have a couple of dark areas that already had the old style PIR built into the inline socket in a dumb switch version. One was failing giving random on/off results and driving us nuts, so replacement was in order. Of course I needed to run it all thru Home Assistant.

My first try got rather complicated. The Home Assistant after version .80 had the binary sensor MQTT set-up modifies so that there can only be 2 codes per entity. Using the 433mhz switching thru the Sonoff RF bridge worked differently. You get 1 topic and it sends the multitude of codes from 433 sensors thru this same topic. If you have an RF bridge you may notice a lot of warnings popping up when a code comes thru. If you have say 6 binary sensors set-up in your system coding thru the RF-Bridge and one code is sent into it, you will get the response of the 1 sensor in Home Assistant, but in the HA system log you will see warning messages from the other 5 sensors stating that this code does not match on or off for this topic. To stop this I have built several things to code around that, and this is one of them.

You see the Sonoff Slampher has the ability to read an RF signal directly as sent from a 433 device. I thought I could load the code and go. Ha ha, no such luck…

I flashed Tasmota onto the Slampher and plugged it all in, fired up the PIR. I followed the Sonoff instructions to pair the devices and it worked! The PIR sensor saw me and the light came on. 10 seconds later the PIR sensor saw me again and the light turned off. It was toggling the light on and off every time the code came in. Well, that’s no good. At that point I felt inspired by Digiblur’s (Thanks Travis!) mastery of Tasmota rules and decided I should be able to do this with rules. Here is my solution.

First, as I said, I flashed Tasmota onto the Slamphers. I got my information on how to do that from the Tasmota site. Once I got the device running and the web interface up, I added all my network information into the configuration, and I pulled in the template for #9 Slampher from the Tasmota website. So far so good.

After playing for a while, I came up with this new Template:

{"NAME":"SlampherSpltRF","GPIO":[17,255,0,255,0,0,0,0,22,56,0,0,21],"FLAG":0,"BASE":9}

It turns out that the device has an RF radio internally that is tied to Button1/GPIO0/POWER1 internally. What I did was move GPIO12 (connected to the main relay) onto POWER2, and change POWER1 on another unused GPIO pin. Then I can ‘interrupt’ the input from the RF swirtch and trigger it whenever I want to instead of on every toggle of the RF.

Here are the rules that make this happen:

rule1 on power1#state=1 do power2 on endon on power2#state=1 do ruletimer5 300 endon on Rules#Timer=5 do power2 off endon

What rule1 does is waits for the RF signal to fire power1 and when it does, that fires power2 which is the light bulb turning on. It then starts a 5 minute timer. When the timer expires, power2 turns off.

rule2 on power1#state=1 do ruletimer4 5 endon on Rules#Timer=4 do power1 off endon

What rule 2 does is waits for power1 to turn on, then sets a different 5 second timer and turns power1 off when that expires. This resets the slampher to recieve another RF signal of ON and ignore OFF.

In effect the light now will only respond to the RF switch turning the light on, and will always turn the light off after 5 minutes.

Here is a debug log of the device running thru a cycle where you can see everything happening:

21:47:58 APP: Button1 multi-press 1                 (This is the RF signal being detected)
21:47:59 SRC: Button
21:47:59 MQT: bhall_socket/stat/RESULT = {"POWER1":"ON"}
21:47:59 MQT: bhall_socket/stat/POWER1 = ON (retained)
21:47:59 RUL: POWER1#STATE=1 performs "power2 on"
21:47:59 SRC: Rule
21:47:59 RSL: Group 0, Index 2, Command POWER, Data on
21:47:59 MQT: bhall_socket/stat/RESULT = {"POWER2":"ON"}
21:47:59 MQT: bhall_socket/stat/POWER2 = ON (retained)
21:47:59 RUL: POWER1#STATE=1 performs "ruletimer4 5"
21:47:59 SRC: Rule
21:47:59 RSL: Group 0, Index 4, Command RULETIMER, Data 5
21:47:59 MQT: bhall_socket/stat/RESULT = {"T1":0,"T2":0,"T3":0,"T4":5,"T5":0,"T6":0,"T7":0,"T8":0}
21:47:59 RUL: POWER2#STATE=1 performs "ruletimer5 300"
21:47:59 SRC: Rule
21:47:59 RSL: Group 0, Index 5, Command RULETIMER, Data 300
21:48:00 MQT: bhall_socket/stat/RESULT = {"T1":0,"T2":0,"T3":0,"T4":4,"T5":300,"T6":0,"T7":0,"T8":0}
21:48:00 CFG: Saved to flash at F4, Count 305, Bytes 3584
21:48:05 RUL: RULES#TIMER=4 performs "power1 off"
21:48:05 SRC: Rule
21:48:05 RSL: Group 0, Index 1, Command POWER, Data off
21:48:05 MQT: bhall_socket/stat/RESULT = {"POWER1":"OFF"}
21:48:05 MQT: bhall_socket/stat/POWER1 = OFF (retained)
21:48:05 CFG: Saved to flash at FB, Count 306, Bytes 3584
21:50:01 MQT: bhall_socket/tele/STATE = {"Time":"2019-06-21:53:00 RUL: RULES#TIMER=5 performs "power2 off"
21:53:00 SRC: Rule
21:53:00 RSL: Group 0, Index 2, Command POWER, Data off
21:53:00 MQT: bhall_socket/stat/RESULT = {"POWER2":"OFF"}
21:53:00 MQT: bhall_socket/stat/POWER2 = OFF (retained)
21:53:00 CFG: Saved to flash at FA, Count 307, Bytes 3584

One of my installations of this is a porch where daylight affects the need for light. My HA already has a sensor for dark that I like taking into account cloud cover and time of day. I got this from another user a while ago, so thank you if you originally wrote this, but I am putting it to use here.

Here is the binary sensor I use for dark:

  #####################################################
  # Weather                                           #
  #####################################################
  - platform: template
    sensors:
      dark_outside:
        friendly_name: 'Is it Dark outside'
        value_template: >-
          {% if is_state('input_boolean.sunset_offset.state', 'on') %}
            true
          {% elif (states.sun.sun.attributes.elevation | int < 2) %}
            true
          {% elif ( (states.sun.sun.attributes.elevation | int < 3.5) and (states.sensor.dark_sky_cloud_coverage.state | int > 85)) %}
            true
          {% elif ( (states.sun.sun.attributes.elevation | int < 5.5) and (states.sensor.dark_sky_cloud_coverage.state | int > 90)) %}
            true
          {% elif (states.sensor.dark_sky_cloud_coverage.state | int > 95) %}
            true
          {% else %} 
            false
          {% endif %}

Here is the automation I use to push that binary sensor out thru MQTT to my Slampher:
  ####################################################
  # Dark out?                                        #
  ####################################################
  - id: mqtt_dark_switch
    initial_state: 'on'
    alias: MQTT Dark Switch
    trigger:
    - platform: state
      entity_id: binary_sensor.dark_outside
    action:
    - service: mqtt.publish
      data_template:
        topic: "bp_socket/cmnd/EVENT"
        payload: >-
          {% if trigger.to_state.state == 'on' %}
            'DARK'
          {% else %}
            'DAY'
          {% endif %}

Then I add 1 additional rule to the slampher that looks for the event and acts on the information:

rule3 on event#DARK do rule1 1 endon on event#DAY do rule1 0 endon

This rule looks for the event topic DARK to come to the slampher and when it does it turns on rule1 enabling the light to function. Then when the code DAY comes thru, it disables rule 1 so the light cannot turn on at all from the RF. Tasmota has an internal sunrise/sunset thing but I did not like the timing of that and wanted to use the same as the rest of my network.

To go along with this, I added another service to my HA reset automation that makes sure my Tasmota stuff reports back with it’s current state on HA boot. I added this to default the dark sensor to dark to default the light to work if it doesn’t know the state. Seemed like the way to go here:

  ####################################################
  # MQTT Restart Tasmota                             #
  ####################################################
  ####    Use this automation to get all your devices in sync, including
  ####     power state, immediately after Home Assistant is (re)started.
  ####    Also taking this opportunity to start other things up for a clean restart.
  - id: tasmota_restart
    alias: Power state on HA start-up
    initial_state: 'on'
    trigger:
      platform: homeassistant
      event: start
    action:
    - service: mqtt.publish
      data:
        topic: sonoffs/cmnd/state
        payload: ''
    - service: mqtt.publish
      data:
        topic: bp_socket/cmnd/EVENT
        payload: 'DARK'

Notice in all this that I prefer my Tasmota MQTT Topics flipped as this way it makes more sense to me. You may need to adjust that if you run yours differently.

I am waiting for more hardware, but one on my installations of this involves a staircase into the basement with a landing where there are 2 slamphers and 2 pir’s, and I’ll have both rules turning when either PIR is triggered. I’ll add to this when I get my Bang Good order.

Thanks for reading, I hope this has helped someone!

3 Likes

None of your code is posted correctly:

Looks OK to me. What’s the issue?

Looks fine to me too.

1 Like

Like your thinking

1 Like

I found another issue… If day is triggered when the light is on, there is nothing to turn the light off and it just stays on. I changed rule 3 to also turn the light off if it gets the day signal. Here’s all 3 final rules. I have retain turned on in tasmota so HA gets the state from MQTT when it boots already plus the tasmota-tized lights get the retained dark or day signal from MQTT when it boots.

Backlog Rule1 on power1#state=1 do power2 on endon on power2#state=1 do ruletimer5 300 endon on Rules#Timer=5 do power2 off endon
Backlog Rule2 on power1#state=1 do ruletimer4 5 endon on Rules#Timer=4 do power1 off endon
Backlog Rule3 on event#DARK do rule1 1 endon on event#DAY do Backlog rule1 0; power2 off endon
1 Like

Here is an update that I’m actually surprised no one had suggested.
I did realize at the time that there was a lot of moving parts and complications in order to get the lights to turn off when I wanted them to.
I came across the Tasmota command PulseTime while setting up something else. It seemed to be an extraordinary way for me to uncomplicate and to reduce memory wear on the device.

Here are the backlog commands. You will of course need to add in your own local logins and passwords. Also some of the commands are choices on my part and not required, but I like them. This includes the inversion of the topic. Once I tried SetOption19 on something, the topics started being logical in my head. Even though I rarely use discovery (except for power monitoring devices because there is so much going on there), I set all my topics to be switched from the Tasmota default like the discovery option does. Like I said, choices.

Backlog Commands:

Backlog SSID1 YourSSID; Password1 YourWIFIPassword; MqttHost YourMQTTHostIP; MqttUser YourMQTTUserLogin; MqttPassword YourMQTTUserPassword; SysLog 2; WebLog 2; SerialLog 0; sleep 100; FullTopic %topic%/%prefix%/

Backlog Topic bp_socket; FriendlyName1 b-porch-socket; FriendlyName2 bmt_hall_rf_socket; Hostname b-porch-socket; MqttClient b-porch-socket; PowerRetain 1; PulseTime1 5; PulseTime2 300

Backlog Rule1 on POWER1#state=1 do POWER2 ON endon; Rule1 on
Backlog Rule2 on event#DAY do rule1 0 endon on event#DAY do POWER2 off endon; Rule2 on
Backlog Rule3 on event#DARK do rule1 1 endon; Rule3 on

Template:

{"NAME":"SlampherSpltRF","GPIO":[17,255,0,255,0,0,0,0,22,56,0,0,21],"FLAG":0,"BASE":9}

Sample output:

00:21:28 RUL: EVENT#DAY performs "rule1 0"
00:21:28 MQT: bp_socket/stat/RESULT = {"Rule1":"OFF","Once":"OFF","StopOnError":"OFF","Free":475,"Rules":"on POWER1#state=1 do POWER2 ON endon"}
00:21:28 RUL: EVENT#DAY performs "POWER2 off"
00:21:28 MQT: bp_socket/stat/RESULT = {"POWER2":"OFF"}
00:21:28 MQT: bp_socket/stat/POWER2 = OFF (retained)
00:21:54 MQT: bp_socket/stat/RESULT = {"POWER1":"ON"}
00:21:54 MQT: bp_socket/stat/POWER1 = ON (retained)
00:21:55 MQT: bp_socket/stat/RESULT = {"POWER1":"OFF"}
00:21:55 MQT: bp_socket/stat/POWER1 = OFF (retained)
00:22:15 MQT: bp_socket/stat/RESULT = {"Event":"Done"}
00:22:15 RUL: EVENT#DARK performs "rule1 1"
00:22:15 MQT: bp_socket/stat/RESULT = {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Free":475,"Rules":"on POWER1#state=1 do POWER2 ON endon"}
00:22:34 MQT: bp_socket/stat/RESULT = {"POWER1":"ON"}
00:22:34 MQT: bp_socket/stat/POWER1 = ON (retained)
00:22:34 RUL: POWER1#STATE=1 performs "POWER2 ON"
00:22:34 MQT: bp_socket/stat/RESULT = {"POWER2":"ON"}
00:22:34 MQT: bp_socket/stat/POWER2 = ON (retained)
00:22:34 MQT: bp_socket/stat/RESULT = {"POWER1":"OFF"}
00:22:34 MQT: bp_socket/stat/POWER1 = OFF (retained)
00:25:21 MQT: bp_socket/tele/STATE = {"Time":"1970-01-01T00:25:21","Uptime":"0T00:25:14","Heap":13,"SleepMode":"Dynamic","Sleep":100,"LoadAvg":9,"POWER1":"OFF","POWER2":"ON","Wifi":{"AP":1,"SSId":"Creative Touch","BSSId":"08:62:66:91:70:30","Channel":9,"RSSI":90,"LinkCount":1,"Downtime":"0T00:00:04"}}
00:25:54 MQT: bp_socket/stat/RESULT = {"POWER2":"OFF"}
00:25:54 MQT: bp_socket/stat/POWER2 = OFF (retained)

The HA commands have not changed so I will not repeat them from above.

So as you see, much less complicated, cleaner, and less to go wrong. I’m not sure if I was hitting Memory or the SD card with the rules, but either way this is better for me to understand.

Thanks for reading.
If you have any suggestions for improvements let us all know!

Sir Goodenough…

Also see:
Sonoff Slampher and PIR Coordination of 2 Seperate Units
For using this hardware and template in a different application.

Please NOTE that I am not updating this post here except for comments. i have moved it over to my YouTube website. Please look here for it: https://whatarewefixing.today/?p=129