0
1
00:00:00,840 --> 00:00:06,390
In the last video, we saw a first method to request messages received under the LoRaWAN server.
1

2
00:00:06,900 --> 00:00:09,900
This method is interesting because it's very simple.
2

3
00:00:10,200 --> 00:00:14,880
Whenever we need to get the uplink message, then we just ask for it.
3

4
00:00:16,230 --> 00:00:20,580
But if we analyze it closer, we can see a few drawbacks.
4

5
00:00:21,150 --> 00:00:24,960
The first drawback is that we only worked on the uplink stream.
5

6
00:00:25,410 --> 00:00:30,450
There is no possibility to send a downlink message to the LoRaWAN server with this kind of request.
6

7
00:00:30,780 --> 00:00:31,770
Why?
7

8
00:00:31,800 --> 00:00:38,400
Simply because no LoRaWAN server has implemented the possibility to ask to the user, the downlink message to
8

9
00:00:38,400 --> 00:00:39,660
send to the device.
9

10
00:00:39,840 --> 00:00:43,920
It doesn't really matter because we'll see other methods to do so.
10

11
00:00:44,280 --> 00:00:51,420
But we have to keep in mind that with HTTP GET request, we can only get the uplink message from the
11

12
00:00:51,420 --> 00:00:54,660
server, but we can't send downlink message to it.
12

13
00:00:55,290 --> 00:01:02,070
The second drawback is that for the uplink stream, we spend our time requesting data that potentially
13

14
00:01:02,070 --> 00:01:03,210
doesn't exist.
14

15
00:01:03,240 --> 00:01:07,260
We request data without knowing if it has been received.
15

16
00:01:07,920 --> 00:01:15,630
So, for example, if a sensor is sending, let's say a few times a day, then we'll have to make periodic
16

17
00:01:15,720 --> 00:01:19,530
requests with a high chance of receiving empty responses.
17

18
00:01:19,920 --> 00:01:24,930
That's definitely not efficient because it increases unnecessarily the network load.
18

19
00:01:25,290 --> 00:01:31,740
So if this HTTP GET request is so bad, then you could ask why does it exist?
19

20
00:01:31,920 --> 00:01:39,150
Actually, if for some reasons on our IoT platform, we've had a problem during a certain time, then
20

21
00:01:39,150 --> 00:01:44,580
we will be very happy to know that these data are still on the LoRaWAN server for a few hours and
21

22
00:01:44,580 --> 00:01:47,460
we can get them with the HTTP GET request.
22

23
00:01:48,780 --> 00:01:54,660
So what can we do to improve the data transmission between the LoRaWAN server and the IoT platform?
23

24
00:01:55,110 --> 00:01:59,430
From the IoT platform side, instead of asking for data.
24

25
00:01:59,640 --> 00:02:04,320
Then, it would be a much better idea to receive them whenever they are available.
25

26
00:02:04,890 --> 00:02:06,980
It's possible and very simple.
26

27
00:02:06,990 --> 00:02:10,430
We just need to reorganize the client and server rules.
27

28
00:02:10,440 --> 00:02:14,130
And now the client Pushes the message to the server.
28

29
00:02:14,520 --> 00:02:20,550
It's possible because the request is not a GET request anymore, but a POST request.
29

30
00:02:20,700 --> 00:02:23,550
That's what we're going to explain in the next video.