米家的设备价格合适、品类齐全但真正把它们编进一套统一的自动化体系时麻烦就来了——App 里各自为战跨品牌联动基本靠手动。ha_xiaomi_home这个集成解决的就是这件事它把米家生态里的设备按统一的设备模型翻译成 Home Assistant 里的实体让灯、传感器、插座、网关子设备能和其它品牌的东西放在同一张自动化图里。这篇内容面向已经装好 Home Assistant、手里有一批米家设备、想一次性把接入跑通并长期维护下去的人从环境盘点到安装路径、从本地控制模式到踩坑排查链路我会把自己反复折腾过的顺序和判断依据写清楚新手可以照着做有经验的人可以直接跳到排查和进阶那两节。1. 先把为什么要接想明白再动手装很多人是被一句能本地控制吸引过来的装完发现体验并没有想象中好于是又退回去用 App。问题往往不在集成本身而在于动手之前没想清楚自己要的是什么。接入这件事本质上是把设备的控制权从一个封闭的 App 搬到一个开放的自动化平台收益和代价都很具体先摆清楚再决定投入多少精力。1.1 云端接入和本地接入差的不只是延迟先说清楚两种模式到底差在哪。云端模式下Home Assistant 通过厂商服务器的接口下发指令、拉取状态链路是主机 → 公网 → 厂商云 → 设备。本地模式下主机直接在同一局域网里和设备对话链路是主机 → 局域网 → 设备。这两个链路的差别体现在三个地方维度云端模式本地模式响应延迟通常 0.3 到 1.5 秒受公网状况影响通常 0.05 到 0.3 秒断网可用性外网中断即失效局域网正常即可用状态刷新靠轮询或订阅有间隔事件上报接近实时设备覆盖全品类仅支持本地协议的型号账号依赖需要长期有效的授权凭证首次配对后基本不依赖延迟这一项看着不起眼但它直接决定了自动化能不能用。举个例子走廊人体传感器触发开灯云端链路走完可能已经过去一秒多人已经走到灯下面了灯才亮本地链路基本是同步的。再比如开门 → 玄关灯亮这种场景超过一秒的延迟就会让人觉得这套系统不灵。断网可用性更关键。云端模式在外网波动时会出现大面积实体不可用而家里老人小孩并不知道什么叫外网波动他们只知道按开关没反应。本地模式在这方面的体验是质变级别的。但本地模式不是万能钥匙。它只覆盖支持本地协议的设备型号很多早期设备、部分 Wi-Fi 设备、几乎所有需要走厂商云的摄像头都不在其中。所以我一般建议能本地就本地不能本地的老老实实留在云端两套并存不要追求 100% 本地化。1.2 这个集成真正做的事情设备模型翻译理解了它的工作方式后面很多为什么实体长得这么奇怪的疑问就自然消解了。米家生态里的设备在协议层面是用一套描述规范来表达的每个设备有一个型号标识每个型号下面定义了若干服务service每个服务下面定义了若干属性property属性有编号、数据类型、读写权限和取值范围。这套东西很像一张设备能力清单但它不是 Home Assistant 能直接理解的东西。ha_xiaomi_home干的就是把这张清单翻译成 Home Assistant 的实体模型一个可读写的布尔属性变成switch一个只读的数值属性变成sensor一个可调亮度的属性变成light带范围约束的数值属性变成number。翻译规则是通用的不是针对每个型号手写适配这既是它覆盖面广的原因也是很多实体命名看起来比较机械的原因。这个机制带来两个直接影响需要提前知道第一同一个物理设备可能生成一堆实体。一个带温湿度、电量、开关状态的传感器可能会冒出五六个实体其中一部分对你毫无用处。这是正常的后面要做的是整理而不是删掉。第二实体 ID 的生成依赖设备上报的名称。如果设备名称里有中文、空格或者特殊字符自动生成的 entity_id 可能是拼音混杂的一长串。这个不影响功能但会让你在写自动化时非常痛苦。我在第 3 节会给出固定的做法。1.3 什么家庭环境适合上什么情况下别折腾不是所有场景都值得投入。我列几个典型判断适合的情况家里米家设备数量在 10 台以上、已经有其它品牌的设备或平台、想做跨品牌联动比如米家人体传感器触发非米家品牌的灯、外网质量不稳定、对自动化响应速度有要求。不太适合的情况全屋只有两三台米家设备、没有任何跨品牌联动需求、家里网络是运营商光猫直接拨号且不方便改网段、对维护成本敏感毕竟要跟着版本升级。还有一种情况要单独说如果你家里已经装了第三方米家集成那在装这套之前必须先想好迁移方案。两套集成同时接管同一批设备大概率会出现实体重复、状态互相打架、账号被频繁重新授权的问题。我的建议是二选一不要贪心。2. 动手前的环境盘点版本、网络、账号安装失败的情况里超过一半不是安装步骤错了而是环境不满足。花十分钟做一次盘点比装完再排查省事得多。2.1 Home Assistant 的版本与部署形态这套集成对版本有要求太老的版本会因为缺少依赖或者 API 变更直接报错。动手之前先看一眼设置 → 关于里的版本号保持在一个较新的稳定版上是比较稳妥的做法。我不建议为了装一个集成去用开发版稳定性优先。部署形态方面常见的几种选择差异如下系统级安装整机镜像最省心依赖齐全升级路径清晰。缺点是资源占用相对高。容器部署灵活但需要自己维护依赖某些集成会因为缺少系统库而加载失败。虚拟环境部署可控性最高适合愿意自己处理 Python 依赖的人。如果你用的是容器方式要特别注意一点集成需要能够访问主机的网络层来做设备发现。如果容器用了独立网络命名空间设备发现会失效表现为设备明明在同一个局域网但集成搜不到。这个坑我在第 5 节会展开说排查方法。另外留出磁盘空间。设备数量多的时候集成会在本地缓存设备描述文件几百台设备的规模下缓存目录会明显增长。2.2 网络拓扑决定了本地模式能不能成这一节是整篇内容里最容易被忽略、又最容易导致装完了但本地模式开不了的部分。本地控制的硬性前提是Home Assistant 主机和米家设备处在同一个二层网络里能互相直接通信。所谓二层网络通俗讲就是同一个路由器下、没有被路由器隔离的两个设备。以下几种常见拓扑会导致失败拓扑情况结果处理方式设备连在主路由 Wi-Fi主机连在光猫 Wi-Fi跨网段发现失败统一到一个路由下主机接在主路由设备连在子路由路由模式跨网段子路由改为桥接/AP 模式设备连在访客网络被 AP 隔离移到主网络路由器开启了 AP 隔离设备间无法互访关闭隔离主机在虚拟机的 NAT 网络里收不到广播改为桥接模式最容易踩的是最后一个。很多人把 Home Assistant 跑在虚拟机或者轻量服务器上网络默认是 NAT主机能上网但收不到局域网广播设备发现一直失败。改成桥接模式以后立刻就正常了。还有一个细节组播和广播。设备发现依赖组播如果你的网络里有多个 VLAN 或者用了较严格的防火墙规则需要放行组播流量。普通家用路由器一般不用管这个但如果你做过网络分段就得留意。我的建议是先做一次最朴素的验证在主机上尝试访问设备的局域网地址能通再继续。这一步省下来的是后面半小时的困惑。2.3 账号与地区设置里的隐藏约束集成在首次添加时需要完成授权用来拉取你账号下的设备清单。这里有几个容易忽略的点。地区必须和账号实际归属一致。选错地区的结果是设备清单为空或者只返回一部分设备。表现出来像是集成没工作实际上是查了一个不存在的设备库。家庭的选择会影响设备范围。米家账号下可以建多个家庭集成在添加时会让你选择拉取哪个家庭的设备。如果你有多个家庭比如自己家和父母家只选一个的话另一边的设备不会出现。多家庭场景要么分多次添加集成要么在同一个集成里全部勾选。授权凭证有有效期。部分授权方式拿到的令牌会过期过期后表现为所有实体突然变成不可用日志里能看到鉴权失败。这种情况不需要重装重新走一次授权流程即可。我的做法是把这个失效当成常态提前在自动化里加一条实体不可用超过 5 分钟就推送提醒的机制比事后发现灯不亮要体面得多。不要频繁触发重新授权。短时间内反复授权可能触发风控表现为登录环节卡住或者返回异常。真正需要重授权时间隔开一点。3. 安装路径的三条岔路以及每一步卡住的原因安装本身不复杂但三条路径各有各的坑。我按省事程度从高到低排你可以对照自己的环境选。3.1 通过 HACS 安装省事但刷新那一步最容易卡如果你已经装了 HACS这条路是最顺的。流程是在 HACS 里添加自定义仓库填入集成的仓库地址类型选集成然后搜索安装最后重启 Home Assistant。卡点几乎都集中在添加自定义仓库之后搜不到这个环节。原因通常有三个一是仓库类型选错。填地址的时候如果类型选成了前端或者主题安装完成后它不会出现在集成列表里你会以为是安装失败。这个错误非常常见重来一次改对类型就好。二是HACS 的缓存没刷新。添加仓库后需要等 HACS 重新拉取仓库信息网络慢的时候这一步会超时。表现是列表一直转圈或者显示空。处理方式是去 HACS 设置里清理缓存再重新加载或者干脆重启一次。三是版本标签不匹配。有些仓库的发布标签和 HACS 预期的不一致会提示没有可用的发布版本。这种情况改用下一种手动安装更省时间。装完并且重启之后正确的位置是设置 → 设备与服务 → 添加集成在里面能搜到对应名称。搜不到就是没装上别急着往下走。3.2 手动安装文件放对位置重启后仍然看不到怎么办手动安装的步骤很直白把仓库里的集成目录整个复制到 Home Assistant 配置目录下的custom_components文件夹里目录名保持和集成域名一致然后重启。# 进入配置目录路径按你的部署方式调整 cd /config/custom_components # 确认目录结构集成目录名必须与集成域名一致 ls -la | grep xiaomi # 重启服务以容器方式为例 docker restart homeassistant重启后仍然看不到集成按这个顺序查目录层级错了一层。常见错误是复制成了custom_components/xiaomi_home/xiaomi_home/manifest.json多套了一层目录。正确结构应该是custom_components/xiaomi_home/manifest.json也就是manifest.json直接位于集成目录下。缺少依赖文件。手动下载压缩包时有些工具会漏掉子目录或者.py之外的资源文件。检查集成目录下的文件数量和仓库对比一下。权限问题。文件属主不对Home Assistant 进程读不到。容器部署下尤其常见复制文件时用了宿主机的 root 权限。日志里有明确的报错。去设置 → 系统 → 日志里搜集成域名加载失败的原因通常会写得很清楚比如缺少某个 Python 包、版本不兼容等。提示手动安装后升级需要重新覆盖文件不建议和 HACS 安装混用同一个集成容易出现版本错乱。3.3 添加集成时的登录与设备勾选集成出现在列表里之后点添加会进入授权流程。这一步的交互通常是选择登录方式 → 在跳转页面完成授权 → 回到 Home Assistant → 选择地区 → 选择家庭 → 勾选设备。几个实操建议设备勾选不要一次全选。第一次添加时如果账号下有几十上百台设备全量拉取会让首次加载非常慢而且生成的实体多到无法管理。我的做法是先选一个房间或者一个品类比如先只接灯具和传感器跑通验证没问题再回来补充。授权页面跳转失败的处理。如果授权页打开是空白或者提示无法访问通常是主机的网络出口有问题或者浏览器拦截了跳转。换一个浏览器、或者在同一台机器的浏览器里操作成功率会高一些。添加完成后先别急着改名字。让集成把实体生成完等状态稳定下来再统一整理中途改名容易导致后续的实体 ID 混乱。3.4 实体命名与区域归属一次性整理好后面省几百次麻烦这一步是最枯燥但收益最大的。集成生成的实体entity_id往往是一长串自动拼音写自动化的时候要翻半天。我的整理顺序是这样的先归属区域。给每个实体指定所属区域房间这一步做完仪表盘和语音助手会自动按房间分组后面很多功能是白送的。再改显示名称。显示名称用人类能读的中文比如客厅主灯。最后固定 entity_id。在实体设置里手动把entity_id改成有语义的英文比如light.living_room_main。改完要立刻去检查已有的自动化有没有引用旧 ID。注意entity_id一旦确定就尽量不要再改。改一次要连带修所有引用它的自动化、脚本、仪表盘和模板成本很高。4. 打开本地控制从能用到好用的那一步设备接进来只是完成了第一步。默认走云端的情况下你的体验和直接用 App 差别不大只是多了个统一界面。真正让这套方案有价值的是把支持本地协议的设备切到本地模式。4.1 本地模式的开关在哪切了之后发生什么在集成的配置项里通常有一个使用本地控制之类的选项。打开它之后集成会尝试和设备直接建立连接连不上的设备会自动回落到云端所以打开这个选项本身不会让设备失联这一点可以放心。切换之后你会观察到的变化状态更新从每隔几秒拉一次变成设备一变就上报传感器的触发几乎实时。开关类设备的响应明显变快尤其是连续操作比如调亮度滑块时不会一顿一顿。断外网后已本地化的设备照常工作。日志里会多出连接相关的记录设备离线时会看到重连尝试。也有不那么美好的一面本地连接需要维持长连接设备数量多的时候主机内存和文件描述符占用会上升部分设备在本地模式下功能反而不全比如某些设备的云端特有功能只在云端模式下暴露。所以我的一般策略是传感器和灯具优先本地特殊功能设备保留云端。4.2 本地模式开不起来的自查清单这是被问得最多的问题。按下面这个顺序查八成能定位设备和主机是否在同一网段。在主机的终端里尝试访问设备的局域网地址先确认三层可达。设备是否支持本地协议。不是所有型号都支持。判断方法是看集成在设备详情里有没有本地连接的标识或者查设备的能力描述里是否有本地相关字段。老款 Wi-Fi 设备大概率不支持。设备是否在 App 里开启了局域网通信。有些设备在 App 的设备设置里有独立的开关默认可能是关闭的。这个开关不打开集成怎么试都连不上。是不是网关子设备。Zigbee 子设备本身没有 IP它的本地能力取决于网关。网关支持本地子设备才能本地网关不支持子设备只能走云端。路由器是否做了客户端隔离。前面提过这是隐形杀手。主机是否有多个网卡。多网卡环境下集成的连接可能从错误的网卡出去。可以在配置里指定使用的网络接口。排查的过程中日志是你的朋友。搜索设备标识或者集成域名看连接尝试是超时、被拒绝还是握手失败这三种情况指向完全不同的原因超时多半是网络不可达被拒绝多半是设备端没开放握手失败往往和协议版本或凭证有关。4.3 不同品类的本地能力差异这个差异比想象中大直接决定你的自动化设计。按经验大致是这样分布的品类本地支持情况说明灯具、开关、插座多数支持Wi-Fi 直连型号本地化收益最大温湿度、人体、门窗传感器视连接方式走网关的看网关能力Wi-Fi 直连的多数支持网关及其子设备取决于网关网关支持本地则子设备可本地摄像头多数不支持视频流基本依赖云端本地 RTSP 仅部分型号空调、窗帘等大家电部分支持型号差异大需要逐个验证扫地机等复杂设备多数不支持地图、任务等功能强依赖云端这份表不是绝对的同一品类不同批次都可能不一样。我的建议是不要先看表而是先把设备接进来打开本地控制然后在日志里看哪些设备建立了本地连接。用实际结果代替猜测比查资料快。5. 排查链路从搜不到设备到状态不同步真正折磨人的不是安装失败是那种看起来装好了但就是不工作的状态。下面这几条排查链路是我按实际遇到频率排的每条都给出从现象到根因的推演过程你可以照着走。5.1 集成装好了但设备列表是空的现象添加集成流程能走完授权也提示成功但设备清单为空或者只有零星几个。排查顺序第一步看地区选择。这是最高频的原因。地区和账号归属不一致时查询的是一个空的设备库。回到集成配置里检查地区设置。第二步看家庭选择。如果你的账号下有多个家庭而当前选的家庭里确实没有设备那结果当然是空的。在 App 里确认设备的家庭归属。第三步看账号本身。有些设备是共享给你的不是你自己账号下的设备。共享设备在授权拉取时通常不会返回需要用设备所属账号来授权。第四步看日志。授权成功但拉取失败的情况会留下记录比如返回数据解析异常、权限不足等。我遇到过一个比较隐蔽的情况账号在两台手机上登录其中一台长期未同步导致云端设备列表和本地不一致。重新在 App 里同步一次之后集成拉到的清单就正常了。所以如果前面几步都正常不妨在 App 里做一次手动刷新。5.2 实体生成了但一直是不可用现象设备列表里有设备实体也生成了但状态显示不可用点开关没反应。这条链路要分成云端模式不可用和本地模式不可用两种来查处理方式完全不同。云端模式下的不可用主要查三件事授权是否过期日志里会有鉴权失败、设备是否在线在 App 里看一眼如果 App 里也离线那就是设备本身的问题、服务是否正常这种情况通常是成批设备一起不可用不是单台。本地模式下的不可用重点查连接设备是否在同一个网段、局域网开关是否打开、IP 是否变了。最后这条特别值得说——很多设备走 DHCP 拿地址路由器重启后 IP 变了集成还连着旧地址自然不可用。解决办法是在路由器里给这些设备绑定静态地址一次配置长期省心。还有一种混合情况设备本身支持本地但集成没连上理论上应该回落到云端结果两边都不通。这种多半是回落逻辑没有触发把本地控制关掉再打开一次或者重启集成通常能恢复。5.3 状态延迟、自动化误触发现象灯能控制但状态更新慢或者自动化偶尔触发两次、偶尔不触发。先区分是设备上报慢还是集成处理慢。判断方法在 App 里操作设备同时看 Home Assistant 里实体状态变化的时间差。如果 App 里立刻就变了而 HA 里慢是集成侧的问题如果 App 里也慢那是设备或网络的问题。集成侧最常见的原因是仍在云端模式。云端模式的状态依赖轮询轮询间隔决定了延迟下限。切到本地模式延迟会立刻降下来。第二个原因是轮询频率被限制。设备数量多的时候云端接口有调用频率约束集成可能会自动降频。表现就是设备越多状态越不准。这种情况下把不重要的设备移出集成或者提高本地化比例都能缓解。自动化误触发则要往另一个方向想传感器的状态抖动。有些传感器在临界值附近会反复跳变比如光照传感器在某个照度阈值上下浮动导致自动化反复触发。解决办法是在自动化里加for持续时间条件或者用mode: single加冷却时间。automation: - alias: 玄关灯随人体感应开启 trigger: - platform: state entity_id: binary_sensor.entry_motion to: on for: 00:00:02 # 持续 2 秒才认为是真实触发过滤抖动 mode: single # 触发期间不重复执行 max_exceeded: silent action: - service: light.turn_on target: entity_id: light.entry_main这段配置里for是关键它把瞬时电平变化过滤成了稳定状态能挡掉大部分误触发。5.4 重启之后自动化全废了entity_id 漂移这是一个很典型的坑而且发生得很突然。现象系统重启或者重新加载集成之后之前写好的自动化全部失效日志提示找不到实体。打开实体列表一看entity_id后面多了_2、_3这样的后缀。原因在于集成的实体 ID 生成机制。当集成在启动时发现某个 ID 已经被占用会自动加后缀。什么情况下会被占用最典型的是设备在集成里重复添加了两次或者设备的显示名称被改了导致重新生成。处理步骤检查是否有重复的集成条目。同一个账号添加了两次就会出现两套实体。检查实体是否被手动重命名过。重命名会触发重新生成 ID。把不需要的那套实体删掉保留一套。给保留下来的实体手动设置固定的entity_id不再依赖自动生成。防患的做法很简单接入完成的当天就把关键实体的entity_id全部固定下来。这一步花二十分钟能省掉未来无数次的排查。我在第 3.4 节提过这件事这里再强调一次因为它是所有莫名其妙失效问题里最常见的一个。6. 把米家设备真正编进自动化体系设备接进来只是素材真正的价值在编排。这一节讲几个我认为收益最高的玩法。6.1 用模板实体补齐设备没有的能力米家设备提供的属性是设备视角的不一定是你自动化需要的场景视角。举个典型例子一个温湿度传感器提供温度和湿度两个数值但你的加湿器自动化真正关心的是体感是否干燥这需要把温度和湿度合成一个判断。这时候用模板就能补上template: - binary_sensor: - name: 室内偏干 unique_id: indoor_dry_flag state: {% set t states(sensor.indoor_temperature) | float(0) %} {% set h states(sensor.indoor_humidity) | float(0) %} {{ t 20 and h 40 }} availability: {{ states(sensor.indoor_temperature) not in [unknown,unavailable] and states(sensor.indoor_humidity) not in [unknown,unavailable] }}这里有两个细节值得说。第一数值转换要用float(0)带上默认值否则实体在不可用时会抛异常导致整个模板失效。第二一定要写availability让这个模板实体在源实体不可用时也标记为不可用而不是给出一个错误的false。这一点在实际使用中差别很大——错误的false会让你的自动化在数据缺失时做出错误决策。同样的思路可以用来做很多事情把电量低于 20%变成一个告警实体把某设备连续在线时长变成一个诊断实体把多个传感器的任意一个触发合成一个区域占用实体。6.2 网关子设备的联动编排要点走网关的传感器人体、门窗、按钮在自动化里使用时有几个和直连设备不一样的地方。触发要宽松一点。网关子设备的上报路径长了一环偶尔会有丢失。所以自动化里不要设计成必须收到两次触发才执行那是给自己找麻烦。相反重复触发是更常见的风险用前面说的mode: single加for来收敛就够了。离线要能识别。子设备掉线时父实体的状态可能仍然是最后一次上报的值看起来一切正常。建议给关键传感器加一个辅助检测连续 N 小时没有状态变化的传感器单独推送一条提醒。这个逻辑不复杂但能让你在设备真的没电之前就发现异常。按钮类设备的用法。很多网关配套的无线开关支持单击、双击、长按。这几种事件在实体上表现为状态值的变化而不是简单的开/关。用状态触发器配合具体的值来区分比用状态变化触发器可靠得多。6.3 数据留存把设备状态变成可回看的历史Home Assistant 默认只保留有限时长的历史数据且是状态变化记录不是连续的数值采样。想要过去一周的室内温度曲线这种视图需要额外的存储方案。我的做法是把关键的数值实体通过记录服务定期写入本地数据库然后再做可视化automation: - alias: 每小时记录室内环境数据 trigger: - platform: time_pattern minutes: 5 mode: single action: - service: recorder.record data: entity_id: - sensor.indoor_temperature - sensor.indoor_humidity这个配置控制的是记录策略具体落地还要结合你使用的数据库组件来配置。要点在于不要把所有实体都纳入长期记录。设备多的时候全量记录会让数据库迅速膨胀查询变慢最终拖垮整台主机的响应速度。只挑真正会回看的十几个实体就够了。7. 长期维护升级、备份与什么时候该退回去跑通一次不难难的是半年之后它还正常工作。这一节讲维护。7.1 升级前该先确认的三件事集成更新和系统更新都是风险点。我每次升级前会确认三件事第一看变更说明里有没有破坏性改动。特别是实体名称、配置项、授权方式的变化这三类改动一旦发生需要配套调整。只写优化性能的版本风险低写了重构设备模型的版本要留出时间验证。第二确认新版本对应的最低系统版本。系统版本太低会导致集成加载失败而且报错信息往往不直观容易误判成安装问题。第三先备份再升级。完整的备份应该包含配置目录和数据库。有备份在手升级出问题最坏的结果是回滚十分钟没有备份就是从头再来。升级之后不要只看能不能打开要实际触发几条关键自动化验证一遍。状态显示正常但自动化不执行是升级后最常见的隐性故障。7.2 授权失效、设备更换、家庭变更这三类维护场景这三件事在长期使用中一定会遇到提前知道怎么处理能避免慌乱。授权失效表现为所有云端模式设备同时不可用。处理方式是进入集成配置重新走一次授权不需要删除集成。重新授权后实体 ID 通常不会变但要确认一下有没有新增设备导致的重复。设备更换旧设备坏了换新型号可能不一样。不要直接删掉旧设备对应的实体先记下旧实体的entity_id接入新设备后把新实体的entity_id改成旧的这样所有自动化都不用改。这个小技巧能省掉大量排查工作。家庭或账号变更如果设备从 A 家庭搬到 B 家庭集成的设备清单需要重新拉取。这种情况下建议删掉集成重新添加比在原有条目上折腾更干净。7.3 出现什么信号时应该考虑退回去用云端本地化是目标不是信仰。出现下面这些情况我会果断把设备切回云端模式设备在本地模式下功能残缺比如某些设备的状态字段只在云端上报本地连接频繁断开又重连日志里持续刷错误主机资源紧张长连接占用的内存影响了其他服务设备固件更新后本地协议不兼容。判断标准很简单如果本地模式带来的麻烦超过了它省下的延迟那就退回去。我自己的配置里大概有七成设备走本地三成走云端这个比例是反复调整之后稳定下来的。追求 100% 本地化最后往往是花大量时间去维护一个并不稳定的系统性价比不高。最后分享一个我在实际操作中的体会这套接入的价值不在于把所有设备接进来而在于把你真正会用的那几十个实体整理干净。我见过太多把上百个实体全部接入、结果仪表盘乱七八糟、自动化写不下去的例子。真正的功夫花在接入之后的整理上——固定entity_id、归属区域、隐藏无用实体、给关键设备写好模板。把这些做完你会发现整套系统的可用度是另一回事。至于后续的扩展方向比较自然的一步是把区域和设备的层级关系理清楚之后用语音助手去做入口再往后可以考虑把设备状态同步到外部做长期分析但那是另一个话题了先把眼前这套跑稳更重要。