ACTION Triggers

Overview

Every Action needs a trigger—the event that starts its execution. Choosing the right trigger type determines how your automation responds to real-world conditions.

Think of triggers like different ways to start your car. A time-based trigger is like an auto-start that warms up your car every morning at 7 AM. A topic-based trigger is like pushing the start button when you get in. A callable action is like asking someone else to start it for you.

When to Use Each Type

Trigger Type	Use When	Example
Time-Based (`ON EVERY`, `ON TIMESTAMP`)	You need a clock-driven schedule (interval or wall-clock)	Heartbeats, polling, shift windows, one-shot cutovers
Topic-Based (`ON TOPIC`, `ON CHANGE`)	You need to react when MQTT data arrives	Sensor processing, commands; `ON CHANGE` when only new values matter
Initialization (`ON START`)	You need to run logic once when the broker starts	Bootstrap UNS structure, set default config values
Callable (no trigger)	You need reusable logic invoked by other actions	Utility functions, shared calculations

Time-Based Triggers

LoT supports several time-based trigger forms. All of them use the ON keyword and run the action’s DO block automatically—no MQTT message is required to fire them. Together they cover recurring intervals, calendar rules (a specific weekday, Monday–Friday, or Saturday–Sunday), daily wall-clock times, and single one-shot executions.

Quick reference

Syntax	Pattern	Recurs?
`ON EVERY` N UNIT	Every N seconds, minutes, hours, and so on	Yes — indefinitely
`ON EVERY` DAY `AT` `"HH:mm"`	Named weekday at a fixed local time	Yes — every week
`ON EVERY WEEKDAY AT` `"HH:mm"`	Monday–Friday at a fixed local time	Yes — every weekday
`ON EVERY WEEKEND AT` `"HH:mm"`	Saturday–Sunday at a fixed local time	Yes — every weekend
`ON TIMESTAMP` `"HH:mm:ss"`	Every day at a fixed local time	Yes — every day
`ON TIMESTAMP` `"dd-MM-yyyy HH:mm:ss"`	Exact date and time	No — one-shot

Time zone: For HH:mm and HH:mm:ss in ON EVERY … AT and in daily ON TIMESTAMP, values are interpreted in the local time of the machine running the broker, then converted to UTC internally. The action is scheduled for the correct wall-clock time across daylight saving changes. The one-shot form dd-MM-yyyy HH:mm:ss is interpreted as UTC, as described below.

Structured payloads: PUBLISH TOPIC does not support inline JSON object literals. For multi-field records, define a COLLAPSED model and use PUBLISH MODEL … TO … WITH (see Publishing Models). The timed-action examples below use that pattern.

1. `ON EVERY` N UNIT — fixed interval

Fires repeatedly every N units of time. Common for monitoring, polling, and heartbeats.

DEFINE ACTION <Name>
ON EVERY <N> <UNIT> DO
    -- body

Supported units

Keyword(s)	Example
`MILLISECOND` / `MS`	`ON EVERY 500 MS`
`SECOND` / `SECONDS`	`ON EVERY 30 SECONDS`
`MINUTE` / `MINUTES`	`ON EVERY 5 MINUTES`
`HOUR` / `HOURS`	`ON EVERY 1 HOUR`
`DAY` / `DAYS`	`ON EVERY 1 DAY`
`WEEK` / `WEEKS`	`ON EVERY 2 WEEKS`
`MONTH` / `MONTHS`	`ON EVERY 1 MONTH`
`YEAR` / `YEARS`	`ON EVERY 1 YEAR`

Singular and plural unit names are interchangeable (for example, 1 SECOND and 1 SECONDS). ON EVERY 1 DAY fires every 24 hours from the last run; for the same clock time every calendar day, use daily ON TIMESTAMP instead.

DEFINE ACTION SystemHeartbeat
ON EVERY 5 SECONDS DO
    PUBLISH TOPIC "system/heartbeat" WITH "alive"
    PUBLISH TOPIC "system/heartbeat/timestamp" WITH TIMESTAMP "UTC"

