MODEL Examples

Examples Index

Find the right pattern for your use case:

Example	Pattern	Best For
Simple Sensor Reading	Basic	Single source, static metadata
Multi-Source Equipment	Basic	Combining multiple topics
Production Record	Calculated	Derived metrics
Multi-Instance Sensor	Wildcard	Multiple similar devices
Factory Hierarchy	Wildcard	Multi-level topic structures
Alarm Record	Action-Published	JSON processing, conditional logic
Production Event	Action-Published	Complex calculations
Quality Check	Action-Published	Pass/fail determination
Alert Family	Inheritance	Related data types
Sensor with Metadata	Nested Objects	Grouped configuration

Basic Model Examples

Simple Sensor Reading

A straightforward model that formats raw sensor data with static metadata. This model adds context (sensor ID, unit, status) to a raw temperature value:

DEFINE MODEL SensorReading WITH TOPIC "sensors/formatted/temperature"
    ADD STRING "sensor_id" WITH "TEMP001"
    ADD DOUBLE "value" WITH TOPIC "sensors/raw/temperature" AS TRIGGER
    ADD STRING "unit" WITH "celsius"
    ADD STRING "timestamp" WITH TIMESTAMP "UTC"
    ADD STRING "status" WITH "ACTIVE"

When a value arrives at sensors/raw/temperature, the model publishes:

{
  "sensor_id": "TEMP001",
  "value": 25.5,
  "unit": "celsius",
  "timestamp": "2025-10-25T14:30:15Z",
  "status": "ACTIVE"
}

Multi-Source Equipment Status

Combine data from multiple topics into a unified equipment status report. Each field pulls from a different source topic. The status topic acts as the trigger:

DEFINE MODEL EquipmentStatus WITH TOPIC "equipment/status/formatted"
    ADD STRING "equipment_id" WITH TOPIC "equipment/current/id"
    ADD STRING "status" WITH TOPIC "equipment/current/status" AS TRIGGER
    ADD INT "runtime_hours" WITH TOPIC "equipment/current/runtime"
    ADD DOUBLE "efficiency" WITH TOPIC "equipment/current/efficiency"
    ADD BOOL "maintenance_required" WITH TOPIC "equipment/current/maintenance_flag"
    ADD STRING "last_update" WITH TIMESTAMP "UTC"
    ADD STRING "location" WITH "Factory Floor A"

When the status topic updates, the model publishes a combined report to equipment/status/formatted:

{
  "equipment_id": "CNC-4500",
  "status": "RUNNING",
  "runtime_hours": 1823,
  "efficiency": 92.4,
  "maintenance_required": false,
  "last_update": "2025-10-25T14:30:15Z",
  "location": "Factory Floor A"
}

Production Record with Calculations

Automatically calculate derived values like efficiency percentages. The efficiency_percent field is calculated inline from other topic values:

DEFINE MODEL ProductionRecord WITH TOPIC "production/records/completed"
    ADD STRING "batch_id" WITH TOPIC "production/current/batch_id"
    ADD STRING "product_code" WITH TOPIC "production/current/product_code"
    ADD INT "quantity_produced" WITH TOPIC "production/current/quantity" AS TRIGGER
    ADD INT "quantity_target" WITH TOPIC "production/current/target"
    ADD DOUBLE "efficiency_percent" WITH (GET TOPIC "production/current/quantity" AS DOUBLE / GET TOPIC "production/current/target" AS DOUBLE * 100)
    ADD STRING "operator" WITH TOPIC "production/current/operator"
    ADD STRING "completion_time" WITH TIMESTAMP "UTC"

Example output when 95 of 100 units are produced:

{
  "batch_id": "BATCH_2025_001",
  "product_code": "WIDGET_A",
  "quantity_produced": 95,
  "quantity_target": 100,
  "efficiency_percent": 95.0,
  "operator": "John Smith",
  "completion_time": "2025-10-25T14:30:15Z"
}

Wildcard Model Examples

Multi-Instance Sensor Model

Handle multiple sensors with a single model definition using the + wildcard. The + wildcard matches any single level in the topic hierarchy:

DEFINE MODEL GenericSensorData WITH TOPIC "sensors/+/formatted"
    ADD STRING "sensor_id" WITH TOPIC "sensors/+/id"
    ADD DOUBLE "value" WITH TOPIC "sensors/+/value" AS TRIGGER
    ADD STRING "unit" WITH TOPIC "sensors/+/unit"
    ADD STRING "location" WITH TOPIC "sensors/+/location"
    ADD STRING "timestamp" WITH TIMESTAMP "UTC"

When sensors/temp001/value receives data, the model publishes to sensors/temp001/formatted:

{
  "sensor_id": "TEMP001",
  "value": 23.7,
  "unit": "celsius",
  "location": "Building A - Room 101",
  "timestamp": "2025-10-25T14:30:15Z"
}

