Trigger Schemes

Trigger schemes organize “when to check, which conditions to evaluate, and which actions to execute” into reusable rules.

Scheme structure

A scheme may contain multiple triggers, each with conditions and actions. Conditions can be combined using AND / OR. Schemes can be enabled or disabled and assigned an overall effective date range.

Condition	Purpose
CRON	Run on a calendar schedule
TIME_POINT	Run at a specified daily time, optionally within the scheme’s date range
TIME_PERIOD	Check within a specified time period
INTERVAL	Check at a fixed interval
DATA_CHANGE	Evaluate conditions when point values change; supports shared data

Data-condition scripts return a Boolean. Explicitly check for missing data or convert with tonumber first to avoid treating missing data as a valid observation.

Actions and return values

Actions can write to writable points, time schedules, aggregation variables, or remote devices, and can also record alarms, submit alarm observations, and publish MQTT messages.

Scheme or context	Script return value
EXPRESSION scheme	Action array indexed from 1
MIXED single-point write	Single value for the corresponding point
Data-change condition	true / false

For example, update an aggregation runtime variable in an EXPRESSION action:

return {buildGeneralWriteMap("Aggregation", "demo_state", "ready", false)}

Replace the example point with an actual configured point before use. The function only constructs a pending action; it does not indicate successful execution by a device.

Alarm rules

Simple notifications can create individual alarm records. When recovery and handling workflows are required, use alarm events: continuously report ACTIVE, NORMAL, or UNKNOWN observations, rather than triggering only on abnormalities.

Post-processing and execution records

Actions support post-processing through needPostProcess / postProcessContent. Script validation can check the return structure, but expressions are evaluated, so inspect potential side effects before validating scripts containing direct calls.

Query trigger records to inspect conditions, execution results, and errors. When controlling devices, also inspect device control logs and point readback to distinguish a sent request from actual device execution.

Dynamic devices and scheme activation

Prefix, suffix, and other queries can handle changing device counts. Batch queries return tables keyed by dataKey; iterate with pairs(). Dynamically constructed query patterns require verification that dependencies are complete. Affected points can be configured in a scheme; its details show their current values to help explain the strategy.

Disabled, deleted, or expired schemes unload their runtime tasks, and parent scheme status is checked before execution. Verify the actual outcome of commands already sent to devices. Rate-limit high-frequency strategies as needed to reduce repeated commands.

See the trigger action reference and Lua reference for detailed scripts. For Agent-based configuration, use the trigger scheme Skill.