DEFINE ACTION PollMachineTemperature
ON EVERY 30 SECONDS DO
    SET "temp" WITH GET TOPIC "machine/sensor/temperature"
    IF {temp} > 85 THEN
        PUBLISH TOPIC "alerts/temperature/high" WITH {temp}
    PUBLISH TOPIC "machine/temperature/last_check" WITH TIMESTAMP "UTC"

DEFINE ACTION FastSensorSample
ON EVERY 500 MS DO
    PUBLISH TOPIC "sensors/vibration/sample" WITH GET TOPIC "sensors/vibration/raw"

2. `ON EVERY` DAY `AT` — weekly, specific day

Fires once per week on the named weekday at the given local time. Use "HH:mm" or "HH:mm:ss"; seconds are optional.

Keyword	Fires on
`MONDAY` … `SUNDAY`	That weekday each week

DEFINE ACTION <Name>
ON EVERY MONDAY AT "08:00:00" DO
    -- body

DEFINE MODEL ProductionWeeklyReport COLLAPSED
    ADD STRING "week"
    ADD INT "total_parts"
    ADD INT "total_rejects"

DEFINE ACTION WeeklyProductionReport
ON EVERY MONDAY AT "08:00:00" DO
    SET "week_total" WITH GET TOPIC "factory/line1/parts_produced"
    SET "week_rejects" WITH GET TOPIC "factory/line1/rejects"
    PUBLISH MODEL ProductionWeeklyReport TO "reports/weekly/production" WITH
        week = TIMESTAMP "UTC"
        total_parts = {week_total}
        total_rejects = {week_rejects}
    PUBLISH TOPIC "factory/line1/parts_produced" WITH 0
    PUBLISH TOPIC "factory/line1/rejects" WITH 0

3. `ON EVERY WEEKDAY AT` — Monday–Friday

Fires Monday through Friday at the same local time—one action instead of five separate daily schedules.

DEFINE MODEL ShiftMorningBriefing COLLAPSED
    ADD STRING "line_status"
    ADD STRING "pending_orders"
    ADD STRING "shift_start"

DEFINE ACTION ShiftStartBriefing
ON EVERY WEEKDAY AT "07:30" DO
    SET "line_status" WITH GET TOPIC "factory/line1/status"
    SET "pending_orders" WITH GET TOPIC "erp/orders/pending"
    PUBLISH MODEL ShiftMorningBriefing TO "shift/briefing/morning" WITH
        line_status = {line_status}
        pending_orders = {pending_orders}
        shift_start = TIMESTAMP "UTC"

4. `ON EVERY WEEKEND AT` — Saturday and Sunday

Fires on both weekend days at the specified local time—useful for maintenance windows or weekend-only reporting.

DEFINE ACTION WeekendMaintenanceWindow
ON EVERY WEEKEND AT "06:00:00" DO
    PUBLISH TOPIC "maintenance/window/open" WITH "true"
    PUBLISH TOPIC "maintenance/window/start" WITH TIMESTAMP "UTC"
    PUBLISH TOPIC "notifications/maintenance" WITH "Weekend maintenance window is now open"

5. `ON TIMESTAMP` — daily fixed time

Fires every day at the given local wall-clock time. Unlike ON EVERY 1 DAY, this tracks clock time, not elapsed time since the broker or last run started.

DEFINE ACTION <Name>
ON TIMESTAMP "08:00:00" DO
    -- body

"HH:mm" without seconds is accepted.

DEFINE ACTION DailyCounterReset
ON TIMESTAMP "00:00:00" DO
    PUBLISH TOPIC "factory/line1/parts_produced" WITH 0
    PUBLISH TOPIC "factory/line1/rejects" WITH 0
    PUBLISH TOPIC "factory/line1/day_start" WITH TIMESTAMP "UTC"

6. `ON TIMESTAMP` — one-shot, exact date and time

Fires once at the exact instant given, then never again (the scheduler moves the next run far into the future). Format is strictly dd-MM-yyyy HH:mm:ss (day–month–year). The timestamp is treated as UTC.

