0
1
00:00:00,530 --> 00:00:06,800
First, if you want to know more about the MQTT protocol, I advise you to go back to the previous chapter
1

2
00:00:06,800 --> 00:00:10,490
where we explain everything about the protocol itself.
2

3
00:00:10,940 --> 00:00:16,190
I'm going to use exactly the same diagram for this explanation about the liquidity integration with
3

4
00:00:16,430 --> 00:00:19,880
ChirpStack, because it works exactly in the same way.
4

5
00:00:20,060 --> 00:00:25,220
So, if you were comfortable with the previous demonstration, this one should be easy.
5

6
00:00:25,760 --> 00:00:32,900
What we want to do is to connect two clients, one subscriber for the uplink stream and one publisher
6

7
00:00:32,900 --> 00:00:34,160
for the downlink stream.
7

8
00:00:34,520 --> 00:00:39,080
And these two clients will be connected to the embedded broker in ChirpStack.
8

9
00:00:39,410 --> 00:00:44,810
This broker is already available and enabled because this service was part of the ChirpStack installation
9

10
00:00:44,810 --> 00:00:45,620
process.
10

11
00:00:46,040 --> 00:00:51,680
Now let's recap what we need to configure for the connection of the subscriber and the publisher.
11

12
00:00:52,310 --> 00:00:58,100
First, we need to know the broker address on ChirpStack to reach the broker.
12

13
00:00:58,130 --> 00:01:03,690
We need to use the IP address of the LoRaWAN server colon 1883.
13

14
00:01:03,960 --> 00:01:11,130
In our case it will be chirpstack.univ-lorawan.fr:1883
14

15
00:01:11,490 --> 00:01:12,240
Fine.
15

16
00:01:12,270 --> 00:01:16,380
Secondly, we said that we will need credentials to connect to this broker.
16

17
00:01:16,620 --> 00:01:21,900
However, the default ChirpStack installation remove these needs of credentials.
17

18
00:01:21,930 --> 00:01:24,360
This is absolutely not secure.
18

19
00:01:24,360 --> 00:01:29,790
So of course, except for this demonstration, we will never leave it like this.
19

20
00:01:30,030 --> 00:01:36,330
If we want to apply some credentials, then before the installation we need to configure the MQTT broker
20

21
00:01:36,330 --> 00:01:37,710
called Mosquitto.
21

22
00:01:37,950 --> 00:01:43,700
We can do this configuration thanks to the configuration folder from the ChirpStack installation files.
22

23
00:01:43,710 --> 00:01:47,940
In this folder we will find a folder for each service.
23

24
00:01:48,060 --> 00:01:54,570
In the folder called Mosquitto, which is the name of the broker used in ChirpStack, there is a configuration
24

25
00:01:54,570 --> 00:01:55,160
file.
25

26
00:01:55,170 --> 00:02:01,890
This file is called mosquitto.conf, and that's in this file that we will need to set the credentials.
26

27
00:02:02,040 --> 00:02:05,610
We just have to follow the steps explained in the documentation.
27

28
00:02:07,050 --> 00:02:08,910
Third, we need a topic.
28

29
00:02:08,910 --> 00:02:14,730
And again, we'll make it easy for the subscriber because we're going to use the #.
29

30
00:02:15,090 --> 00:02:16,830
What happens if I do that?
30

31
00:02:17,130 --> 00:02:21,600
I will receive all events from all sensors of all applications.
31

32
00:02:21,840 --> 00:02:28,620
Of course, if we want the data from a specific device of a specific application, then we need the
32

33
00:02:28,620 --> 00:02:29,820
exact topic.
33

34
00:02:29,850 --> 00:02:33,800
And again, we'll find this information in the documentation.
34

35
00:02:33,810 --> 00:02:35,520
So, let's have a look.
35

36
00:02:36,870 --> 00:02:39,240
We go on the ChirpStack website?
36

37
00:02:40,180 --> 00:02:44,080
Then in the ChirpStack section, we go on Integrations.
37

38
00:02:45,050 --> 00:02:46,460
Then MQTT.
38

39
00:02:48,520 --> 00:02:51,340
Here we have the default event topic.
39

