Run Modes: Handling Overlapping Triggers
Now and then an automation gets nudged again while it's still busy with a
previous run. The mode setting decides how WoowTech reacts to that overlap —
whether it brushes off the new trigger, scraps the current run and begins anew,
lines the request up behind whatever's already going, or spins up a separate copy
side by side.
For the vast majority of automations the built-in single mode is the right
call. The alternatives exist for niche situations — say a notifier that should
fire a brand-new copy for every incoming event, or a lengthy routine that ought
to start over from the top each time something nudges it.
| Mode | What it does |
|---|---|
| single | The default. Refuses to launch a second run while one is active, and logs a warning. |
| restart | Kills the in-flight run, then starts a fresh one — but only when the conditions still hold. |
| queued | Holds the new run until earlier ones finish, executing them strictly in arrival order. A queued run only joins the line if its own conditions are satisfied at trigger time. |
| parallel | Spins up a separate, independent run that proceeds alongside the others. |
With queued and parallel, the max option caps how many runs may be active
or waiting at once. If you don't set it, the ceiling is 10.
Crossing that ceiling (effectively 1 in single mode) writes a log entry to flag
the overflow. The max_exceeded option sets how loud that entry is: choose
silent to suppress it entirely, or name any log level. It defaults to
warning.
Throttling an Automation to Once Every Few Minutes
Suppose you only want an automation to act at most once every ten minutes. Pair
single mode with a trailing delay, and mute the overflow warnings so the log
stays clean while the run is still ticking.
automation:
- mode: single
max_exceeded: silent
triggers:
- ...
actions:
- ...
- delay: 600 # seconds (= 10 minutes)
Serializing Runs with a Queue
When an automation drives a device that can't cope with two commands at the same moment, queue the runs. Each new run then waits its turn, kicking off only after the current run and everything ahead of it in the line have wrapped up.
automation:
- mode: queued
max: 15
triggers:
- ...
actions:
- ...
Run Modes: Handling Overlapping Triggers
Now and then an automation gets nudged again while it's still busy with a
previous run. The mode setting decides how WoowTech reacts to that overlap —
whether it brushes off the new trigger, scraps the current run and begins anew,
lines the request up behind whatever's already going, or spins up a separate copy
side by side.
For the vast majority of automations the built-in single mode is the right
call. The alternatives exist for niche situations — say a notifier that should
fire a brand-new copy for every incoming event, or a lengthy routine that ought
to start over from the top each time something nudges it.
| Mode | What it does |
|---|---|
| single | The default. Refuses to launch a second run while one is active, and logs a warning. |
| restart | Kills the in-flight run, then starts a fresh one — but only when the conditions still hold. |
| queued | Holds the new run until earlier ones finish, executing them strictly in arrival order. A queued run only joins the line if its own conditions are satisfied at trigger time. |
| parallel | Spins up a separate, independent run that proceeds alongside the others. |
With queued and parallel, the max option caps how many runs may be active
or waiting at once. If you don't set it, the ceiling is 10.
Crossing that ceiling (effectively 1 in single mode) writes a log entry to flag
the overflow. The max_exceeded option sets how loud that entry is: choose
silent to suppress it entirely, or name any log level. It defaults to
warning.
Throttling an Automation to Once Every Few Minutes
Suppose you only want an automation to act at most once every ten minutes. Pair
single mode with a trailing delay, and mute the overflow warnings so the log
stays clean while the run is still ticking.
automation:
- mode: single
max_exceeded: silent
triggers:
- ...
actions:
- ...
- delay: 600 # seconds (= 10 minutes)
Serializing Runs with a Queue
When an automation drives a device that can't cope with two commands at the same moment, queue the runs. Each new run then waits its turn, kicking off only after the current run and everything ahead of it in the line have wrapped up.
automation:
- mode: queued
max: 15
triggers:
- ...
actions:
- ...
Start writing here...