We'll start with a completely different architecture. During this first video about MQTT, 1
we're going to move away from the LoRaWAN architecture in order to concentrate on the protocol itself. 2
This MQTT protocol is widely used in IoT, but it has nothing to do with LoRaWAN. 3
So everything we're going to learn here could be applied to other applications. 4
Once we'll have a good understanding of MQTT, then we'll use it for the dialogue between the LoRaWAN server 5
and the IoT platform. 6
The central point of this protocol is an entity called Broker. 7
It centralizes all data. 8
That means that if we want to send something, we need to send it to the broker first. 9
And if we want to receive something, then the broker will provide it. 10
But who sends the data? 11
In IoT, it's mainly sensors that provide the information. 12
So they're the ones that want to send data. 13
If, for example, we have a temperature sensor and a humidity sensor, then they simply provide the 14
data to the broker. 15
To keep things tidy, they will push the data to the broker within a specific topic. 16
It's a simple name that can be chosen accordingly to classify the data on the broker. 17
In our example, the humidity sensor and temperature sensor could simply use the topic humidity and 18
temperature. 19
Anyone who sends data to the broker in a topic is called a publisher, and we say that the sensor publishes 20
data. And now who receives the data? 21
It could be anyone that needs it. 22
In reality, they are mainly actuators that retrieve the information to process it and act accordingly. 23
The action carried out can be as simple as displaying the value to the user. 24
In our example, if the actuator is a heating system, then it would surely be interested in the temperature. 25
But to be more efficient, the actuator must not ask for the temperature information. 26
It should receive them right away as soon as they are available on the broker. 27
For that it must subscribe to a specific topic on the broker. 28
In our case, it will subscribe to the temperature topic. 29
If we now take the example of a drying system, then it will probably be interested in both the temperature 30
and the humidity. 31
Therefore, it needs to subscribe to both topics. 32
Speaking about topics, I would like to give you a little bit more information about them. 33
We'll take another simple example of a smart building application. 34
In this house, there are two rooms in which there are three sensors : temperature, humidity and noise. 35
To refer to a specific sensors in the house, 36
we represent the topic with a string representing its hierarchy. 37
So if I'm interested in the temperature of a bedroom in the house, the topic will be : 38
house/room/temp. 39
And if I'm now interested in the temperature of the living room, then the topic will be : 40
house/living-room/temp. 41
And if we use special characters, we can refer to several topics at the same time. 42
For example, if I'm now interested in all sensors representing the temperature, the humidity and the 43
noise in the whole house, then we use the # character. 44
So the topic will be house/#, or simply #. Hash can only be at the end of the topic, 45
and it's a multi level wild card. 46
Everything under the level where the hash is is targeted by this wild card. 47
And finally, it's also possible to designate a specific sensor in the house. 48
For this example, let's say we're looking for the temperature of all rooms in this house. 49
So we need both the temperature of the bedroom and the temperature of the living room, but only temperatures. 50
In that case, I need a wild card for the room name because I don't want to choose a specific one at 51
the room topic level. 52
The signal level wild card is the + characters. 53
The topic will be house/+/temperature. 54
So we can see that we have a lot of flexibility in the designation of the topic. 55
And thanks to the two wild card characters, publishers and subscribers will be able to select exactly 56
the data they want to target. 57
Great. 58
So MQTT might be a new concept for us. 59
There are still a few characteristics that I want to explain. 60
First, publishers and subscribers don't know each other. 61
There is never any direct dialogue between subscribers and publishers. 62
They always deal with the broker. 63
They just have a common point of interest, which is their topics. 64
So a publisher doesn't know if there is any subscriber interested in this topic. 65
And if there is, it doesn't know how many of them. 66
Secondly, there could be an infinite number of topics, but they are created 67
by the publisher when the message reaches the broker. 68
There is no specific action to create a topic. 69
Only the fact to send data to a broker will automatically create a topic if it didn't exist before. 70
However, if we want to organize the broker properly, then we usually have a fixed and predefined number 71
of topic that we can find in the broker documentation. 72
Because on the broker, if you don't know the topic on which you need to publish or the topic you need 73
to subscribe to, then it won't be useful. 74
Finally, we'll of course need a secure environment, so there will be an authentication procedure for 75
the subscriber and the publisher. 76
They will have specific access right to the broker and to specific topic only. 77
So now that we know what is the MQTT Protocol and how it basically works, let's make a demonstration. 78
Of course, we need three things : a broker and at least one publisher on one subscriber. 79
We're going to do that in the next video.