AI家庭设备判断传感器数据是否还能用于控制，不能只看数值，也不能只看设备在线。应同时核对数据对应的设备和位置、采样与接收时间、有效期限、质量状态，以及动作执行前的最新条件。超过允许时限的数据可以保留为历史记录，但不应继续冒充当前现场状态。
这项设计尤其适用于家庭网关、环境控制终端和能调用设备工具的智能体。模型理解“房间有点闷”以后，仍需要可靠的现场输入，才能决定下一步查什么、是否执行，以及怎样向用户解释结果。
一个一直不变的温度，可能对应两种完全不同的现场
假设某个房间的温度一直显示为24℃。一种情况是传感器持续上报，环境确实稳定；另一种情况是设备已经停止采集，界面还在展示最后一次收到的值。两者看起来一样，自动化系统应作出的判断却不同。
因此，“数值没有变化”不能直接解释成“设备失效”，也不能直接解释成“现场没有变化”。在数据入口保留观测与接收信息，比让智能体根据上下文猜测更可靠。单位、所在空间和设备身份也应一起保存，避免把另一个房间的读数用于当前控制。
Home Assistant的状态对象把状态、属性与时间信息放在一起，并区分unknown和unavailable：前者没有可用的状态值，后者表示实体当前无法提供状态。它们不应被转成温度0℃、无人或关闭等正常业务值。状态对象文档
在产品界面中，也可以区分“最新读数”“上次读数”和“等待更新”。用户看见一个温度数字时，应该能知道它代表当前观测还是历史信息；控制系统读取时，则需要结构化字段，而不是依赖界面文字。
把采样、到达和使用三个时刻分开
数据从端点走到控制系统，至少会经历传感器采样、网关接收和业务读取。网络延迟、设备休眠、离线缓存都会拉开这些时刻。只记录服务器收到消息的时间，可能把刚刚补传的旧数据误当成刚发生的新情况。
可为每条观测建立以下信息。字段名称可以按项目接口调整，含义需要在设备端、网关和应用端保持一致。
| 信息 | 回答的问题 | 缺失时怎样处理 |
|---|---|---|
| 设备与实体标识 | 到底是谁的哪项观测 | 不能仅凭显示名称自动匹配 |
| 空间与单位 | 哪里、测量什么 | 先核对映射，避免混用 |
| 采样时间 | 现场何时被观测 | 注明不能确定采样时刻 |
| 接收时间 | 系统何时收到它 | 用于排查传输延迟 |
| 序号或消息标识 | 是否重复、乱序或补传 | 由接入层保留可追踪信息 |
| 质量与有效期限 | 现在还能否用于决策 | 按规则拒绝或重新读取 |
并非所有低功耗设备都有准确的实时时钟。对于没有可信采样时间的端点，可结合网关接收时间、协议特征与上报周期建立较保守的有效期限，同时保留时间可信度。不要给缺少时间依据的数据补一个看似精确的“现场时间”。
重启也要考虑。设备重启后消息序号可能从头开始，服务器不能简单把所有较小序号都判定为过期。可将启动批次与序号配合，或者采用协议已有的会话信息。不同来源的时钟未同步时，也不宜只按一个时间字段排序所有观测。
有效期限由任务决定，不能全屋共用一个超时值
温湿度趋势展示、灯光联动、门窗状态判断，对时效的要求不同。一个适合历史图表的数据期限，未必适合即时控制。合理做法是从任务可接受的观测延迟倒推，而不是给全系统统一设置“几分钟后过期”。
例如，假设某类环境传感器约每60秒产生一次有效上报，项目可以先用180秒作为待验证的失效阈值，再结合正常抖动、休眠与场景要求调整。这是配置示例，不能当作所有传感器的推荐参数。若设备只在数值变化时发送，就还需要心跳或独立存活信息，否则难以区分稳定环境与停止工作。
在Home Assistant的MQTT传感器中，expire_after可设置状态失效的秒数，过期后变为unavailable；默认不设置失效期限。这个机制提供了实现入口，但不能替代对实际上报行为的确认。MQTT传感器配置
评审时可以让设备方回答：正常上报间隔是什么、无变化是否仍有消息、最慢多久应该收到一次、断线后怎样补传。把这些答案写进接口资料，后续才能判断超时是故障、正常休眠还是配置不匹配。
在线心跳和有效测量应分别保存
网关能连接，不代表它下面的每个传感器都在工作；传感器能响应，也不代表刚得到的测量通过了质量检查。通信存活、测量有效和业务可用，是三个可独立变化的条件。
可以保留两条状态链：一条回答设备或连接是否存活，另一条回答最近一次有效观测是否仍在期限内。这样，现场就能区分“网关在线、端点超时”“端点在线、测量异常”和“测量正常、业务权限受限”，减少把所有问题归结为网络不稳的情况。
MQTT接入提供availability相关配置用于可用性消息，传感器值通过state_topic进入系统。这种分离有助于把通信与观测分别管理。接入方仍要明确在线消息由谁发出、代表哪个范围，以及断开后何时更新。MQTT集成
对于只在变化时发送的设备，心跳的价值尤为明显。它能够证明某个通信环节仍在活动，但不能证明某个温度探头当前校准正确。故障定位需要沿着采样、编码、传输和业务使用逐层检查。
旧消息重放，是恢复联网后容易遗漏的一道题
设备离线时可能缓存消息，消息系统也可能保留最近值。恢复后看到一条消息刚刚抵达，不能据此认定现场刚刚发生了对应变化。记录原始采样时间、消息序号与补传属性，才能避免把历史事件重新触发为当前动作。
MQTT传感器官方文档特别说明，保留消息可能在Home Assistant重启或重新加载时重放，使已经过期的状态重新显示为可用。因此，使用expire_after时，状态消息的保留策略也需要一起核对。过期与保留消息说明
工程上可以把恢复过程拆成两条路径：历史观测进入记录与分析，当前观测进入控制候选。若两者共用消息入口，接入层至少应带上足以区分的时间和类型信息。业务侧不应对补传数据无条件重新执行场景。
还要设计重复消息的处理。相同事件经过重试抵达多次时，不能让一次操作变成多次操作。数据层去重与执行层的幂等记录可以配合，但二者不要混成一个状态：观测已经保存，不等于动作已经完成。
智能体读取到什么，决定它能否说清为什么没有执行
如果工具只返回一个数值，模型很难区分当前值、历史值与异常值。更合适的工具响应应把观测值、单位、空间、时间、质量及可用性一起返回。需要重新读取、等待更新还是转人工，也应有明确的业务规则。
例如，用户希望根据室内环境调整设备，工具返回的数据已过有效期限。系统可以先尝试刷新；刷新失败，就说明当前无法取得可靠观测，保留用户手动操作入口。不要把缺失值默认为0，也不要让语言模型自行把历史值修补成当前值。
对涉及多个房间或多个设备的任务，还要防止“拼接出一个从未同时存在的现场”。不同读数的时间跨度若超出任务允许范围，应分别刷新或缩小结论。把相关数据放进同一段提示词，并不会自动完成时间对齐。
动作执行前再检查一次关键状态也有必要。从用户提出需求到智能体完成推理之间，设备、权限或环境可能已经变化。最终决策应由明确规则约束，执行结果则用设备回执与状态反馈核对。
验收时，把故障注入到数据链路中
只展示正常上报，无法证明系统识别过期数据的能力。可以在隔离测试环境中设计几组可重复的输入，核对展示、工具响应和执行决策是否一致。测试不应直接作用于有风险的真实设备。
第一组让数值保持不变，但持续发送有效观测，检查系统是否误报失效。第二组停止观测而保留网关心跳，检查过期后是否仍被当作可用输入。第三组延迟并乱序发送，检查旧值是否覆盖新值。第四组重启接入服务并重放历史消息，检查是否错误触发动作。
每组留下输入时间线、接收记录、状态变化、工具响应和执行结果，才能复核问题发生在哪一层。若只是界面出现了“离线”字样，工具调用却仍返回旧值，控制链路并没有完成验收。
还应核对恢复后的行为。系统重新取得有效观测后，是恢复展示、恢复自动任务，还是等待用户确认，应按具体动作确定。不能让所有暂停任务在网络恢复瞬间一起执行。
从一项观测开始，建立可以复用的数据约定
先选一个房间的一项观测，把身份、单位、时间、有效期、异常状态和恢复流程完整跑通，再扩展到其他设备。这样形成的接口约定，比一开始接入很多品牌、却无法解释某条数据是否可信，更有长期价值。
普众数智的居家智能开发围绕终端、家庭网关与多设备联动展开。项目准备阶段可先整理设备型号、已有系统、目标场景与可获得的数据字段，用于确定接入范围和控制条件。居家智能方案