AWS 平臺(tái)部署 OTA 升級(jí)任務(wù)

AWS 平臺(tái)按照不同的業(yè)務(wù)類型，劃分為不同的服務(wù)。這樣處理起來，流程更規(guī)范，操作步驟也更多，當(dāng)然也更賺錢一些！

從上一篇文章中可以看到，當(dāng)一個(gè)新的固件準(zhǔn)備好之后，需要做 2 件事情：

把固件（bin 文件）和一個(gè)固件描述文件（json格式的文本文件），上傳到 S3 云存儲(chǔ)服務(wù)器上；

在 AWS Core 任務(wù)管理中，新建一個(gè)升級(jí)任務(wù)（會(huì)得到一個(gè) Job ID）。在這個(gè)任務(wù)中需要選擇：

（1） 步驟1中上傳的 json 文件；

（2） 哪些終端設(shè)備需要升級(jí)；

json 格式的固件描述文檔，格式大概如下（可以根據(jù)實(shí)際的業(yè)務(wù)需求進(jìn)行修改）：

｛
 ＂product＂： ＂產(chǎn)品名稱＂，
 ＂group＂： ＂設(shè)備分組＂，
 ＂firmware＂：
 ［
    ｛
       ＂ota＿type＂： ＂esp32＂，
       ＂url＂： ＂http：／／xxx／esp32－v1．1．0．bin＂，
       ＂md5＂： ＂xxx＂
    ｝
 ］
｝

不知道您是否注意到：在 firmware 字段中，使用的是數(shù)組（［．．．］），而不是對(duì)象（｛．．．｝）？

這樣來組織的原因是，OTA 升級(jí)不僅僅可以對(duì) ESP32 模組中的固件進(jìn)行升級(jí)（＂ota＿type＂： ＂esp32＂），還可以對(duì)其他的一些固件或用戶數(shù)據(jù)進(jìn)行更新。

比如：更新 ESP32 串口連接的 MCU 中的固件程序。

對(duì)了，一個(gè)終端在通過網(wǎng)絡(luò)連接到云平臺(tái)時(shí)，都有一個(gè)唯一的 ID 編號(hào)，一般都是利用 ESP32 模組上的網(wǎng)卡 MAC 地址來作為唯一 ID。

當(dāng)完成以上步驟時(shí)，在服務(wù)器端，就存在著一個(gè)升級(jí)任務(wù)關(guān)系鏈：

也就是說：一個(gè) Job ID 就對(duì)應(yīng)著一次 OTA 升級(jí)任務(wù)。終端設(shè)備在進(jìn)行 OTA升級(jí)過程中，就是從這個(gè) Job ID 開始的。

ESP32 OTA 升級(jí)的觸發(fā)

ESP32 與 AWS 平臺(tái)之間，是通過 MQTT 協(xié)議進(jìn)行通信的。

因此，當(dāng)運(yùn)營人員創(chuàng)建了一個(gè) OTA 升級(jí)任務(wù)后，所有相關(guān)的終端設(shè)備，必須從某個(gè)預(yù)先確定好的主題（topic）中，接收到 OTA 升級(jí)通知指令。

例如一個(gè)可能的 topic：＄aws／things／xxx／job／notify

其中的 xxx，代表終端設(shè)備的 MAC 地址，只有這樣，每一個(gè)設(shè)備才能夠接收到屬于自己的命令。

升級(jí)通知指令的內(nèi)容中，一定會(huì)包含 OTA 升級(jí)的 Job ID，例如：

｛
 ＂timestamp＂： ＂xxxxxx＂，
 ＂job＿id＂： ＂001＂
｝

當(dāng)終端設(shè)備接收到這個(gè)升級(jí)通知指令時(shí)，提取出 job＿id 字段，然后向云平臺(tái)發(fā)起請(qǐng)求：獲取與這個(gè) job＿id 關(guān)聯(lián)的固件描述信息，也就是之前上傳的 Json 格式的文件息。

AWS 平臺(tái)接收到這個(gè)請(qǐng)求后，就會(huì)把與這個(gè) job＿id 相關(guān)聯(lián)的 OTA 升級(jí)任務(wù)描述文件（json文件），發(fā)送給終端設(shè)備。

設(shè)備拿到了固件描述文件，自然也就知道了固件的：版本，下載地址，MD5 值等信息，于是就進(jìn)入后面的下載環(huán)節(jié)了。

以上的過程描述，基本上是一個(gè)終端設(shè)備觸發(fā) OTA 升級(jí)的最基本的過程。

在實(shí)際的項(xiàng)目中，可能會(huì)遇到一些稍微復(fù)雜的情況。

例如：一個(gè)終端設(shè)備一直處于斷電狀態(tài)。此時(shí)，云平臺(tái)中已經(jīng)對(duì)固件進(jìn)行了好幾次的升級(jí)，但是由于這臺(tái)設(shè)備一直沒有運(yùn)行，因此它的固件已經(jīng)過時(shí)了好幾個(gè)版本。

有一天，這臺(tái)設(shè)備上電運(yùn)行了，此時(shí)它會(huì)從云平臺(tái)接收到好幾個(gè)升級(jí)任務(wù)，這個(gè)時(shí)候應(yīng)該如何處理呢？

也許，我們就要對(duì)升級(jí)通知的指令中，賦予更多詳細(xì)的內(nèi)容，讓這臺(tái)設(shè)備有足夠的信息來判斷該如何進(jìn)行升級(jí)。