Skip to main content

​
The Language of IoT

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe messaging protocol designed for constrained devices and low-bandwidth, high-latency networks. It has become the de facto standard for IoT communication. Before diving into Coreflux features like LoT Actions and Models, you need to understand how MQTT works. Every Coreflux capability builds on these fundamentals—topics, subscriptions, QoS, and message patterns.
Think of MQTT like a radio station. Publishers broadcast on a frequency (topic), and anyone who tunes in (subscribes) hears the message. The broker is the transmission tower that makes it all work.
MQTT is designed to be simple, lightweight, and easy to implement. A minimal MQTT control message can be as small as 2 bytes, making it ideal for resource-constrained devices.

​
In This Page

SectionDescription
The Publish-Subscribe PatternHow MQTT decouples senders and receivers
TopicsThe routing mechanism for messages
WildcardsSubscribe to multiple topics at once
Quality of ServiceMessage delivery guarantees
Retained MessagesStore last message for new subscribers
Last Will and TestamentHandle unexpected disconnections

​
The Publish-Subscribe Pattern

Unlike traditional request-response protocols (like HTTP), MQTT uses a publish-subscribe (pub/sub) pattern. This decouples the sender (publisher) from the receiver (subscriber), allowing for more flexible and scalable architectures.

​
How It Works

1

Publisher sends message

A client publishes a message to a specific topic on the broker.
2

Broker receives message

The broker receives the message and checks which clients are subscribed to that topic.
3

Broker delivers message

The broker forwards the message to all subscribers of that topic.

​
Topics

Topics are the routing mechanism in MQTT. They are UTF-8 strings that the broker uses to filter messages for each connected client.

​
Topic Structure

Topics are hierarchical, using forward slashes (/) as level separators. This hierarchy is powerful for organizing data—especially in industrial settings using patterns like the Unified Namespace (UNS). 
building/floor1/room101/temperature
building/floor1/room101/humidity
building/floor2/room201/temperature

​
Topic Tree Example

A well-designed topic tree organizes your entire system logically: Here’s how this maps to real topics: 
enterprise/
├── factory-munich/
│   ├── production/
│   │   ├── line-1/
│   │   │   ├── cnc-machine-01/
│   │   │   │   ├── temperature
│   │   │   │   ├── vibration
│   │   │   │   └── status
│   │   │   └── robot-arm-02/
│   │   │       ├── position
│   │   │       └── status
│   │   └── line-2/
│   │       └── ...
│   └── quality/
│       └── ...
└── factory-berlin/
    └── ...
Design your topic hierarchy carefully. A well-structured topic tree—often called a Unified Namespace (UNS)—makes it easier to subscribe to related data, manage access control, and scale your system.

​
Topic Best Practices

PracticeExampleDescription
Use hierarchical structurefactory/line1/machine1/statusOrganize topics logically
Be specificsensors/temp/celsiusAvoid overly generic topics
Use lowercasehome/living-room/lightConsistent naming convention
Avoid leading slasheshome/kitchen not /home/kitchenLeading slash creates empty level

​
Wildcards

MQTT supports two wildcard characters for subscribing to multiple topics at once.
The + wildcard matches exactly one topic level.Subscription: building/floor1/+/temperature
Matches: building/floor1/room101/temperature, building/floor1/room102/temperature, building/floor1/lobby/temperature
Does NOT match: building/floor2/room201/temperature (different floor), building/floor1/room101/humidity (different measurement), building/floor1/west/room101/temperature (extra level)
Use wildcards carefully. Subscribing to # alone would receive ALL messages on the broker, which could overwhelm your client and create security risks.

​
Quality of Service (QoS)

MQTT defines three levels of Quality of Service for message delivery. Choose based on your reliability requirements and network conditions.

​
QoS 0 — At Most Once

Fire and forget. The message is sent once with no acknowledgment.
AspectDetail
DeliveryAt most once (may be lost)
AcknowledgmentNone
PerformanceFastest
Use whenFrequent sensor readings where occasional loss is acceptable
Best for: High-frequency telemetry data like temperature readings every second. Missing one reading doesn’t matter when the next arrives immediately.

​
QoS 1 — At Least Once

Acknowledged delivery. The sender stores the message until the broker confirms receipt.
AspectDetail
DeliveryAt least once (may duplicate)
AcknowledgmentPUBACK from broker
PerformanceModerate
Use whenImportant data where your application can handle duplicates
Best for: Event logs, alerts, or status updates. If the same alert arrives twice, your system should deduplicate it.

​
QoS 2 — Exactly Once

Assured delivery. A four-way handshake ensures the message arrives exactly once.
AspectDetail
DeliveryExactly once (guaranteed, no duplicates)
AcknowledgmentPUBREC → PUBREL → PUBCOMP handshake
PerformanceSlowest
Use whenCritical data where duplicates cause problems
Best for: Financial transactions, billing events, or commands where duplicate execution would be harmful (e.g., “dispense medication”).

​
Retained Messages

When a message is published with the retain flag set, the broker stores the last message for that topic. Any new subscriber immediately receives this retained message upon subscribing.
Retained messages are useful for status topics. A new client connecting can immediately know the current state without waiting for the next update.
Example use cases:
  • Device status (online/offline)
  • Current configuration values
  • Last known sensor readings

​
Last Will and Testament (LWT)

The Last Will and Testament feature allows a client to specify a message that the broker should publish if the client disconnects unexpectedly. This is essential for detecting device failures.

​
How LWT Works

1

Client connects with LWT

When connecting, the client specifies its LWT message, topic, QoS, and retain flag.
2

Connection maintained

The broker holds the LWT message as long as the client stays connected.
3

Unexpected disconnect

If the client disconnects without sending a proper DISCONNECT packet (crash, network loss), the broker publishes the LWT message.

​
LWT Configuration Example

A typical pattern for device status monitoring:
SettingValuePurpose
LWT Topicdevices/sensor-01/statusWhere to publish if device disconnects
LWT MessageofflineWhat to publish
LWT RetaintrueKeep message for new subscribers
LWT QoS1Ensure delivery to monitoring systems
When the device connects, it publishes online to the same topic (retained). If it crashes, the broker publishes offline. Monitoring systems always know the current state.

​
Clean Sessions

MQTT supports two session types:
Session TypeClean Session FlagBehavior
Clean SessiontrueNo state is stored between connections. Subscriptions are discarded on disconnect.
Persistent SessionfalseBroker stores subscriptions and queued messages (QoS 1/2) for the client.
Persistent sessions are useful for mobile devices or intermittent connections where you don’t want to miss messages during brief disconnections.

​
Keep Alive

The keep-alive mechanism ensures the connection remains active and detects dead connections quickly.

​
How It Works

StepDescription
1. ConnectClient specifies a keep-alive interval (in seconds) when connecting
2. ActivityClient must send a control packet within each keep-alive period
3. PingIf no data is being sent, the client sends PINGREQ
4. ResponseThe broker responds with PINGRESP
5. TimeoutIf no communication occurs within 1.5x the keep-alive period, the connection is considered dead
Choose keep-alive values based on your network. Shorter intervals (15-30s) detect failures faster but use more bandwidth. Longer intervals (60-120s) are better for mobile networks with variable latency.

​
Next Steps

Broker Commands

Learn how to control the Coreflux broker via MQTT commands.

$SYS Topics

Explore system topics for monitoring and control.