为什么固件批量处理任务没有显示？
需要检查设备是否正常上报原始版本号。
固件升级这里的静态升级跟动态升级有什么区别？
静态升级：指仅针对当前已经满足升级条件的设备进行升级操作。一旦升级开始，系统只会处理这些已满足条件的设备，对于后续新出现的满足升级条件的设备，不会自动纳入本次升级范围。
动态升级：不仅会对当前满足升级条件的设备进行升级，还会持续监控设备状态，对后续满足升级条件的设备也进行升级处理。
涵盖以下情况：
后续新激活的设备满足升级条件：若在动态升级开始后，有新设备被激活且其状态符合升级条件，系统会自动将该设备纳入升级范围并进行升级。
设备当前上报的固件版本号不满足升级条件，后续上报了满足升级条件的固件版本号：有些设备在动态升级开始时所上报的固件版本号不符合升级要求，但在后续运行过程中，设备上报了满足升级条件的固件版本号，此时系统也会对该设备进行升级操作。
一个设备是否支持定义多个固件进行应用升级？
一个设备支持多个固件进行应用升级，可通过在平台上为设备定义不同的模块来实现。
同一个设备是否支持多个 OTA 任务并行？
不支持。当前版本下，同一个设备 ID 在后台只能串行执行一个 OTA 任务。
相同设备 ID 在不同批次任务下的覆盖逻辑是怎样的？
若设备正在执行一个任务，此时被纳入一个新的任务，新任务会覆盖旧任务。旧任务将停止并标记为失败。
任务被覆盖后重试逻辑是怎样的？
被覆盖的旧任务显示失败，且不可重试，因为新任务已在运行。
如何取消一个 OTA 任务？取消后有什么影响？
可以手动取消任务。取消后，该任务下所有正在升级的设备状态会被置为 “取消”，平台将不再处理这些设备针对此任务的后续上报。
用户手动取消后自动重试逻辑是怎样的？
若任务创建时开启了 “失败自动重试”，用户手动取消后，该设备的自动重试逻辑也随之取消。后续若需重试，必须由用户手动确认。
当设置了“用户确认升级”后，应用端用户点击“同意升级”后，应该调用什么接口开始升级？
待确认自动重试逻辑是怎样的？
创建批量任务选择需要用户确认，失败自动重试时，后台自动重试不需要用户确认，但是如果手动取消设备升级任务后重试需要用户确认。
离线状态的设备 OTA 任务状态是否会超时？
不会超时。超时计时从设备成功接收到升级指令开始。离线设备尚未接收指令，故不会超时。
什么情况下 OTA 任务状态会显示为 “超时”？
从设备成功接收到升级指令起，若在设定的超时时间内未完成升级（上报成功或失败），则任务状态会变为 “超时”。
升级包较大，设备侧总是下载失败，支持断点续传吗？不使用腾讯云设备 SDK 如何做断点续传（设备端）？
设备 OTA 任务状态卡在下载中99%，设备也正确上报了 OTA 报文到平台，为什么不显示升级成功？
该问题通常由平台消息处理能力瓶颈导致。当大量设备在同一批次任务中同时进行 OTA 升级时，设备侧频繁上报的 OTA 状态消息（特别是在下载完成阶段）会导致 MQTT 消息并发量激增。如果此并发量超过了您所购买实例的设备消息 TPS（每秒消息数）上限，平台将无法及时处理所有消息，可能导致任务状态更新延迟或失败，从而使任务卡在 “下载中” 状态。
解决方案：
优化上报策略：在设备端集成腾讯云 IoT 设备端 SDK，SDK 已内置了优化的消息发送和重试机制。若自行封装协议，请务必控制 OTA 状态消息的上报频率，避免不必要的重复上报。
进行容量评估：在执行大规模 OTA 任务前，应结合非 OTA 业务的设备消息量，综合评估总消息量是否会超过实例的 TPS 上限。如有需要，可考虑提升实例规格以获得更高的 TPS 配额。
腾讯云 IoT 设备端 SDK 是否支持多个固件、应用并行下载升级？
IoT 设备端不支持多个固件、应用并行下载升级。
设备无法使用 https 下载固件，可以修改为 http 吗？
不支持。
常见下载升级包错误
签名错误
如果设备端获取的升级包的 URL 不全或者手动修改了 URL 内容，就会出现如下错误：
拒绝访问
设备端获取到升级包的 URL 后，进行下载升级包时，若报错提示拒绝访问，是由于升级包 URL 过期导致，URL 有效期为24小时。
如下图报错，Expires 为过期时间。
旧版本 OTA 常见问题
说明：
新版本 OTA 功能发布后，OTA 交互自动兼容旧的数据。客户的存量设备都无需修改固件，包括原来的云 API 也无需变动，无缝支持。
关于旧版本设备升级时下发协议的问题确认
在旧版本客户设备进行升级操作时，经验证，下发的是新版本协议。针对 “下发新版本协议对老的 OTA 设备是否会有影响” 这一问题，结论为：若设备侧能够正常解析 JSON 报文，则不会受到影响。
