Skip to main content

What are Routes?

Routes define connections between your Coreflux MQTT broker and external systems. They enable broker-to-broker communication, database storage, industrial protocol integration, REST API connectivity, email notifications, AI integration, and media processing - all without writing custom middleware.
Routes extend your broker’s capabilities by creating managed connections to external systems - all configured through LoT syntax.
Architecture diagram showing the Coreflux MQTT broker at the center connected to databases, PLCs, REST APIs, cloud brokers, email, and AI through Routes

Route Categories

System Routes

Broker clustering and scalability configurations for high-availability deployments.

Data Pipeline Routes

MQTT bridges, email notifications, and MQTT-to-REST forwarding.

Data Storage Routes

Store MQTT data in PostgreSQL, MySQL, MongoDB, OpenSearch, Snowflake, and more.

REST API Routes

HTTP client/server for external API integration and webhook endpoints.

Industrial Routes

Connect to PLCs via Modbus, Siemens S7, OPC UA, ADS, Allen-Bradley, and FINS.

MCP Routes

Connect to external tools and services through MCP.

Media Routes

Barcode scanning and video streaming capabilities.
This page covers the fundamentals of route configuration. Choose a specific route category above for detailed syntax and examples.

Basic Syntax

DEFINE ROUTE <route_name> WITH TYPE <route_type>
    ADD <CONFIG_SECTION>
        WITH <parameter> "<value>"
    ADD MAPPING <mapping_name>
        WITH SOURCE_TOPIC "<source>"
        WITH DESTINATION_TOPIC "<destination>"

Components

route_name
string
required
Unique identifier for the route. Use descriptive names like CloudBridge, SensorDataIndexer, AlertEmailer.
route_type
type
required
The type of route (see Available Route Types below).
CONFIG_SECTION
block
Configuration blocks specific to the route type (e.g., MQTT_CONFIG, MONGODB_CONFIG, REST_API_CONFIG).
MAPPING
block
Defines topic mappings for data flow between source and destination.

Available Route Types

Route TypeDescription
MQTT_CLUSTERBroker clustering and scalability

Quick Examples

Send email notifications from MQTT events:
DEFINE ROUTE AlertEmail WITH TYPE EMAIL
    ADD SMTP_CONFIG
        WITH HOST "smtp.gmail.com"
        WITH PORT '587'
        WITH USERNAME "alerts@company.com"
        WITH PASSWORD "app-password"
        WITH USE_TLS "true"
    ADD EVENT criticalAlert
        WITH SOURCE_TOPIC "alerts/critical/+"
        WITH SUBJECT "Critical Alert: {value.json.type}"
        WITH RECIPIENT "team@company.com"

Understanding Route Configuration

Routes share two common building blocks: MQTT configuration and topic mappings. You’ll see these across most route types, so understanding them here saves time when setting up any specific route.

Connecting to a Broker

Routes that communicate with MQTT brokers — like bridges — need to know which broker to talk to. The simplest option is BROKER SELF, which tells the route to use your local Coreflux broker:
ADD MQTT_CONFIG
    WITH BROKER SELF
When you need to reach a remote or authenticated broker (for example, a cloud broker or a second Coreflux instance on your network), provide the connection details explicitly:
ADD MQTT_CONFIG
    WITH BROKER_ADDRESS "192.168.1.50"
    WITH BROKER_PORT '1883'
    WITH CLIENT_ID "MyRouteClient"
    WITH USERNAME "user"
    WITH PASSWORD "password"
Not every route type requires an MQTT_CONFIG block. Database routes, email routes, and REST routes have their own configuration sections. Check the specific route page for details.

Controlling Data Flow with Mappings

Mappings define which MQTT topics flow through a route and in which direction. For example, to push local sensor readings to a cloud broker:
ADD MAPPING sensorSync
    WITH SOURCE_TOPIC "sensors/+/temperature"
    WITH DESTINATION_TOPIC "cloud/sensors/+/temperature"
    WITH DIRECTION "out"
The DIRECTION parameter controls where data goes:
DirectionWhat it doesExample scenario
outLocal broker to destinationPush edge data to the cloud
inDestination to local brokerPull remote commands locally
bothBidirectional syncKeep two brokers in sync

Route Status Monitoring

Every route automatically publishes real-time health and status information to a dedicated MQTT topic. No additional configuration is required — the status topic is created as soon as the route is defined.
Status updates are published to a $SYS topic and are available to any client subscribed to the broker.

Status Topic

The topic follows this pattern:
$SYS/Coreflux/Routes/<route_name>/status
For example, a route named MyS7Route publishes its status to $SYS/Coreflux/Routes/MyS7Route/status.

Status Payload

The status topic publishes a JSON object with connection health, message statistics, and timing information:
{
  "name": "MyS7Route",
  "type": "SIEMENS_S7",
  "connection": "Connected",
  "health": "Green",
  "errors": {
    "total": 0,
    "consecutive": 0,
    "rate": 0
  },
  "messages": {
    "total": 4749,
    "succeeded": 4749,
    "failed": 0
  },
  "lastActivity": "2026-03-03T15:03:14.563Z",
  "lastSuccess": "2026-03-03T15:03:14.563Z",
  "lastError": null,
  "uptime": "00:08:01",
  "connectedSince": "2026-03-03T14:55:13.299Z",
  "timestamp": "2026-03-03T15:03:14.590Z"
}

Field Reference

FieldTypeDescription
namestringThe route name as defined in LoT
typestringThe route type (e.g., SIEMENS_S7, MQTT_BRIDGE, POSTGRESQL)
connectionstringCurrent connection state (Connected, Disconnected, etc.)
healthstringOverall health indicator (Green, Yellow, Red)
errors.totalintegerTotal number of errors since the route started
errors.consecutiveintegerNumber of consecutive errors without a successful message
errors.ratenumberCurrent error rate
messages.totalintegerTotal messages processed
messages.succeededintegerMessages processed successfully
messages.failedintegerMessages that failed processing
lastActivitystringISO 8601 timestamp of the last message (success or failure)
lastSuccessstringISO 8601 timestamp of the last successful message
lastErrorstring | nullISO 8601 timestamp of the last error, or null if no errors occurred
uptimestringTime the route has been running (HH:MM:SS)
connectedSincestringISO 8601 timestamp of when the route established its current connection
timestampstringISO 8601 timestamp of when this status update was generated

Checking Route Status

You can monitor any route’s health by subscribing to its status topic. Use MQTT Explorer or any MQTT client to subscribe:
$SYS/Coreflux/Routes/+/status
This wildcard subscription shows status updates for all active routes at once.

Use Cases

Bridge local edge data to cloud brokers:
DEFINE ROUTE EdgeToCloud WITH TYPE MQTT_BRIDGE
    ADD SOURCE_CONFIG
        WITH BROKER SELF
    ADD DESTINATION_CONFIG
        WITH BROKER_ADDRESS "iot.cloud-provider.com"
        WITH BROKER_PORT '8883'
        WITH USE_TLS "true"
    ADD MAPPING allSensors
        WITH SOURCE_TOPIC "local/sensors/#"
        WITH DESTINATION_TOPIC "edge-01/sensors/#"
        WITH DIRECTION "out"

Next Steps

Industrial Routes

Connect to PLCs and industrial equipment.

Data Storage

Store MQTT data in databases.