# Temporal Control ### Overview **Temporal control** lets a rule condition fire only after it has stayed true for a period of time, instead of the instant a value crosses a threshold. This prevents false alarms from brief, momentary readings and makes your rules react to *sustained* situations. Without temporal control, a condition like `Temperature > 30°C` triggers the moment the sensor reports `30.1°C` — even if it was just a one-second spike. With temporal control, you can require the temperature to stay above `30°C` for, say, **10 minutes straight** before the rule acts. Temporal control is optional and configured **per condition** (per statement) in the Rule Builder. Conditions without it keep working exactly as before. *** ### When to use it Use temporal control when you care about how *long* a situation lasts, not just whether it happened once. Common examples: * **Avoid false alarms** — only alert if a freezer stays warm for 10 minutes, not on a single noisy reading. * **Detect sustained problems** — a pump running over pressure for 5 minutes is a real issue; a 2-second blip is not. * **Reduce alert fatigue** — stop notifications that flap on and off when a value hovers near the threshold. *** ### Where to find it 1. Open or create a rule in the **Rule Builder**. 2. Click a condition (statement) to open its configuration panel. 3. Scroll to the **Temporal control** section, below the comparison settings. 4. Turn the toggle **on** to reveal the temporal options. > **Note:** Temporal control is available for value and geofence conditions. It is **not** available for *Offline Alert* conditions. *** ### Settings #### Persist duration (required) How long the condition must hold **continuously** before the statement becomes true. * Enter a number and choose a unit: **seconds**, **minutes**, or **hours**. * Example: `10 minutes` means the condition must be true non-stop for 10 minutes before it fires. When you enable temporal control, this defaults to **10 minutes**. #### Ignore short spikes (optional) Brief moments where the condition stops being true should not always reset your timer. With this enabled, a violation **shorter** than the configured duration is ignored and the timer keeps running. * Toggle **Ignore short spikes** on. * Set the **ignore duration** (e.g. `30 seconds`). * Example: with a 30-second ignore window, if the temperature dips below the threshold for 10 seconds and then climbs back up, the 10-minute timer is **not** reset. When enabled, the ignore duration defaults to **30 seconds**. #### Reset after prolonged violation (optional) If the condition stops being true for a **long** time, the accumulated progress can be reset so a new sustained period is required. * Toggle **Reset after prolonged violation** on. * Set the **reset after** duration (e.g. `5 minutes`). * Example: if the condition is violated for more than 5 minutes, the timer goes back to zero. When enabled, the reset-after duration defaults to **5 minutes**. **Pause instead of full reset** Within the *Reset after prolonged violation* block, you can enable **Pause instead of full reset**: * **Off (default):** after a prolonged violation, progress is wiped and the count starts over from zero. * **On:** progress is **paused and preserved** during the violation. When the condition becomes true again, counting resumes from where it left off (a softer, time-based behavior). *** ### How the timing works A few things to keep in mind: * **Server time is used.** Timing is based on when the platform evaluates each event, not on the device's clock, to avoid issues with devices whose clocks drift. * **Checks happen on incoming data.** The persist duration is evaluated whenever the device sends an event. If a device goes quiet, the check waits until the next event. * **Unusual silence resets the rule.** If a device stops reporting for far longer than its normal interval, the rule's progress is reset. *** ### Works alongside other settings * **Hysteresis (switching threshold range)** controls re-arming by *value*. Temporal control works by *time*. They are independent and can be used together on the same condition. * **Multiple conditions.** Each condition has its own temporal control. For example, you can require condition A to hold for 10 minutes while condition B is checked instantly. *** ### Examples | Goal | How to configure | | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | `Temperature > 30°C` sustained for 10 minutes | Persist duration = `10 minutes` | | Both `A` and `B` true for 10 minutes | Set persist duration = `10 minutes` on **both** conditions | | `A` true for 10 minutes **and** `C` true right now | Persist duration on `A`; leave temporal off on `C` | | Ignore 30-second dips | Enable *Ignore short spikes*, ignore duration = `30 seconds` | | Reset the timer after 5 minutes off | Enable *Reset after prolonged violation*, reset after = `5 minutes` | | Soft reset (pause, then reset) | Enable *Reset after prolonged violation*, reset after = `5 minutes`, turn on **Pause instead of full reset** | *** ### Tips & FAQ **Do I have to use temporal control?** No. It is fully optional. Leave the toggle off and the condition fires instantly, just like before. **What happens when I turn it off again?** The temporal settings are removed from the condition and it returns to instant behavior. **Will my existing rules change?** No. Rules that never had temporal control are unaffected. **Why didn't my rule fire exactly at the 10-minute mark?** The duration is checked when the device sends data. If your device reports every minute, the rule can fire up to one reporting interval after the threshold is reached. **Can I use very short durations?** Yes — you can enter durations in seconds (for example, `30 seconds`). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.widgelix.com/rule-engine/temporal-control.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.