DEFINE ACTION SystemCutoverNotice
ON TIMESTAMP "01-04-2026 06:00:00" DO
    PUBLISH TOPIC "system/cutover/notice" WITH "New firmware version going live in 1 hour"
    PUBLISH TOPIC "notifications/all" WITH "Scheduled maintenance begins at 07:00 UTC"

Combination patterns

Real systems often split schedules across several actions—one trigger per concern.

Fast poll + daily summary

DEFINE MODEL DailyTemperatureReport COLLAPSED
    ADD DOUBLE "max"
    ADD DOUBLE "min"
    ADD STRING "date"

DEFINE ACTION SensorPoll
ON EVERY 10 SECONDS DO
    SET "value" WITH GET TOPIC "sensors/temperature/raw"
    PUBLISH TOPIC "sensors/temperature/current" WITH {value}

DEFINE ACTION DailySensorSummary
ON TIMESTAMP "00:00:00" DO
    SET "max" WITH GET TOPIC "sensors/temperature/max"
    SET "min" WITH GET TOPIC "sensors/temperature/min"
    PUBLISH MODEL DailyTemperatureReport TO "reports/daily/temperature" WITH
        max = {max}
        min = {min}
        date = TIMESTAMP "UTC"
    PUBLISH TOPIC "sensors/temperature/max" WITH 0
    PUBLISH TOPIC "sensors/temperature/min" WITH 0

Weekday operations + weekend maintenance

DEFINE ACTION WeekdayProductionStart
ON EVERY WEEKDAY AT "06:00" DO
    PUBLISH TOPIC "factory/line1/mode" WITH "production"
    PUBLISH TOPIC "factory/line1/shift_start" WITH TIMESTAMP "UTC"

DEFINE ACTION WeekendMaintenance
ON EVERY WEEKEND AT "07:00" DO
    PUBLISH TOPIC "factory/line1/mode" WITH "maintenance"
    PUBLISH TOPIC "notifications/maintenance/start" WITH TIMESTAMP "UTC"

Weekly reset + daily snapshot + live throughput

DEFINE MODEL DashboardThroughput COLLAPSED
    ADD INT "parts"
    ADD DOUBLE "rate_per_min"
    ADD INT "updated"

DEFINE ACTION WeeklyKpiReset
ON EVERY MONDAY AT "00:00:00" DO
    PUBLISH TOPIC "kpi/weekly/parts_produced" WITH 0
    PUBLISH TOPIC "kpi/weekly/reset_time" WITH TIMESTAMP "UTC"

DEFINE ACTION DailyKpiSnapshot
ON TIMESTAMP "23:59:00" DO
    SET "daily_parts" WITH GET TOPIC "factory/line1/parts_produced"
    PUBLISH TOPIC "kpi/daily/snapshot" WITH {daily_parts}
    PUBLISH TOPIC "kpi/daily/snapshot_time" WITH TIMESTAMP "UTC"

DEFINE ACTION LiveThroughput
ON EVERY 1 MINUTE DO
    SET "parts" WITH GET TOPIC "factory/line1/parts_produced"
    SET "rate" WITH GET TOPIC "factory/line1/production_rate"
    PUBLISH MODEL DashboardThroughput TO "dashboard/live/throughput" WITH
        parts = {parts}
        rate_per_min = {rate}
        updated = TIMESTAMP "UNIX"

One-shot cutover + ongoing heartbeat

DEFINE ACTION CutoverActivation
ON TIMESTAMP "01-07-2026 06:00:00" DO
    PUBLISH TOPIC "system/version" WITH "2.0"
    PUBLISH TOPIC "system/cutover/complete" WITH TIMESTAMP "UTC"

DEFINE ACTION V2Heartbeat
ON EVERY 30 SECONDS DO
    SET "ver" WITH GET TOPIC "system/version"
    IF {ver} EQUALS "2.0" THEN
        PUBLISH TOPIC "system/v2/heartbeat" WITH "running"

Error handling

If a time string does not match an expected format, the broker logs an error similar to: Invalid DATE_TIME format: <value>. Expected formats:

