Skip to main content

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.
Like a form that fills itself out. You define what fields the form should have (temperature, humidity, timestamp), and the model automatically grabs the latest values from different sources whenever it needs to publish.

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

ModelName
string
required
Unique identifier for the model. Use descriptive names like SensorReading, EquipmentStatus, ProductionRecord.
WITH TOPIC
string
required
The MQTT topic where the model’s JSON output will be published. Supports wildcards for multi-instance models.
FIELD_TYPE
type
required
One of: STRING, INT, DOUBLE, BOOL, ARRAY, OBJECT
AS TRIGGER
modifier
Optional. Marks this field as the trigger—the model publishes only when this field’s source topic updates.

Trigger Mechanism

The AS TRIGGER modifier controls when your model publishes. Without it, you’d flood your broker with updates every time any source topic changes.
Like a doorbell that takes a photo. The model waits quietly until the trigger topic “rings,” then takes a snapshot of all fields and publishes the complete picture. No ring, no photo.
Behavior:
  • Model publishes only when equipment/status changes
  • Changes to equipment/id or equipment/runtime alone do not trigger publication
  • All field values are fetched at trigger time

No Trigger Specified

If no field has AS 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:
Only publishes when sensor C updates, but includes current values from sensors A and B.

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 than ADD OBJECT become properties of the sub-object. When the indentation returns to the parent level, subsequent fields belong to the parent again.
Produces a nested structure in the JSON output:
Indentation must be consistent throughout the model. Use either tabs or spaces — mixing them causes parsing errors.

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.
Example: If sensors/raw/temperature currently holds 23.5, the model’s temperature field will be 23.5 when it publishes. If the value changes to 24.0 before the next publish, the model will output 24.0.

Timestamps

Built-in timestamp generation—no external time source needed:

Calculated Values

Perform inline math using topic data:
Always use AS DOUBLE or AS INT when performing mathematical operations to ensure correct type handling.

Conditional Values

Dynamic values based on conditions:

Wildcard Topics

Multi-Instance Models

Use + wildcards to create models that handle multiple instances automatically:
Matches:
  • sensors/temp001/formatted
  • sensors/pressure002/formatted
  • sensors/humidity003/formatted
Each unique topic creates a separate model instance.

JSON Reception with Wildcards

When JSON arrives at a wildcard topic, the broker “explodes” it into individual topics:
When JSON arrives at Process/Machine/33/Material/Content:
Explodes to:
  • Process/Machine/33/Material/Content/MaterialID132323
  • Process/Machine/33/Material/Content/NamePeppers
  • Process/Machine/33/Material/Content/Quantity21

Complete Examples

This model aggregates equipment data from multiple topics into a single, structured output. It triggers whenever the status changes.
Output:

Best Practices

Establish naming conventions and follow them across all models:
Explicit type casting prevents errors and ensures predictable results:
Always include fields that help downstream consumers understand the data:
  • Identification fields (IDs, names)
  • Timestamps
  • Units of measurement
  • Status or quality indicators
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.
Last modified on May 22, 2026