40
00:02:51,370 --> 00:02:56,410
That is the generic topic we need to subscribe if we want information on an event.
40

41
00:02:56,710 --> 00:02:59,260
Application/APPLICATION_ID.
41

42
00:02:59,560 --> 00:03:02,050
device/DEV_EUI.
42

43
00:03:02,170 --> 00:03:02,920
event/
43

44
00:03:03,100 --> 00:03:04,030
EVENT
44

45
00:03:04,300 --> 00:03:08,710
APPLICATION_ID needs to be replaced by our application identifier.
45

46
00:03:08,740 --> 00:03:16,090
DEV_EUI needs to be replaced by the device EUI in lower case and EVENT needs to be replaced by the type
46

47
00:03:16,090 --> 00:03:17,800
of event we are interested in.
47

48
00:03:18,400 --> 00:03:21,990
Let's see what we can have: all these ones.
48

49
00:03:22,000 --> 00:03:26,350
But of course the most important will probably be the up event.
49

50
00:03:26,890 --> 00:03:34,360
Anyway, if you want all of them then we just need to use the wildcard + instead of the keyword EVENT.
50

51
00:03:35,320 --> 00:03:35,920
Okay.
51

52
00:03:35,920 --> 00:03:37,540
And now for the publisher,
52

53
00:03:37,540 --> 00:03:43,570
so to send downlink messages, the information we need is just at the bottom of that page.
53

54
00:03:43,750 --> 00:03:45,910
The topic is this one.
54

55
00:03:45,940 --> 00:03:51,410
Again, we need to replace the APPLICATION_ID and DEV_EUI with the right values.
55

56
00:03:52,370 --> 00:03:53,960
Okay, we're almost done.
56

57
00:03:53,990 --> 00:03:56,870
We need one last information for the publisher.
57

58
00:03:56,900 --> 00:03:59,630
That's the format of the downlink message.
58

59
00:03:59,750 --> 00:04:03,710
The payload of the message has to respect a specific JSON format.
59

60
00:04:03,740 --> 00:04:06,410
It's represented here in the documentation.
60

61
00:04:06,440 --> 00:04:14,780
Basically, we will specify once again the devEui, whether it's a confirmed or unconfirmed value and obviously
61

62
00:04:14,780 --> 00:04:16,430
the data we want to send.
62

63
00:04:16,790 --> 00:04:17,570
Great.
63

64
00:04:17,600 --> 00:04:20,390
We are now ready. For this demonstration
64

65
00:04:20,390 --> 00:04:27,410
my device is going to send a temperature each time I press the user button. On the left, I've got my
65

66
00:04:27,410 --> 00:04:34,400
end-device logs and on the right I've got my application and I can check that everything works well.
66

67
00:04:34,820 --> 00:04:38,570
Now I want to connect my subscriber and publisher.
67

68
00:04:39,230 --> 00:04:44,990
Let's start with Node-red and after I will show you the same demonstration with MQTT Explorer.
68

69
00:04:45,140 --> 00:04:50,060
We will need all the information gathered previously so I saved everything here.
69

70
00:04:50,540 --> 00:04:52,940
First, let's start with the uplink.
70

71
00:04:54,350 --> 00:04:57,230
I come back on my node-red user interface.
71

72
00:04:57,410 --> 00:05:01,370
I will keep the previous demonstration so I open a new tab.
72

73
00:05:01,610 --> 00:05:07,670
But the flow I'm going to use is very similar, so I copy all nodes of the demonstration we made already
73

74
00:05:07,670 --> 00:05:10,070
and I paste them on my new flow.
74

75
00:05:13,910 --> 00:05:15,590
I change the name of the tab.
75

76
00:05:15,620 --> 00:05:22,460
This demonstration is about an MQTT connection with ChirpStack, so the name will be MQTT ChirpStack.
76

77
00:05:23,180 --> 00:05:25,220
The broker is now ChirpStack.
77

78
00:05:25,250 --> 00:05:28,580
Again, this is just a comment, so don't worry about that.
78

79
00:05:28,580 --> 00:05:33,110
But I think it's clearer if we keep in mind that there is a ChirpStack broker here.
79