dd-MM-yyyy HH:mm:ss (one-time)
HH:mm:ss / HH:mm (daily)
Weekly forms using a day name with AT and a time string

Errors are also published (retained) to: $SYS/Coreflux/Actions/<ActionName>/Error Subscribe to $SYS/Coreflux/Actions/+/Error to observe failures from any action.

At a glance — valid time triggers

ON EVERY 500 MS DO
ON EVERY 10 SECONDS DO
ON EVERY 5 MINUTES DO
ON EVERY 1 HOUR DO
ON EVERY 1 DAY DO
ON EVERY 1 WEEK DO
ON EVERY 1 MONTH DO
ON EVERY MONDAY AT "08:00:00" DO
ON EVERY WEEKDAY AT "07:30" DO
ON EVERY WEEKEND AT "06:00" DO
ON TIMESTAMP "07:00" DO
ON TIMESTAMP "00:00:00" DO
ON TIMESTAMP "25-12-2026 09:00:00" DO

More examples

System heartbeat

DEFINE ACTION SystemHeartbeat
ON EVERY 5 SECONDS DO
    PUBLISH TOPIC "system/status" WITH "online"
    PUBLISH TOPIC "system/timestamp" WITH TIMESTAMP "UTC"

Counter with state

DEFINE ACTION IncrementCounter
ON EVERY 10 SECONDS DO
    IF GET TOPIC "counter/value" == EMPTY THEN
        PUBLISH TOPIC "counter/value" WITH 0
    ELSE
        PUBLISH TOPIC "counter/value" WITH (GET TOPIC "counter/value" + 1)

Topic-Based Triggers

MQTT-driven actions use a topic trigger — the condition that tells the broker when to run the action body. Both triggers share the same topic patterns and wildcards; the difference is whether repeated identical payloads should be ignored.

Trigger	When the action runs
`ON TOPIC`	On every message that matches the topic pattern
`ON CHANGE`	When the message matches the pattern and the payload is different from the last message on that same topic

`ON TOPIC` — react to every message

Use ON TOPIC when each publish matters: commands, alarms, counters, or any flow where duplicate payloads still need processing.

DEFINE ACTION ProcessTemperature
ON TOPIC "sensors/+/temperature" DO
    SET "sensor_id" WITH TOPIC POSITION 2
    SET "temp" WITH PAYLOAD AS DOUBLE
    PUBLISH TOPIC "processed/" + {sensor_id} + "/temperature" WITH {temp}

Key characteristics:

Any client (or route) that publishes to a matching topic runs the action.
Publishing the same value twice runs the action twice.
Wildcard + matches one topic level (same rules as MQTT wildcards).

`ON CHANGE` — react only when the value changes

Use ON CHANGE for telemetry, status fields, or setpoints that are published often but only need logic when the reading actually changes. This reduces CPU load, database writes, and downstream noise.

DEFINE ACTION ProcessTemperatureOnChange
ON CHANGE "sensors/+/temperature" DO
    SET "sensor_id" WITH TOPIC POSITION 2
    SET "temp" WITH PAYLOAD AS DOUBLE
    PUBLISH TOPIC "processed/" + {sensor_id} + "/temperature" WITH {temp}

Key characteristics:

The first message on a given topic always runs the action (there is no previous value yet).
Later messages run the action only if the payload bytes are not identical to the last message on that exact topic name.
Example: sensors/line1/temperature and sensors/line2/temperature are tracked separately.
Wildcard patterns work the same as ON TOPIC; change is evaluated per real topic, not per pattern.

What counts as “changed”? Comparison is on the raw message body (bytes), not on parsed numbers or JSON. 25 and 25.0 are different payloads. {"temp":25} and {"temp": 25} (different spacing) are different payloads. If you need semantic equality (for example, treat 25 and 25.0 as the same), handle that inside an ON TOPIC action with your own logic.

Choosing between `ON TOPIC` and `ON CHANGE`

