What is MQTT?

MQTT helps devices and systems exchange data without being directly connected to each other. A sensor, machine, or gateway sends a message to the MQTT broker. Other systems, for example a dashboard or MES, subscribe to the matching data and receive it automatically.

The important difference from many classic interfaces: MQTT works with events. A system does not have to keep asking whether new data is available. It subscribes to a topic and automatically receives new messages when they are published.

That makes MQTT a good fit for IoT and industry: many devices can send small amounts of data, even when connections are not always stable. The data moves quickly from machines and sensors into IT systems.

The name MQTT today simply refers to the protocol. It used to mean “MQ Telemetry Transport”. Some people also say “Message Queuing Telemetry Transport” – but that is not quite technically correct.

MQTT has only a few roles and a clear flow. Every participant is a client. The client connects to the broker, publishes messages, or subscribes to topics. The broker is the hub.

• Connect: The client connects with host, port, client ID, keep alive, and optional credentials.
• Subscribe: A receiving client subscribes to a topic or topic filter.
• Publish: A sending client publishes a message with topic, payload, QoS, and optional retain flag.
• Forward: The broker forwards the message to every matching subscription.

MQTT usually runs over TCP. Common ports are 1883 for plain MQTT and 8883 for MQTT over TLS. In browsers and web dashboards, MQTT is often transported over WebSockets.

The MQTT broker is the central server in an MQTT system. MQTT clients do not normally talk directly to each other.

Common brokers include Mosquitto, HiveMQ, EMQX, and cloud services such as AWS IoT Core.

MQTT topics are hierarchical names for messages. A topic can look like this:

factory/line1/press7/temperature

Good topic design matters. It defines how systems find, filter, and authorize data. A typical industrial structure separates site, line, machine, and signal.

• Plus wildcard: factory/+/press7/state stands for exactly one variable segment in the topic path, for example line1 or line2.
• Hash wildcard: factory/line1/# matches everything below factory/line1, no matter how many additional path segments follow.
• System topics: topics that start with $ contain internal broker information such as status, statistics, or connection data. They are not normal machine data.

Topics should be stable, readable, and not too granular. Modeling every single bit as a separate topic usually creates more operational overhead than value.

QoS means Quality of Service. MQTT defines three delivery levels. They describe the guarantee between sender, broker, and receiver. Higher QoS means more protocol traffic and more state in the system.

• QoS 0 - at most once: The message is sent once. There is no acknowledgement. Good for frequent measurements where losing one value is acceptable.
• QoS 1 - at least once: Delivery is acknowledged. The message arrives, but duplicates can happen during retries. Receivers must handle that.
• QoS 2 - exactly once: Delivery uses a four-step handshake so the message arrives exactly once. It is the heaviest option and should be reserved for cases where duplicates are a real business problem.

In many industrial projects, QoS 1 is the pragmatic default for relevant events. QoS 0 fits fast telemetry. QoS 2 is rarely needed and should be a deliberate decision.

MQTT is more than live messages. Retained messages, persistent sessions, and Last Will make systems more robust when connections are interrupted.

• Retained message: The broker stores the last message on a topic and sends it immediately to new subscribers. This is useful for current setpoints, status, or configuration.
• Session: The broker can keep subscriptions and pending QoS messages for a client while it is offline.
• Last Will and Testament: The client registers a will message. The broker publishes it if the client disconnects unexpectedly.

MQTT 3.1.1 is widely deployed and still completely sufficient for many applications. MQTT 5 extends the protocol with features that make large professional systems easier to operate and diagnose.

• Reason codes: Clients receive clearer feedback on why a connection or subscription was rejected.
• User properties: Messages can carry metadata as key-value pairs.
• Message expiry: Messages can become invalid automatically after a defined time.
• Topic alias: Repeated long topic names can be sent more efficiently.
• Request/response: Response Topic and Correlation Data make request-response patterns easier.

New projects should evaluate MQTT 5. If existing devices only support MQTT 3.1.1, that is not a blocker. The key point is that broker, clients, and security concept fit together.

MQTT is not automatically secure or insecure. Security depends on transport, authentication, authorization, and operation. An open broker in a production network is a risk. A segmented broker with TLS and topic-level rights is a solid integration component.

• TLS: Encrypts the connection and prevents payloads and credentials from moving in clear text.
• Authentication: Clients identify themselves with username/password, certificates, or an external identity system.
• Authorization: Not every client should read or write every topic. The broker should clearly define which clients may access which topics.
• Network design: Brokers belong in defined zones. Direct connections from the IT network into control networks should be avoided.

MQTT does not replace every protocol. It is strong when many clients exchange event-based telemetry or status messages. Other protocols have different strengths.

• MQTT vs HTTP: HTTP is ideal for classic request-response APIs. MQTT is more efficient for continuous telemetry and many small events.
• MQTT vs WebSocket: WebSocket is a transport for bidirectional connections. MQTT can run over WebSocket, but adds topics, QoS, and broker semantics.
• MQTT vs AMQP: AMQP is broader and strong in enterprise messaging with queues and routing. MQTT is simpler and better suited for small clients.
• MQTT vs Kafka: Kafka is a distributed event-log and streaming platform. MQTT is lightweight edge and device communication. In large architectures, both are often combined.

MQTT is used where many sources deliver small data packets or receive control information. In industry, MQTT is often the bridge between the plant level and IT.

• Machine data from gateways to MES, ERP, or a time-series database.
• Status messages from plants, robots, and conveyors.
• Energy, temperature, pressure, and vibration data.
• Home Assistant, ESP32, and Raspberry Pi projects.
• Remote monitoring for distributed machines and sites.
• Edge-to-cloud integration with AWS IoT, Azure IoT, or private brokers.

See our practical Industry 4.0 guide for the wider architecture connecting MQTT with PLCs, edge, MES, and cloud platforms.

The MQTT ecosystem offers tools for different tasks.