Skip to main content

Rule Engine 2

The Rule Engine lets you build event-driven automations visually. Instead of a single "if this then that" statement, you connect blocks on a canvas: a rule starts at a trigger, optionally branches through one or more conditions, and ends in one or more actions. When a matching event arrives, Yggio walks the graph from the trigger and runs the actions it reaches.

Opening the editor

Open Rule Engine from the navigation menu. The page lists your existing rules and opens the canvas editor. From the canvas you can:

  • start from a template for a ready-made rule you only need to finish, or
  • start from Blank and drag blocks from the palette yourself.

The palette on the left is grouped into Triggers, Conditions and Actions. Drag an item onto the canvas to add it, then drag from a block's handle to another block to connect them.

Building a rule

A rule must contain at least one trigger - you can add several, and the rule runs whenever any of them fires. Every trigger must connect to at least one downstream block. The smallest valid rule is a single trigger wired directly to one action.

  1. Add a trigger and configure what it listens to (see below).
  2. Optionally add conditions and connect the trigger to them.
  3. Add the actions to run and connect them to the trigger or to a condition branch.
  4. Give the rule a name, then Save.

Select any block to edit its settings in the right-hand panel. The editor validates the rule as you build it and reports problems such as a missing trigger, an unconnected trigger, or an action that is wired incorrectly.

Enabling and disabling

A rule has an enabled switch. A disabled rule is kept but never runs - use it to pause an automation without deleting it.

Triggers

A trigger decides which events start the rule.

TriggerFires when
Device updatedOne of the selected devices reports new data.
Missing expected reportA device has not reported within the interval you expect it to.

For a Device updated trigger you must select at least one device. The rule only runs for events from the devices you pick.

Conditions

A condition evaluates the incoming event and splits the flow into a true and a false branch. Connect downstream blocks to the branch you want them to run on.

The Value threshold condition compares a left operand against a right operand using an operator:

  • Each operand is either a field path into the event data (for example a measurement field) or a fixed value.
  • Operators: equals, not equals, greater than, greater than or equal, less than, less than or equal, contains, does not contain.

When the comparison is true the true branch runs; otherwise the false branch runs.

Actions

Actions are what the rule does when the flow reaches them. Most actions send a message through a connector, so create the relevant connector first.

ActionWhat it does
Send MQTTPublishes a payload to an MQTT topic.
Send emailSends an email to organization members or custom addresses.
Send SMSSends an SMS to organization members or custom numbers.
Send HTTPCalls an external endpoint with a method, headers, params and body.
Do nothingA placeholder that runs no action - handy while building.

When an action runs

Messaging actions have an execution policy that controls how often they fire relative to a condition:

  • Every event - run every time the flow reaches the action.
  • On enter - run once when the condition becomes true (a false-to-true transition). Connect the action to the condition's true branch.
  • On exit - run once when the condition becomes false again. Connect the action to the condition's false branch.

"On enter" and "on exit" let you, for example, send one alert when a value crosses a threshold and a separate "all clear" when it returns to normal, instead of repeating the same message on every report.

Templates

Templates give you a starting graph that you finish by filling in devices, connectors and values. Templates that still need details show a Needs setup badge.

TemplateStarting point
BlankAn empty canvas.
Value alertA value-threshold check feeding a Send HTTP action you can configure.
Missing reportA missing-expected-report trigger feeding an action.
Device updateA value-threshold check feeding a Send MQTT action you can point at another device.

History

Each rule keeps a record of its recent runs. Open History for a rule to see, for each run, which conditions matched, which actions ran and what event data was involved. This is the quickest way to confirm a rule behaves as intended after you save it.

Managing access

Rules are access-controlled like other Yggio resources. Save a rule first, then use its access controls to share it - read access lets others view the rule, and higher levels let them edit or administer it.