Recently Active: A Template Blueprint With an On/Off State Plus an Off Delay All-In-One

[jamieFL (James Lander)]

Recently Active is a template blueprint that builds a binary sensor that reads on while a source is on, and stays on for a window of seconds after the source clears. It works on any on/off source and on any numeric sensor with an above or below threshold.

Why this Matters

Home Assistant triggers fire once, the instant a state crosses a line. The door opens, the event fires, it's gone. Five seconds later you ask "was the door just used" and nothing in your config can answer, because the crossing happened once and Home Assistant moved on. Every automation that wants a soft linger hits this wall: act when the room has been quiet for five minutes, hold off on the cycle-complete alert until the appliance is really done, don't run the vacuum while people are around.

Recently Active solves it with one entity that anything can read. Accurate to the second under the hood, because it builds a delay_off binary sensor. Add a half-dozen of them in one package and your config gets simpler, not heavier, because the answer to "is X recently active" stops being scattered across the automations that need it.

Versus the Alternatives

• A for: clause inside a single trigger: good for sub-30-second windows that live entirely inside one automation. The held state never leaves that automation.
• A timer helper plus automations: good for long windows you want to pause, cancel, or watch tick down on a dashboard. Survives restarts visibly.
• History Stats: good for sums ("on for X minutes in the last hour"), not "recently on."
• Recently Active: good for the band between thirty seconds and an hour, especially when more than one automation needs to read the same recently-true answer.

Worked Example: Motion-Activated Lights with a Five-Minute Linger

A motion sensor fires for a few seconds then clears. You want the lights on for five minutes after the last motion. Build the sensor:

template:
  - use_blueprint:
      path: TheThinkingHome/recently_active.yaml
      input:
        source_entity: binary_sensor.hallway_motion
        unique_id: hallway_recently_active
        linger_seconds: 300
        sensor_name: Hallway Recently Active
        device_class: occupancy

Then drive the lights off the linger, not the raw motion:

automation:
  - alias: Hallway lights on with motion
    trigger:
      - trigger: state
        entity_id: binary_sensor.hallway_recently_active
        to: "on"
    action:
      - action: light.turn_on
        target:
          entity_id: light.hallway

  - alias: Hallway lights off after linger
    trigger:
      - trigger: state
        entity_id: binary_sensor.hallway_recently_active
        to: "off"
    action:
      - action: light.turn_off
        target:
          entity_id: light.hallway

Lights on the moment motion arrives, off five minutes after the last motion. If only the lights cared, a for: clause on the trigger would do the job too. The blueprint pays off the moment something else also wants the same answer: the robot vacuum's "don't start in an active room" check, the goodnight script's "are we sure" guard, an away routine's sanity check. One sensor, many readers.

A Numeric Example: Is the Appliance Actually Finished?

For numeric sources, use the above or below mode. A dishwasher draws power in bursts with quiet stretches between them, so a plain "drawing power" check fires "done" mid-cycle. With Recently Active:

template:
  - use_blueprint:
      path: TheThinkingHome/recently_active.yaml
      input:
        source_entity: sensor.dishwasher_power
        comparison: above
        threshold: 5
        linger_seconds: 300
        sensor_name: Dishwasher Recently Running
        unique_id: dishwasher_recently_running
        device_class: running

binary_sensor.dishwasher_recently_running stays on through the quiet stretches and only drops when the draw has been under five watts for the full five minutes. Hang the cycle-complete notification on its off transition and it lands when the dishes are actually clean.

Get It

One click imports the blueprint. The README on GitHub has the full setup walkthrough, the parameters reference, device-class advice, and the longer story behind a couple of design choices: Automations/blueprints/template/recently_active.md at 8323333b57aa704eae8bee10bad7c121e51905b6 · TheThinkingHome/Automations · GitHub

Tested with Home Assistant 2026.5.4 or newer.

GPL-3.0-or-later. First of a small series, each one a single useful thing kept deliberately simple.

Other blueprints in The Thinking Home series:

• Recently Active — Create a "was active recently" sensor from any source, with a configurable look-back window.
• Sensor Failover — Fall back to a secondary sensor when the primary goes unavailable.
• Linked Entities Pro — Two-way sync for any number of entities across switches, lights, input_booleans, fans, and groups.
• Sensor Watchdog — Detect sensors that have stopped responding and power-cycle them back.

[jamieFL (James Lander)]

Well...fifty views and absolute silence is a clear signal. I explained the wiring perfectly, but I forgot to show you what the machine actually builds.

Reading about template sensors and delay_off variables is dry. The problems this blueprint solve is not. This is the exact annoyance that makes living in a smart home frustrating. Home Assistant is incredibly fast, which means it is often entirely too impatient to handle human behavior.

Lets look at a few physical realities where adding a simple linger stops your house from acting like a dumb machine.

The Camera Mute Button

You walk out the front door. The camera sees you. Your phone immediately buzzes with a "Person Detected" alert. You already know you are outside. It is noise.

