ThinkLink 设备显示在线就正常吗：心跳、检测状态与业务新鲜度

先约定在线的业务含义

温度传感器、只在动作时上报的开关和持续供电设备可能采用完全不同的报告周期。上线前先记录实际消息周期与期望检测方式，再选择心跳配置。本文依据当前设备管理文档，现场必须核对配套版本，特别是 2.00.099 的空心跳语义。不要把网关在线、终端近期通信和业务数据有效混成一个绿色状态；网关正常也可能有终端停止上报，终端有消息也可能没有目标测量字段。面向运维的页面应说明状态来源，并同时提供最后活动与业务数据时间。

保留空心跳与关闭检测的区别

当前文档中，设备 heart_period 为空时视为在线且不登记超时任务，不能擅自补成固定秒数。非空有效心跳才按周期参与时间判断。在离线通知开关 notify_offline 使用字符串 TRUE 或 FALSE，默认关闭；关闭后检测器保留上一次 _online，不代表持续更新的当前结论。缺失状态、未启用、尚未加载和查询失败也不是同一状态。配置读取未完成时，客户端不能把未知值保存成关闭或零秒，否则一次无关编辑可能改变检测行为。保存后应重新读取这两个配置项。

三个状态字段分别解释

API online、server_attrs._online 和 MQTT 消息 data.online 的来源、类型与更新时机不同。当前 API 与检测器在边界时刻等细节上也有差异，不能要求所有通道在每一瞬间完全一致。_online 是检测器维护的数字，状态通知中的 online 是布尔值；通知表示状态变化，不是设备完整快照，也不是业务告警。历史消息的到达可以刷新接收活动，但不证明现场刚刚完成新采样。因此看板应写清统计使用哪个来源，避免把关闭检测后保留的旧数字当作实时在线人数。

测试断报、恢复和重新连接

选择一台允许测试的设备，记录心跳与开关后，观察正常上报、停止上报、跨过判断时限和恢复上报。非空心跳下，检测器严格超过活动时间加两倍心跳后才判离线，实际通知还可能有异步时差；不要把一次边界瞬间截图当成缺陷结论。若消费端通过 MQTT 接收状态，断开重连后应通过现有查询读取当前状态，再与后续事件协调，不能期待所有离线期间的状态变化必然补送。测试应留下接收时间、配置和实际结果，而不只记录颜色。

1. 核对版本、心跳值和检测开关。
2. 注明状态字段来源与类型。
3. 验证断报、超时、恢复及消费端重连。
4. 分别验收状态展示和业务告警。

把通信状态与业务告警分开交付

状态通知不是已经完成的离线告警工作流。是否生成告警、通知谁、多久升级处理，仍需按项目要求配置并验证。建议分别呈现通信状态、测量新鲜度和业务故障，尤其要保留未知和查询失败提示。若接收端需要事件历史或可靠补发，应单独设计存储与恢复方案，不能从状态主题存在推导出平台已提供可靠事件队列。最终交付包含所用状态口径、实际心跳、空值处理、暂停检测说明及测试证据，让现场人员能解释同一设备在不同页面上的短暂差异。