0
1
00:00:00,540 --> 00:00:05,930
We'll start with a completely different architecture.  During this first video about MQTT, 
1

2
00:00:06,150 --> 00:00:11,910
we're going to move away from the LoRaWAN architecture in order to concentrate on the protocol itself.
2

3
00:00:12,240 --> 00:00:17,910
This MQTT protocol is widely used in IoT, but it has nothing to do with LoRaWAN.
3

4
00:00:18,300 --> 00:00:23,010
So everything we're going to learn here could be applied to other applications.
4

5
00:00:23,880 --> 00:00:29,700
Once we'll have a good understanding of MQTT, then we'll use it for the dialogue between the LoRaWAN server
5

6
00:00:29,730 --> 00:00:32,130
and the IoT platform.
6

7
00:00:32,640 --> 00:00:36,360
The central point of this protocol is an entity called Broker.
7

8
00:00:37,050 --> 00:00:39,120
It centralizes all data.
8

9
00:00:39,600 --> 00:00:44,820
That means that if we want to send something, we need to send it to the broker first.
9

10
00:00:45,150 --> 00:00:49,680
And if we want to receive something, then the broker will provide it.
10

11
00:00:50,670 --> 00:00:52,680
But who sends the data?
11

12
00:00:53,340 --> 00:00:57,390
In IoT, it's mainly sensors that provide the information.
12

13
00:00:57,390 --> 00:01:00,000
So they're the ones that want to send data.
13

14
00:01:00,390 --> 00:01:06,360
If, for example, we have a temperature sensor and a humidity sensor, then they simply provide the
14

15
00:01:06,360 --> 00:01:07,530
data to the broker.
15

16
00:01:08,190 --> 00:01:13,050
To keep things tidy, they will push the data to the broker within a specific topic.
16

17
00:01:13,380 --> 00:01:18,510
It's a simple name that can be chosen accordingly to classify the data on the broker.
17

18
00:01:19,140 --> 00:01:26,340
In our example, the humidity sensor and temperature sensor could simply use the topic humidity and
18

19
00:01:26,340 --> 00:01:27,120
temperature.
19

20
00:01:27,600 --> 00:01:34,140
Anyone who sends data to the broker in a topic is called a publisher, and we say that the sensor publishes
20

21
00:01:34,140 --> 00:01:37,410
data. And now who receives the data?
21

22
00:01:37,920 --> 00:01:39,900
It could be anyone that needs it.
22

23
00:01:39,930 --> 00:01:46,380
In reality, they are mainly actuators that retrieve the information to process it and act accordingly.
23

24
00:01:47,010 --> 00:01:51,330
The action carried out can be as simple as displaying the value to the user.
24

25
00:01:51,810 --> 00:01:58,190
In our example, if the actuator is a heating system, then it would surely be interested in the temperature.
25

26
00:01:58,200 --> 00:02:03,730
But to be more efficient, the actuator must not ask for the temperature information.
26

27
00:02:03,750 --> 00:02:07,770
It should receive them right away as soon as they are available on the broker.
27

28
00:02:08,100 --> 00:02:12,030
For that it must subscribe to a specific topic on the broker.
28

29
00:02:12,120 --> 00:02:15,450
In our case, it will subscribe to the temperature topic.
29

30
00:02:15,720 --> 00:02:21,300
If we now take the example of a drying system, then it will probably be interested in both the temperature
30

31
00:02:21,300 --> 00:02:22,560
and the humidity.
31

32
00:02:22,830 --> 00:02:26,100
Therefore, it needs to subscribe to both topics.
32

33
00:02:26,880 --> 00:02:31,290
Speaking about topics, I would like to give you a little bit more information about them.
33

34
00:02:31,530 --> 00:02:35,280
We'll take another simple example of a smart building application.
34

35
00:02:35,700 --> 00:02:43,920
In this house, there are two rooms in which there are three sensors : temperature, humidity and noise.
35

36
00:02:44,460 --> 00:02:46,990
To refer to a specific sensors in the house,
36

37
00:02:47,020 --> 00:02:50,850
we represent the topic with a string representing its hierarchy.
37

38
00:02:51,150 --> 00:02:59,310
So if I'm interested in the temperature of a bedroom in the house, the topic will be : 
38

39
00:02:59,310 --> 00:03:00,600
house/room/temp.
39

