农业物联网的通信记录里，一条下行消息可能先后出现queued、sent和ack等名称。The Things Stack官方AWS IoT集成说明，将它们分别解释为下行已经入队、网络服务器已经发送，以及终端已经确认需要确认的下行。[1] 这些名称所处的环节不同，不能只因都与同一消息有关，就统一转写为“终端已确认”。

queued首先说明队列状态。消息进入队列，意味着系统已留下等待后续处理的对象；官方事件表并未把这个名称定义成设备收到消息。sent再向前一步，说明网络服务器已发送，但它的定义仍没有使用终端确认的含义。若一份历史记录仅列这两个事件，可以分别描述入队与发送，而不能替它补上尚未出现的ack记录。

该事件表还列出failed和nack。failed说明网络服务器发送下行失败，nack则对应终端没有确认需要确认的下行。二者不是同一种失败位置的两个拼法。前者将问题放在发送事件上，后者属于确认反馈；读一份包含错误名称的记录时，仍须保留该名称来自哪一项事件，而非只留下一个不分环节的“失败”。

Data Formats文档提供了另一个容易相混的字段：confirmed。它被解释为这条下行是否期待设备确认。[2] 因此，confirmed为true表达请求的性质，并非终端确认已经返回。要求确认与取得确认可以出现在同一通信过程的不同位置；若只看见这个布尔字段，便把消息改标成ack，会将期望改写成结果。

确认怎样成为返回记录，官方Confirmed Downlinks Behavior另有说明。终端将相应确认标志附在下一条上行中，网络服务器接收到带ACK标志的上行后，产生downlink ack消息，应用服务器再将它传给集成。[3] 此处至少区分设备反馈、网络服务器产生事件和应用服务器转交三个环节，不能把应用侧看到一个发送事件等同于这条反馈链已经完成。

这也解释了部分记录为什么可能暂时没有ack或nack。文档说，B类与C类设备可以在没有先收到上行的情况下，由网络发起下行；携带反馈标志的下一条上行却可能不规则到来。在下一上行到来之前，网络服务器不会生成相应ack或nack。[3] 因而，已发送后暂未出现确认事件，与已经得到终端确认是不同的记录状态；本篇没有据这种空缺给出重发办法。

发送失败的资料还保留更细的结构。Data Formats中的downlink_failed将downlink对象和error对象分开，前者描述触发失败的消息，后者列出namespace、name、message_format、correlation_id和code。[2] 组件所在范围、错误名称、说明文字、关联标识与错误码各有字段。来源示例使用application_downlink_too_long，这只是文档示例中的错误身份，不能作为某个真实农场设备已经出现该故障的证明。

对现有农业遥测记录，事件名说明到了哪个环节，confirmed说明是否期待反馈，ack或nack则保留返回确认的结果。这三层关系可用于准确描述通信资料，却没有直接证明灌溉或其他实体作业已经执行。本文只采用上述官方文档的静态字段与确认流说明，不发送消息、不配置设备，也不提供控制、无线参数或重试策略；网页首次发布日期未知。

资料：[1] https://www.thethingsindustries.com/docs/integrations/cloud-integrations/aws-iot/messages/ ；[2] https://www.thethingsindustries.com/docs/integrations/data-formats/ ；[3] https://www.thethingsindustries.com/docs/hardware/devices/concepts/confirmed-downlinks-behavior/

信息来源

本文基于上述公开资料整理，未使用来源页面的图片、视频或嵌入媒体。