ACTION Syntax Reference

Actions are executable logic blocks triggered by events such as timed intervals, topic updates, or explicit calls. They are the primary way to implement automation in LoT.

Actions run inside the MQTT broker itself, eliminating the need for external middleware or application servers.

Basic Syntax

DEFINE ACTION <action_name>
ON <EVENT_TRIGGER>
DO
    <action_logic>

Components

string

required

A unique identifier for the action. Use descriptive names that indicate the action’s purpose (e.g., SensorDataProcessor, HeartbeatMonitor).

trigger

required

Specifies when the action executes. Can be time-based (ON EVERY, ON TIMESTAMP), topic-based (ON TOPIC, ON CHANGE), initialization (ON START), client lifecycle (ON CONNECT, ON DISCONNECT, ON SUBSCRIBE), or omitted for callable actions.

statements

required

One or more LoT statements that execute when the action triggers. These can include publishing, variable assignment, conditionals, and Python calls.

Action Structure

Every action follows this general structure:

DEFINE ACTION ActionName
ON <trigger_type> DO
    // Variable assignment
    SET "variable" WITH <value>
    
    // Conditional logic
    IF <condition> THEN
        // Statements
    ELSE
        // Alternative statements
    
    // Topic operations
    PUBLISH TOPIC "output/topic" WITH <payload>
    KEEP TOPIC "internal/topic" WITH <payload>

Disable an Action

Add DISABLE true on its own line to switch an action off without deleting it:

DEFINE ACTION Heartbeat
DISABLE true
ON EVERY 5 SECONDS DO
    PUBLISH TOPIC "system/heartbeat" WITH TIMESTAMP "UTC"

A disabled action stays defined and listed, but no trigger runs it: topics, ON EVERY, schedules, ON START, and client connect, disconnect, or subscribe. -runAction refuses it, and an action that calls it with CALL ACTION fails to compile until it is enabled again. DISABLE false, or no DISABLE line, means enabled. A DISABLE line inside a comment is ignored. The line is saved with the definition, so the action stays disabled after a restart and in a project export. To switch it without editing the code, use -disableAction <name> and -enableAction <name>. See Disable and enable.

Trigger Types

Time-Based
Topic-Based
Client lifecycle
Callable

Execute at regular intervals:

DEFINE ACTION PeriodicTask
ON EVERY 5 SECONDS DO
    PUBLISH TOPIC "system/heartbeat" WITH "alive"

Supported units: SECOND(S), MINUTE(S), HOUR(S), DAY(S), WEEK(S)

Execute when a topic receives data. Use ON TOPIC for every message, or ON CHANGE to run only when the payload differs from the last message on that topic:

DEFINE ACTION MessageProcessor
ON TOPIC "sensors/temperature" DO
    PUBLISH TOPIC "processed/temp" WITH PAYLOAD

Detection of values changed:

DEFINE ACTION OnValueChange
ON CHANGE "sensors/+/temperature" DO
    PUBLISH TOPIC "analytics/updated" WITH PAYLOAD

Supports wildcards: + (single level), # (multi-level). See Action Triggers for details.

Execute when MQTT clients connect, disconnect, or subscribe:

DEFINE ACTION AuditConnect
ON CONNECT DO
    PUBLISH TOPIC "audit/connect/" + CLIENTID WITH USER + "@" + ENDPOINT

DEFINE ACTION AuditDisconnect
ON DISCONNECT DO
    PUBLISH TOPIC "audit/disconnect/" + CLIENTID WITH DISCONNECTREASON

DEFINE ACTION TrackSubscriptions
ON SUBSCRIBE "sensors/#" DO
    PUBLISH TOPIC "audit/sub" WITH SUBSCRIBETOPIC + " qos=" + SUBSCRIBEQOS

Omit the pattern on ON SUBSCRIBE to run on every allowed subscription. See Client Lifecycle Triggers.

No trigger - called manually or by other actions:

DEFINE ACTION UtilityFunction
DO
    KEEP TOPIC "cache/data" WITH (GET TOPIC "source/data")

Invoked via CALL ACTION from other ACTIONs. See Callable ACTIONs.

Compatible Keywords

Keywords that can be used within action logic:

Variable Operations

Keyword	Description
`SET`	Create or assign a variable
`GET TOPIC`	Retrieve data from a topic
`GET JSON`	Extract fields from JSON payloads — see Working with JSON
`GET PROTO`	Extract fields from protobuf payloads (`GET PROTOBUF` is the same) — see Protobuf Models

// For topic "sensors/temp001/data": POSITION 1="sensors", POSITION 2="temp001", POSITION 3="data"
SET "sensor_id" WITH TOPIC POSITION 2
SET "temperature" WITH (GET TOPIC "sensors/temp" AS DOUBLE)
SET "humidity" WITH (GET JSON "humidity" IN PAYLOAD AS DOUBLE)

Topic Operations

Keyword	Description
`PUBLISH TOPIC`	Publish to subscribers, connectors, and dashboards. Optional `RETAIN` sets the MQTT retain flag on the published message. Optional `QOS0`, `QOS1`, or `QOS2` select MQTT QoS; the default remains QoS 0. Omitting `RETAIN` keeps the historical non-retained behaviour.
`KEEP TOPIC`	Broker-internal cache for `GET TOPIC`. Never sets the MQTT retain flag. Does not accept `RETAIN`.