Each sensor instance (temp001, pressure002, etc.) gets its own output topic automatically. The wildcard maintains topic context through the model.

Factory Hierarchy Model

Handle multi-level topic hierarchies with multiple wildcards. Multiple + wildcards capture different levels of the hierarchy:

DEFINE MODEL MachineData WITH TOPIC "factory/+/+/data/formatted"
    ADD STRING "line_id" WITH TOPIC "factory/+/id"
    ADD STRING "machine_id" WITH TOPIC "factory/+/+/id"
    ADD STRING "status" WITH TOPIC "factory/+/+/status" AS TRIGGER
    ADD DOUBLE "output_rate" WITH TOPIC "factory/+/+/output_rate"
    ADD STRING "timestamp" WITH TIMESTAMP "UTC"

When factory/line1/machine1/status updates, the model publishes to factory/line1/machine1/data/formatted:

{
  "line_id": "LINE_01",
  "machine_id": "MACH_01",
  "status": "RUNNING",
  "output_rate": 145.8,
  "timestamp": "2025-10-25T14:30:15Z"
}

Models Published by Actions Examples

Use this pattern when you need full control over publishing logic—conditional decisions, complex calculations, JSON extraction, or custom routing. The action determines when and where to publish.

Alarm Record from JSON

Process incoming JSON payloads into structured alarm records. First, define the model schema with COLLAPSED (no automatic trigger):

DEFINE MODEL AlarmRecord COLLAPSED
    ADD STRING "alarm_id"
    ADD STRING "equipment_id"
    ADD STRING "alarm_type"
    ADD DOUBLE "trigger_value"
    ADD DOUBLE "threshold"
    ADD STRING "severity"
    ADD STRING "message"
    ADD STRING "timestamp"
    ADD BOOL "auto_generated"

Then create an action that extracts JSON fields and publishes the model:

DEFINE ACTION ProcessAlarmJSON
ON TOPIC "alarms/+/json_input" DO
    SET "equipment_id" WITH TOPIC POSITION 2
    
    PUBLISH MODEL AlarmRecord TO "alarms/structured/" + {equipment_id} WITH
        alarm_id = (RANDOM UUID)
        equipment_id = {equipment_id}
        alarm_type = (GET JSON "type" IN PAYLOAD AS STRING)
        trigger_value = (GET JSON "value" IN PAYLOAD AS DOUBLE)
        threshold = (GET JSON "threshold" IN PAYLOAD AS DOUBLE)
        severity = (GET JSON "severity" IN PAYLOAD AS STRING)
        message = (GET JSON "message" IN PAYLOAD AS STRING)
        timestamp = TIMESTAMP "UTC"
        auto_generated = TRUE

When a JSON payload arrives at alarms/pump003/json_input, the action publishes to alarms/structured/pump003:

{
  "alarm_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "equipment_id": "pump003",
  "alarm_type": "OVERHEAT",
  "trigger_value": 95.3,
  "threshold": 85.0,
  "severity": "CRITICAL",
  "message": "Motor temperature exceeded safe limit",
  "timestamp": "2025-10-25T14:30:15Z",
  "auto_generated": true
}

Production Event with Calculations

Create production records with computed metrics like efficiency. Define the schema for production events:

DEFINE MODEL ProductionEvent COLLAPSED
    ADD STRING "event_id"
    ADD STRING "line_id"
    ADD STRING "event_type"
    ADD INT "parts_count"
    ADD DOUBLE "cycle_time"
    ADD DOUBLE "efficiency_percent"
    ADD STRING "operator"
    ADD STRING "timestamp"

The action performs calculations before publishing:

DEFINE ACTION ProcessProductionEvent
ON TOPIC "production/+/events" DO
    SET "line_id" WITH TOPIC POSITION 2
    SET "parts" WITH (GET JSON "parts_produced" IN PAYLOAD AS INT)
    SET "cycle" WITH (GET JSON "cycle_time" IN PAYLOAD AS DOUBLE)
    SET "target" WITH (GET JSON "target_cycle_time" IN PAYLOAD AS DOUBLE)
    SET "eff" WITH ({target} / {cycle} * 100)
    
    PUBLISH MODEL ProductionEvent TO "production/events/structured/" + {line_id} WITH
        event_id = (RANDOM UUID)
        line_id = {line_id}
        event_type = (GET JSON "event_type" IN PAYLOAD AS STRING)
        parts_count = {parts}
        cycle_time = {cycle}
        efficiency_percent = {eff}
        operator = (GET JSON "operator" IN PAYLOAD AS STRING)
        timestamp = TIMESTAMP "UTC"

When a production event arrives at production/line2/events with a target cycle time of 10s and an actual cycle time of 8.5s, the action publishes to production/events/structured/line2:

