As described in the Rule Engine Getting Started, a trigger is an event or condition that initiates rule execution. For a trigger to execute a rule, it must be attached to the rule. The same trigger can be attached to none, one, or many rules.
If a trigger is not attached to any rule, it is passive because it has nothing to execute. If a trigger is attached to one or more rules, it is active, meaning it will execute the rule(s) once the monitored condition occurs, e.g., a device posted telemetry.
As you may recall from Rule Engine Getting Started, a rule is always executed for a particular endpoint. The trigger is responsible for determining that endpoint. A trigger always monitors conditions for an endpoint or a set of endpoints. If a trigger is configured for a specific endpoint, it monitors the condition only for that endpoint. If a trigger is configured for an application or application version, it monitors the condition for all endpoints belonging to that application or version.
All trigger types, among others, share a common set of fields:
Only one of these three options must be specified: either Application, Application version name, or Endpoints. These fields define for which endpoint(s) the attached rule(s) must be executed.
Executes a rule once the endpoint metadata is updated on a monitored endpoint. Metadata can be updated either via the UI or by the endpoint itself.
Executes a rule once an endpoint posts telemetry via the MQTT device API or the HTTP device API.
Executes a rule once the monitored time series value is updated.
Executes a rule once a monitored command type (e.g., SWITCH_ON
) is dispatched to an endpoint.
Commands are dispatched from the UI or via the REST API.
Executes a rule once an endpoint reports an executed command via the MQTT device API or the HTTP device API.
Executes a rule once a monitored alert lifecycle event occurs. Available alert lifecycle events:
HIGH
to CRITICAL
.CRITICAL
to HIGH
.Executes a rule based on a cron expression or at a specified interval.