Macros

Macros turn a sequence of steps — fire a webhook, call a Home Assistant service, wait, ask “are you sure?”, branch on the result — into one tile you tap on your watch. It’s the multi-step evolution of HTTP Actions: where an HTTP Action is a single request, a Macro is a whole routine.

A Macro is a reusable, named list of steps you build once on the iPhone and reference from a watch tile. The watch runs the steps in order, shows you live progress, and can pass a value captured from one step into the next.

What You Can Do

One tap, many steps — “leaving home” can lock the door, set the thermostat, and arm an alarm from a single tile.
Ask before acting — drop a confirmation step in front of a risky action so the watch asks “Run this now?” first.
Read, then decide — pull a value out of a reply and branch: go one way if a sensor says ok, another if it doesn’t.
Retry until ready — loop a check on a timer until something comes online, then continue.
Mix worlds — combine plain HTTP requests with Home Assistant service calls in the same routine. HTTP-only Macros work even when Home Assistant is unreachable.

Free vs Pro

Macros themselves aren’t behind a paywall — every step type is available to everyone while the feature is in BETA. The one limit you’ll meet is inherited: an HTTP Action step draws from your HTTP Actions library, and the free tier includes exactly one HTTP Action. The Home Assistant steps (control a device, call a service, wait for an entity) have no such cap.

Building a Macro

Open Settings → Tools & Automations → Macros and tap New Macro. You can start from a recipe or from a blank macro, then add steps with the Add Step menu.

Give the macro a name (it’s the default tile label) and an icon, then build the step list. Each step shows a one-line summary and its flow — where it goes on success, and where it goes if it fails.

Step Types

The Add Step menu groups the Home Assistant steps on top, then the general-purpose steps below a divider:

Home Assistant

HA · Control a Device — pick a device (light, switch, lock, cover, fan, scene…) and a friendly action (Turn On, Set Brightness, Open, Close…). No YAML or JSON to write.
HA · Call Service — the power-user escape hatch: a raw domain.service call with an optional target entity and a JSON data payload.
HA · Wait for Entity — poll an entity’s live state until a condition matches or a timeout elapses (default 30s, up to 600s) — handy for “wait until the garage is actually closed.”

General

HTTP Action — fire one of your HTTP Actions and, optionally, gate the rest of the macro on what it replies. This includes a Voice Clip Action: the watch pauses mid-macro to record a clip, then POSTs it before moving on.
If / Condition — evaluate a condition and take the Then path or the Else path. The Else branch is opt-in, so a false condition simply falls through to the next step unless you say otherwise.
Run a Macro — call another macro as a reusable sub-routine. Captured values flow in and out, so you can factor a shared sequence out once and reuse it.
Wait — pause for a number of seconds (the wait is wall-clock, so it resumes correctly even if the app suspends mid-pause).
Confirmation — show a message with Continue / Cancel on the watch. Cancel ends the run (or takes your Else path); an unanswered prompt auto-cancels after two minutes.
Show Result (Banner) — flash a message and a haptic, then carry on. Great for a “Done ✓” at the end.

Flow & Branching

By default a macro runs top to bottom: each step continues to the next on success, and the run stops as failed the moment a step fails. You only think about branching when you want something cleverer.

Any step can override where it goes — separately for success and for failure:

Continue to the next step,
Go to a specific step (this is what makes loops and if/else possible),
Finish the run successfully, or
Stop the run as failed.

A condition (on an If / Condition step, or as a gate on an HTTP Action) compares a left-hand value to a right-hand one. Both sides accept {{captures}}. Operators cover equals, is not, contains, matches a regular expression, and numeric <, ≤, >, ≥ (a non-numeric value just evaluates false rather than erroring). Point a failed gate’s “go to” back at an earlier step and you’ve built a retry loop; point success and failure at two different steps and you’ve built if/else.

Captures & Tokens

Give any value-producing step (an HTTP Action, a service call, a device control, a wait-for-entity) a capture name, and its result becomes a {{token}} you can drop into every later step:

in a service call’s target entity or JSON data — {"brightness": {{level}}},
in a confirmation or banner message — Temperature is {{temp}}°,
on either side of a condition — {{temp}} compared to > 25.

Your library-wide HTTP global variables work here too, under the same {{name}} syntax. The editor shows a row of tappable token chips so you insert a capture instead of typing the braces.

Behavior: Auto-Close & Run Silently

Two settings on the macro tile control how a run feels on the wrist:

When the run sheet closes — a three-way choice:

On success (default) — the sheet auto-dismisses after a clean finish; a failure stays on screen so you can read it.
Always — closes on any outcome; a failure rides the action toast instead.
Stay open — never auto-closes; you tap Done.

Run silently — skip the steps sheet entirely and run with just haptics and a result banner. A macro that contains a Confirmation step always shows the sheet anyway — the question can’t be silent.

Testing on the iPhone

You don’t debug a macro by squinting at watch haptics. Every editor has a Test that runs the macro live on the phone — firing the real HTTP requests and real Home Assistant calls — with each step lighting up pending → running → ✓ / ✗, its captured value shown inline, and a retry count when a step repeats.

You can also test a single step two ways:

Test This Step — run just that step in isolation.
Test Up to Here — run the macro from the top through this step, so upstream captures flow in.

Confirmation steps show Continue / Cancel right in the test sheet, and Run a Macro steps expand inline to show the sub-macro’s real steps rather than an opaque “ran it” row.

Running on the Watch

Tap the macro tile and — unless it’s set to run silently — a run sheet appears with a pinned title and a live status line (Running / Completed / Failed / Needs confirmation). Steps light up as they execute, captured values show beneath them, a repeating step gets a ×N badge, and sub-macros nest visually so you see exactly what ran.

A Confirmation step shows its message with Continue / Cancel inline. If the sheet is closed or set to run silently, a failure surfaces on the action toast so you’re never left guessing.

The watch keeps a last-run record per macro — success, failure, or aborted — and the tile carries a small status dot reflecting it.

Recipe Gallery

New macros can start from a built-in recipe, each a tiny working example you finish by connecting your own HTTP Action:

Ping a webhook — fire one request, buzz when it lands.
Fetch a value & show it — read a value back, then show it on your wrist.
Confirm, then fire — ask before acting; a safety tap for risky actions.
Check something & branch — go one way if it’s OK, another if it isn’t.
Retry until ready — keep checking on a loop until it’s ready.

Recipes ship with their HTTP step unbound on purpose — the editor walks you through pointing it at one of your own actions before the macro will run.

Limits & Requirements

Run limits — every macro has a cap on total step executions (default 100) and a wall-clock timeout (default 5 minutes), both adjustable under Run limits in the editor. They exist so a runaway loop can’t run forever.
Sub-macros — nest up to 5 levels deep; the editor blocks reference cycles before you can save.
Home Assistant steps need a live Home Assistant connection on the watch — the editor warns you if you test them while disconnected. HTTP-only macros have no such requirement and keep working when HA is down.
Preflight checks — the iPhone editor lints a macro before it can run: an empty macro, an unconnected HTTP step, a missing target, a broken “go to”, or bad JSON are all flagged with per-step detail.