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 升级的最基本的过程。

在实际的项目中，可能会遇到一些稍微复杂的情况。

例如：一个终端设备一直处于断电状态。此时，云平台中已经对固件进行了好几次的升级，但是由于这台设备一直没有运行，因此它的固件已经过时了好几个版本。

有一天，这台设备上电运行了，此时它会从云平台接收到好几个升级任务，这个时候应该如何处理呢？

也许，我们就要对升级通知的指令中，赋予更多详细的内容，让这台设备有足够的信息来判断该如何进行升级。