自架 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 位數的配對碼，也會顯示一個 QR code。用 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 的既有裝置」這個範圍，而不是所有智慧家庭流量的必經之路。