0 1 00:00:00,930 --> 00:00:06,540 We take the same diagram we saw before, and we'll now focus on the downlink stream. 1 2 00:00:07,260 --> 00:00:14,310 The IoT platform will transmit an HTTP POST request to the LoRaWAN server, and in this request there 2 3 00:00:14,310 --> 00:00:16,890 will be the downlink message to send to the device. 3 4 00:00:17,010 --> 00:00:21,930 So we're going to install a client that is able to transmit these HTTP POST request. 4 5 00:00:22,230 --> 00:00:27,720 Once again, we'll simply use a terminal with a curl command because we saw earlier that Curl can send 5 6 00:00:27,720 --> 00:00:29,460 any HTTP request. 6 7 00:00:29,670 --> 00:00:34,080 After that, we need to install an HTTP server on the LoRaWAN server. 7 8 00:00:34,200 --> 00:00:38,790 It should be able to handle the HTTP POST request sent by the IoT platform. 8 9 00:00:39,780 --> 00:00:42,060 So we'll start by installing the server. 9 10 00:00:42,150 --> 00:00:46,560 It's going to be extremely easy because actually it's already done. 10 11 00:00:47,040 --> 00:00:52,440 In fact, when we set up the webhook for the uplink, then a server has also been enabled. 11 12 00:00:52,470 --> 00:00:55,260 This service is therefore ready and running. 12 13 00:00:55,440 --> 00:01:02,220 So, when we created the webhook, we enabled both an HTTP client and an HTTP server. 13 14 00:01:03,180 --> 00:01:09,120 So the only thing I need to do with this webhook is to handle the authentication, because what we 14 15 00:01:09,120 --> 00:01:12,330 did earlier for the uplink was extremely insecure. 15 16 00:01:12,750 --> 00:01:17,260 Indeed, when I configure the webhook to send data to my HTTP endpoint. 16 17 00:01:17,280 --> 00:01:19,890 There was no authentication at all. 17 18 00:01:20,100 --> 00:01:22,980 Actually, everyone could have sent data to this endpoint. 18 19 00:01:23,100 --> 00:01:24,390 It doesn't matter. 19 20 00:01:24,390 --> 00:01:27,870 It was just a demo and hopefully you wouldn't do that for a deployment. 20 21 00:01:28,380 --> 00:01:30,750 But of course for the other way around. 21 22 00:01:30,750 --> 00:01:32,580 TTN won't allow it. 22 23 00:01:32,610 --> 00:01:36,990 So in the API Key section, I need to generate a new key. 23 24 00:01:37,470 --> 00:01:43,410 If you watch the previous video, then you know that I've done it already for the HTTP GET request and 24 25 00:01:43,410 --> 00:01:45,780 if you've properly saved the key you can reuse it. 25 26 00:01:46,170 --> 00:01:49,530 Otherwise you just need to create a new one here. 26 27 00:01:50,880 --> 00:01:53,940 In my case, I'm going to use the one I had already. 27 28 00:01:55,740 --> 00:02:01,110 Now to send the right HTTP POST command, then I need to check the documentation. 28 29 00:02:01,590 --> 00:02:08,040 So we go back on the things stack website, and in the search bar we could look for HTTP POST request 29 30 00:02:08,040 --> 00:02:12,480 and do exactly the same journey we've had when we dealt with the HTTP GET request. 30 31 00:02:12,930 --> 00:02:18,960 At the end, we ended up in the storage integration section because that was the name of the integration 31 32 00:02:18,960 --> 00:02:19,680 we used. 32 33 00:02:20,040 --> 00:02:26,580 So let's save time and look for the webhook integration directly, because this time we're dealing with 33 34 00:02:26,580 --> 00:02:27,930 web integration. 34 35 00:02:28,770 --> 00:02:34,950 And in the Webhook tab, there is a schedule downlink section where everything is explained in 35 36 00:02:34,950 --> 00:02:35,550 detail. 36 37 00:02:36,390 --> 00:02:41,460 We've done the API Key creation already, so fine, we can carry on. 37 38 00:02:41,820 --> 00:02:46,050 And at the bottom there is a template of the curl command to complete. 38 39 00:02:46,440 --> 00:02:50,670 In this command we'll have to modify the API Key for the authentication. 39 40 00:02:51,120 --> 00:02:58,650 "app1" should be replaced by the application name, "wh1" replaced by the webhook name "dev1" replaced 40 41 00:02:58,650 --> 00:02:59,820 by the device name. 41 42 00:02:59,820 --> 00:03:05,210 And finally the server address should be replaced by TTN community server address. 42 43 00:03:05,220 --> 00:03:07,500 That's the one we're using in this demo. 43 44 00:03:08,300 --> 00:03:10,890 Okay, I copy this command and I will edit it. 44 45 00:03:12,530 --> 00:03:15,590 - I modify the API key I generated earlier. 45 46 00:03:17,850 --> 00:03:19,560 - I modify the message. 46 47 00:03:19,560 --> 00:03:24,030 In my case, I want to send 0 or 1 in my application. 47 48 00:03:24,030 --> 00:03:26,520 0 or 1 represent an LED status. 48 49 00:03:26,520 --> 00:03:29,100 But of course you can imagine whatever you want. 49 50 00:03:29,700 --> 00:03:33,540 The only thing is that it has to be written in 64 base format. 50 51 00:03:33,630 --> 00:03:36,330 For this demonstration, I give you the value: 51 52 00:03:36,330 --> 00:03:40,110 If you want to send 0 , it's "AA==". 52 53 00:03:40,200 --> 00:03:46,440 And if you want to switch on the LED, then you need to send 1 which is "AQ==". 53 54 00:03:46,830 --> 00:03:52,730 - I modify the Application port in my application it should be 15 to control the LED. 54 55 00:03:52,740 --> 00:03:56,010 But again, you can choose whatever you want for your other application. 55 56 00:03:56,610 --> 00:03:58,890 - The server is the things network, 56 57 00:04:01,760 --> 00:04:03,950 the application ID is training-usmb. 57 58 00:04:03,950 --> 00:04:07,940 The webhook ID is webhook-http, 58 59 00:04:08,240 --> 00:04:12,530 and finally, my device ID is deviceA-abp. 59 60 00:04:13,430 --> 00:04:16,580 I copy this command and I will send it from my terminal. 60 61 00:04:18,020 --> 00:04:23,780 I've got one window representing my device on the left and one window representing my IoT platform on 61 62 00:04:23,780 --> 00:04:24,530 the right. 62 63 00:04:24,680 --> 00:04:27,500 This is where I'm going to send my curl command. 63 64 00:04:28,160 --> 00:04:34,370 Once this command will be sent, then I will go and check what's going on on my network server as well. 64 65 00:04:34,520 --> 00:04:42,830 So the data transmission path is: 1. The IoT platform where it starts, 2. The application server, 65 66 00:04:42,830 --> 00:04:43,550 3. The network server. 66 67 00:04:43,640 --> 00:04:44,660 4. My gateway, and 67 68 00:04:44,690 --> 00:04:50,270 finally, my enddevice, here. I send the curl command. 68 69 00:04:50,540 --> 00:04:53,210 Now the downlink is scheduled, 69 70 00:04:53,360 --> 00:05:00,020 so when my enddevice will send a new uplink frame to the server, then this message will be sent. 70 71 00:05:00,590 --> 00:05:03,650 So I press the button to send an uplink frame. 71 72 00:05:06,130 --> 00:05:07,240 And there we go. 72 73 00:05:07,510 --> 00:05:10,750 We have received our command on the device. 73 74 00:05:10,870 --> 00:05:14,920 In my case, when the command is properly received, an LED turns OFF. 74 75 00:05:14,920 --> 00:05:18,730 But obviously you can take any action depending on your application.