监控离线与断电事件
适用场景
适用于后端更新设备可用性、产生告警或记录设备支持的断电信号，同时避免反复轮询设备状态。
device.connection.online和device.connection.offline表示连接状态变化。device.power.lost表示设备上报了断电信号。- 不同设备类型不一定具有相同的断电检测能力。对产品承诺断电告警前，应检查设备类型定义和交付的设备文档；没有明确记录断电能力时，不能推断为支持。
推荐流程
WebSocket 提供及时通知，但不是永久状态来源。当前状态应保存在你的服务中；发生事件缺口后，通过 REST 恢复。
分步骤实现
- 使用查询设备列表建立账号的初始状态。
- 开启断电相关 UI 或告警前，检查设备类型定义列表和交付的设备文档。通用操作列表不能证明设备支持断电检测。
- 创建 WebSocket Ticket，建立连接，并启动协议 Ping/Pong 与
session.ping。 - 收到
device.connection.offline后，停止把设备展示为可控制状态，并记录occurredAt。 - 收到
device.connection.online后，更新连接状态，但不要假定外设数据已经完成同步。需要当前状态时再刷新单台设备。 - 收到
device.power.lost后，持久化事件，并根据结构化 topic 和时间字段告警。不要解析可选的固件message或据此做程序分支。 - 重连后使用 REST 恢复账号状态基线，只立即确认关键设备。
关键接口与事件
| 用途 | 文档 |
|---|---|
| 当前账号状态基线 | 查询设备列表 |
| 确认单台设备 | 查询设备详情 |
| 在线和离线事件 | 设备连接事件 |
| 断电事件语义 | 设备断电事件 |
| 心跳与恢复 | 心跳与重连 |
失败与恢复策略
- 检测连接关闭和心跳超时，使用有上限的指数退避和随机抖动重连。
- 不要复用
wsTicket；每次尝试建连前都创建新 ticket。 - 事件不会补发。重连后应重建当前状态，而不是假设断线期间没有事件。
- 重试或重连边界可能出现重复处理。使用已有的 topic、
deviceId、时间字段和最终状态实现幂等，不要依赖事件契约中不存在的字段。 - 断电事件通常会伴随离线事件，但告警流程必须允许其中一类事件单独到达。
生产环境注意事项
- 分别保存事件接收时间和设备的
occurredAt，便于观测延迟。 - 设计告警抑制和恢复规则，避免重连抖动产生重复事件单。
- 将 WebSocket 作为实时更新通道，将 REST 作为状态恢复路径。
- 设备接入时确认断电检测能力，不要因为其他设备类型支持就直接推断当前设备支持。