自建 Home Assistant 最常见的下一步需求之一,是让它管理的设备也能被 Siri 语音控制、出现在 iPhone 的”家庭”App 里,或是被 HomePod、Apple TV 当成自动化条件使用。做法是 Home Assistant 内置的 HomeKit Bridge 集成,让它伪装成一台 HomeKit 桥接器,把选定的实体(entity)逐一暴露给 Apple 的 HomeKit 生态系统。
1. 先分清楚方向:Bridge 不是 Controller
Home Assistant 官方文档特别提醒过一个最常见的混淆:HomeKit Bridge(homekit 集成)跟 HomeKit Controller(homekit_controller 集成)做的是完全相反的事,名字又长得几乎一样。HomeKit Controller 是把”原生支持 HomeKit(Works with HomeKit)“的第三方设备接进 Home Assistant,让 HA 可以控制那些设备;HomeKit Bridge 则是反过来,把 HA 里的实体暴露出去,让 Apple Home 和 Siri 可以控制它们。这篇文章要配置的是后者:让自建的设备对 Apple 生态系统可见,而不是把 Apple 设备接进 Home Assistant。两个集成可以同时安装,但功能完全不重叠,装反方向不会报错,只会让人以为”配置了却没作用”。
2. 启用 HomeKit Bridge
在 Home Assistant 的”设置 → 设备与服务 → 添加集成”搜索 HomeKit,选择要暴露的实体域(例如 light、switch、climate)或个别实体,完成后 Home Assistant 会生成一组 8 位数的配对码,也会显示一个二维码。用 iPhone 内置的”家庭”App 扫描或手动输入配对码,就能把这个 bridge 加入家庭。加入后,Apple Home 看到的不是”Home Assistant”,而是一台名称可以自定义的桥接器,底下挂着每一个被暴露出来的实体。
3. Docker 部署下的 mDNS 陷阱
HomeKit 依赖 mDNS(Bonjour)在局域网内广播自己,Apple 设备才找得到这座桥。Docker 默认的 bridge 网络模式会挡掉 mDNS 需要的 UDP 5353 多播包,这代表如果 Home Assistant 是用一般的 docker run(没有额外处理网络模式)跑起来,Apple 设备很可能完全发现不了这台桥接器,或者配对后很快就显示”找不到”。
最直接的解法是把容器改成 network_mode: host,让 Home Assistant 直接共用主机的网络接口,mDNS 广播自然就能送到局域网其他设备。如果因为其他服务的端口号冲突,或部署环境本身不允许 host networking,退而求其次的做法是在 HomeKit 集成配置里指定 advertise_ip 为主机的固定局域网地址,并在主机上另外跑一个 mDNS 反射器(例如以 reflector 模式运行的 avahi-daemon),把容器内的广播转发到实体网络上。如果是用 Home Assistant OS(HAOS)以虚拟机或实体机安装,则默认就有完整的主机网络访问权限,不会遇到这个问题,这也是官方文档建议跑 HomeKit Bridge 时优先考虑 HAOS 的原因。
4. 150 个设备的上限
每一座 HomeKit 桥接器最多只能挂 150 个配件(accessory)。设备数量不多时感觉不出来,但如果打算把整个智能家居——每一盏灯、每一个开关、每一个传感器——全部暴露出去,很容易超过这个上限。做法是先筛选真正需要被 Siri 或 Apple Home 控制的实体(用集成配置里的域/实体过滤器排除不需要的),如果筛选后仍然超过 150 个,就需要创建第二个 HomeKit Bridge 集成实例,把设备分配到不同的桥接器,各自独立配对进 Apple Home。
5. Matter 出现后,这座桥还有多少必要性
近年 Apple Home 已经直接支持 Matter 协议,Home Assistant 也有自己的 Matter Server 集成。如果设备本身是 Matter 原生的,可以直接配对进 Apple Home(或其他支持 Matter 的生态系统),完全不需要通过 Home Assistant 的 HomeKit Bridge 转一手。HomeKit Bridge 真正还有价值的场景,是设备不支持 Matter、也没有原生 HomeKit 支持,但已经被 Home Assistant 通过其他方式(Zigbee、Z-Wave、厂商云端 API 等)集成进来的情况——这时候 HomeKit Bridge 仍然是让这些设备对 Apple 生态系统可见的唯一桥梁。换句话说,设备本身的协议支持情况决定了该不该用这座桥,而不是”能用就用”。
6. 小结
HomeKit Bridge 和 HomeKit Controller 方向相反,先确认自己要的是哪一个,是避免白忙一场的第一步。Docker 部署时 mDNS 常常是唯一卡关的地方,host networking 或 avahi 反射器是两条可行路径;HAOS 部署则通常不会遇到这个问题。设备数量逼近 150 个上限时,筛选实体或拆成多个桥接器都比放着不管更务实。Matter 的普及也代表这座桥的角色会逐渐收敛到”不支持 Matter 的既有设备”这个范围,而不是所有智能家居流量的必经之路。