Timer-Based Lighting Blueprint for Home Assistant

There is no shortage of “Motion-activated light” blueprints in the Home Assistant ecosystem. You can find massive, kitchen-sink versions that include everything from Illuminance requirements to complex “Wait for trigger” sequences.

However, I found many of them to be overly complicated, requiring me to run into edge cases, and spend time learning how to get around undesired behavior. Also, when a third-party blueprint ceases to be maintained, or an update breaks its logic, one of the most useful features of your smart home goes dark.

I wanted something I owned and managed. By writing my own, I ensured it would always work (and I could fix myself because I could understand it), I could add features on my own roadmap, and I could optimize the logic for 100% reliability. This blueprint has been the backbone of my home for over six months, powering more than 30 automations without a single failure.

The “Timer-Based” Advantage

Most lighting automations rely on a “Wait for no motion” delay. While this works, it can be fragile if sensors drop offline or if multiple triggers are involved.

My blueprint uses a Timer Helper entity as the source of truth. Here’s why this approach is superior:

1. Resilience: If Home Assistant restarts, a running timer can be restored. A “Wait for trigger” action in a standard automation is lost forever on a reboot.
2. Decoupled Logic: The motion sensor just tells the timer to start (or restart). The timer finishing is what actually triggers the lights to turn off. It’s a much cleaner state machine.
3. Visual Feedback: You can see exactly how much time is left in the Home Assistant UI.

How it Works

Let's look at the key elements that make this blueprint robust.

1. Multi-Target Flexibility

The blueprint uses target selectors for the lights. This means you aren't limited to a single bulb; you can target Entities, Devices, Areas, or even Labels. If you add a new light to a room's “Area,” this automation automatically includes it without any configuration changes.

2. The Logic Engine

The automation uses mode: restart. Every time the trigger entities (like a motion sensor) detect activity, the automation restarts.

• The Restart Loop: When activity is detected, it hits the entity_triggered ID and calls timer.start. Because it restarts on every movement, it constantly “kicks” the timer back to the beginning, keeping the lights on as long as you are in the room.
• Decoupled On/Off: The lights don't turn on because of the motion sensor; they turn on because the timer transitioned to active. They don't turn off because motion stopped; they turn off because the timer transitioned to idle.

3. Triple-Layer Conditions

One of the most powerful features I added is the tiered condition system:

• Global Conditions: Must be met for any action to happen (e.g., “Only if lighting automations toggle is enabled”).
• Turn ON Conditions: Specific requirements to start the lights (e.g., “Only if it's after sunset and before sunrise”).
• Turn OFF Conditions: Specific requirements to stop the lights (e.g., “Don't turn off the gym lights if the media player is playing”).

4. Dynamic Duration

I included a timer_duration override. If left empty, it uses whatever duration you set on the Timer Helper itself. This allows you to manage timing globally or override it for specific rooms (like a 30-second hallway vs. a 10-minute bathroom timer) within the same blueprint.

5. Flexible trigger

While many lighting automations are strictly tied to motion sensors, this blueprint is designed for broader flexibility. It treats any state change—such as a binary_sensor for occupancy or even a cover entity like a garage door—as a valid catalyst. For instance, you can configure the automation to trigger when your garage door transitions to an “open” state, turning on lights even before motion is detected.

Getting Started

To use this logic, you'll need to create a Timer Helper first:

1. Go to Settings > Devices & Services > Helpers.
2. Create a new Timer.
3. Give it a name (e.g., “Kitchen Motion Timer”) and a default duration.

I defined these in bulk in YAML like this, but the UI also works if you prefer it.

timer:
  east_hall_lights:
    name: East hall lights
    duration: "00:03:00"
    restore: true
  west_hall_lights:
    name: West hall lights
    duration: "00:03:00"
    restore: true
  bathroom_lights:
    name: Bathroom lights
    duration: "00:05:00"
    restore: true

  ...

Installation

You can import this blueprint directly into your Home Assistant instance using this URL (or clone it directly in GitHub and make it your own):

Once imported, just select your timer, your motion sensors, and the lights you want to control.

By owning your lighting logic, you move one step closer to a truly “bulletproof” smart home. If you have ideas for features or find a way to break it, I’d love to hear your feedback.