🔴 ALLES über MQTT in nur 14 Minuten, einfach erklärt! | #EdisTechlab

Edi's Techlab
6 Feb 202114:16

Summary

TLDRThis Edis Techlab video delves into MQTT, a network protocol for machine-to-machine communication, originally designed for minimal battery and bandwidth usage in remote systems. It explains the protocol's evolution to IoT applications, the client-server model with a broker at its core, and the roles of publishers and subscribers. The video covers MQTT topics, wildcards, Quality of Service levels, retained messages, persistent sessions, and the Last Will and Testament feature. It also touches on keep-alive mechanisms ensuring active connections, promising a practical MQTT application in the next episode.

Takeaways

  • 📚 MQTT stands for Message Queuing Telemetry Transport, a network protocol for machine-to-machine communication.
  • 🛠️ It was developed in 1999 by Dr. Andy Stanford-Clark and Ellen Neibach, primarily for low battery and bandwidth connectivity, such as satellite connections to oil pipelines.
  • 🔄 MQTT's focus has shifted from embedded systems to the Internet of Things (IoT) and became an OASIS standard on October 29, 2014.
  • 🌐 It operates on a client-server model with a broker at the center, similar to a post office, filtering and distributing messages to subscribers.
  • 🔄 MQTT clients can act as both publishers and subscribers, depending on whether they are sending or receiving messages.
  • 📈 Topics in MQTT are used for message filtering and can consist of multiple levels separated by slashes, with certain rules for structuring them effectively.
  • 🌟 MQTT supports topic wildcards, allowing clients to subscribe to multiple topics simultaneously, using single-level (+) and multi-level (#) placeholders.
  • 📉 Quality of Service (QoS) levels in MQTT range from 0 (At Most Once) to 2 (Exactly Once), determining message delivery guarantees and reliability.
  • 🔒 Retained messages allow the broker to store the last message on a topic, ensuring that new subscribers immediately receive the most recent data.
  • 🔄 Persistent sessions help maintain subscriptions across client reconnections, conserving resources by avoiding the need to resubscribe to topics.
  • 🗝️ Last Will and Testament is a feature that allows a client to leave a final message to be sent in the event of an unexpected disconnection.
  • 🕒 Keep-alive is a mechanism to ensure an active connection between the client and broker by sending ping requests within a specified time frame.

Q & A

  • What does MQTT stand for and what is its primary purpose?

    -MQTT stands for Message Queuing Telemetry Transport. It is a network protocol for communication between machines, primarily designed for minimum battery loss and minimum bandwidth usage, originally to connect to oil pipelines via satellite.

  • Who developed the MQTT protocol and when was it developed?

    -The MQTT protocol was developed in 1999 by Dr. Andy Stanford-Clark from IBM and Ellen Neibach from Agrom, now at CirrusLink.

  • What does OASIS stand for and when did MQTT become an officially recognized OASIS standard?

    -OASIS stands for Organization for the Advancement of Structured Information Standards. MQTT became an officially recognized OASIS standard on October 29, 2014.

  • What is the role of a broker in MQTT communication?

    -In MQTT communication, the broker acts as a central hub, similar to a post office, filtering all incoming messages and sending them to the appropriate subscribers, ensuring that senders and subscribers never have direct contact with each other.

  • Can an MQTT client be both a publisher and a subscriber?

    -Yes, an MQTT client can be both a publisher and a subscriber, depending on whether the client is currently sending or receiving messages.

  • What are the basic rules for structuring MQTT topics?

    -The basic rules for MQTT topics include: being case sensitive, not starting with a dollar sign, not using a slash at the beginning, avoiding spaces, keeping topics short to save resources, and not using special characters.

  • What are the two types of wildcards used in MQTT topics for subscribing to multiple topics at once?

    -The two types of wildcards are single-level placeholders (represented by a plus sign '+') and multi-level placeholders (represented by a hash sign '#').

  • What does QoS stand for and what are the three levels of QoS in MQTT?

    -QoS stands for Quality of Service. The three levels are: 0 - At Most Once (Fire and Forget), 1 - At Least Once, and 2 - Exactly Once.

  • What is the purpose of the Last Will and Testament feature in MQTT?

    -The Last Will and Testament feature allows a client to save a message on the broker, which will be sent to all clients subscribed to the Last Will Topic if the client loses connection to the broker.

  • What is the function of the keep-alive mechanism in MQTT?

    -The keep-alive mechanism defines a time interval in which communication between the client and the broker must occur. If no communication happens within this interval, the client sends a ping request to ensure the connection is still active, and the broker responds to confirm the connection.

  • What is a retained message in MQTT and how does it differ from a non-retained message?

    -A retained message in MQTT is a message that is saved in the broker and sent to new subscribers immediately upon their subscription. A non-retained message is deleted if no one is subscribed to it, and new subscribers will only receive messages sent after their subscription.

  • What is the significance of a persistent session in MQTT and how does it differ from a non-persistent session?

    -A persistent session in MQTT ensures that the topics to which a client has subscribed are not lost when the connection is terminated. The client will automatically reconnect to all subscribed topics upon reconnection. In contrast, a non-persistent session requires the client to resubscribe to topics with each new connection.

Outlines

00:00

📚 Introduction to MQTT Protocol

This paragraph introduces the MQTT protocol, which stands for Message Queuing Telemetry Transport, designed for machine-to-machine communication with an emphasis on minimal battery consumption and bandwidth usage. Developed in 1999 by Dr. Andy Stanford-Clark and Ellen Neibach, MQTT was initially intended for satellite communication with oil pipelines but has since evolved to support IoT applications. It operates on a client-server model with a broker acting as a message filter and distributor. The protocol allows clients, which can be sensors or devices like laptops or phones, to publish and subscribe to topics, enabling efficient data exchange. The paragraph also covers basic MQTT topic structures, wildcards for subscribing to multiple topics, and the importance of adhering to certain rules for effective communication.

05:05

🔄 Understanding MQTT's Quality of Service (QoS) and Retained Messages

This section delves into MQTT's Quality of Service (QoS) levels, which determine the reliability of message delivery. QoS 0, 'At Most Once', is the least reliable, with messages sent without confirmation. QoS 1, 'At Least Once', ensures message delivery by using packet IDs and acknowledgments, which may result in message duplication. QoS 2, 'Exactly Once', guarantees unique message delivery through a four-step handshake process involving packet IDs and multiple acknowledgment packets. The paragraph also explains retained messages, which allow the broker to store the last published message on a topic for new subscribers, ensuring they receive the most recent data upon subscription.

10:07

🔒 MQTT Connection Management and Last Will and Testament

The final paragraph discusses MQTT's connection management features, including persistent sessions that allow clients to maintain their subscription state across reconnects by setting a 'clean session' flag to false. It also introduces the concept of 'Last Will and Testament', a feature that allows clients to send a final message in case of an unexpected disconnection. The paragraph explains how to set up a persistent connection, the process of subscribing to topics with different QoS levels, and the automatic reconnection to topics upon reestablishing a connection. Additionally, it covers the 'keep-alive' mechanism, which ensures the connection remains active by exchanging ping requests and responses between the client and broker. The paragraph concludes with an invitation to a future practical MQTT application example involving a pushbutton and an LED.

Mindmap

Keywords

💡MQTT

MQTT, which stands for Message Queuing Telemetry Transport, is the central theme of the video. It is a network protocol designed for communication between machines, particularly in the context of the Internet of Things (IoT). The protocol was developed to facilitate minimal battery loss and bandwidth usage, as exemplified by its initial application in connecting oil pipelines via satellite. The video script explains how MQTT operates on a client-server model with a broker acting as an intermediary for message exchange.

💡IoT (Internet of Things)

IoT refers to the network of physical devices, vehicles, and other items embedded with sensors, software, and connectivity that enable them to collect and exchange data. In the context of the video, MQTT's primary focus has shifted from embedded systems to IoT, highlighting its importance in modern smart device communication.

💡OASIS Standard

OASIS, which stands for Organization for the Advancement of Structured Information Standards, is mentioned in the script as the body that officially recognized MQTT as a standard on October 29, 2014. This signifies the protocol's acceptance and standardization for broader use in structured information exchange.

💡Broker

In the MQTT protocol, the broker is likened to a post office, filtering and forwarding messages between clients. It is central to the client-server architecture, ensuring that publishers and subscribers do not need to be in direct contact with each other, which is crucial for the efficient routing of messages.

💡Client

A client in the MQTT context can be any device capable of sending or receiving messages, such as a sensor, actuator, or even a laptop or telephone. The script mentions that clients can be both publishers and subscribers, depending on whether they are sending or receiving data at any given moment.

💡Topic

Topics in MQTT are used by the broker to filter messages. They consist of one or more topic levels separated by slashes and are crucial for organizing and categorizing the data being exchanged. The script provides examples of how topics can be structured and the rules for creating a clean topic structure.

💡Wildcards

Wildcards in MQTT allow clients to subscribe to multiple topics simultaneously. The script explains the use of single-level (+) and multi-level (#) placeholders, which can be used to subscribe to various topics under a certain level or to all topics at any depth, respectively.

💡Quality of Service (QoS)

QoS levels in MQTT determine the reliability of message delivery. The video script outlines three levels: 0 (At Most Once), 1 (At Least Once), and 2 (Exactly Once). Each level ensures a different degree of message delivery guarantee, with increasing levels requiring more bandwidth and complexity.

💡Retained Messages

Retained messages are a feature in MQTT where the broker saves a message even if no client is currently subscribed to the topic. The script explains that when a client subscribes to a topic with retained messages, they immediately receive the last published message, ensuring that they have the most recent data available.

💡Persistent Session

A persistent session in MQTT ensures that the client's subscription to topics is maintained even after a connection is terminated. The script describes how setting a clean session flag to false creates a permanent connection, allowing the client to retain its subscription status upon reconnection.

💡Last Will and Testament

This feature allows a client to send a final message to a specified topic if it unexpectedly loses connection to the broker. The script details how the Last Will and Testament is configured in the Connect packet, including the message content and whether it should be retained.

💡Keep-Alive

Keep-alive in MQTT is a mechanism to ensure that the connection between a client and the broker remains active. The script explains that if no communication occurs within the specified keep-alive time, the client sends a ping request, which the broker must acknowledge, thus preventing the connection from timing out.

Highlights

MQTT stands for Message Queuing Telemetry Transport, a network protocol for machine-to-machine communication.

Developed in 1999 by Dr. Andy Stanford-Clark and Ellen Neibach for minimum battery loss and bandwidth to connect oil pipelines via satellite.

MQTT's primary focus has shifted from embedded systems to open Internet-of-Things (IoT).

On October 29, 2014, MQTT became an officially recognized OASIS standard.

MQTT operates on the client-server principle with a broker at the center of communication.

A client can be a sensor, actuator, or any device capable of sending or receiving data to/from the broker.

MQTT topics are used by the broker to filter messages and consist of one or more topic levels separated by slashes.

Topics are case sensitive and have basic structural rules for clarity and efficiency.

Topic wildcards allow clients to subscribe to multiple topics simultaneously.

QoS (Quality of Service) levels determine message delivery reliability: At Most Once, At Least Once, and Exactly Once.

Retained messages allow the broker to store the last message on a topic for new subscribers.

Persistent sessions maintain client subscriptions across connection interruptions.

Last Will and Testament allows a client to leave a final message to be sent in case of abrupt disconnection.

Keep-alive mechanism ensures the connection is active by sending ping requests.

Upcoming practical MQTT application example: Reading a pushbutton signal to switch on an LED via MQTT.

Edis Tech Lab offers a DIY home automation book with growing content and early bird pricing.

Transcripts

play00:00

Hello and welcome to Edis Techlab. Today's video is about MQTT. I have before

play00:08

already made a video about it a long time ago about it. If you want it short and sweet,

play00:12

I'll link you to it below in the video description the link to it. If you want it in detail,

play00:18

you can now look forward to it. And after this video I am sure that EVERYONE CAN DO IT!!!

play00:37

MQTT stands for Message Queuing Telemetry Transport and is a network protocol for

play00:44

communication between machines to machines. The MQTT protocol was developed in 1999 by Dr. Andy Stanford-Clark

play00:53

by IBM and Ellen Neibach at the time from Agrom and now at CirrusLink

play01:01

invented. They needed a protocol for minimum battery loss and minimum bandwidth,

play01:07

to connect to oil pipelines via satellite. via satellite. However, the primary

play01:15

focus of the protocol has shifted from embedded systems to open Internet-of-Things, the so-called IoTs,

play01:22

modified. On October 29, 2014, MQTT became an officially recognized OASIS standard. OASIS stands for

play01:34

for Organization for the Advanced of Structured Information Standards. MQTT works according to the

play01:41

so-called client-server principle. At the center of every MQTT communication is the broker. The

play01:50

broker is like a post office, so to speak. The senders and subscribers never

play01:56

in direct contact with each other. All incoming messages are filtered by the broker and sent to the

play02:02

subscribers. A client can now be a be a sensor, such as a temperature sensor, a

play02:10

actuator or any output device such as a fan fan or even a laptop or telephone. Any

play02:18

participant can send data to the broker. Here example, the temperature sensor, which measures 20 degrees

play02:25

to the temperature topic. If the fan is interested in the temperature data, it can send

play02:33

subscribe to the temperature topic and receives receives the 20 degrees from the MQTT broker. On

play02:40

MQTT client can be both a publisher and a subscriber, depending a subscriber, depending on whether the client is currently

play02:48

is sending or receiving messages. Let's take a look at now take a closer look at the MQTT topic. The topic,

play02:56

translated topic, is used by the broker to filter messages messages from all clients. The topic

play03:04

consists of one or more topic levels. Each topic level is separated by a slash

play03:10

separated by a slash. Which structure you choose for your topics for your topics is up to you and there are so

play03:16

almost no restrictions. Nevertheless, there are a a few basic rules for a clean topic structure.

play03:22

The topics are case sensitive. capitalization. The dollar sign

play03:28

must not be used at the beginning of a topic as it is used for internal statistics by the broker

play03:34

is used for internal statistics. Do not use the slash at the beginning of a topic. It is allowed, but

play03:41

This creates another topic label, which is filled with a zero character and nothing

play03:46

brings. Do not use spaces in the topics. These are difficult to read and you can

play03:53

Avoid mistakes. Use short topics. These are sent with every message and you

play03:59

do not waste unnecessary resources. As a last point, do not use special characters. These

play04:06

are often displayed incorrectly and the use of of umlauts or special characters is not recommended.

play04:11

recommended. Next, let's take a look at the Topic wildcats. When a client subscribes to a topic,

play04:19

he can subscribe to the exact topic of a published message or it can subscribe to placeholders

play04:25

to subscribe to several topics at the same time. at the same time. There are single-level placeholders

play04:33

and multi-level placeholders. With the plus sign can be used to replace one or more topic levels.

play04:40

Let's take an example. Let us assume we assume that all temperatures in the

play04:46

first floor. The wildcard is used for the different rooms on the first floor.

play04:52

The wildcard now replaces the various rooms, such as the kitchen in this example,

play04:57

the storage room or the terrace. With the hash sign replaces several topic labels

play05:04

and the hash sign is always in the last position position and replaces the subsequent topic labels,

play05:10

regardless of how deeply they are nested. With this wildcard we get all the data that we

play05:18

from the first floor. For example the kitchen, temperature and humidity,

play05:23

whether the light is on in the storage room or the temperature on the terrace. Now we come to

play05:31

to QoS. This stands for Quality of Service Level. The lowest quality of service level is 0.

play05:42

And it is called At Most Once, i.e. at most once. The message is sent after

play05:49

is not saved or sent again. This method is also called Fire and Forget.

play05:57

The QoS1 label stands for at least once, i.e. at least once. This QoS1 label guarantees,

play06:07

that a message reaches the recipient at least once. recipient at least once. And that is also

play06:14

the most frequently used. The sender sends a packet ID when sending each message

play06:20

and stores it until receipt of the message is confirmed with a message is confirmed with a pub-back packet.

play06:26

The Pub-Back stands for Publish Acknowledgement and contains the packet ID to ensure

play06:33

that the correct message has been received. If the sender does not receive a Pub-Back packet,

play06:38

then it sends the message again and marks it as a duplicate. This makes it possible,

play06:44

that the message is sent multiple times. QoS 2 exactly once,

play06:53

the last and highest level of QoS guarantees that each message is only sent once to a recipient

play07:00

arrives only once. The packet ID of the message is also sent by Abender and the message

play07:07

is saved. The broker confirms receipt of the of the message with a PubRec packet. This is

play07:14

for Publish Received. If the sender does not receive a PubRec packet, the message is sent again at

play07:21

is sent again and marked as a duplicate. If the sender has received the PubRec packet, the message

play07:28

is deleted and a PubRel packet, Publish Release, is sent to the recipient. The receipt is confirmed by the

play07:36

Broker confirms receipt by sending a PubComp package, Publish Complete, with the package ID as content to the

play07:43

sender. The additional messages delays the delivery and valuable

play07:49

bandwidth is required for QoS 2. If you want to learn more about MQTT, I can provide you with a

play07:58

good book. You can find it in the e-book store at Edis Tech Lab on the website. For only 99

play08:05

cents. If you would rather have all the projects, then I recommend the DIY home automation book

play08:12

in the Early Bird Edition. Here you will find all Edis Tech Lab projects and the book is growing

play08:19

month by month. If you buy the book early you can really save money, because by

play08:26

the increased content, the price is also slightly month slightly adjusted. Many thanks in advance!

play08:34

Retained messages, or withheld messages.

play08:39

When a temperature sensor sends a message to the broker, the message,

play08:45

is deleted again if no one has subscribed to it. If a client now subscribes to the temperature topic,

play08:51

then he will not receive a message. He must now wait until the temperature sensor sends new

play08:58

sends new data. Only then will the broker make this data available to him. A display

play09:06

for the temperature would not display a value after the connection with a topic would not display a value for this long,

play09:12

until a temperature sensor sends a new value to the sends a new value to the topic. This state can be bypassed,

play09:18

by the client setting the retained flag sets the retained flag to true. This will

play09:26

the temperature value is saved in the broker. If the client now subscribes to the temperature topic,

play09:33

then the broker will immediately display the temperature value that is stored,

play09:38

will be sent back to him. This means that the temperature display instead of no value at all, at least an older

play09:45

instead of no value at all. Persistent session or the permanent connection connection If a non-persistent session

play09:54

between the client and the broker is terminated, the topics to which the client has subscribed are lost,

play10:00

are lost. With each new connection, the client must log in again for all topics

play10:07

and this costs a lot of resources. To avoid this problem to avoid this problem, the client can connect to the

play10:14

broker can request a permanent connection. To do this a clean session flag is set in the connect package

play10:21

is used. If this is set to False, a permanent connection is created. At

play10:27

True is not. The broker confirms this with a Connection Acknowledgement packet. After the

play10:37

connection is established, the client can subscribe to all subscribe to all the topics it wants. This can be

play10:44

in the form of a list where the topic and the corresponding associated Quality of Service is specified.

play10:51

The broker now saves all information that is relevant for the client and sends a

play10:58

Subscribe-Acknowledge packet. If the connection is interrupted and the client reconnects with the

play11:04

broker, then all messages with a QoS with a QoS 1 and QoS 2, which it still wants to receive.

play11:12

has not yet received. And it is automatically reconnected reconnected to all topics to which he has subscribed.

play11:21

If you haven't done so yet, now is a good time a good time to subscribe to the channel and

play11:27

to press the little bell. While you're at it I would of course also appreciate a Like

play11:33

very much. Now we come to Last Will and Testament, which means the last will and testament.

play11:41

the will. With the Last Will and Will function can be used in the broker at the first

play11:48

the will can be saved by the client on the first be saved. The Last Will and Testament is a

play11:55

normal MQTT message in the Connect package. Here we can specify the Last Will Topic with the

play12:01

associated Quality of Service number. In the Last Will Message we can write the text,

play12:08

that we want to store as a will. With Last Will Retain we specify whether we want to use

play12:15

whether we want to save the message in the broker. The The broker confirms receipt of the connect packet

play12:21

with a Connection Acknowledge packet. If the client loses the connection to the broker, then

play12:28

the broker sends the Last Will message to all clients clients that have subscribed to the Last Will Topic.

play12:37

We have almost done it. Now the Keep-alive and then we'll be through.

play12:43

With keep-alive we define a time in seconds, in which communication between the client

play12:50

and the broker must take place. If no message is sent within this no message is sent during this specified time,

play12:55

then the client sends a ping request is sent by the client. This ping request packet

play13:02

is then confirmed by the broker with a ping response by the broker. This allows us to ensure that

play13:08

that the connection is still active. If the keep-alive time is exceeded by 50% without

play13:16

a message has been sent, then the broker broker terminates the connection to the client. If the client

play13:22

does not receive the ping response file from the broker, then the client disconnects from the broker.

play13:30

Next week we will then make a practical application example for MQTT. We will read

play13:36

a pushbutton signal and switch on the LED on the other the LED on the other microprocessor using MQTT.

play13:44

See you next week. Your Edi. If you liked the video, please give me a

play13:53

Thumbs up. Subscribe to the channel. Thank you very much for watching. See you next time. Edis Techlab

Rate This

5.0 / 5 (0 votes)

Etiquetas Relacionadas
MQTT ProtocolIoT CommunicationTech TutorialMessage QueuingClient-ServerQuality of ServiceRetained MessagesPersistent SessionsLast WillKeep-AliveIoT Basics
¿Necesitas un resumen en inglés?