The Sensor-Boolean-Timer Pattern (My #1 Automation Building Block)

The Pattern That Runs My Entire House: Sensor → Boolean → Timer → Action

If I could go back to day one of my Home Assistant build and tell myself one thing, it would be this: never connect a sensor directly to an action.

Every beginner automation looks like this: motion sensor triggers → turn on light. Door opens → send notification. It works. It's simple. And it completely falls apart the moment your system gets real.

I run 70+ automations across security, lighting, cameras, voice announcements, and garage control. The reason it's manageable — the reason I can add new behavior in 3 minutes instead of rewriting automations — is a single architectural pattern.

The Naive Approach (And Why It Breaks)

Here's a real example. French door opens at night → turn on back patio lights for 2 minutes.

The naive automation:

Trigger: sensor.elkm1_zone_026 changes to "Violated"
Condition: After sunset
Action: Turn on light.back_blue_dots and light.ext_door_cans, delay 2 minutes, turn off

Works fine. Now add requirements:

Zone 027 (second french door sensor) should also trigger the same lights
The lights should also come on when the camera detects a person in the backyard
When the lights come on, also announce "back door opened" on the speaker
Don't re-trigger if the lights are already on (restarting the 2-minute timer while someone is outside is annoying)
If the alarm is armed, the response should be different — flash lights instead of steady on

With the naive approach, you're now maintaining multiple automations with overlapping triggers, duplicate actions, and conflicting timers. Change the light list and you're editing three automations. Add a sensor and you're touching two more. It's a mess inside a month.

The Pattern

Decouple it into layers:

Layer 1 — Detection: Sensor events flip an input_boolean ON. That's ALL they do.

Layer 2 — Cooldown: A timer prevents re-triggering. Boolean only flips if the timer is idle.

Layer 3 — Response: Separate automations watch the boolean. When it turns ON, they execute actions — lights, notifications, voice, whatever.

The input_boolean is the API. It's a semantic event — "french doors opened at night" — not a hardware signal. The detection side doesn't know or care what happens in response. The response side doesn't know or care which sensor triggered it.

Why This Matters at Scale

Add new sensors without touching responses. I wired zone 027 (second french door sensor) as a new trigger for the same boolean. Zero changes to the lighting automation, the voice announcement, or the notification. One new trigger line in the detection automation, done.

Add new responses without touching sensors. When I added Jarvis voice announcements to my system (9 automations in one session), I didn't modify a single detection automation. The voice automations just watch the same booleans that the lighting automations watch. Completely independent.

Debug in one place. Is the boolean ON? Then detection is working — the problem is in the response chain. Is the boolean OFF? Then the sensor or cooldown is the issue. The boolean is a clean diagnostic boundary.

Override cleanly. Guest mode? Set the boolean to ignore certain triggers. Alarm armed? The response automation checks panel state and escalates. Vacation mode? Swap the response entirely. The boolean doesn't change — only what listens to it.

Package Files: Organize by Domain, Not Room

This pattern gets 10x more powerful with the right file organization. I use HA's packages feature to organize by domain:

camera_ai.yaml — all camera detection booleans, timers, and webhook automations
camera_push.yaml — all camera notification automations
alarm_response.yaml — all alarm-triggered responses
time_based.yaml — all time/sensor-triggered lighting (night lights, etc.)
jarvis_tts.yaml — all voice announcement automations
security_modes.yaml — arm/disarm mode logic

NOT by room. Not kitchen.yaml, bedroom.yaml, garage.yaml. Here's why: a single event (front door opens) triggers automations across security, lighting, voice, and camera domains. If those are scattered across room files, you can't see the full response chain. If they're in domain files, you open alarm_response.yaml and see everything that happens when an alarm fires. Open jarvis_tts.yaml and see every voice announcement in one place.

Each package file contains its own input_boolean, timer, and automation sections. Everything the domain needs is self-contained. You can delete a package file and the rest of the system keeps running — that domain's responses just stop.

The Night Light Example

My french door night light — the one I started this article with — uses this exact pattern. Zone 026 or 027 violated after sunset → flip boolean → timer starts → lighting automation sees boolean, turns on back blue dots and exterior door cans for 2 minutes → timer expires → boolean resets.

Adding the camera boolean as a trigger? One line. Adding a voice announcement ("back door activity detected")? New automation in jarvis_tts.yaml that watches the same boolean. The original night light automation: untouched.

If you want a ready-made implementation of this pattern for common night light scenarios — hallway, bathroom, exterior doors, closets — the Night Lights Pack includes 6 pre-built automations using this exact sensor-boolean-timer architecture, with the timer durations and conditions already dialed in.

Quick Tips

Name booleans semantically: input_boolean.french_door_night_activity not input_boolean.zone_026_trigger. The boolean represents an event ("someone used the french doors at night"), not a hardware signal.
Set timer durations based on the response, not the sensor: A camera notification cooldown might be 60 seconds. A night light timer might be 120 seconds. A voice announcement cooldown might be 300 seconds. Each response has its own appropriate cooldown.
Keep detection automations minimal: The trigger automation should do exactly three things — check cooldown, flip boolean, start timer. No actions, no conditions beyond the cooldown check.

Next Issue

Making your house talk — Piper TTS with a custom Jarvis voice model. Local, free, and sounds better than the $5/month cloud service I tried first.

— The Automated Home