新在线不卡免费视频|www国产精品久久麻豆|美女午夜福利网站|《福克斯号上空姐们》|关于秘书的电影|美少女的哀羞txt|日产国产一区二区三区

AWS 平臺部署 OTA 升級任務

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

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

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

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

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

（2） 哪些終端設備需要升級；

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

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

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

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

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

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

當完成以上步驟時，在服務器端，就存在著一個升級任務關系鏈：

也就是說：一個 Job ID 就對應著一次 OTA 升級任務。終端設備在進行 OTA升級過程中，就是從這個 Job ID 開始的。

ESP32 OTA 升級的觸發

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

因此，當運營人員創建了一個 OTA 升級任務后，所有相關的終端設備，必須從某個預先確定好的主題（topic）中，接收到 OTA 升級通知指令。

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

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

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

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

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

AWS 平臺接收到這個請求后，就會把與這個 job＿id 相關聯的 OTA 升級任務描述文件（json文件），發送給終端設備。

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

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

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

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

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

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