Automation triggers in detail

This page is the detailed companion to Automation triggers. Read that one first for what each trigger is for; read this one when you want to know exactly when a rule runs, and why one occasionally does not.

Ignition

The four states

The Car App derives one ignition state from the car: OFF, ACC, ON, Remote ON. A rule targets one of them under When state becomes; ACC, ON and Remote ON can be picked, OFF cannot.

Readings the app cannot interpret are ignored outright — they neither count as a change nor erase what the app already knew, so a momentary data gap never fires a rule.

Edge detection

The first state seen after the app starts is a baseline. It never fires anything.
The state must settle for about 1.5 seconds before it counts as a change. Cold-start flicker through ACC is filtered out this way.
Only the destination matters. A rule on ON fires whether the car came from OFF, ACC, or Remote ON.
The same state repeating is not a change.

The launch pause

Pause after the car starts (Settings → Automation) exists because a car that has just woken up has not reported its readings yet. Without the pause, a rule such as “heat the steering wheel if it is below 0 °C” was dropped for the whole ignition cycle, because the outside temperature was still unknown at the instant of start.

Applies only to rules targeting ON and Remote ON. ACC rules are unaffected — nothing is booting.
Choices are 0, 5, 10, 20 and 30 seconds; the default is 10 s, and any value up to 60 s is accepted.
On the state change the rule is armed on direction alone — the condition is not consulted yet.
When the pause expires the rule is re-checked, and it runs if the condition was true either at the moment of start or now. That double reading is deliberate: slow readings (outside temperature, charge level, range) usually arrive during the pause, while fast ones (gear, seat belts, charge gun) can be true at start and false ten seconds later because you have already pulled away.
If the car went back to OFF or ACC during the pause, the launch was abandoned and nothing runs. Remote ON → ON is progress, not a cancellation — a remote start followed by the driver arriving still runs the rule.
A rule deleted or switched off during the pause does not run.
If the state changes into the target again while a pause is running (OFF → ACC → ON), that rule’s pause simply restarts.

Why an ignition rule did not run

The app had just started and this was its first reading (baseline).
The state did not hold long enough to count.
The condition was false both at start and after the pause.
A check (“And only if”) did not hold, or the reading it needs was unknown.
The car went back to OFF or ACC before the pause ended.

Sensor

How a crossing is detected

Every rule of this type is looked at on each vehicle-data update:

If the condition reads false, the rule is re-armed and nothing else happens.
If it reads true, the rule fires only when it was false on the previous update, the rule is armed, and the sensor already had a value beforehand.

So the rule fires on the edge, not while the condition stays true. “Charge below 20%” fires once as you pass 20% and can fire again only after the level has gone back above it.

The first-reading rule

A sensor the app has never had a value for cannot have crossed anything, so no rule fires on the very first reading. This is what stops rules like “seat belt unfastened” or “gear is in P” from running every time the app restarts on a parked car, where those are the normal resting values.

Checks and the edge

Extra checks are tested only against the current readings, never against the previous ones. They qualify the edge, they are not part of detecting it.

Why a sensor rule did not run

The condition was already true before — no crossing happened.
It has not gone false since it last fired, so the rule is not re-armed.
The reading was seen for the first time on this update.
A check did not hold, or its reading was unknown.

Time

When it is checked

Once a minute, and once immediately when the app resumes receiving vehicle data. The Car App is stopped at ignition OFF and brought back automatically, and that immediate check is what catches a schedule that came due in between.
Nothing is held in memory: the rule itself is the schedule, so a restart cannot lose it.

The rules of firing

The rule fires when the current time is at or after the scheduled minute, on a ticked weekday, and the rule has not already fired for that occurrence.
Catch-up window: 10 minutes. Later than that, the occurrence is skipped rather than run late.
No weekday ticked = never runs. The Car App warns you when saving.
Moving a rule to an earlier time that has not yet happened today makes it eligible today.
Running the rule by hand does not consume the day’s occurrence: a manual test at 07:29 still leaves the 07:30 run in place.

Why a time rule did not run

Today is not a ticked weekday, or no weekday is ticked at all.
More than 10 minutes have passed since the scheduled time.
It has already run for that occurrence.
A check did not hold at the scheduled minute.

Data available

Fires on a connectivity event — the car obtaining working Wi-Fi or mobile data.
Ignored while the car is off. A parked car re-joining home Wi-Fi does not run these rules.
There is no edge memory: if the connection drops and returns during one drive, the rule can run again. Keep the action safe to repeat, or narrow it with a condition and checks.
The condition is optional. With no condition, any connection event runs the rule.

Common to every trigger

If / And only if

If (condition) — one sensor, one comparison, one value. Optional for Ignition and Data available; a Sensor rule is defined by it.
And only if (checks) — all must hold at the moment the trigger fires. An unknown reading blocks the rule: a check exists to prevent an action in the wrong conditions, so an absent outside temperature is never read as “warm enough”.
A check turning true is never an event by itself.

Pause before action

Delays the action after the trigger fires. The rule is re-tested for being switched on when the delay ends, so disabling a rule during its delay stops the action.

Duration (auto-revert)

Available for actions that have a known opposite; the app schedules the reverse after the set number of minutes.
The revert is cancelled if you switch the rule off or delete it, and it does not survive the car being shut down — the pending revert is dropped along with everything else when evaluation stops. Use it for comfort within a drive, not as a guarantee across a parked night.

Running a rule by hand

Bypasses the trigger and the checks — you are the trigger — and works even for a rule that is switched off, so the button next to a disabled rule still does something. It does not record a run, so it never cancels a scheduled one. Safety layers below still apply: a command the car would refuse while asleep is still refused.

When automations are active

Evaluation runs while the Car App has a live vehicle-data connection. When it stops, pending launch pauses and pending reverts are cancelled; when it resumes, time rules are checked at once and ignition edge detection starts from a fresh baseline.

Each fire and each skip is recorded in the app’s logs with the rule name, so if a rule behaves unexpectedly, the diagnostic bundle from Settings → Diagnostics shows which stage stopped it.