{
  "event_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "line_id": "line2",
  "event_type": "BATCH_COMPLETE",
  "parts_count": 250,
  "cycle_time": 8.5,
  "efficiency_percent": 117.6,
  "operator": "Maria Garcia",
  "timestamp": "2025-10-25T14:30:15Z"
}

Quality Check with Validation

Determine pass/fail status based on measurement tolerances.

Complex conditional logic (like tolerance checking) is cleaner in an action than inline in a model. The action can also route to different topics based on the result.

Define the quality reading schema:

DEFINE MODEL QualityReading COLLAPSED
    ADD STRING "inspection_id"
    ADD STRING "part_id"
    ADD DOUBLE "measurement"
    ADD DOUBLE "target"
    ADD DOUBLE "tolerance"
    ADD STRING "result"
    ADD STRING "timestamp"

The action checks if the measurement is within tolerance and routes accordingly:

DEFINE ACTION ValidateQuality
ON TOPIC "quality/+/measurement" DO
    SET "part_id" WITH TOPIC POSITION 2
    SET "value" WITH (GET JSON "value" IN PAYLOAD AS DOUBLE)
    SET "target" WITH (GET JSON "target" IN PAYLOAD AS DOUBLE)
    SET "tolerance" WITH (GET JSON "tolerance" IN PAYLOAD AS DOUBLE)
    SET "min_allowed" WITH ({target} - {tolerance})
    SET "max_allowed" WITH ({target} + {tolerance})
    
    IF {value} >= {min_allowed} AND {value} <= {max_allowed} THEN
        PUBLISH MODEL QualityReading TO "quality/passed/" + {part_id} WITH
            inspection_id = (RANDOM UUID)
            part_id = {part_id}
            measurement = {value}
            target = {target}
            tolerance = {tolerance}
            result = "PASS"
            timestamp = TIMESTAMP "UTC"
    ELSE
        PUBLISH MODEL QualityReading TO "quality/failed/" + {part_id} WITH
            inspection_id = (RANDOM UUID)
            part_id = {part_id}
            measurement = {value}
            target = {target}
            tolerance = {tolerance}
            result = "FAIL"
            timestamp = TIMESTAMP "UTC"

When a measurement of 10.02 mm arrives for a part with a target of 10.00 mm and tolerance of 0.05 mm, it passes and publishes to quality/passed/PART_A1:

{
  "inspection_id": "b7e8f9a0-1234-5678-90ab-cdef01234567",
  "part_id": "PART_A1",
  "measurement": 10.02,
  "target": 10.0,
  "tolerance": 0.05,
  "result": "PASS",
  "timestamp": "2025-10-25T14:30:15Z"
}

Model Inheritance Examples

For complete inheritance patterns and syntax, see Model Inheritance.

Alert Model Family

Create specialized alert types from a common base model. First, define the base model with common fields:

DEFINE MODEL BaseAlert COLLAPSED
    ADD STRING "alert_id"
    ADD STRING "source_system"
    ADD STRING "timestamp"
    ADD STRING "severity"
    ADD STRING "message"
    ADD BOOL "acknowledged"

Then create specialized models that inherit and extend it:

DEFINE MODEL TemperatureAlert FROM BaseAlert
    ADD DOUBLE "temperature_value"
    ADD DOUBLE "threshold_exceeded"
    ADD STRING "sensor_location"
    ADD STRING "unit"

DEFINE MODEL PressureAlert FROM BaseAlert
    ADD DOUBLE "pressure_value"
    ADD DOUBLE "max_safe_pressure"
    ADD STRING "pressure_unit"
    ADD STRING "system_affected"

DEFINE MODEL MaintenanceAlert FROM BaseAlert
    ADD STRING "equipment_id"
    ADD STRING "maintenance_type"
    ADD INT "hours_since_service"
    ADD INT "recommended_interval"

Use the specialized model in an action:

DEFINE ACTION GenerateTemperatureAlert
ON TOPIC "sensors/temperature/+/alert" DO
    SET "sensor_id" WITH TOPIC POSITION 3
    
    PUBLISH MODEL TemperatureAlert TO "alerts/temperature/" + {sensor_id} WITH
        alert_id = (RANDOM UUID)
        source_system = "TemperatureMonitor"
        timestamp = TIMESTAMP "UTC"
        severity = "HIGH"
        message = "Temperature threshold exceeded"
        acknowledged = FALSE
        temperature_value = (GET JSON "value" IN PAYLOAD AS DOUBLE)
        threshold_exceeded = (GET JSON "threshold" IN PAYLOAD AS DOUBLE)
        sensor_location = (GET JSON "location" IN PAYLOAD AS STRING)
        unit = "celsius"

