MQTT Vocabulary

Acknowledgement

There are various acknowledgements that are used within MQTT:

• SUBACK
• CONNACK
• PUBACK / PUBREC / PUBREL

Broker

There is no alternative for clients (publisher and subscribers) than to connect to a broker when you are using MQTT protocol architecture. All packets must pass the broker. Each getting checked for specific properties, also the broker filters the package to figure out whom (subscribers) to forward the package to. See more https://docs.cedalo.com/mosquitto/2.1/mqtt/#the-broker-is-the-central-entity

Clean Session

This parameter shows if a client wants to establish a persistent session with a broker or not. Therefore, the cleanSession parameter can have two values: “true” (Client doesn’t want to establish a persistent session. In addition, all previous persistent sessions are dismissed.) or “false”(Client wants to establish a persistent session.)

Clean Start

cleanStart = 0 In this case the server resumes communication with the client based on the state of the current session (the session is identified by the clientId). If there is no earlier session, the broker must create a new session. In case of a connection disconnectiong, the broker must store: Whether the session exists. Even though a topic has no subscriptions and therefore the session would be without real use. All subscriptions. All QoS1 or QoS2 messages that haven't been confirmed by the client yet. cleanStart = 1 In this case the broker discards any previous sessions and opens a new one.

Client

The data is sent via the MQTT protocol. The MQTT broker receives the data, filters the data packet, and forwards it to the receiving clients. In this scenario, the receiving clients could be the radiator or humidifier. This is possible because of the efficient protocol format, and because a broker is used to decouple the sender and receiver. https://docs.cedalo.com/mosquitto/2.1/broker-introduction#intro

Client ID

Most used for cleanSession. In case you have set CleanFlag=false and reconnected with the same clientId, the broker remembers the topics you have subscribed to.

CONNACK

The broker in return responds by sending a so-called CONNACK packet (Acknowledge connection request) and a status code. If the clean session value in a client’s CONNECT message is “true,” then the session present value in the CONNACK response will be “false.” It means that a client and broker should establish a new session and, at the same time, discard any existing one. After the CONNECT and CONNACK packet is exchanged, the connection is enabled. https://docs.cedalo.com/mosquitto/2.1/mqtt/#broker-client-connection

CONNECT

An MQTT broker always connects clients who want to share and clients who want to receive data. https://docs.cedalo.com/mosquitto/2.1/mqtt/#broker-client-connection

Device

In this documentation, any device can be a client. And any client can be a publisher or subscriber.

DUP

A dupFlag indicates the duplicate of a message. https://docs.cedalo.com/mosquitto/2.1/mqtt#dupflag

Flag

There is only the DUP flag available within MQTT.

IP

The Internet Protocol (IP) is a network protocol that is widespread in computer networks and represents the basis of the Internet due to its function. The IP is the implementation of the Internet layer of the TCP/IP model. https://docs.cedalo.com/mosquitto/2.1/security#tcpip-is-not-safe-on-its-own

Keep Alive

The MQTT keepAlive parameter identifies the maximum interval in seconds (e.g., 120, as I show in this article’s example) when a client maintains the MQTT connection but without communication (sending an MQTT packet). After the specified keepAlive parameter period is over, a client sends a PING request (PINGREQ), and a broker has to respond with a PING Response (PINGRESP). If no response follows the PING request, the client can assume the connection has disconnected. Also, the broker is waiting for the PING request. The broker must expect a PINGREQ and wait for another half of the set in the keepAlive parameter time, but then disconnect the connection for good. https://docs.cedalo.com/mosquitto/2.1/mqtt#keepalive

Last Will

The lastWill message is sent by the broker on behalf of the client when a disconnect occurs without a DISCONNECT packet before the actual break-off. Link-> https://docs.cedalo.com/mosquitto/2.1/mqtt/#lastwill

Message

The actual content of a message is the content of a payload. MQTT is not limited by its payload format. It delivers what the publisher is sending. This could be a value, string, JSON file, or even content of a jpg or an mp3 file. Up to 256MB. The payload does not encrypt the content. The broker simply delivers what the publisher inserts into the payload. Link-> https://docs.cedalo.com/mosquitto/2.1/mqtt/#payload

MQTT

MQTT = “MQ Telemetry Transport”. The setup consists of two basic concepts: PUBLISH / SUBSCRIBE and CLIENT / BROKER. And three basic functionalities: CONNECT, PUBLISH, SUBSCRIBE -> https://docs.cedalo.com/mosquitto/2.1/mqtt/

MQTT v.3.1.1

Most MQTT-related devices support v.3.1.1 whilst v.5.0 not. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

MQTT v.5.0