40
00:03:01,230 --> 00:03:07,440
And if I'm now interested in the temperature of the living room, then the topic will be :
40

41
00:03:07,440 --> 00:03:08,970
house/living-room/temp.
41

42
00:03:09,570 --> 00:03:14,460
And if we use special characters, we can refer to several topics at the same time.
42

43
00:03:14,850 --> 00:03:21,090
For example, if I'm now interested in all sensors representing the temperature, the humidity and the
43

44
00:03:21,090 --> 00:03:25,050
noise in the whole house, then we use the # character.
44

45
00:03:25,230 --> 00:03:33,510
So the topic will be house/#, or simply #. Hash can only be at the end of the topic, 
45

46
00:03:33,510 --> 00:03:35,820
and it's a multi level wild card.
46

47
00:03:35,940 --> 00:03:40,350
Everything under the level where the hash is is targeted by this wild card.
47

48
00:03:40,860 --> 00:03:45,690
And finally, it's also possible to designate a specific sensor in the house.
48

49
00:03:46,080 --> 00:03:50,760
For this example, let's say we're looking for the temperature of all rooms in this house.
49

50
00:03:50,880 --> 00:03:57,780
So we need both the temperature of the bedroom and the temperature of the living room, but only temperatures.
50

51
00:03:57,990 --> 00:04:03,000
In that case, I need a wild card for the room name because I don't want to choose a specific one at
51

52
00:04:03,000 --> 00:04:04,470
the room topic level.
52

53
00:04:04,680 --> 00:04:07,860
The signal level wild card is the + characters.
53

54
00:04:08,250 --> 00:04:11,970
The topic will be house/+/temperature.
54

55
00:04:12,540 --> 00:04:17,090
So we can see that we have a lot of flexibility in the designation of the topic.
55

56
00:04:17,100 --> 00:04:23,070
And thanks to the two wild card characters, publishers and subscribers will be able to select exactly
56

57
00:04:23,070 --> 00:04:24,480
the data they want to target.
57

58
00:04:25,650 --> 00:04:26,300
Great.
58

59
00:04:26,310 --> 00:04:29,320
So MQTT might be a new concept for us.
59

60
00:04:29,340 --> 00:04:32,400
There are still a few characteristics that I want to explain.
60

61
00:04:32,550 --> 00:04:35,940
First, publishers and subscribers don't know each other.
61

62
00:04:35,970 --> 00:04:39,910
There is never any direct dialogue between subscribers and publishers.
62

63
00:04:39,930 --> 00:04:41,790
They always deal with the broker.
63

64
00:04:42,600 --> 00:04:46,380
They just have a common point of interest, which is their topics.
64

65
00:04:46,830 --> 00:04:51,450
So a publisher doesn't know if there is any subscriber interested in this topic.
65

66
00:04:51,600 --> 00:04:55,020
And if there is, it doesn't know how many of them.
66

67
00:04:55,590 --> 00:04:59,670
Secondly, there could be an infinite number of topics, but they are created 
67

68
00:04:59,980 --> 00:05:02,530
by the publisher when the message reaches the broker.
68

69
00:05:02,980 --> 00:05:05,580
There is no specific action to create a topic.
69

70
00:05:05,590 --> 00:05:11,890
Only the fact to send data to a broker will automatically create a topic if it didn't exist before.
70

71
00:05:12,640 --> 00:05:19,000
However, if we want to organize the broker properly, then we usually have a fixed and predefined number
71

72
00:05:19,000 --> 00:05:21,880
of topic that we can find in the broker documentation.
72

73
00:05:22,180 --> 00:05:27,040
Because on the broker, if you don't know the topic on which you need to publish or the topic you need
73

74
00:05:27,040 --> 00:05:29,770
to subscribe to, then it won't be useful.
74

75
00:05:30,490 --> 00:05:35,960
Finally, we'll of course need a secure environment, so there will be an authentication procedure for
75

76
00:05:35,960 --> 00:05:37,840
the subscriber and the publisher.
76

77
00:05:38,290 --> 00:05:43,060
They will have specific access right to the broker and to specific topic only.
77

78
00:05:44,260 --> 00:05:50,110
So now that we know what is the MQTT Protocol and how it basically works, let's make a demonstration.
78

79
00:05:50,230 --> 00:05:56,500
Of course, we need three things : a broker and at least one publisher on one subscriber.
79

80
00:05:56,860 --> 00:05:58,630
We're going to do that in the next video.