PUBLISH TOPIC "output/data" WITH {temperature}
PUBLISH TOPIC "devices/" + {device_id} + "/status" WITH "online"
PUBLISH TOPIC "status/last" WITH "online" RETAIN
PUBLISH TOPIC "status/last" WITH "online" RETAIN QOS1
PUBLISH TOPIC "status/last" WITH "online" QOS2
KEEP TOPIC "cache/last_reading" WITH PAYLOAD

KEEP TOPIC is different: it stores a value for GET TOPIC in the broker cache and does not set the MQTT retain flag. KEEP does not accept RETAIN (use PUBLISH TOPIC ... RETAIN when new subscribers must receive the last payload). RETAIN and a QoS keyword can appear in either order (RETAIN QOS1 or QOS1 RETAIN). Each PUBLISH TOPIC and each KEEP TOPIC in one run is sent in the order it is written, including several writes to the same topic. Full actions are in ACTION Operations.

Control Flow

Keyword	Description
`IF ... THEN ... ELSE`	Conditional execution

IF {temperature} > 80 THEN
    PUBLISH TOPIC "alerts/high_temp" WITH {temperature}
ELSE
    PUBLISH TOPIC "status/normal" WITH "OK"

Entities

Entity	Description
`PAYLOAD`	The data that triggered the action; use `PAYLOAD AS BYTES` for binary passthrough
`CLIENTID`	MQTT client ID for the session or publisher that fired the trigger
`USER`	Authenticated username for the session or publisher
`ENDPOINT`	Client address (`ip:port`) on connect and lifecycle events
`CLEANSESSION`	`"true"` or `"false"` from the client’s CONNECT packet
`DISCONNECTREASON`	Disconnect type or MQTT reason on `ON DISCONNECT`
`SUBSCRIBETOPIC`	Topic filter from an `ON SUBSCRIBE` event
`SUBSCRIBEQOS`	Requested QoS (`0`, `1`, or `2`) from an `ON SUBSCRIBE` event
`TOPIC POSITION n`	Extract segment from topic path
`TIMESTAMP`	Generate timestamps (UTC, UNIX)
`EMPTY`	Check if a topic has no data

Python Integration

Keyword	Description
`CALL PYTHON`	Execute Python functions

Extend LoT with Python: Use CALL PYTHON to execute complex calculations, data validation, or integrate external libraries. See the Python Integration guide for complete syntax and examples.

Type Casting

Use AS to cast values when performing comparisons or calculations:

GET TOPIC "sensors/value" AS DOUBLE
GET TOPIC "config/enabled" AS BOOL
GET TOPIC "settings/count" AS INT
GET JSON "temperature" IN PAYLOAD AS DOUBLE

Supported types: STRING, INT, DOUBLE, FLOAT (alias SINGLE, for protobuf float), BOOL, TIMESTAMP, BYTES For binary MQTT payloads you want to forward unchanged (protobuf, Modbus frames, image chunks), use PAYLOAD AS BYTES with PUBLISH TOPIC or KEEP TOPIC. See Binary passthrough. To read or write protobuf fields, use GET PROTO and PUBLISH MODEL — see Protobuf Models.

Complete Example

Putting It All Together: This example demonstrates topic extraction, JSON parsing, conditional logic, and publishing - the core patterns you’ll use in most actions.

DEFINE ACTION SensorDataProcessor
ON TOPIC "sensors/+/raw" DO
    // Extract sensor ID from topic (position 2 = the wildcard)
    // Topic: sensors/temp001/raw → POSITION 1="sensors", POSITION 2="temp001", POSITION 3="raw"
    SET "sensor_id" WITH TOPIC POSITION 2
    
    // Get the temperature value
    SET "temp_value" WITH (GET JSON "temperature" IN PAYLOAD AS DOUBLE)
    
    // Check thresholds
    IF {temp_value} > 80 THEN
        PUBLISH TOPIC "alerts/high_temp/" + {sensor_id} WITH PAYLOAD
    ELSE
        PUBLISH TOPIC "sensors/processed/" + {sensor_id} WITH PAYLOAD
    
    // Always update the last reading timestamp
    PUBLISH TOPIC "sensors/" + {sensor_id} + "/last_update" WITH TIMESTAMP "UTC"

Quick Start

Coreflux MQTT Broker

LoT Language

Coreflux HUB

VS Code - LoT Notebooks

Coreflux Portal

Using AI with Coreflux

Product Updates

Basic Syntax

Components

Action Structure

Disable an Action

Trigger Types

Compatible Keywords

Variable Operations

Topic Operations

Control Flow

Entities

Python Integration

Type Casting

Complete Example

Next Steps

Action Triggers

Operations

​Basic Syntax

​Components

​Action Structure

​Disable an Action

​Trigger Types

​Compatible Keywords

​Variable Operations

​Topic Operations

​Control Flow

​Entities

​Python Integration

​Type Casting

​Complete Example

​Next Steps

Action Triggers

Operations

Basic Syntax

Components

Action Structure

Disable an Action

Trigger Types

Compatible Keywords

Variable Operations

Topic Operations

Control Flow

Entities

Python Integration

Type Casting

Complete Example

Next Steps