Skip to main content

Automation Triggers

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

Schedules run on the Node; Automations run 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.
  3. Actions — a list of targets, each naming a Node, a Parameter path such as Light.Power, and the value to write.

An Automation named Too Hot, evaluated in the cloud: two Triggers on two different Nodes — Sensor.Temperature greater than 30 on Patio Sensor, and Window.Open equal to false on Bedroom Window — are combined by a flat and condition, which then writes AC.Power true on Living Room AC and Fan.Speed 5 on Ceiling Fan

An Automation has 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.

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.

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.
  • Subgroup access is limited. 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.

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 lost.

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