Why Define a Schema?
Models transform scattered MQTT data into structured, predictable JSON. Instead of parsing raw payloads in your application, you define once how data should look—and Coreflux handles the rest.When to Use This Reference
Use this page when you need to:- Define field types for your model (STRING, INT, DOUBLE, etc.)
- Pull values from multiple MQTT topics into a single output
- Calculate or transform values inline
- Control when your model publishes using triggers
Basic Model Syntax
Every model follows this structure:Components
Unique identifier for the model. Use descriptive names like
SensorReading, EquipmentStatus, ProductionRecord.The MQTT topic where the model’s JSON output will be published. Supports wildcards for multi-instance models.
One of:
STRING, INT, DOUBLE, BOOL, ARRAY, OBJECTOptional. Marks this field as the trigger—the model publishes only when this field’s source topic updates.
Trigger Mechanism
TheAS TRIGGER modifier controls when your model publishes. Without it, you’d flood your broker with updates every time any source topic changes.
- Model publishes only when
equipment/statuschanges - Changes to
equipment/idorequipment/runtimealone do not trigger publication - All field values are fetched at trigger time
No Trigger Specified
If no field hasAS TRIGGER, the model acts as a template. You must publish it explicitly using PUBLISH MODEL from an Action.
Learn how to publish models on-demand in Publishing Models.
Multiple Data Sources, Single Trigger
You can pull data from many topics but trigger on just one:Field Types
Each field in your model has a type that determines how the value is serialized to JSON.STRING
Text data of any length:INT
Whole numbers (integers):DOUBLE
Decimal numbers (floating-point):BOOL
Boolean values (true/false):ARRAY
JSON arrays:OBJECT
Nested JSON objects. Fields indented one level deeper thanADD OBJECT become properties of the sub-object. When the indentation returns to the parent level, subsequent fields belong to the parent again.
Data Sources
Fields can pull values from several sources. Mix and match as needed.Static Values
Fixed values that never change—useful for metadata, units, or default settings:Topic Data
Pull live values from other MQTT topics. The value is fetched at publish time, not when the model is defined.Timestamps
Built-in timestamp generation—no external time source needed:Calculated Values
Perform inline math using topic data:Conditional Values
Dynamic values based on conditions:Wildcard Topics
Multi-Instance Models
Use+ wildcards to create models that handle multiple instances automatically:
sensors/temp001/formattedsensors/pressure002/formattedsensors/humidity003/formatted
JSON Reception with Wildcards
When JSON arrives at a wildcard topic, the broker “explodes” it into individual topics:Process/Machine/33/Material/Content:
Process/Machine/33/Material/Content/MaterialID→132323Process/Machine/33/Material/Content/Name→PeppersProcess/Machine/33/Material/Content/Quantity→21
Complete Examples
- Equipment Status
- Production Record
This model aggregates equipment data from multiple topics into a single, structured output. It triggers whenever the status changes.Output:
Best Practices
Use Consistent Field Naming
Use Consistent Field Naming
Establish naming conventions and follow them across all models:
Always Type Cast in Calculations
Always Type Cast in Calculations
Explicit type casting prevents errors and ensures predictable results:
Include Essential Context
Include Essential Context
Always include fields that help downstream consumers understand the data:
- Identification fields (IDs, names)
- Timestamps
- Units of measurement
- Status or quality indicators
Choose Triggers Carefully
Choose Triggers Carefully
Trigger on the primary data field, not metadata:
Next Steps
Publishing Models
Learn to publish models dynamically from Actions.
Model Examples
See complete model examples for common use cases.