The MQTT version 5.0 is the next development step in the evolution of MQTT. Especially interesting is the changes made to the cleanSession. Have a look here. https://docs.cedalo.com/mosquitto/2.1/mqtt#connect https://docs.cedalo.com/mosquitto/2.1/supported-mqtt-versions/#v50

Packet

There is no definition of when a delivery is called a packet or message. Cedalo is using the term "packet" for any of the commands, and "message" for publishing or subscribing messages. All packets must pass the broker.

Packet ID

Unique packet identifier the broker uses to identify the packet when needed. https://docs.cedalo.com/mosquitto/2.1/mqtt#packetid-1

Password

MQTT can forward and handle username and password within a sent packet. It's important that whenever a packet is not encrypted or hashed (either by implementation or TSL), the password is sent as plain text. https://docs.cedalo.com/mosquitto/2.1/mqtt/#usernamepassword

Payload

MQTT is not limited by its payload format. It delivers what the publisher is sending. The actual content of a message is the content of a payload. https://docs.cedalo.com/mosquitto/2.1/mqtt#payload

Persistent Session

The Persistent session is active when the cleanSession flag is set to false. An active MQTT persistent session (with the cleanSession having the “false” value) is activated whenever the client disconnects ungracefully. All information that the client did not receive from the broker since the last active connection will be preserved on the broker and delivered to the client once the connection is restored. The broker resumes the client in the existing session if the clientId is the same as the disconnected client. A client will not have to resubscribe to all topics again. https://docs.cedalo.com/mosquitto/2.1/mqtt#persistent-sessions

PINGREQ

No matter who is not answering or sending the PINGREQ or PINGRESP within the specific time interval plus another half of the very same interval, the broker or client must disconnect. When this happens, the broker sends the lastWill and testament message. If the client has created one. Within the interval, it's ok that the client and broker do not transmit messages. In fact, after this interval, the client must send a so-called PING Request packet (PINGREQ). https://docs.cedalo.com/mosquitto/2.1/mqtt/#keepalive

PINGRESP

The broker must respond with a PING Response (PINGRESP). If the connection is out of sync, and a participant is not responding - called a "half-open connection", keepAlive takes action. https://docs.cedalo.com/mosquitto/2.1/mqtt/#keepalive

Pub / Sub

The PUBLISH/SUBSCRIBE model connects client that want to exchange information/data/messages. The model consists of the client-server model. Any client communicates with an endpoint via the broker. Before a client wants to publish messages it first has to set up a connection with the broker. Also, a subscribing client has to do the same. Therefore, the broker can decouple the publisher and subscriber. Link-> https://docs.cedalo.com/mosquitto/2.1/mqtt/#central-hub

PUBACK

The broker must acknowledge each SUBSCRIBE packet. Therefore the broker sends a SUBACK packet (subscribe acknowledge) to the client. https://docs.cedalo.com/mosquitto/2.1/mqtt/#subscriptions

PUBCOMP

To discard all stored states and answers a so-called PUBCOMP packet (Publish complete) is sent. That's the end of the QoS2 order of events. https://docs.cedalo.com/mosquitto/2.1/quality-of-service/#qos2---exactly-once

PUBLISH

The PUBLISH packet consists of details that indicate to the broker what to do. Read more about these here. https://docs.cedalo.com/mosquitto/2.1/mqtt/#packetid https://docs.cedalo.com/mosquitto/2.1/mqtt/#mqtt-pubsub-model

Publisher

Either one publisher publishes messages to multiple Subscribers. Or multiple publishers publish messages to just one subscriber. Or any combination of multiple publishers/subscribers. Any publisher can only be identified when information about the publisher is included in the topic or payload. https://docs.cedalo.com/mosquitto/2.1/mqtt#client-server-model

PUBREC

A PUBREC Packet is a response to a PUBLISH Packet with QoS 2. It is the second packet of the QoS 2 protocol exchange. https://docs.cedalo.com/mosquitto/2.1/quality-of-service/#qos2---exactly-once

PUBREL

A PUBREL is another packet the broker sends after receiving the PUBREC packet. This packet must be responded to with a PUBCOMP packet. https://docs.cedalo.com/mosquitto/2.1/quality-of-service/#qos2---exactly-once

Quality of Service QoS

The QoS (Quality of Service) defines a certain level of service that enables the publisher to make sure that the certainty and quantity of a subscriber receiving a sent message equal the importance to receive the message at all, plus whether to receive the message only once. Also, a subscriber can set a QoS, defining the importance to receive every message, and whether to accept one message multiple times or not. There are three levels available. -> https://docs.cedalo.com/mosquitto/2.1/mqtt/#qos

QoS 0

