双11的米家设备到货后，自动化频频翻车？先让小爱说句话
双11的快递拆完，贴好电池的你对未来充满信心：从此人来灯亮、人走灯灭。结果三天后就开始怀疑人生——明明有人走过去，灯就是不理你；说好十一点关窗帘，它装死；昨天还灵，今天就失灵。
先别急着骂设备。折腾米家智能的老手有个共识：自动化不执行，九成不是设备坏了，而是「触发、条件、执行」三段里有一段空的——米家的失败是静默的，不会告诉你哪一段出了问题。知乎小红书
第一步：安一个「会出声的探针」
在这条自动化的动作列表最后加一条「小爱音箱播报一句话」，内容随便写，然后手动触发一次：音箱响了灯没动，问题在执行段；音箱根本没响，问题在触发段或条件段。一次出声，范围砍半。知乎
执行段：最隐蔽的坑是「失效设备记录」
设备删掉重加过、或从别的家庭转移过？自动化里那条动作界面上看着完全正常，底层却指向旧记录，执行时被直接丢弃、不报错。凡是"重装某个设备之后这条自动化就不灵了"，八成是它——把动作删掉重选一遍设备就好。另外，设备当时离线米家不重试，动作直接丢；WiFi设备开着「双频合一」重连慢，恰好错过那一秒；一两分钟内反复触发会被节流，动作前加个「延时30秒」再复查。知乎
触发段：「事件型」和「状态型」不是一回事
这是「有人，灯却不亮」的头号原因：「当以下情况发生」负责触发，而「且满足全部状态」是在触发那一刻检查的，它们不是同一回事。人体传感器是事件型，只在那一瞬间成立，状态值却依赖设备上报；人走过走廊，传感器立刻发事件，光照传感器可能五分钟才报一次，系统读到的是五分钟前的亮度，判定不满足，整条自动化就安静地不执行。要改的不是阈值，是把状态条件挪到「延时几十秒」之后再判，或干脆换成时间段。小红书知乎
两个顺手要查的：「满足全部」里混进一个不主动上报的设备（Zigbee子设备已掉线、App首页却还显示在线），条件就恒假——判断要去网关的子设备列表里看，别信App首页。还有跨夜时间段22:00到次日06:00这种写法，部分版本会当成无效区间，拆成两段试。知乎
最大的坑：自动化默认在「云上跑」
家里没有中枢网关、场景也没标本地执行，路由器WAN口一抖、米家服务器一波动，自动化就不执行，事后还查不出异常。验证很简单：拔掉WAN口只断外网，等两分钟再走过传感器，照常执行说明走了本地，没反应就是纯云端。知乎
要么补一台支持本地自动化的网关把关键场景迁过去，要么接受它偶尔失灵。但主从网关谁当主是新坑高发区，自带中枢功能的设备一上位，独立中枢网关可能被挤成备份还改不了，买前一定想清楚。哔哩哔哩
至于条件超过三四条、要"同一事件十分钟内只执行一次"、要按日出日落偏移的——米家的表达能力就到这儿了，合理做法是设备仍留在米家、判定搬到 HA 或 Node-RED。知乎
灯该亮的时候亮，不是魔法，是工程。 下次自动化装死，别急着重置设备，先花三分钟：探针→执行段→条件段→本地化，一路排下来，大概率就通了。
