Skip to main content

​
Examples Index

Find the right pattern for your use case:
ExamplePatternBest For
Simple Sensor ReadingBasicSingle source, static metadata
Multi-Source EquipmentBasicCombining multiple topics
Production RecordCalculatedDerived metrics
Multi-Instance SensorWildcardMultiple similar devices
Factory HierarchyWildcardMulti-level topic structures
Alarm RecordAction-PublishedJSON processing, conditional logic
Production EventAction-PublishedComplex calculations
Quality CheckAction-PublishedPass/fail determination
Alert FamilyInheritanceRelated data types
Sensor with MetadataNested ObjectsGrouped 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"

​
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"
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"

​
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

​
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"

​
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"

​
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"

​
Nested Object Examples

​
Sensor with Metadata

Include nested configuration data using the OBJECT field type. Group related fields into nested objects for cleaner JSON output: 
DEFINE MODEL SensorWithMetadata WITH TOPIC "sensors/comprehensive/+"
    ADD STRING "sensor_id" WITH TOPIC "sensors/current/id"
    ADD DOUBLE "value" WITH TOPIC "sensors/current/value" AS TRIGGER
    ADD STRING "unit" WITH TOPIC "sensors/current/unit"
    ADD OBJECT "metadata" WITH {
        "location": TOPIC "sensors/current/location",
        "installation_date": TOPIC "sensors/current/install_date",
        "firmware_version": TOPIC "sensors/current/firmware",
        "last_calibration": TOPIC "sensors/current/last_cal"
    }
    ADD OBJECT "thresholds" WITH {
        "warning_low": TOPIC "sensors/current/warn_low",
        "warning_high": TOPIC "sensors/current/warn_high",
        "critical_low": TOPIC "sensors/current/crit_low",
        "critical_high": TOPIC "sensors/current/crit_high"
    }
    ADD STRING "timestamp" WITH TIMESTAMP "UTC"
This produces structured JSON with logical groupings: 
{
  "sensor_id": "TEMP001",
  "value": 23.5,
  "unit": "celsius",
  "metadata": {
    "location": "Building A, Floor 2",
    "installation_date": "2024-01-15",
    "firmware_version": "v2.1.3",
    "last_calibration": "2025-01-01"
  },
  "thresholds": {
    "warning_low": 10,
    "warning_high": 35,
    "critical_low": 5,
    "critical_high": 40
  },
  "timestamp": "2025-10-25T14:30:15Z"
}

​
Choosing the Right Pattern

Use when: Data flows continuously and formatting is straightforward.Best for: Sensor readings, status updates, simple aggregation.Trigger: Automatic when source topic updates.
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.
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.
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.
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.
Use when: Your output needs logical groupings of related fields.Best for: Metadata, configuration, hierarchical data.Benefit: Cleaner JSON structure for downstream systems.

​
Next Steps

Routes Overview

Connect your broker to external systems and databases.

Actions Syntax

Master the action syntax for publishing models.