Situation	Recommended trigger
Commands, events, “do something” signals	`ON TOPIC`
Alarms that must fire on every notification	`ON TOPIC`
High-frequency sensor values (temperature, level, status)	`ON CHANGE`
Writing to a database or historian only when value moves	`ON CHANGE`
Forwarding data only when it differs	`ON CHANGE`
Same pattern, but some actions need every message and others only on change	Use both (two actions on the same pattern)

You can deploy two actions on the same topic pattern: one with ON TOPIC and one with ON CHANGE. The broker runs ON TOPIC every time and skips the ON CHANGE action when the payload is unchanged.

Side-by-side example

Two devices publish temperature every second. Only 22.5 → 23.1 should trigger heavy processing.

DEFINE ACTION LogEveryReading
ON TOPIC "sensors/+/temperature" DO
    PUBLISH TOPIC "logs/all" WITH PAYLOAD

On value change only:

DEFINE ACTION ProcessWhenDifferent
ON CHANGE "sensors/+/temperature" DO
    SET "temp" WITH PAYLOAD AS DOUBLE
    PUBLISH TOPIC "analytics/updated" WITH {temp}

Publish to	Payload	`LogEveryReading`	`ProcessWhenDifferent`
`sensors/a/temperature`	`22.5`	Runs	Runs (first value)
`sensors/a/temperature`	`22.5`	Runs	Skipped (unchanged)
`sensors/a/temperature`	`23.1`	Runs	Runs (changed)

Inside the action body, PAYLOAD is the content of the message that fired the trigger, and TOPIC POSITION N is segment N of the actual topic (1-based), useful with +.

Wildcard Patterns

LoT supports MQTT wildcards for flexible topic matching:

Single-Level (+)
Multi-Level (+/+)

The + wildcard matches exactly one topic level:

DEFINE ACTION SensorRouter
ON TOPIC "sensors/+/temperature" DO
    // POSITION 1="sensors", POSITION 2=wildcard (sensor_id), POSITION 3="temperature"
    SET "sensor_id" WITH TOPIC POSITION 2
    PUBLISH TOPIC "processed/" + {sensor_id} + "/temp" WITH PAYLOAD

Matches: sensors/room1/temperature, sensors/room2/temperature

Does NOT match: sensors/building1/floor2/temperature (too many levels)

Use multiple single-level wildcards for deeper hierarchies:

DEFINE ACTION FactoryMonitor
ON TOPIC "factory/+/+/status" DO
    // POSITION 1="factory", POSITION 2=line_id, POSITION 3=machine_id, POSITION 4="status"
    SET "line_id" WITH TOPIC POSITION 2
    SET "machine_id" WITH TOPIC POSITION 3
    
    PUBLISH TOPIC "monitoring/" + {line_id} + "/" + {machine_id} WITH PAYLOAD

Matches: factory/line1/machine1/status, factory/line2/press3/status

Does NOT match: factory/line1/status (missing one level), factory/status (missing two levels)

Initialization Triggers

Use ON START to execute logic exactly once when the broker starts or when the action is first deployed. This is the right place to bootstrap a Unified Namespace (UNS) structure, publish retained default configurations, and log startup events.

DEFINE ACTION InitUNSRoot
ON START DO
    KEEP TOPIC "config/uns_root" WITH "factory/lisbon"
    KEEP TOPIC "factory/info/name" WITH "Lisbon Plant"
    KEEP TOPIC "factory/info/timezone" WITH "Europe/Lisbon"
    PUBLISH TOPIC "system/log" WITH "UNS root initialised"

Key characteristics:

Runs exactly once per broker start — not on a schedule, not on a message
KEEP TOPIC publishes with the retain flag so the value is delivered to any future subscriber immediately on connection
Use it to set default configuration values and retained state that must survive restarts
There is no ON STOP equivalent — ON START is the correct place for setup logic

Callable Actions

Actions without a trigger clause (ON TOPIC, ON EVERY, ON START, and so on) are callable—they run only when another ACTION calls them with CALL ACTION. Use callables for reusable logic (conversions, validation, shared math) that several trigger-based Actions need. They accept typed INPUT parameters and can RETURN one or more OUTPUT values.

Full guide: Callable ACTIONs—reusable logic, on-demand scripts, and CALL ACTION syntax.