80
00:05:34,460 --> 00:05:38,150
Okay, so now let's configure the Subscriber.
80

81
00:05:38,750 --> 00:05:44,120
So let's click on the subscriber node and I'm going to add a new broker.
81

82
00:05:44,510 --> 00:05:46,130
I fill in the server name.
82

83
00:05:46,130 --> 00:05:52,040
So chirpstack.univ-lorawan.fr on port 1883.
83

84
00:05:54,250 --> 00:05:57,010
This time in the security tab.
84

85
00:05:57,040 --> 00:06:02,470
There is nothing to enter because, as we said, ChirpStack doesn't use credentials for its default
85

86
00:06:02,470 --> 00:06:03,490
configuration.
86

87
00:06:03,850 --> 00:06:08,170
So I just add the broker to the list available when the configuration is done.
87

88
00:06:08,290 --> 00:06:11,890
Now I've got the new ChirpStack broker available in the list.
88

89
00:06:12,130 --> 00:06:12,850
Great.
89

90
00:06:12,850 --> 00:06:14,530
So, now the topic.
90

91
00:06:14,530 --> 00:06:19,150
I said I would use the #, but if you want you can specify one.
91

92
00:06:19,840 --> 00:06:21,130
And there we go.
92

93
00:06:21,160 --> 00:06:23,170
We are done with the Subscriber.
93

94
00:06:23,290 --> 00:06:26,200
So we can retry that part and it should work.
94

95
00:06:26,320 --> 00:06:28,270
I click on deploy.
95

96
00:06:28,390 --> 00:06:29,560
For this test.
96

97
00:06:29,560 --> 00:06:35,020
I'm only interested on the subscriber part, so don't look at the publisher because this is just the
97

98
00:06:35,020 --> 00:06:37,360
one I copied from our previous demonstration.
98

99
00:06:37,660 --> 00:06:44,140
And if I hit the push button of my end device, then I receive the message on my application.
99

100
00:06:44,290 --> 00:06:51,160
This message has traveled all the way from my device, my gateway, the Network Server, the Application
100

101
00:06:51,160 --> 00:06:55,730
Server, the ChirpStack broker, and finally has been pushed on my Subscriber here.
101

102
00:06:56,540 --> 00:07:01,100
If we want the exact topic of our device, then we can find it here in the debug.
102

103
00:07:01,580 --> 00:07:07,040
We just need to copy that and change the topic of our subscriber with this one if we wish.
103

104
00:07:09,410 --> 00:07:10,070
Okay.
104

105
00:07:10,070 --> 00:07:14,570
So the right part of this flow is working for the uplink traffic.
105

106
00:07:14,780 --> 00:07:20,210
Now on the left, I'm going to take care of the Publisher part for the downlink traffic.
106

107
00:07:20,570 --> 00:07:25,820
So I click on the Publisher here, I choose the ChirpStack broket I've just added.
107

108
00:07:25,820 --> 00:07:30,290
And for the topic I just paste, the topic I took from the documentation.
108

109
00:07:30,800 --> 00:07:31,610
All right.
109

110
00:07:31,640 --> 00:07:33,950
We are done with the Publisher configuration.
110

111
00:07:35,070 --> 00:07:40,200
Now I need to select the content of the JSON object to send the downlink message.
111

112
00:07:40,770 --> 00:07:46,590
This is what I picked up from the documentation, so I just opened the JSON editor here.
112

113
00:07:46,740 --> 00:07:52,440
I erase the content because this is the one used for the other Network Server and I paste it here.
113

114
00:07:52,860 --> 00:07:59,280
In this example, I'm just going to send the command 1, which is this payload in base 64.
114

115
00:07:59,400 --> 00:08:04,770
On the application port 15 that will turn on the LED on  my end-device.
115

116
00:08:05,070 --> 00:08:05,790
Great.
116

117
00:08:05,790 --> 00:08:08,310
So let's deploy and test this application.
117

118
00:08:10,140 --> 00:08:13,230
Both Publisher and Subscriber are now connected.
118

119
00:08:13,410 --> 00:08:17,250
If there were any problems, I would have them reported here.
119

120
00:08:17,550 --> 00:08:20,940
So now everything seems fine. For the moment,
120

