Macros: automation sequences that run on the ESP32 gateway, not in the cloud

Updated 15 Sep 2026

A macro is a small program you build once and run whenever you want — a sequence of device commands with waits, loops, and simple logic. The classic example: a DIY camera slider that glides A → B → A a few times with smooth acceleration, triggered from your phone. But macros drive any actuator — relays, PWM dimmers, Modbus registers, stepper motors.

Macros run on your gateway, not in the cloud. The platform compiles your macro into a compact program and pushes it to the gateway, which executes it locally. That's the only way fast, fine-grained motion (like micro-second stepper timing) can stay smooth. Only "call a webhook / publish to MQTT" steps run on our servers.

Requirements: a Synacl gateway running firmware 1.2.0+. Stepper moves need a gpio-stepper device (STEP/DIR/EN pins) configured on that gateway.

Build a macro

Open Macros → New Macro and give it a name and a target gateway. Then build the routine two ways — switch freely between them:

• Blocks — add steps from a menu (Move stepper, Set output, PWM, Modbus write, Wait, Read sensor, Set variable, Call backend action, Log/Notify), reorder them, and tick "Repeat whole routine N times" to loop.
• Code — the same routine as JSON, for advanced logic like nested loops or if conditions.

Parameters

Declare parameters (e.g. DISTANCE, MAX_SPEED_US) with defaults and min/max. They become inputs you can change each time you run — so one "slide" macro covers any distance or speed without editing.

Run it

Each macro card has a Run button. If the macro has parameters, you'll get a quick form to tweak them first. While it runs you'll see live status (started → running → done), and an Abort button stops it immediately. You can also drop a Macro Button widget on any dashboard for a big tap-to-run control that works great on a phone.

Trigger it automatically

Beyond the manual button, a macro can run:

• On a schedule — every N seconds, or once a day at a set time (great for a golden-hour timelapse).
• From a sensor rule — add a Run macro action to a Rule so a threshold launches it.
• On a device event — when a device or gateway goes online/offline.

Limits & safety

• Plan limits: your plan can cap how many macros you can create and how many steps each macro can contain. The Macros page shows your current usage and any caps right under the title (e.g. "2 / 5 macros · up to 50 steps each"). On most plans these default to unlimited — so if you don't see a number, there's no cap yet. You'll get a clear message if a save would exceed a limit.
• Macros are bounded by design: a maximum number of instructions, loop iterations, and total run time — a macro can't run away. There's no infinite loop; repeats are always a fixed count.
• Only one macro runs per gateway at a time.
• Actuators move real hardware — start with conservative speeds, and use the macro button's confirm-before-run option for anything that could damage equipment.

None of that is a safety function

This is worth stating plainly, because the limits above can read like protection and they are not.

• The ten-minute run ceiling bounds a mistake, it doesn't make one safe. Ten minutes of a pump, a heater or a stepper is more than enough to flood a room, damage a machine or injure someone.
• Abort is not an emergency stop. It's a message sent from Synacl to the gateway over the network. A macro runs on the gateway, which is the whole point — so if the link is down, the gateway keeps going and abort cannot reach it. Never rely on it to stop something dangerous.
• Synacl is not a safety-rated system. Nothing here is certified for machinery safety, and a macro must never be the thing that protects a person.

If a machine can hurt somebody or destroy something, the protection has to be physical and independent of this platform: a hardwired emergency stop in the power path (not routed through the ESP32), guards and interlocks, a safety-rated relay, and actuators sized so their worst case is something you can live with. Build it so that the software failing — or doing exactly what it was told, at the wrong moment — is survivable. That is true of any automation; it is not special to Synacl, and it is not special to AI.

Let an AI assistant write one

If you have connected an AI assistant over MCP, you can describe the sequence instead of building it: "pulse the pump relay for two seconds, wait a minute, repeat five times". The assistant writes the macro, and if it doesn't compile Synacl tells it exactly which step is wrong so it can fix it and try again. This is the shortest path from an idea to something running on an ESP32 — no toolchain, no firmware, no code.

An assistant cannot run what it writes, by default. Two separate things have to be true before one can start a macro, and you control both:

1. The assistant's permissions include macro:run — a permission that arrives unticked on the approval screen and is never granted by "select all".
2. That specific macro is marked "Let an AI agent run this" — a tick box in the macro editor, off by default on every macro. An assistant can never set it, on its own macros or anyone's.

The second one is the one that matters. A permission decides which software may act; it says nothing about whether a particular sequence is safe to hand over. So the platform asks you about the sequence, one at a time.

Read it before you allow it. An assistant that has never seen your rig gets the shape right and the details wrong in ways that look plausible: a speed that is fine for a slider and wrong for a pump, a duration off by a factor of ten, the right block pointed at the wrong relay. That is the realistic failure — not a model deciding to do harm, but a model being confidently approximate about your hardware. Everything in Limits & safety below still applies to a macro an assistant wrote, and none of it knows what your hardware is attached to.

Triggers stay yours. An assistant cannot put a macro on a schedule or fire it from a device event, whatever permissions it holds. Arming a sequence to run with nobody watching is a decision you make, in this editor.

Worked example — camera slider

Start from the Camera slider template (the "Start from template…" menu). It repeats 3×: move forward, wait, move back, wait — with DISTANCE, MAX_SPEED_US, MIN_SPEED_US, and RAMP_STEPS as parameters. Point the move steps at your gpio-stepper device, set the parameters to your rail, and tap Run.

More examples

Want something to copy and adapt? We have two cookbooks of ready-to-run recipes:

• Starter recipes — pulse a relay, blink an output, dimmer scenes, servo park & sweep, stepper jog & home, Modbus coil/register writes.
• Advanced recipes — fades and ramps with variables, a scheduled thermostat, staged cooling, pump hysteresis, step-and-shoot timelapse, dosing, and condition-triggered webhooks.