设备正常退出为什么没发遗嘱，怎样核对 MQTT 遗嘱延迟

正常发送成功的 DISCONNECT 通常不会触发遗嘱，MQTT5还可以配置Will Delay避免短暂掉线立即告警。异常断链后，遗嘱在延迟到期或会话结束时触发，取较早条件；若在延迟结束前重新连接到原会话，规范规定不发送该遗嘱。不能简单写成“断电立刻offline”。

环境和证据范围

限定MQTT5，正常退出使用原因码0x00；原因码0x04是主动要求发布遗嘱的特殊情况，仍受Will Delay与会话结束规则约束，并不强制立即发布。合成时间线假设服务端持续运行且已检测到断链，不把物理断电时刻直接当检测时刻，也没有测Broker故障时的延迟。

核对顺序

1. 先区分物理失联、代理检测到网络连接关闭、遗嘱发布、订阅端接收这四个时刻。Keep Alive会影响检测，Will Delay影响检测后的等待，两者相加才可能接近用户看到的延迟。

2. 记录连接时登记的遗嘱主题、Will Delay和会话过期值，正常退出也保存DISCONNECT原因码。若会话先结束，应按会话结束处理，不要机械等待完整Will Delay。

3. 在隔离环境分别安排正常退出、无恢复断链、延迟内恢复同会话、会话先过期四种条件。恢复连接必须核对Session Present等会话证据，重新创建新会话不自动等于取消旧会话遗嘱。

可复算的输入与预期

检测断链记为0秒：delay=10、session_expiry=60且不恢复，预期10秒发布；3秒恢复同会话，预期取消；delay=10而session_expiry=5，预期5秒发布；正常原因码0退出，预期不发布。另有原因码4、delay=10、session_expiry=60的样例，仍为10秒发布，作为“主动发遗嘱就立即发送”的反例。

时间线中的0秒是代理检测到网络连接关闭，不是拔电源的时刻。保活检测、操作系统连接状态与订阅端排队都会引入额外时间，不能把脚本算出的10秒写成“断电后10秒必达”。异常检测与遗嘱延迟两段都应保留可对照日志。

下载与现场记录

下载本题合成输入与预期JSON、离线只读核验脚本和现场空白记录CSV。放在同一目录，用 Python 3 运行 python verify.py，逐项计算或解析后与预期比较，失败会显示差异。

现场字段包括 disconnect_detected_at、reason_code、will_delay_s、session_end_at、same_session_resumed_at、will_observed_at。合成样例保持原样，实测另存并填写型号、版本、证据路径，未采集处留空。本地核验不代表真实设备、代理、浏览器或长期稳定性已测。

失败分支与移交

如果Broker自己停机，规范允许在后续重启后再处理遗嘱，因此不能把遗嘱当毫秒级故障切换或安全联锁。订阅者也可能离线，发布时刻不等于告警展示时刻。真实验收要同时保存代理日志与订阅日志，不能只录屏看卡片变灰。

运营交接应解释短暂断网期间为何仍显示待确认、多少时间后显示离线，以及恢复后谁发布online。遗嘱负载若采用保留消息，还应核对online/offline的状态覆盖和采样时间，避免旧offline在重连时被误当新故障。

基础背景可看MQTT 物联网控制协议在展厅的应用速查。遗嘱与会话结束先后有关，可配合核对MQTT 重连后订阅还在不在，怎样核对 Clean Start 与会话过期。更多资料在设备协议库。

需要接入中控时，可对照SoftControl设备联动需求核实适配范围；独立校验方法是否纳入交付需逐项约定。

一级资料

• 官方资料：§3.1.2.5与§3.1.3.2.2 Will Delay Interval

核对日期：2026-10-24。规范定义与本文应用约定分开，示例门限及脚本不自动代表产品原生能力。