121
00:08:20,970 --> 00:08:22,050
nothing happened.
121

122
00:08:22,320 --> 00:08:29,550
And then I press the button to publish the downlink message on the broker. On my debug window,
122

123
00:08:29,580 --> 00:08:34,650
I've got a message from the LoRaWAN server telling me that the message has been queued.
123

124
00:08:34,890 --> 00:08:41,340
It has not been sent yet because I remind you that this device is a class A end-device, so I need to
124

125
00:08:41,340 --> 00:08:43,800
send a message before sending a downlink.
125

126
00:08:43,980 --> 00:08:49,440
And for that I need to press my end-device push button. On my application,
126

127
00:08:49,440 --> 00:08:54,660
I received two messages, one telling me that an uplink data has been received.
127

128
00:08:56,460 --> 00:09:01,020
And another message telling me that my downlink message has been transmitted.
128

129
00:09:01,290 --> 00:09:03,330
So, let's go on the device.
129

130
00:09:04,980 --> 00:09:08,430
And yes, indeed, I've received 01 and
130

131
00:09:08,430 --> 00:09:10,500
I can check that the LED is turned on.
131

132
00:09:11,520 --> 00:09:17,640
If I now want to turn it off, then I just need to modify the downlink frame payload in the other injection
132

133
00:09:17,640 --> 00:09:18,200
node.
133

134
00:09:18,210 --> 00:09:24,690
This time, I want to send the payload "AA==" which is zero coding in base 64.
134

135
00:09:29,980 --> 00:09:33,310
Once we send this, the LED will turn off.
135

136
00:09:37,370 --> 00:09:37,880
Great.
136

137
00:09:37,880 --> 00:09:41,930
So, now we can try to do the same demonstration with MQTT Explorer.
137

138
00:09:42,080 --> 00:09:49,100
Now that we know the broker address and the payload to send, it would be quicker. On MQTT Explorer,
138

139
00:09:49,130 --> 00:09:51,200
I create a new connection.
139

140
00:09:51,380 --> 00:09:53,000
I call it chirpstack.
140

141
00:09:54,010 --> 00:09:59,860
And I enter the broker address, again with no credential. For the topic,
141

142
00:09:59,890 --> 00:10:04,480
I leave it like this because if you remember, the default topic is #.
142

143
00:10:04,480 --> 00:10:10,930
So, that means that if I don't change this configuration, I will receive all messages from all topics.
143

144
00:10:11,800 --> 00:10:16,220
I connect my client to the broker and I can send an uplink message from my end-device.
144

145
00:10:16,240 --> 00:10:19,240
For that, I just need to press the push button.
145

146
00:10:19,780 --> 00:10:20,890
There we go.
146

147
00:10:21,840 --> 00:10:22,950
The content is here.
147

148
00:10:25,530 --> 00:10:28,320
And I can see the frame payload in base 64.
148

149
00:10:29,670 --> 00:10:31,290
That was the uplink traffic.
149

150
00:10:31,290 --> 00:10:34,350
So now, how do we send a downlink message?
150

151
00:10:34,740 --> 00:10:36,930
We go on the Publisher part.
151

152
00:10:36,960 --> 00:10:44,810
We assign the right topic, which is this one, and I enter the JSON object message with the right devEUI,
152

153
00:10:44,850 --> 00:10:47,700
the right port and the payload.
153

154
00:10:48,300 --> 00:10:53,760
As soon as I publish it, a new message is received from the broker telling us that the message is queued.
154

155
00:10:55,040 --> 00:11:02,120
And when I press the push button, I receive two messages one telling me that a new uplink has been
155

156
00:11:02,120 --> 00:11:07,580
received and another message telling me that my downlink message has been transmitted.
156

157
00:11:07,820 --> 00:11:14,240
And obviously, on the device I've received the command and the LED is now on.
157

158
00:11:14,840 --> 00:11:15,660
Great.
158

159
00:11:15,680 --> 00:11:20,630
The integration with ChirpStack is now over as we've covered both HTTP and MQTT.
159

160
00:11:20,870 --> 00:11:24,290
Please tell us if you've managed to do it on your own server.
