As I expand the reach of Home Assistant, I continuously try to build automations that make life generally easier for the users of the home. To me, automation isn’t about being able to control anything from my phone - in fact, the less I have to get my phone out, the better. I will still enjoy tracking history entries and status of nodes with both the web UI and app, but I shouldn’t have to, the house should just work. With all of this, my next goal is to merge automated lighting with security cameras, to improve the user experience when coming home at night. This is an all-encompasing goal that includes motion sensing lighting with PIR sensors, door switches, and of course Frigate’s AI person detection.

We’ll Leave The Light On For You

Without any way to control exterior lighting from outside the house, this is a very common occurance when someone is out late. If someone is coming home and parking in the driveway, they will be wandering around in the dark trying to find the back door, or if they open the garage door, dealing with the dim light of a single bulb in an overhead door motor to see where they are going. It’s not a great user experience. The age-old solution to this is to leave the exterior lights on all the time, so anyone arriving after dark can see where they are going and find the back door. Even when they do find the back door, they enter the kitchen, and need to find the switch for that light (which is not near the exterior door), and the process continues with lights being turned on and off until they make it to their bedroom.

I’m approaching this in a multi-pronged way. I need more sensor information to make informed decisions about lighting, and I need more control of the lights. I’ve started with the following goals for automation:

  • The back deck exterior lights and deck rope lights shall turn on when persons are detected on the deck or in the driveway next to the garage between sunset and sunrise
  • The front and side exterior lights shall turn on when persons are detected on the deck, in the driveway next to the garage, in the front yard, or on the front porch, between sunset and sunrise
  • The front and side exterior lights shall turn on when any garage overhead door is opened, between sunset and sunrise
  • The garage lights shall turn on when any garage overhead door is opened, between sunset and sunrise
  • The mud room lights shall turn on when the garage to mud room door is opened or when motion is detected, at all times
  • The kitchen lights shall turn on when the deck door is opened, motion is detected in the kitchen, or motion is detected in the mud room, between sunset and sunrise, and automatically dim based on the time of day if on.
  • The second floor stair lights shall turn on when motion is detected, between sunset and sunrise, and dim based on the time of day if on.

Detecting if a door contact recently changed

One key here is that I don’t want the lights to stay one when the door is open, I want them to turn on when the door is opened and stay on for a few minutes. Since closing the door usually follows, but closing the door also indicates a person is in the vicinity of the door, I’m okay triggering when the door opens or closes, but not when it remains in the opened state. To do this, I wrote a template sensor for each door switch which triggers if the value has changed in the last 10 seconds. Since triggers are evaluated whenever a corresponding entity changes, but triggers containing now() are also evaluated every 60 seconds, this means the resulting binary sensor will stay true for between 10 and 70 seconds depending on when the condition is re-evaluated. This is acceptable to me. The following needs to go in your templates.yaml:

#Indicate if any door switches have **changed** recently (for motion lights) 
- binary_sensors:
    - name: "Kitchen Door Deck Contact Changed"
        unique_id: "kitchen_door_deck_contact_changed"
        state: "{{ (as_timestamp(now()) - as_timestamp(states.binary_sensor.kitchen_door_deck_contact.last_changed)) | float < 10 }}" 
    - name: "Garage Door Entry Contact Changed"
        unique_id: "garage_door_entry_contact_changed"
        state: "{{ (as_timestamp(now()) - as_timestamp(states.binary_sensor.garage_door_entry_contact.last_changed)) | float < 10 }}"       
    - name: "Front Door Contact Changed"
        unique_id: "front_door_contact_changed"
        state: "{{ (as_timestamp(now()) - as_timestamp(states.binary_sensor.front_door_contact.last_changed)) | float < 10 }}"       

If you don’t have a templates.yaml, see if you have a templates in your configuration.yaml and add them there. If not, make a new templates.yaml and point to it from configuration.yaml like this:

template: !include templates.yaml

Setting Up Motion Groups

The easiest way to implement this in Home Assistant is to create groups for each of these events (groups OR the entities they contain by default), and use that group as the trigger for the motion sensing lights automation. In my case, I started with a group for the back deck lights based on person detection from the 3 relevant cameras, and a group for the mud room lights based on the door and motion sensors. These go in groups.yaml:

#Motion sensors which contribute to Deck Lights
    name: Deck Light Motion
        - binary_sensor.back_door_person_motion
        - binary_sensor.parking_person_motion
        - binary_sensor.driveway_person_motion
        - binary_sensor.kitchen_door_deck_contact_changed

#Sensors which contribute to mud room lights
    name: Mud Room Light Motion
        - binary_sensor.garage_door_entry_contact_changed
        - binary_sensor.mud_room_motion_occupancy

Obviously, more motion groups exist for all of the scenarios above, but this is an example.

Setting Up Lighting Automations

Although there is already a blueprint for motion-activated lights, it’s very picky about what it accepts. In my case, the issue is it will only accept a Light entity, not a Switch entity, so I can’t use it since I use Switches (Inovelli Red) for my exterior lights. I could use it for my interior lights which have Dimmers (and are Light entities), but it’s not a terribly hard automation to write manually.

So, the automation goes something like this (using the GUI):

  • Mode - Restart - means it will start the timer over when new motion is detected before the lights have turned off automatically
  • Triggers - State - (group name), to on
  • Conditions - none
  • Actions:
    • Turn on light (using either Call Service or Device)
    • Wait for Trigger - State - (group name), to off, no timeout
    • Delay - the time you want the lights to remain on after motion is not detected
    • Turn off light (using either Call Service or Device)

Copy that automation for every case where you want to use it.

Setting Up Sunrise/Sunset Actions

I setup two automations, one which runs at Sunrise + 30min, and one which runs at Sunset -30min, to setup the house for day and night time activities. These two automations are exactly the opposite of each other, and basically do the following:

  • Turn on/off all of the Automations which are responsible for daytime only motion sensing (bedrooms)
  • Turn on/off all of the Automations which are responsible for nightitme only motion sensing (garage, deck, kitchen)
  • Set parameters on the dimmers for the default dim level, to either 100% (daytime) or the night time % selected for that room, duplicated for both the local on and Z-wave on parameters - for my Inovelli dimmers, this is parameters 9 and 10 respectively (parameter 12 and 13 instead for Inovelli LZW-36 dual fan light dimmer))


So far, I’ve been running this for a few weeks with a few different lighting groups - one for the back deck lights and one for the front porch lights. So far, feedback has been excellent. The front porch and garage exterior lights come on when cars or people are detected in the driveway, so they come on quickly as someone arrives. The back deck lights come on when people are detected on the deck or in the driveway, so they come on with slightly more filtering compared to the porch lights. There are relatively minor issues in dealing with what happens when the automation is turned on when the lights should be on - I need a bit more logic to decide if it should turn the lights on immediately when the automation becomes active. The interior kitchen lights are also starting to be automated, more on that in the future.