---
title: "Delay"
description: "Configure the Delay Smart Rule to execute actions after a waiting period, with support for event and state triggers"
url: "https://taphome.com/en/docs/smart-rules/delay/"
language: en
lastmod: 2026-11-01
generator: hugo
ai:
  topics: ["smart-rules","delay-timer","triggered-actions","grace-period","motion-lighting","two-phase-cycle"]
  questions: ["How do I set up a Delay Smart Rule?","What is the difference between event triggers and state triggers in the Delay Smart Rule?","How does the end delay grace period work?","Can I use multiple triggers with the Delay Smart Rule?","What happens when a trigger fires again during the start delay or end delay?","How do I keep lights on after motion stops for a set time?","Can I use a start delay to filter out brief or accidental triggers?","What happens if the system restarts during a delay cycle?","Why can't I use a trigger device as an action target in the same smart rule?","How do I configure ventilation that runs for a fixed time after someone leaves?","What is the minimum value for the end delay?","How do multiple motion sensors work together with OR logic in the Delay Smart Rule?"]
---

# Delay

Last updated: 2026-11-01

> [!NOTE]
> 🚀 **Available** — TapHome Next 2026.1.36599+.

The **Delay** smart rule adds a waiting period between a trigger and a response: it waits before it executes actions, and can wait again before it ends them. For example, a motion sensor detects movement, the smart rule waits 5 seconds to confirm it is real and turns on the lights; once motion stops, it keeps them on for 10 more minutes and only then turns them off.


## How the delay cycle works {#cycle}

The cycle has two phases, in the order of the sections on the smart rule page. When the trigger activates, the **Start delay** runs; after it the **Start actions** execute and stay in effect. Then the **End delay** runs; after it the **End actions** execute and the cycle ends.

The kind of trigger decides when the end delay begins. With a **state** trigger (**Value equals** **Motion spotted**) it begins only once the condition stops being true, and the condition coming back cancels it. With an **event** trigger (**Value changed to** **Motion spotted**) it begins together with the start actions, and every further event starts it again. The start delay follows the kind too: a state condition that stops being true during it cancels the cycle, while a further event is ignored. Use a state trigger when the actions should stay in effect as long as the condition lasts, plus the end delay after it; use an event trigger when they should stay in effect for a fixed time that a further event extends.

How to read the charts on this page: grey lanes show what the triggers watch (bar = condition true, dot = event), blue lanes show what the smart rule does and carry the names of the sections of its page (bar = actions in effect, dot = actions executed once). A striped bar is a delay counting down, a white gap in it a restart, and a dashed outline the rest of a delay that was cancelled. The static charts are not to scale; the simulator's axis is in minutes.




## Examples and scenarios {#examples}

### Bathroom ventilation after leaving {#example-ventilation}

**Goal**: When someone leaves the bathroom, turn on the exhaust fan 4 minutes later. Keep it running for 10 minutes to clear the air.

**Configuration**:
- **Triggered by**: bathroom motion sensor, **Motion** **Value changed to** **Motion cleared** (event trigger)
- **Start delay**: **4 minutes**
- **Start actions**: bathroom exhaust fan → **On**
- **End delay**: **10 minutes**
- **End actions**: bathroom exhaust fan → **Off**

**Behavior**: The fan turns on 4 minutes after the motion stops and runs for 10 minutes. If the person comes back within those 4 minutes and leaves again, the fan still turns on 4 minutes after the first departure. Leaving again while the fan runs restarts the 10 minutes.


### Conference room climate on confirmed occupancy {#example-climate}

**Goal**: Switch the conference room thermostat to comfort mode when the sensor reports motion without a break for at least 5 minutes (a break cancels the count). Revert to eco mode 15 minutes after everyone leaves.

**Configuration**:
- **Triggered by**: conference room motion sensor, **Motion** **Value equals** **Motion spotted** (state trigger)
- **Start delay**: **5 minutes**
- **Start actions**: conference room thermostat → **22 °C**
- **End delay**: **15 minutes**
- **End actions**: conference room thermostat → **18 °C**

**Behavior**: A short visit (someone grabs a cable) ends before the 5 minutes are up and the thermostat stays at eco. After 5 minutes of occupancy the room switches to 22 °C and stays there until 15 minutes after the last person leaves.


## Getting started {#getting-started}

The smart rule page has five sections of its own; the second dialog belongs to the trigger page:



