Skip to main content

Automation Triggers

An Automation is an "if this, then that" rule that spans Nodes: when a condition holds on one device, ESP RainMaker Neo writes Parameters on others. It is assembled from two pieces — Triggers, which watch a single Node, and the Automation itself, which combines Triggers and performs the Actions.

The distinction from Schedules matters, and is worth stating plainly:

Schedules run on the Node against its own clock; Automations are evaluated in the cloud. A Schedule keeps firing while the Node is offline; an Automation cannot run at all unless the cloud is reachable.

What the user sees​

Three things to define, in this order:

  1. Triggers on the Node to watch. A Trigger names a Parameter path, a comparison operator, and a value — for example Light.Power eq true. Triggers belong to one Node and are pushed down to its firmware, which is what actually decides that the condition became true.
  2. A condition combining Trigger references with and or or. and requires every listed Trigger to be true; or requires any one. If both are given, the result is (all of and) OR (any of or).
  3. Actions — a list of targets, each naming a Node, a Parameter path such as Light.Power, and the value to write.

An Automation also has a name, an optional description, and a status of enabled or disabled. A disabled Automation is still stored and still tracks its Triggers; it simply never runs its Actions.

Automations are Group-scoped. They live in the Group, and their Action targets are Nodes in that Group. Triggers, by contrast, are per-Node — and independent of Automations. Deleting an Automation leaves the Trigger definitions on their Nodes, where the firmware keeps evaluating them; they are simply no longer wired to anything.

Writes replace, they do not merge. A write to a Node's Trigger set replaces the whole array — there is no per-Trigger endpoint. Likewise, updating an Automation replaces it wholesale.

What the firmware must do​

Trigger evaluation is built in, alongside Schedules, and comes up with esp_rmaker_node_init(). There is nothing to enable.

  • Accept the Trigger set from the cloud and evaluate it against your Parameter values. The supported operators are eq, ne, gt, lt, ge, le; the ordered ones are valid only on numeric Parameters, and the value's type is inferred from its JSON type — there is no type field.
  • Report a fired Trigger to the cloud. Nothing happens until the Node says a Trigger changed.
  • Nothing to do for Actions. An Action arrives as an ordinary Parameter write on the Node's desired state, so your existing write callback handles it with no new code.

See Schedules and automations for the firmware side.

What the operator must do​

Nothing per deployment. Automations run inside the base platform: the definitions live in an Automations table keyed by Group, and evaluation happens in the same pipeline that handles Node notifications. There is no rules engine to provision and no external rules service in the path.

Two operational behaviours worth knowing:

  • Automations self-clean when a Node leaves a Group. If the departing Node appears in an Automation's condition, the whole Automation is deleted — a condition referencing an absent Node can never be meaningfully satisfied. If it appears only among the Action targets, those targets are stripped, and the Automation is deleted only if nothing remains. Deleting a Group wipes all of its Automations.
  • Read access is granted separately from list access. A user shared into a single Subgroup can enumerate that Group's sub-entities but cannot read or list its Automations. That is deliberate, so Automation definitions are not leaked to Subgroup-only members.
Actions are not re-authorised at fire time

Action execution writes to whichever Nodes the Automation names, running with system privilege. The control point is who may create or edit Automations in the Group, not who may write to the target Node. Treat edit access to a Group's Automations as write access to every Node in it.

Limits and caveats​

Offline Nodes. A Trigger on an offline Node cannot report, so the Automation never fires. An Action aimed at an offline Node is written to its desired state and applied when it reconnects — the Action is not lost, but it is not immediate either.

Condition shape. One flat combination of and and or. There is no nesting and no negation.

No time-based Triggers. Automations are event-driven, fired by Node Trigger reports. Time-based rules are Schedules.

No write-time validation of meaning. The cloud checks only that Trigger IDs are unique strings and that a status is enabled or disabled. A condition referencing a Trigger that does not exist, or an Action naming a Parameter that does not exist, is accepted on write and quietly skipped at run time.

Automation ID — a three-character token minted by the cloud on create and returned to the caller. Unique within the Group, not globally.

Cross-Node spoofing is blocked. A Node can only flip Trigger values attributed to itself; a report naming another Node's Trigger is dropped.

Trigger count limits unconfirmed

Neither specification states a maximum number of Triggers per Node, Automations per Group, or Action targets per Automation. No limit beyond the DynamoDB item-size ceiling is documented — if your design pushes these boundaries, verify against your deployment.