IoT 监测项目准备清单：设备、数据、网络与告警

设备与协议：知道在连接什么

记录厂商、型号、硬件与固件版本、设备数量、唯一编号和责任人。提供通信说明及一段授权脱敏报文；注明串口、Modbus、MQTT、HTTP 或私有协议，哪些文档和访问权限仍待取得。

MQTT 的 QoS 是消息传递语义，不能单独证明数据库不会重复记账、指令已经执行或断网数据必定恢复。项目仍需定义消息标识、处理幂等和执行确认。

协议资料最好同时附上一条原始报文和它的预期解释。例如某个字段代表设备累计运行时间，需要写清单位、溢出和重启后的行为。只有一个“数值正常”的截图，开发者很难判断设备重启后计数归零是故障、正常行为，还是解析错误。

测点与数据：保留含义和时间

左右滑动，查看完整表格。

网络与恢复：先说明离线会怎样

说明现场网络、信号覆盖、供电、出口限制、网关资源和谁能安排接入。约定离线缓存、满载淘汰、重连节流、去重及迟到数据规则。若暂时不知道最长中断时间，将它列为待测条件。

先以“消息数 × 每条字节数 × 离线时长”估算原始缓存，再考虑编码、索引和运行余量。实际容量需测量确认；振动原始波形不能按低频状态值的体量估算。

告警与责任：谁需要采取什么动作？

记录阈值来源、持续时间、恢复条件、维护静默、分组、升级和接收人。把设备离线与数值异常分开；记录确认人、时间与处理说明。缺少现场依据时，阈值只能是待验证配置，不能宣传为诊断结论。

监测与远程控制分开评估。涉及启停或参数修改时，确认操作权限、命令过期、设备回执、人工确认和必要的现场联锁。

最好指定一个能回答告警问题的人。设备工程师知道什么工况值得检查，值班人员知道通知太频繁时会发生什么，管理者则可能只需要每日汇总。三者需要的界面和节奏不同，不能把所有报警都发送给同一个群就算完成。

用异常回放写验收清单

• 选择一种设备和一段数据，核对身份、单位、时间与趋势。
• 模拟断网、重复、乱序和时钟偏移，检查标记与恢复。
• 触发、确认、恢复一条告警，核对责任人与记录。
• 按约定负载持续运行，核对数据缺失、延迟与查询。
• 保留数据样本、配置版本、预期结果与失败说明。

清单用于项目准备，不替代现场安全评估、传感器选型或设备认证。未确定的资料可以先列出，由双方确认如何验证。

交接时，换一个没有参与开发的人试一次故障处理：只看文档和页面，能否判断是设备、网关还是平台的问题，能否找到对应日志，知道该联系谁？这能暴露很多功能演示看不见的缺口，例如日志没有设备号、告警找不到原始值，或资料只存在开发者的电脑里。