状态缓存与TTL：给每个设备状态贴一张“保质期”

一、智能家居最大的坑你以为你知道其实你不知道做智能家居的朋友都遇到过这种尴尬你写好了代码红外发射器“滴”一声电视开了。系统里记录电视开。然后你妈走过来拿起物理遥控器把电视关了。你的系统不知道。它还傻傻地以为电视开着。用户下一条指令“打开B站”系统自信满满地发了一串红外码——结果全打在关着的电视上什么都没发生。这个问题的本质是大多数家用设备能控制但没反馈。红外控制的电视、空调你能发指令但它不会告诉你“我收到了我执行了”。米家云端API你能调接口但有延迟而且别人也能用App控制你的缓存瞬间过期。你系统里维护的那个“设备状态”本质上是一个缓存。它记录的是“上次我让它干什么了”而不是“它现在真实是什么”。缓存一定会过期。问题是什么时候过期过期了怎么办二、TTL给状态贴张“保质期”计算机里有一个经典概念TTLTime To Live存活时间。说白了就是一个数据从生成开始能活多久。过期就作废不能再用了。冰箱里的牛奶保质期7天。1月1日生产1月8日过期。1月9日你拿起来喝之前看一眼标签过期了扔。设备状态也一样。你给电视发“开机”指令记录状态为“开”同时贴一张标签30秒后过期。10秒后用户说“音量大点”30秒内没过期直接执行。50秒后用户说“打开B站”过期了不能信了得重新确认。TTL让你不用每秒钟都去问状态但也不会在状态过期后还傻傻相信它。三、在我的系统里不同来源的状态TTL不一样这是我项目里实际的设计状态怎么来的我能信多少TTL设多久为什么我发了红外指令推测它成功了很低30秒红外没反馈物理遥控器随时覆盖米家API返回的中等10-30秒云端有延迟家里别人也用AppADB直接读屏幕较高5-10秒真实读到的但用户可能按物理键我用识图OCR“看”了屏幕高这次会话内眼见为实但界面可能自己变一句话越不可靠的来源TTL越短。四、过期了怎么办能看就看不能看就问状态过期不是终点是决策起点。两条路能自动探测的悄悄刷新。比如电视接了ADB我能读UI树或者我跑了识图OCR能“看”屏幕。那就静默刷新用户无感知。不能探测的问用户。老电视只有红外除了发指令什么都拿不到。那就降级为对话“电视现在是开着的吗”这不是技术不行是物理世界没给我反馈通道。在感知受限的条件下承认“不知道”比瞎猜更可靠。五、为什么固定TTL还不够好固定TTL有一个问题它和用户的使用节奏是脱节的。用户连续说话——“开电视”、“打开B站”、“音量大点”、“暂停”——每次间隔几秒。这时候物理状态基本稳定因为用户自己在主导。但固定TTL可能在第三句话时判定“状态过期”突然问一句“电视还开着吗”——打断体验。所以我设计了一个会话冷却机制这个话题后面单独写。核心思想是TTL是机器视角的过期我要的是用户视角的过期。用户在连续用状态就保鲜用户沉默了一段时间状态才开始过期。六、总结我这个智能家居系统面对的是大量“能控制但没反馈”的老设备。状态管理不能靠理想假设只能靠务实设计。TTL就是这个务实设计的核心给每个状态贴保质期过期了就想办法重新确认不假装知道。这套机制让我在红外、米家API这些不可靠的感知通道上依然能维持一个相对可靠的系统状态。