设备失联时应明确提示而非静默保持最后状态
别名: 失联提示 · stale state · last-known value · 静默过期
概念解释
智能家居设备与网关或云的连接断开——失联（offline）——时，应用界面应把这个事实标示出来，而不是继续显示失联前最后一次上报的状态。继续显示的那个值叫最后已知值（last-known value），它是一个可能早已过期的快照；把它当当前值展示，就是状态静默过期（stale state）。
失联不提示的问题不在「少了一条通知」，而在展示值与实际值脱钩：设备离线期间物理世界照样会变——家人拨了墙上的开关、设备本身进了故障态——而界面读起来一切正常。用户据此做的每个判断都建立在假数据上。
机制
静默过期在工程上是「省事默认」：状态界面直接绑定数据库里的最后一条记录，连接断开只是让记录停止更新，展示层并不区分「新鲜的当前值」与「过期的快照」。要正确呈现，系统得维护两套语义——当前值，和「最后已知值 + 失联判定时间」——并把两者在视觉上分开。多数实现只做了前者。
对用户的伤害来自不可区分性：「系统知道且正常」与「系统已不知道但在装正常」在屏幕上长一个样。智能家居的设备恰恰有不少是物理状态不可直接观察的（门锁有没有锁上、传感器还工不工作、温控器还在不在控温），显示值的可信度是用户唯一的依据；失联静默直接击穿这个依据。
怎么研究
失联提示的研究以实地与情境访谈为主。Edwards 与 Grinter 对家庭泛在计算挑战的分析把家庭网络的不稳定列为持续的管理负担；智能家居故障排查的实地研究里，用户把失联设备误判为「设备坏了」或「网坏了」、围绕一个其实只是离线的设备反复折腾，是反复出现的片段（此处按领域共识泛写，不落具体数字）。
可操作的实证做法：给同一故障场景做提示方式的被试间比较——无提示、被动图标、主动通知——因变量取用户发现失联的时延、误操作次数与归因正确率。方法论注意点：实验室环境里被试预期「今天会有故障」，警觉远高于真实家庭；失联提示的价值恰恰在低警觉的长尾时刻，评估需用长周期部署或日记法补足。
边界
- 提示要有防抖。 几秒的重连抖动不该触发提示，否则频繁的「上线/离线」闪烁制造提示疲劳，用户很快学会无视所有失联标记——把真正重要的那次淹掉。
- 伤害与设备的可观察性成正比。 灯亮不亮抬眼可见，显示错了损失小；门锁、漏水、烟感这类看不见内部的设备，失联显示错是安全隐患，要按安全等级分流处理。
- 多设备家庭不能逐个即时通知。 路由器一重启全屋离线，几十条推送等于骚扰。分层：安全相关即时推，普通设备进「失联清单」由用户主动查。
怎么落地
- 数据模型把「当前值」与「最后已知值 + 时间戳」分成两个字段，超时判定后才允许切到过期语义。
- 过期态的视觉要减值而非新增：灰显、降透明度、加失联角标，让「正常」与「不知道」一眼可分，而不是多一个红色徽章。
- 设备列表页提供「仅看失联」过滤，恢复在线时清掉。
- 安全相关设备（门锁、烟感、漏水）失联走即时推送；普通设备日汇总即可。
- 验证办法：随机抽一台设备断电或断网，检查应用是否在超时窗口后把显示切到过期语义；恢复供电后显示是否回到当前值。再拔一次路由器，检查是否只收到一条汇总而非几十条通知。