The broker/client is delivering the message only once, without confirmation. There is no guarantee that the message sent has been sent to the subscriber. The recipient on the other end does not acknowledge the receipt. Neither is the acknowledgment stored. The QoS0 - level is often referred to be the "fire and forget"-level. https://docs.cedalo.com/mosquitto/2.1/mqtt/#qos-0---at-most-once

QoS 1

Level 1 QoS guarantees the delivery of a message to the receiver at least once. https://docs.cedalo.com/mosquitto/2.1/mqtt/#qos-1---at-least-once

QoS 2

QoS level 2 guarantees each message is received exactly once. https://docs.cedalo.com/mosquitto/2.1/mqtt/#qos-2---exactly-once

Queue

When a persistent session is active, the broker must queue the missed messages. Whenever a persistent session is created by the client, and the broker already queued messages of an earlier persistent session, the broker delivers the queued messages using the same old session. https://docs.cedalo.com/mosquitto/2.1/mqtt#persistent-sessions

Retained Message

A retained message safes the last known value of the topic. It's only possible to save up to one retained message, equal to one retained value. The retainFlag identifies a message to be a retained message. To identify the message itself the packetId is used. https://docs.cedalo.com/mosquitto/2.1/mqtt#retainflag

Return Code

The return code is used within a SUBACK packet. The broker sends one return code for each topic/QoS-pair that it receives in the SUBSCRIBE packet. The return codes can be:

• 0 - Success-Maximum QoS0
• 1 - Success-Maximum QoS1
• 2 - Success-Maximum QoS2
• 128 - Failure

Session

If a client connects to the broker a session is started. If a client connects to the broker and another client session already exists with the clientId that the new client has chosen, the old session will be kicked out and taken over.

Session Expiry Interval

sessionExpiryInterval:

Whenever a session ExpiryInterval is set (e.g. 60) a cleanStart is automatically set to “0”. With a sessionExpiryInterval active the sessionState will be saved immediately after the keepAlive runs out (e.g. 120 plus half of the keepAlive - that would be 60 seconds in this case).The sessionState is safed for the amount of time set (in this case 60 seconds). sessionExpiryInterval is solving the problem that you don’t need to send anther CONNECT packet including cleanSession=1 (MQTT v.3.1.1) to discard the session after set it retained.

SUBSCRIBE

To receive messages on topics of interest, the client sends a SUBSCRIBE packet to the broker. https://docs.cedalo.com/mosquitto/2.1/mqtt#subscribe

Subscriber

Direct contact between subscriber and publisher is never able. Only the broker enables transmitting messages. Also, the subscribing client only has one duty. To subscribe to the topic it wants to receive messages from. The subscriber-only knows about the existence of the publisher as the client subscribes to the published topics. https://docs.cedalo.com/mosquitto/2.1/subscribing

Subscription

A subscription consists of a packetId. And the subscriptions the subscriber wants to subscribe to. Each subscription consists of a topic and a QoS level. When subscriptions overlap, the broker delivers the message that has the highest QoS level for the specific topic. https://docs.cedalo.com/mosquitto/2.1/broker-introduction#subscribe

TCP

TCP is embedding TLS (Transport Layer Security). Allowing MQTT packets to be transmitted via encrypted pipes. TLS protects all parts of an MQTT packet, not only the payload. https://docs.cedalo.com/mosquitto/2.1/security#authorization

TLS

Using Transport Layer Security (TLS) provides a secured communication channel a client and a server can use to connect. TLS is a cryptographic protocol, that uses a handshake mechanism to create a secure connection between client and server. https://docs.cedalo.com/mosquitto/2.1/security#server-side-tls

Topic

The topic is set using a simple UTF-8 string. Topics are treated hierarchically. To delimiter, a slash "/" symbolizes a separation. Allowing the client organizational structure, much like a common filesystem. There is no need for creating a topic. You can subscribe to any topic, even though there might not be messages published. On the other hand, you must know about the topic names to be able to subscribe to them. Link-> https://docs.cedalo.com/mosquitto/2.1/mqtt/#central-hub

UNSUBSCRIBE

A client can always UNSUBSCRIBE from a topic. The UNSUBSCRIBE packet includes the packetId and list of topics the subscriber wants to unsubscribe from.

Username

MQTT can forward and handle username and password within a sent packet. https://docs.cedalo.com/mosquitto/2.1/mqtt/#usernamepassword

Wildcard

Subscribing to several topics simultaneously is an option that's possible. There are two kinds of wildcards: single-level and multiple levels. https://docs.cedalo.com/mosquitto/2.1/mqtt/#subscriptions

"#" is used, the client subscribes to each topic that's after the #.

+

“+” is the wildcard used to match a single level of hierarchy.