In the picture, pick the other condition in the **Trigger type** dialog and the descriptions of both delays change with the kind of trigger — see [Event triggers vs state triggers](https://taphome.com/en/docs/smart-rules/delay/#event-vs-state).

### Basic example {#basic-example}

You have a motion sensor in the hallway. You want the hallway light to turn on when motion is detected and stay on for 5 minutes after the last motion.

1. Create a new **Delay** smart rule.
2. In the **Triggered by** section, tap **Add trigger** to open the trigger configuration page.
3. Tap **Add Device** and select your hallway motion sensor.
4. On the trigger page, in the **Triggered by** section select **Motion**, in the **When** section **Value equals**, and the value **Motion spotted**.
5. Go back to the smart rule page.
6. Leave the **Start delay** at **0 seconds** (react immediately).
7. In the **Start actions** section, tap **Add New Action** and set the hallway light to **On**.
8. Set the **End delay** to **5 minutes**.
9. In the **End actions** section, tap **Add New Action** and set the hallway light to **Off**.
10. Tap **Save**.


## Triggers {#triggers}

You can add multiple triggers to the same smart rule. The smart rule activates when **any one** of them is active (OR logic) — with three motion sensors and a state condition, the end delay starts only once none of them sees motion. For configuration details, see [Triggers](https://taphome.com/en/docs/smart-rules/triggers/).

Triggers of this smart rule watch device values only. Time triggers and the time settings of a trigger (delay, minimum and maximum duration) are not available here — the smart rule has its own two delays instead.

> [!NOTE]
> Trigger devices cannot be used as action targets within the same smart rule. This prevents feedback loops where an action would trigger its own smart rule.
> To turn a device off some time after it was switched on, use its [default value and manual override](https://taphome.com/en/docs/smart-rules/default-values/#auto-off).

### Event triggers vs state triggers {#event-vs-state}

The trigger condition decides the kind: the **Trigger type** dialog lists the conditions in two groups, **States** and **Events**. All triggers in one smart rule must be the same kind: once a trigger has a condition, the dialog offers only conditions of that kind, for every trigger including the first. To switch a smart rule to the other kind, remove its triggers and add them again.

A trigger row on the smart rule page does not show the kind: **Value equals** and **Value changed to** both read as value type, equals sign, value.

The chart compares two **Delay** smart rules on the same motion sensor, both with a start delay of **0** and the same end delay. The first uses the state condition **Value equals** **Motion spotted**, the second the event condition **Value changed to** **Motion spotted**:



1. **Motion starts** — both smart rules execute their start actions.
2. **Event**: the end delay, counted from the event, expires and the start actions end although the motion continues.
3. **Motion stops** — **State**: the end delay begins.
4. **Motion again** — **State**: the end delay is cancelled. **Event**: a new event starts a new cycle.
5. **Event**: the end delay, counted from the second event, expires.
6. **State**: the end delay expires, counted from the moment the motion stopped again.


## **Start delay** {#start-delay}

The description under the section heading depends on the kind of trigger:

- **State triggers**: **Optional delay before executing start actions. It counts from the moment the condition becomes true, and the cycle is cancelled if the condition becomes false during this period.**
- **Event triggers**: **Optional delay before executing start actions. It counts from the first event - further events during this period are ignored and the cycle cannot be cancelled.**

Set the duration using the time picker, from days down to milliseconds.

| Parameter | Range | Default |
|:----------|:------|:--------|
| **Start delay** | 0 and above | 0 (no delay) |

With a state trigger, the start delay filters out brief triggers — for example, a door that is opened only for a moment rather than left open:



1. The condition becomes false before the start delay expires. The cycle is cancelled and the start actions never execute.
2. The condition becomes true again. The start delay counts from the beginning.


## **Start actions** {#start-actions}

Tap **Add New Action** to add device actions. You can add multiple actions — they all execute together.

Each action section can also hold one notification action: tap the notification bell icon in the section header. When the actions execute, it sends a push notification to the recipients you pick in its **Groups**, **Users** and **Client devices** sections.


## **End delay** {#end-delay}

| Parameter | Range | Default |
|:----------|:------|:--------|
| **End delay** | 500 milliseconds and above | 60 seconds |

How the end delay starts depends on the kind of trigger:

- **State triggers**: **Delay before executing end actions. It starts when the condition becomes false, and it is cancelled if the condition becomes true again.**
- **Event triggers**: **Delay before executing end actions. It starts when the start delay ends, and each further event restarts it.**

Both cases are drawn in [Cycle step by step](https://taphome.com/en/docs/smart-rules/delay/#cycle-steps).


## **End actions** {#end-actions}

**Actions executed once when the end delay expires. Typically, end actions are not needed - when the smart rule stops returning a value, the device will receive a value from another active smart rule with lower priority, or fall back to its default value.**

A device whose **Default values** are set to **Do not change** keeps the value the start actions gave it — for such a device add the opposite action here, for example turning off what the start actions turned on.


## Cycle step by step {#cycle-steps}

### State trigger cycle {#cycle-state}



1. **Trigger activates** — the start delay begins.
2. **Start delay expires** — the **Start actions** execute and stay in effect until the end delay expires.
3. **Trigger deactivates** — the **End delay** begins.
4. **Trigger activates again** — the end delay is cancelled.
5. **Trigger deactivates again** — the end delay counts from the beginning.
6. **End delay expires** — the **End actions** execute and the cycle ends.

### Event trigger cycle {#cycle-event}



1. **First event** — the cycle and the start delay begin.
2. **Another event during the start delay** — ignored.
3. **Start delay expires** — the **Start actions** execute and the **End delay** begins.
4. **Event during the end delay** — the end delay restarts from the beginning.
5. **End delay expires** — the **End actions** execute. The next event starts a new cycle.

### System restart {#system-restart}

If the system restarts while a delay cycle is in progress, the smart rule resumes where it left off. A delay that ran out during the restart is caught up right after start-up; an end delay that follows it counts from the start-up. A state trigger is evaluated against its current value after start-up: if the condition is no longer true, a start delay that is still running is cancelled (one that ran out during the restart is caught up all the same), and if the condition is true again, the end delay is cancelled.

Saving a change to the smart rule is different: it cancels a cycle in progress without executing its end actions, and its start actions stop being in effect at once (a device whose **Default values** are set to **Do not change** keeps their value). If a state condition is still true, a new cycle starts right away from the start delay.