确保IoT设备已成功更新的最佳实践是什么？
为了测试OTA更新和验证设备，您需要做什么？更进一步，您如何监视/管理一组IoT设备的软件版本（更新）？
#1 楼
我有每24小时调用一次的软件（Windows Server-与“事物”稍有不同，但原理相同），它会发送有关自身的各种元数据：客户名称（或唯一ID）
软件版本
呼叫/请求的时间戳
产品类型/ id
Web服务将解析数据并插入（或更新（如果更新）客户有一个现有行）在数据库中一行。
通过这种方式，新客户自动添加到数据库中，现有客户的“最后见”时间戳得到更新，我们始终拥有最新的软件版本。
我可以运行数据库查询，告诉我哪些客户使用的是较旧版本，和/或哪些客户已有一段时间没有致电了。
我们还实现了自动更新（请考虑OTA）更新），因为这是一个关键过程，我们为此执行了特定的遥测-记录：
当前版本。
要更新的版本。
/授权时（如果需要接受客户接受）。
每个主要步骤的时间戳和状态代码。
这使我们能够确定自动更新的某些方面是否失败，并且在许多情况下，我们经常在发现任何错误之前就打电话给客户。
“事物”的最大区别是您通常受内存限制，因此要对
xxx Kb的固件进行OTA更新，则需要xxx Kb * 2可用内存的数量（现有固件+足够的内存，可以在开始实际固件更新之前存储新固件）评论
感谢分享。内存使用情况很重要。如果适用，您如何进行授权和客户接受？您需要密码来接受更新吗？
– Noam Hacker
16 Dec 6'在20:02
这是一个不同的用例（因为它是Windows Server），但是当下载了OTA更新时，我们有一个UI弹出警报-警报询问客户是否要更新（并包括发行说明的链接等）。在某件事上，我可能会闪烁一个LED或某事来警告用户（假设您希望用户“允许”更新），然后让他们“长按”一个按钮来启动它...
– KennetRunner
16年6月6日在20:11
#2 楼
例如，您可以每隔X周/天/小时向服务器发出一个请求，请求使用该软件的当前版本号。之后，您将能够使用分析来查看当前设备更新的百分比和数量。评论
这是否考虑了已变砖或无法完成更新的设备（可能停留在重启，下载，崩溃周期中）？
– Sean Houlihane
16 Dec 6'在19:25
在某种程度上，是的。如果您在第1天有100台设备，则在第2天进行了更新，而在第3天，分析中只有25台设备，这意味着发生了一些问题
– WayToDoor
16 Dec 6'在19:28
那很有意思。有没有办法区分故障类型？
– Noam Hacker
16 Dec 6'在19:57
将更新分为几个独立的步骤（例如，添加新的配置值，重新启动gps，设置设备ID，覆盖固件等），每个步骤都有一个开始..呼叫发送“ home”和一个状态为xx呼叫已完成的home。这样，您可以（大概）知道失败的位置以及（希望）状态码是什么。
– KennetRunner
2016年12月6日20:34
#3 楼
这一切都与智能同步策略有关。您需要一个与您的更新推出方法配合使用的智能同步策略。 IoT设备应同步其版本的最明显时间点是在更新之后。同步时间表的其余部分高度取决于设备的类型。
它是否始终处于打开状态并通过电缆连接进行连接，而单个同步无需花费很多（很多），因此可以很好地同步定期保存有关设备的最新数据。
如果设备在某处，则由于使用昂贵的卫星连接而造成的每一比特成本很高，因此同步计划必须适应这种情况。
同步的验证
在足够高级的设备中（阅读证明其价格范围或操作范围的设备），每个设备都可以配备客户端证书，以启用同步的真实性检查。
无论使用哪种终端客户设备，由于电池即将耗尽，设备无法使用或者仅仅是客户更改其无线密码而未通知IoT设备，您总是会遇到设备掉落的情况。即使它们在时序上合在一起，这些更新也可能不需要做任何事情。
评论
我不认为这可以解决OP问题。
– WayToDoor
16年6月6日在21:27
@WayToDoor我的第一段建议在更新后直接进行同步。这将提供是否成功达到新版本的信息。如果不是这种情况，可能采取的对策过于广泛（不要求）。我其余的答案涉及监视现场版本。我想念哪个问题？
– Helmar♦
16 Dec 6'在21:31
评论
就像您的其他问题一样，这太广泛了。这将在很大程度上取决于设备的类型和部署模式。当您说“车队”时，您是指车队吗？如果是这样，我假设使用SkyWave调制解调器通过（加密的）SMS，GPRS上的HTTPS或事件卫星进行通信。如果您可以编辑问题进行澄清，那么我相信它将重新打开。