米家应用能控制设备，不代表外部程序已经拥有相同接口和权限。接入前先画依赖关系。
本文使用米家设备、网关与 Node-RED 的架构研究，接入能力按具体型号确认。米家不是一个所有设备都开放相同本地接口的统一协议。设备型号、网关和固件会影响可用能力，本文不声称任意设备都能绕过云端或直接接受自定义控制。
1. 从现象推到机制
某些设备直接联网，另一些通过网关通信，应用还可能依赖云端账户与授权。具体能力按型号和固件变化。所谓本地控制，需要确认消息是否真的在局域网闭环，而不是只因手机连着 Wi-Fi 就推断没有云。
图中的四个节点分别表示设备型号、网关关系、云端授权、集成范围。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
为本人设备建立能力表，区分官方公开接口、可确认本地能力和未知项。先用模拟设备研究流程，不获取或公开真实令牌。
1
2
3
4
device model -> supported transport and gateway
gateway -> local capability or cloud dependency
account -> documented authorization
integration -> only confirmed supported operations
先核对本人设备支持的公开接口与授权方式，再用模拟设备打通流程。凭据只在受控配置保存；不提供账户绕过、私有密钥提取或未经确认的实物控制命令。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 手机同网控制正常 | 仍不能证明请求未经过云端 |
| 更换网关固件后失败 | 接口能力可能已经变化 |
| 缺少公开控制接口 | 应保留未知而非编造通用命令 |
对照 1：手机同网控制正常
仍不能证明请求未经过云端。观察时记录实际已确认的通信依赖。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：更换网关固件后失败
接口能力可能已经变化。观察时记录型号与固件版本。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：缺少公开控制接口
应保留未知而非编造通用命令。观察时记录接口资料与授权范围。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
本地自动化也要尊重设备所有权和访问权限。不能为了接入便利而绕过账号授权，未确认协议不应写成可直接复用教程。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“缺少公开控制接口”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
