Skip to content

LOT Defining Constructs

These keywords define the main structural components of LOT: Actions, Models, Rules, and Routes.

DEFINE ACTION

Feature Since Version Notes
DEFINE ACTION >v1.4.4 Core feature
Time-based triggers >v1.4.8 SECONDS, MINUTES, HOURS, DAYS
Extended time units >v1.4.8 Added WEEKS, MONTHS, YEARS

Actions are blocks of code that respond to events (time-based or message-based). They perform operations such as publishing messages, processing data, or executing conditional logic using Functional Keywords.

Syntax

DEFINE ACTION <ActionName>
ON <TriggerEvent> DO
    <statements>

Parameters

  • ActionName: A unique identifier for the action
  • TriggerEvent: Either a time-based trigger (EVERY 5 SECONDS) or a topic-based trigger (TOPIC "some/topic")
  • statements: One or more functional keyword statements (PUBLISH, IF/THEN/ELSE, etc.)

Examples

// See examples in Functional Keywords documentation
DEFINE ACTION SystemHeartbeat
ON EVERY 60 SECONDS DO
    PUBLISH TOPIC "system/status" WITH "alive"

DEFINE MODEL

Feature Since Version Notes
DEFINE MODEL >v1.4.4 Core feature
Basic property types >v1.4.6 Constants, topic references
Conditional properties >v1.4.6 Added IF/THEN/ELSE in properties
Timestamp properties >v1.4.6 Added TIMESTAMP format options

Models define data transformation components that process input data (from topics) and produce output data (to topics). They can be triggered by topic updates and perform calculations or data manipulations using Functional Keywords and Operators.

Syntax

DEFINE MODEL <ModelName> WITH TOPIC "<outputBaseTopic>"
    ADD "<propertyName>" WITH <propertyDefinition>
    ADD "<propertyName>" WITH <propertyDefinition>
    ...

Parameters

  • ModelName: A unique identifier for the model
  • outputBaseTopic: The base topic prefix for all properties' output topics
  • propertyName: The name of a property in the model
  • propertyDefinition: Can be a constant, topic reference, expression, or conditional

Examples

// See examples in Functional Keywords documentation
DEFINE MODEL TemperatureConverter WITH TOPIC "processed/temperature"
    ADD "celsius" WITH TOPIC "raw/temperature" AS TRIGGER
    ADD "fahrenheit" WITH (celsius * 9/5 + 32)

DEFINE RULE

Feature Since Version Notes
DEFINE RULE >v1.4.4 Core feature
Basic operations >v1.4.4 Subscribe, Publish
System operations >v1.4.4 Added SubscribeSys, PublishSys
User management >v1.4.4 Added user management operations
Asset management >v1.4.4 Added asset management operations

Rules control permissions and access within the Coreflux system. They determine which users or entities can perform specific operations, often based on conditions evaluated using Functional Keywords and Operators.

Syntax

DEFINE RULE <RuleName> WITH PRIORITY <priorityValue> FOR <operationScope>
    IF <condition> THEN
        ALLOW
    ELSE
        DENY

Parameters

  • RuleName: A unique identifier for the rule
  • priorityValue: A number that determines rule evaluation order (lower values have higher priority)
  • operationScope: The operation type the rule controls (e.g., Publish, Subscribe, UserManagementCreation), optionally restricted to a specific topic (TO TOPIC "path")
  • condition: A logical expression that determines if the operation is allowed or denied (uses IF, USER IS, USER HAS, comparison/logical operators)

Examples

// See examples in Functional Keywords documentation
DEFINE RULE AllowUserPublishSensors WITH PRIORITY 1 FOR Publish TO TOPIC "sensors/#"
    IF USER IS "sensor-gateway" THEN
        ALLOW
    ELSE
        DENY

DEFINE ROUTE

Feature Since Version Notes
DEFINE ROUTE >v1.5.6 Core Feature

Routes enable the connection between different MQTT brokers (or other systems in the future), allowing data to flow between them based on defined mappings. Configuration uses Functional Keywords like ADD and WITH.

Syntax

DEFINE ROUTE <RouteName> WITH TYPE MQTT_BRIDGE
    ADD SOURCE_CONFIG
        WITH <configOption> <value>
        ...
    ADD DESTINATION_CONFIG
        WITH <configOption> <value>
        ...
    ADD MAPPING <mappingName>
        WITH SOURCE_TOPIC "<sourceTopic>"
        WITH DESTINATION_TOPIC "<destinationTopic>"
        WITH DIRECTION "<direction>"

Parameters

  • RouteName: A unique identifier for the route
  • SOURCE_CONFIG/DESTINATION_CONFIG: Configuration blocks for source and destination brokers
  • configOption: Configuration parameters like BROKER_ADDRESS, BROKER_PORT, USERNAME, PASSWORD, USE_TLS, etc.
  • mappingName: A name for the topic mapping
  • sourceTopic/destinationTopic: The topic patterns to map between brokers (can use wildcards)
  • direction: Data flow direction (in, out, or both)

Examples

// See examples in Functional Keywords documentation
DEFINE ROUTE LocalToCloud WITH TYPE MQTT_BRIDGE
    ADD SOURCE_CONFIG WITH BROKER SELF
    ADD DESTINATION_CONFIG WITH BROKER_ADDRESS "cloud.example.com"
    ADD MAPPING sensors WITH SOURCE_TOPIC "local/sensors/#" WITH DESTINATION_TOPIC "devices/edge-1/sensors/#" WITH DIRECTION "out"

Related Documentation