LoT Concepts

Why Paradigms Matter

LoT combines two programming approaches—imperative and declarative—each optimized for different tasks. Understanding when to use each one makes your code cleaner, more maintainable, and easier to debug.

Like a restaurant kitchen. Imperative commands are the chef shouting “Plate this now!” (immediate actions). Declarative definitions are the recipes and menu (structures that define how things work when triggered).

Two Ways to Write LoT

LoT uses two syntax styles based on what you’re doing:

Imperative Commands
Declarative Definitions

Direct actions executed immediately by the broker. Use these inside Actions to do things right now.

PUBLISH TOPIC "alerts/temperature" WITH PAYLOAD
SET "counter" WITH (GET TOPIC "stats/count" + 1)
KEEP TOPIC "data/cached" WITH PAYLOAD
CALL ACTION "ProcessData"

Command	What it does
`PUBLISH`	Send a message to a topic
`SET`	Store a value in a variable
`GET`	Retrieve a value from a topic or variable
`KEEP`	Publish and retain a message
`CALL`	Execute another Action

Blueprints that describe what should exist and when it activates. These define the structure of your automation.

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

DEFINE MODEL SensorReading WITH TOPIC "sensors/formatted"
    ADD STRING "sensor_id" WITH "TEMP001"
    ADD DOUBLE "value" WITH TOPIC "sensors/raw" AS TRIGGER

Keyword	What it defines
`DEFINE ACTION`	Executable logic with a trigger
`DEFINE MODEL`	Data schema for structured messages
`DEFINE ROUTE`	External system integration
`DEFINE RULE`	Access control policy

When to Use Each Paradigm

Scenario	Paradigm	Example
Publish a message now	Imperative	`PUBLISH TOPIC "status" WITH "online"`
React when data arrives	Declarative	`DEFINE ACTION ... ON TOPIC "input" DO`
Store a calculation result	Imperative	`SET "total" WITH ({a} + {b})`
Structure JSON output	Declarative	`DEFINE MODEL ... ADD STRING "id"`
Connect to a database	Declarative	`DEFINE ROUTE ... TO POSTGRESQL`
Forward data in a loop	Imperative	`PUBLISH TOPIC "out" WITH PAYLOAD`

The Four Building Blocks

Everything in LoT is built from four declarative constructs:

Construct	Purpose	Trigger Types
Actions	Execute logic when events occur	Time, Topic, System events, Manual
Models	Structure MQTT data into JSON schemas	Topic values, Action calls
Routes	Connect to external systems	Topic patterns
Rules	Control who can publish/subscribe	Client identity, Topic patterns

Actions in Detail

Actions contain your automation logic. They run when triggered:

Trigger	Syntax	Use Case
Time-based	`ON EVERY 5 SECONDS`	Heartbeats, polling, scheduled tasks
Topic-based	`ON TOPIC "sensors/+"`	React to incoming data
Callable	No trigger clause	Utility functions, subroutines
System	`ON START`, `ON STOP`	Initialization, cleanup

Inside an Action, you use imperative commands like PUBLISH, SET, IF/THEN, and CALL.

Models in Detail

Models define JSON structures that auto-publish when their trigger fields update:

Field Type	Purpose
`STRING`, `INT`, `DOUBLE`, `BOOL`	Typed data fields
`AS TRIGGER`	Field that activates the model when it changes
`FROM`	Inherit fields from another model

Models eliminate manual JSON formatting—define the schema once, and data flows automatically.

Routes in Detail

Routes connect your MQTT infrastructure to external systems:

Category	Examples
Data Storage	PostgreSQL, MongoDB, CrateDB, OpenSearch
Data Pipeline	MQTT bridges, email, HTTP webhooks
Industrial	OPC-UA, Modbus, Siemens S7, Allen-Bradley
System	Broker clustering, replication

Routes are declarative—you define what to connect, and the broker handles the how.

Rules in Detail

Rules define access control at the broker level:

Control	Description
Publish permissions	Who can send messages to which topics
Subscribe permissions	Who can receive messages from which topics
Client identity	Match rules to specific clients or patterns

Rules enforce security policies without modifying your Actions or Models.

How They Work Together

A typical LoT solution combines all four building blocks:

-- 1. ROUTE: Connect to PostgreSQL
DEFINE ROUTE SensorDB TO POSTGRESQL
    CONNECTION "Host=db.local;Database=iot"
    TOPIC "sensors/#"

-- 2. MODEL: Structure incoming data
DEFINE MODEL SensorReading WITH TOPIC "sensors/formatted"
    ADD STRING "device_id" WITH TOPIC "sensors/id"
    ADD DOUBLE "temperature" WITH TOPIC "sensors/raw" AS TRIGGER

-- 3. ACTION: Process and alert
DEFINE ACTION TemperatureAlert
ON TOPIC "sensors/formatted" DO
    SET "temp" WITH (GET JSON "temperature" IN PAYLOAD AS DOUBLE)
    IF {temp} > 80 THEN
        PUBLISH TOPIC "alerts/high_temp" WITH PAYLOAD

-- 4. RULE: Restrict who can publish alerts
DEFINE RULE AlertAccess
    DENY PUBLISH "alerts/#" FOR ALL
    ALLOW PUBLISH "alerts/#" FOR "system-*"

Step	What Happens
1	Route stores all `sensors/#` data to PostgreSQL
2	Model transforms raw data into structured JSON
3	Action checks thresholds and publishes alerts
4	Rule ensures only system clients can write alerts

Quick Start

MQTT Broker

LoT Language

LoT Notebooks

Actions

Routes

Models

Rules

Why Paradigms Matter

Two Ways to Write LoT

When to Use Each Paradigm

The Four Building Blocks

How They Work Together

Next Steps

Write Your First Action

Try the Playground

Quick Start

MQTT Broker

LoT Language

LoT Notebooks

Actions

Routes

Models

Rules

​Why Paradigms Matter

​Two Ways to Write LoT

​When to Use Each Paradigm

​The Four Building Blocks

​How They Work Together

​Next Steps

Write Your First Action

Try the Playground

Why Paradigms Matter

Two Ways to Write LoT

When to Use Each Paradigm

The Four Building Blocks

How They Work Together

Next Steps