“支持本地控制”需要说明是哪条链路。手机、网关与设备的网络依赖可能各不相同。
本文使用米家设备、网关与 Node-RED 的架构研究，接入能力按具体型号确认。米家不是一个所有设备都开放相同本地接口的统一协议。设备型号、网关和固件会影响可用能力，本文不声称任意设备都能绕过云端或直接接受自定义控制。
1. 从现象推到机制
状态读取、下发命令、规则触发和账号登录可能分属不同路径。断开外网但保留局域网是一种对照，关闭网关则是另一种。每次只改变一个依赖，才能知道哪个能力真的可离线完成。
图中的四个节点分别表示能力清单、依赖切分、受控对照、结果范围。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先用模拟自动化链路定义需要的观测，再按设备支持范围做受控验证。保持人工操作入口，不把未确认的离线能力用于关键场景。
1
2
3
4
operation -> required path
read state -> confirmed local or cloud route
execute command -> authorization and device feedback
automation rule -> actual runtime location
先核对本人设备支持的公开接口与授权方式，再用模拟设备打通流程。凭据只在受控配置保存；不提供账户绕过、私有密钥提取或未经确认的实物控制命令。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 仅断开外网 | 可检验该能力是否依赖远端服务 |
| 局域网仍在但网关关闭 | 可区分网关承担的职责 |
| 应用显示缓存状态 | 不能误判为新采集成功 |
对照 1：仅断开外网
可检验该能力是否依赖远端服务。观察时记录操作结果与依赖路径。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：局域网仍在但网关关闭
可区分网关承担的职责。观察时记录设备实际反馈。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：应用显示缓存状态
不能误判为新采集成功。观察时记录状态时间与真实动作。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
离线实验结果只适用于测试过的型号与固件。升级之后需要重新核对关键依赖，不能把一次验证推广到整个生态。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“应用显示缓存状态”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
