Azure IoT Hub OTA流程自定义方案及相关技术问题咨询

问题1：现有Azure IoT Hub设备更新实现是否支持上述自定义流程？ #

支持。Azure IoT Hub 设备更新（DU）本身开放设备端处理逻辑的自定义权限，你完全可以在自研的设备OTA代理代码中插入人工确认逻辑：当收到服务端下发的Download/Install/Apply动作指令后，先不执行对应操作，将当前状态按DU规范上报为等待确认状态，待接收到人工审批信号后再执行对应动作，动作完成后再上报成功/失败状态即可，服务端不会干涉设备端内部的处理流程，只要最终状态上报符合DU的格式要求即可正常流转。

问题2：若设备未对IoT Hub服务的动作请求做出响应，会产生什么后果？是否会直接终止整个OTA流程？ #

不会直接终止整个OTA流程。如果设备在超时时间内未上报任何状态，服务端会将该设备的更新任务标记为「进行中-超时」子状态，只有出现以下三种情况才会终止流程：设备主动上报失败状态、管理员手动取消更新任务、超出服务端配置的最大超时时间。

问题3：IoT Hub服务下发动作请求后，默认的响应等待时长是多少？我的预期是将等待时长设为30天，若30天内未收到确认指令，设备主动向IoT Hub服务返回失败/终止响应。 #

服务端默认的动作响应等待时长为24小时。你需要的30天等待逻辑可以完全在设备端实现，不需要依赖服务端配置：设备端收到动作指令后启动本地30天定时器，定时器触发前收到人工确认就执行对应操作，超时后直接向服务端上报失败状态、携带自定义超时错误码即可满足需求。

问题4：是否可以将IoT Hub服务API的响应等待时长设置为30天？ #

目前服务端侧最大可配置的超时时间为7天，不支持直接设置为30天。你可以结合设备端逻辑实现等效效果：将服务端最大超时时间设为7天的上限，设备端每间隔小于7天的周期主动上报一次等待确认的心跳状态，即可保证服务端不会将任务判定为超时，直到设备端本地30天定时器触发后再上报失败状态即可。 #

内容的提问来源于stack exchange，提问作者Gaurav Choubey