Home Assistant 2026.9 引入子设备：大型智能项目为什么要重做设备层级
在小型智能家居中，一个设备通常就是一个开关、一个传感器或一盏灯。但进入暖通、能源、门禁和楼宇自动化项目后，一个物理网关往往下面挂着几十个通道、房间、回路或逻辑单元。如果所有内容都被平铺成“设备”，管理界面很快就会失去结构。
Home Assistant 开发者文档在 2026 年 8 月公布了一系列设备注册表变化：2026.8 开始，一个设备只归属于单一 config entry；2026.9 引入 child devices，用更轻量的子设备表达父设备内部的逻辑部分。旧接口大多保留到 2027.8 或 2027.9，但现在已经进入迁移窗口。
为什么不再把多个集成合并成一个设备
过去，同一物理设备如果同时被多个集成识别，可能被合并到一个设备条目中。这看似整洁，却会产生信息归属不清：设备名称、型号、连接方式和配置来源可能互相冲突，用户也难以判断某个实体由哪个集成真正负责。
新的单一 config entry 归属，让每个设备拥有明确的管理者。不同集成可以通过链接关系协同，但不再共同“拥有”同一个设备。对项目运维来说，这更接近真实责任边界：出现故障时，可以迅速定位到具体网关、驱动或集成。
子设备适合表达什么
Child device 是父设备内部的轻量逻辑部分，不必拥有独立硬件、固件或序列号。典型场景包括：
- 多区域暖通网关下的各个房间或通道；
- 多回路电表下的分项计量；
- 音频矩阵中的左右声道或独立分区；
- 多端口控制器中的逻辑输出；
- 一个主机内部的多个可独立管理功能模块。
子设备通过 parent_device_id 指向父设备。如果没有独立区域，可以继承父设备所在区域。这让设备树既保持技术归属，也能适应实际空间管理。
自定义集成最需要检查的变化
直接操作设备注册表的自定义集成需要重点检查 via_device、config_entries、devices.get()、default_manufacturer、default_model 和 default_name 等旧用法。官方正在推动使用 via_device_id、单一 config_entry_id 和新的查找辅助函数。
另一个容易忽略的变化是：实体只有同时具备 config entry 和 unique id，才能可靠挂接设备。缺少这些条件时，当前版本可能只记录警告，但设备关联已经可能被丢弃；到 2027.8 后，部分情况会直接报错。
对项目交付意味着什么
大型项目不能只看升级后页面是否还能打开。升级前应导出设备、实体和集成清单，识别自定义组件，检查日志中的弃用警告，并在测试环境验证区域、设备页、自动化引用和历史数据是否仍然正确。
推荐把迁移分成四步：
- 盘点所有 HACS 和自研集成，锁定直接访问设备注册表的代码；
- 在测试实例升级，比较升级前后的设备数量、层级和实体归属；
- 更新自定义集成并补充设备创建、删除、迁移和父子关系测试；
- 准备可回滚备份，再安排生产窗口。
结构清晰比设备数量更重要
Home Assistant 的这轮调整看起来偏开发者，但最终改善的是业主和运维人员看到的设备世界。网关是网关，通道是通道，逻辑子系统可以被准确地放回父设备下面，故障责任和空间归属也更清楚。
对 R智能的项目来说，设备层级不是后台细节，而是系统能否交接、排障和扩展的基础。越复杂的建筑，越需要先把结构设计正确，再谈自动化数量。