DEFINE ACTION CalculateAverage
INPUT value1 AS DOUBLE
INPUT value2 AS DOUBLE
DO
    SET "avg" WITH (({value1} + {value2}) / 2)
RETURN
    OUTPUT avg

DEFINE ACTION ProcessSensorPair
ON TOPIC "sensors/pair/data" DO
    SET "temp1" WITH (GET JSON "sensor1" IN PAYLOAD AS DOUBLE)
    SET "temp2" WITH (GET JSON "sensor2" IN PAYLOAD AS DOUBLE)
    CALL ACTION CalculateAverage
        WITH value1 = {temp1}, value2 = {temp2}
        RETURN result
    PUBLISH TOPIC "sensors/average" WITH {result}

Comparing Trigger Types

Aspect	Time-Based	Topic-Based	ON START	Callable
Trigger	Clock interval or schedule	MQTT message	Broker startup	Manual command
Frequency	Interval, daily, weekly, or once	Event-driven	Once	On-demand
Payload Access	No	Yes (`PAYLOAD`)	No	Via parameters
Best For	Monitoring, reporting	Data processing	Initialization	Reusable utilities

Next Steps

Callable ACTIONs

Reusable logic, on-demand scripts, and CALL ACTION.

Operations

Learn about SET, GET, PUBLISH, and conditional logic.

Quick Start

Developing and Managing Coreflux

Coreflux MQTT Broker

LoT Language

Product Updates

Overview

When to Use Each Type

Time-Based Triggers

Quick reference

1. `ON EVERY` N UNIT — fixed interval

Supported units

2. `ON EVERY` DAY `AT` — weekly, specific day

3. `ON EVERY WEEKDAY AT` — Monday–Friday

4. `ON EVERY WEEKEND AT` — Saturday and Sunday

5. `ON TIMESTAMP` — daily fixed time

6. `ON TIMESTAMP` — one-shot, exact date and time

Combination patterns

Error handling

At a glance — valid time triggers

More examples

Topic-Based Triggers

`ON TOPIC` — react to every message

`ON CHANGE` — react only when the value changes

Choosing between `ON TOPIC` and `ON CHANGE`

Side-by-side example

Wildcard Patterns

Initialization Triggers

Callable Actions

Comparing Trigger Types

Next Steps

Callable ACTIONs

Operations

​Overview

​When to Use Each Type

​Time-Based Triggers

​Quick reference

​1. ON EVERY N UNIT — fixed interval

​Supported units

​2. ON EVERY DAY AT — weekly, specific day

​3. ON EVERY WEEKDAY AT — Monday–Friday

​4. ON EVERY WEEKEND AT — Saturday and Sunday

​5. ON TIMESTAMP — daily fixed time

​6. ON TIMESTAMP — one-shot, exact date and time

​Combination patterns

​Error handling

​At a glance — valid time triggers

​More examples

​Topic-Based Triggers

​ON TOPIC — react to every message

​ON CHANGE — react only when the value changes

​Choosing between ON TOPIC and ON CHANGE

​Side-by-side example

​Wildcard Patterns

​Initialization Triggers

​Callable Actions

​Comparing Trigger Types

​Next Steps

Callable ACTIONs

Operations

Overview

When to Use Each Type

Time-Based Triggers

Quick reference

1. `ON EVERY` N UNIT — fixed interval

Supported units

2. `ON EVERY` DAY `AT` — weekly, specific day

3. `ON EVERY WEEKDAY AT` — Monday–Friday

4. `ON EVERY WEEKEND AT` — Saturday and Sunday

5. `ON TIMESTAMP` — daily fixed time

6. `ON TIMESTAMP` — one-shot, exact date and time

Combination patterns

Error handling

At a glance — valid time triggers

More examples

Topic-Based Triggers

`ON TOPIC` — react to every message

`ON CHANGE` — react only when the value changes

Choosing between `ON TOPIC` and `ON CHANGE`

Side-by-side example

Wildcard Patterns

Initialization Triggers

Callable Actions

Comparing Trigger Types

Next Steps