AWS 平臺部署 OTA 升級任務(wù)

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

從上一篇文章中可以看到，當一個新的固件準備好之后，需要做 2 件事情：

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

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

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

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

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

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

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

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

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

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

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

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

ESP32 OTA 升級的觸發(fā)

ESP32 與 AWS 平臺之間，是通過 MQTT 協(xié)議進行通信的。

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

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

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

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

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

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

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

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

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

在實際的項目中，可能會遇到一些稍微復(fù)雜的情況。

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

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

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