Point Recently Active at your front door contact sensor and give it a two-minute linger. Then tell your camera notification automation to only fire if binary_sensor.front_door_recently_used is off. The blueprint acts as a mute button for your own expected activity, allowing the cameras to stay vigilant without spamming your phone.

YAMLtemplate:
  - use_blueprint:
      path: TheThinkingHome/recently_active.yaml
      input:
        source_entity: binary_sensor.front_door_contact
        unique_id: front_door_recently_used
        linger_seconds: 120
        sensor_name: Front Door Recently Used
        device_class: door

The HVAC Compressor Guard

You open the living room window to clean the window track. Your automation immediately kills the A/C. Thirty seconds later, when you are finished, you close the window. The automation instantly slams the A/C back on, short-cycling your compressor.

Hardware hates rapid toggling. Point the blueprint at the window contact and give it a five-minute linger. Tell your HVAC automation to only resume cooling when that Recently Active sensor drops to off. You just built a debounce timer that protects your expensive climate equipment from your own indecision.

The Premature Auto-Lock

You step out the front door to grab a package. The instant the door closes, your smart lock throws the deadbolt. You are now locked out in your slippers.

A house should be patient. Tell your auto-lock automation to trigger off the Recently Active sensor's to: "off" transition rather than the raw door contact. Set a sixty-second linger. The door now gives you a full minute to step back inside before sealing the perimeter.

---

Home Assistant sees the world in absolute instants. A door is either open or closed. A sensor is either active or quiet. But we live in the messy, lingering moments between those absolute states. This blueprint builds the bridge.

Fixing one frustrating automation is great. But this sensor truly earns its keep the moment a second script needs to ask the exact same question. You build the logic once, and let your entire system read the answer.

Drop it in front of the automations that frustrate you the most, and let me know what you end up fixing.

[Ltek]

Hi James,
Just read over your posts. I get the use cases but not sure I understand, or agree with your premise or benefit for needing to add a blueprint and create (multiple) template sensors in addition to all the automations you still need to create. I think the native functions do everything just as well (or the same) with less work/maintenance.

For example, I published a robust blueprint to handle the Auto-Lock situation you describe. But that is a complex automation, far more than just a linger/delay.

I dont see how this comment you made is accurate?...

Five seconds later you ask "was the door just used" and nothing in your config can answer.

Each entity, by default, stores history (you can disable it in Recorder)... and it does his across reboots since Recorder writes to the database. Automation logic can easily determine if an entity was used, what the state was, and/or how many times it was a given state in a given period of time.

Your FOR clause comment about only being good for that one automation. Yes, that is the point. Add to the automations you need it in. Which is a lot less work, and far easier to manage/maintain/remember at a later date than a template sensor you'll prob forgot about... and has a static 5 min linger when the new automation you want to have a 2 min linger.

Not trying to be mean, but the way I read your posts, I dont see how it creates less work for the automation creator, more reliability?

[jamieFL (James Lander)]

@Ltek, You raise some fair points. Some of them I documented in the README already. Others I will try to answer here.

The FOR clause is the right tool when only one automation cares about the lingered state. For a single-consumer linger under thirty seconds, write the FOR inline and move on. The blueprint is not trying to replace that pattern.

On the Recorder point, you are right that the data is there. I overstated when I wrote that nothing in your config can answer "was the door just used." history_stats, recorder templates, and as_timestamp(states.x.last_changed) calculations can all produce a yes-or-no. What they cannot do is fire a trigger. Automations trigger on state changes, not on query results. When a lingered state flips from on to off because the window has expired, that transition is an event you can hang behavior off: the auto-resume of the A/C, the all-clear notification, the next thing in the chain. A Recorder query can answer the question on demand. It cannot produce the off-transition that lets you trigger the next step. That distinction is what a stateful template sensor buys that a query cannot.

When more than one automation needs the same answer, the FOR-clause approach starts to strain. The dishwasher example in my opening post is the cleanest illustration. "Is the dishwasher really done" feeds the cycle-complete notification, a load-balance gate that holds back the dryer until the dishwasher quiets down, and any next-cycle-start guard you want to layer on. With three consumers, the FOR-clause approach forces three independent debounce timers tracking the same physical reality. They can drift, they can disagree, and they all need to be edited if you ever change the window. The template sensor is the right tool the moment that second reader appears. It is the wrong tool when there is only one.

On the static linger, the answer is one sensor per linger window. They are cheap. front_door_recently_used_2min and front_door_recently_used_5min can coexist without bloat. One template entity per distinct window, no more.

On the maintenance side, I find these sensors easier to manage than scattered FOR clauses, not harder. A naming convention pulls them all into view at once: filter the entity list by recently_used_* and the entire set is right there. If three automations consume a linger and you decide it should change from two minutes to five, you change one sensor and you are done. No hunting through automations to find where FOR clauses are hiding. Building one is one block of YAML, using it is one entity reference, and removing it when it stops earning its keep is one delete.

I appreciate the pushback because it helps to illustrate how I use them and how useful this template blueprint actually is.