When an alert triggers for sensor TH_042, the action publishes to alerts/temperature/TH_042 with both inherited and specialized fields:

{
  "alert_id": "c3d4e5f6-7890-1234-abcd-ef5678901234",
  "source_system": "TemperatureMonitor",
  "timestamp": "2025-10-25T14:30:15Z",
  "severity": "HIGH",
  "message": "Temperature threshold exceeded",
  "acknowledged": false,
  "temperature_value": 92.7,
  "threshold_exceeded": 85.0,
  "sensor_location": "Boiler Room B",
  "unit": "celsius"
}

Nested Object Examples

Sensor with Metadata

Group related configuration and context fields into nested sub-objects using the OBJECT type and indentation. The metadata field uses OBJECT to group location details into a nested object. Fields indented under ADD OBJECT become its properties. When indentation returns to the parent level, fields belong to the top-level model again:

DEFINE MODEL SensorWithMetadata WITH TOPIC "sensors/+/formatted"
    ADD STRING "sensor_id" WITH TOPIC "sensors/+/id"
    ADD DOUBLE "value" WITH TOPIC "sensors/+/value" AS TRIGGER
    ADD OBJECT "metadata"
        ADD STRING "unit" WITH TOPIC "sensors/+/unit"
        ADD STRING "location" WITH TOPIC "sensors/+/location"
        ADD INT "floor" WITH TOPIC "sensors/+/floor"
        ADD STRING "building" WITH TOPIC "sensors/+/building"
    ADD STRING "timestamp" WITH TIMESTAMP "UTC"

When sensors/temp001/value receives data, the model publishes to sensors/temp001/formatted:

{
  "sensor_id": "TEMP001",
  "value": 25.5,
  "metadata": {
    "unit": "celsius",
    "location": "Room 101",
    "floor": 3,
    "building": "Building A"
  },
  "timestamp": "2025-10-25T14:30:15Z"
}

The indentation rule applies everywhere OBJECT is used — in basic models, wildcard models, and COLLAPSED templates published from actions.

Choosing the Right Pattern

Basic Models (WITH TOPIC + AS TRIGGER)

Use when: Data flows continuously and formatting is straightforward.Best for: Sensor readings, status updates, simple aggregation.Trigger: Automatic when source topic updates.

Calculated Fields

Use when: You need derived metrics computed from source values.Best for: Percentages, totals, averages, unit conversions.Note: Keep calculations simple; use actions for complex logic.

Wildcard Models (+)

Use when: You have multiple instances of the same data structure.Best for: Fleets of sensors, multi-line factories, device groups.Benefit: One model definition handles all instances.

Action-Published Models (COLLAPSED)

Use when: You need control over timing, routing, or complex logic.Best for: JSON extraction, conditional publishing, pass/fail routing, complex calculations.Benefit: Full action power with structured output.

Inherited Models (FROM)

Use when: You have related data types sharing common fields.Best for: Alert families, equipment types, event categories.Benefit: DRY principle—define common fields once.

Nested Objects (OBJECT)

Use when: Your JSON output needs grouped or hierarchical data.Best for: Metadata grouping, configuration objects, multi-level status reports.Benefit: Clean nested JSON without external formatting. Indentation controls structure.

Quick Start

Developing and Managing Coreflux

Coreflux MQTT Broker

LoT Language

Product Updates

Examples Index

Basic Model Examples

Simple Sensor Reading

Multi-Source Equipment Status

Production Record with Calculations

Wildcard Model Examples

Multi-Instance Sensor Model

Factory Hierarchy Model

Models Published by Actions Examples

Alarm Record from JSON

Production Event with Calculations

Quality Check with Validation

Model Inheritance Examples

Alert Model Family

Nested Object Examples

Sensor with Metadata

Choosing the Right Pattern

Next Steps

Routes Overview

Actions Syntax

​Examples Index

​Basic Model Examples

​Simple Sensor Reading

​Multi-Source Equipment Status

​Production Record with Calculations

​Wildcard Model Examples

​Multi-Instance Sensor Model

​Factory Hierarchy Model

​Models Published by Actions Examples

​Alarm Record from JSON

​Production Event with Calculations

​Quality Check with Validation

​Model Inheritance Examples

​Alert Model Family

​Nested Object Examples

​Sensor with Metadata

​Choosing the Right Pattern

​Next Steps

Routes Overview

Actions Syntax

Examples Index

Basic Model Examples

Simple Sensor Reading

Multi-Source Equipment Status

Production Record with Calculations

Wildcard Model Examples

Multi-Instance Sensor Model

Factory Hierarchy Model

Models Published by Actions Examples

Alarm Record from JSON

Production Event with Calculations

Quality Check with Validation

Model Inheritance Examples

Alert Model Family

Nested Object Examples

Sensor with Metadata

Choosing the Right Pattern

Next Steps