Home Assistant 藍牙常失聯？ESPHome Bluetooth Proxy 部署指南：選板、位置、斷線與驗收

感測值停在幾小時前、按下控制後沒有回應，或裝置拿到 Home Assistant 主機旁就恢復，確實都可能與藍牙接收位置有關；但電池、裝置整合、網路與節點供電也會製造相同表象。先買板、一次加很多節點，反而會讓故障責任更難追。

BLE 是 Bluetooth Low Energy，也就是低功耗藍牙。ESPHome Bluetooth Proxy 是 Home Assistant 可使用的遠端藍牙接收與連線端點：它在安裝處接觸 BLE，再經 Wi-Fi 或 Ethernet 的 IP 網路把資料與連線能力交給 Home Assistant。它只處理 BLE，不處理 Classic Bluetooth；也不是提高發射功率的 RF repeater，更不是節點間逐跳轉送的 BLE mesh。本文用「建立基線、只改一項、量測驗收」帶你判斷是否需要 Proxy，接著完成選板、擺位、安裝與回滾。

先用 3 分鐘決定：要移位置、加 Proxy，還是先查別處？

暫時移動後變好，只證明該位置值得繼續測，還不是永久安裝的證明。請先選一段符合裝置平常行為的觀察窗，並且一次只改一項條件。

第一步：先確認這是不是覆蓋問題

建立不動設定的基線

先記下目標裝置的最後更新時間、不可用時段、控制成功與失敗次數，以及 Home Assistant、Proxy 的重新啟動時間。感測器原本可能只在數值改變或固定週期時廣播，不能拿幾分鐘沒更新直接判定失聯；控制型裝置則要記錄實際操作，不只看儀表板是否仍顯示上次狀態。

把狀態拆成三層。第一層是 BLE 裝置本身，包括電池、休眠、配對與韌體；第二層是 Proxy，包括供電、記憶體、掃描及 API 連線；第三層是 Home Assistant 的 Bluetooth 與個別裝置整合。若 Proxy 先離線，先修電源或 IP 路徑；若只有一個裝置異常，先查它的整合需求。這個順序能避免把每次失聯都歸咎於訊號。

做一次可重複的 A/B 位置測試

A 點保留原狀，B 點只移動接收節點，或只把裝置移到較近處。不要同時換板、更新韌體、改路由器與換電池，否則結果無法歸因。租屋處可先用延長線建立短期測點；固定前至少跨過一個完整使用週期。技術支援人員則可把時間、位置、更新空窗及控制結果寫在同一張紀錄表，讓下一位接手者不必靠「偶爾會斷」猜測。

RSSI 可協助比較同一裝置在不同位置的相對變化，卻不適合設成全家的萬用及格線。封包方向、天線方向、人體移動與金屬反射都會改變瞬間讀值。真正要回答的是：預期資料有沒有按時到達、控制操作是否成功、節點本身是否保持在線。

圖中的路徑有兩段：BLE 裝置到接收端是無線空中介面；接收端到 Home Assistant 是 IP backhaul。多放一個 Proxy，是增加另一個接收與連線位置，不是在空中重播原封包。

第二步：分清被動廣播、主動掃描與主動連線

被動廣播：先看資料更新規律

BLE advertisement 是裝置送出的小筆廣告資料，附近多個 scanner 都能接收，不必先建立 GATT 連線。溫濕度、按鍵事件或狀態感測常使用這條路，但實際內容仍由 Home Assistant 的個別整合解碼；Proxy 本身不維護一份「所有支援裝置」清單。看到名稱、MAC 或 RSSI，只能證明聽見部分訊息，不能推論能解密、配對、控制或建立全部實體。

被動掃描是接收端只聽廣告，不另外送 scan request。主動掃描則會對可掃描廣告發出要求，以取得 scan response 裡的額外內容。這裡的「主動掃描」和下一段的「主動 GATT 連線」是不同開關。ESPHome tracker 預設會主動掃描；Home Assistant 的 Auto 模式可在平時被動接收，需要額外資訊時短暫切換。若為了省電固定改成被動掃描，必須先證明目標整合不依賴 scan response。

廣告資料不占 connection_slots，但這不代表容量無限，也不代表每筆必達。掃描負載、空中碰撞、網路、主機處理能力與裝置廣播策略都會影響結果。驗收應查看預定觀察窗內是否有異常空窗，以及異常發生時 Proxy 是否仍在線。

主動連線：控制成功率比「被發現」重要

需要讀寫 GATT characteristic、訂閱通知或下達命令的裝置，會要求 Proxy 建立雙向連線。這項能力由 bluetooth_proxy.active 控制；每個持續連線會占用一個槽，短連線則可能完成工作後釋放。ESPHome 2026.7.4 預設三槽，上限雖可更高，官方仍建議一般部署不要超過五槽；增加槽位也會增加記憶體壓力。

智慧鎖、燈具或其他控制裝置是否可用，仍取決於精確 Home Assistant 整合是否支援主動連線及故障移轉。廣告能被看見，不等於控制一定成功。同一裝置也可能以廣告回報狀態，操作時才建立 GATT。驗收時要安排連續操作與同時操作，不可只以設定頁中曾出現裝置作為通過證據。

第三步：替每個 Proxy 寫下責任

建立 Proxy—裝置—功能責任表

部署前先填表，而不是只數家裡有幾片板。被動廣播可能被多個接收端同時聽見；主動操作則受槽位、訊號、整合選路與當下連線負載影響。責任表讓你知道哪個節點失效時，會少哪些資料或控制。

長時間保持 GATT 的裝置要明確列出，並計入尖峰同時操作。Home Assistant 可彙整本機 adapter 與多個遠端 adapter，也可能依訊號與可用槽位選路；只有遵循其 Bluetooth 函式庫最佳實務的整合，才可期待完整的自動選路與故障移轉。因此責任表必須配合實測，不能把「有兩個接收端」直接寫成容錯已完成。

專用節點或兼任節點，依失效域決定

關鍵控制、持續通知或主動連線較多時，採專用 Proxy 能減少其他元件吃掉 RAM、CPU 或共同重啟的風險。若既有 ESPHome 節點只負擔少量感測、資源充足，也可評估兼任；但要以精確 YAML、板卡、framework 和版本完成設定驗證與觀察。Voice Assistant、音訊、web server 等較重元件不宜在未量測記憶體與重啟行為前一起塞入。

cache_services: true 可把 GATT service cache 放入 NVS，讓之後的主動連線更快。它不是歷史廣告佇列，也不是斷網後的補傳機制。Proxy 斷電、Wi-Fi 失聯、交換器中斷或 Home Assistant 重啟期間，短暫廣告可能錯過；ESPHome 官方沒有承諾所有資料會持久化後補送。自動化應容許資料缺口，必要時另做過期狀態告警。

第四步：位置、牆、金屬、2.4 GHz 與供電一起看

先找可長期維護的位置

接收端靠近目標裝置通常有利，但最近不一定最好。先看兩者之間是否有鋼筋混凝土、金屬門、電箱、家電外殼或鏡面背板；再檢查 PCB 天線周圍是否有淨空，避免把天線貼在金屬面或塞進未做 RF 驗證的金屬盒。板卡也不宜靠著路由器、交換器或機櫃。官方一般建議盡量與這類干擾源拉開，現場仍須靠 A/B 結果確認。

USB 3.x 連接埠與線材可能在 2.4 GHz 附近製造干擾。若接收端靠近主機，先用有屏蔽的延長線拉開，或改用可靠的 USB 2.0 供電位置。安裝高度與天線方向也值得固定後比較。不要追求看起來最隱蔽的位置，卻讓板子被大型家電遮住、散熱不良，或日後無法接線重刷。

供電要能長時間穩定，而不是手機充電一次成功就算通過。檢查電源器額定輸出、線材壓降、接頭鬆動與停電後復電行為。租屋可用可移除固定方式，並保留線路防拉扯；透天跨樓層應讓每個節點都可安全維修。固定配線、PoE 或配電箱附近施工，須採符合設備規格的供電器材與合格作法。

Wi-Fi 與 Ethernet 的角色差異

原版 ESP32 的 BLE 與 2.4 GHz Wi-Fi 共用射頻資源，以時間分配方式共存。Wi-Fi Proxy 因此要同時驗收 BLE 端與無線 backhaul；手機在同一位置測速快，不能證明節點會持續穩定。先把節點遠離 AP、USB 3.x 與金屬遮蔽，再比較候選點，通常比一開始調整掃描 interval 或 window 更容易歸因。官方也不建議任意把掃描參數調得激進，因為可能增加 CPU、網路流量與不穩定。

Ethernet 把 IP 回傳移出 ESP32 的 Wi-Fi radio，可減少同晶片上的射頻競用，ESPHome 也把它視為較佳的 Bluetooth 效能路徑。這仍不會改變 BLE 空中傳播：板載天線若被遮蔽，或裝置本身訊號弱，有線網路不會神奇修復。Ethernet 一般可評估四個主動槽，仍要以實際裝置壓力測試，不把一般建議當成每張板的保證。

第五步：依角色挑本站精確板卡

先看需求欄位，不按晶片新舊排名

晶片規格有 BLE，只代表硬體能力的一層；還要核對模組、整板、ESP-IDF、ESPHome 元件與 Home Assistant 整合。原版雙核 ESP32 搭 ESP-IDF 是官方範例的主路徑，記憶體使用也通常比 Arduino framework 有利。不要把更大的 Flash、PSRAM、較新的 Wi-Fi 名稱或外接天線直接包裝成接收距離保證。

兩個不同安裝角色

需要小型 Wi-Fi 節點時，可考慮 FireBeetle 2 ESP32-E 小型 Wi-Fi Bluetooth Proxy 開發板（Product 51907，約 NT$410）。其 ESP32-WROOM-32E 可使用下方 variant: esp32 與 ESP-IDF 路徑，Micro-USB 可燒錄及供電；要準備能傳資料的線。板上的單節鋰電池介面可作特定備援設計，但固定 Proxy 仍應以穩定連續電源為主，不能把小電池當作長期唯一電源。

若安裝點已有網路線，可選 WT32-ETH01 有線 ESPHome Bluetooth Proxy 模組（Product 56328，約 NT$490）。它以 LAN8720A 與 RJ45 承接 Ethernet，但板上沒有 USB 插座；首次燒錄須另備 3.3 V USB-UART，TX/RX 交叉並依下載模式操作 IO0。5 V 或 3.3 V 供電只能擇一，供電能力至少 500 mA，且板卡 revision 必須能對上精確 pin map。

上述價格於 2026-08-10 核實；促銷、庫存與可購買狀態可能變動，採購時請回商品頁確認。板價也不是完整部署成本，仍需計入資料線、電源、燒錄器、網路線、外殼與固定材料。商店欄位只能證明商品身分與當時價格，ESPHome 支援則應由官方文件及鎖定版本的設定驗證建立。

第六步：用可回滾流程安裝

安裝前保存，桌面先跑通

先保存現有 YAML、secrets 引用方式、成功韌體、Home Assistant 與 ESPHome 版本。記錄精確板卡、節點名稱、MAC、原始安裝點與基線。新 Proxy 使用唯一名稱，不直接覆寫仍正常工作的節點；原接收路徑至少保留到新節點走完觀察窗。

第一次加入 esp32_ble_tracker 可能需要調整分割區，官方要求先以 USB 完成初刷，再使用 OTA。桌面流程應依序確認供電、編譯、實體燒錄、網路取得位址、Native API 加密、Home Assistant 採用與測試裝置可見。確認這些層都正常後，才移到候選位置。每次只改位置、供電、backhaul 或韌體其中一項。

Native API 的 Noise PSK 與 Wi-Fi WPA 密碼屬於不同安全層。下列範例把 API key、Wi-Fi 及 OTA 密碼都放在 secrets.yaml；請用各部署的強隨機值，不要把真實憑證提交到版本庫。OTA 會啟用 safe mode；多次啟動失敗後，節點可能只保留網路、序列日誌與 OTA 以便救援，此時節點重新上線不代表 Bluetooth Proxy 功能已恢復。

網路面也要納入責任表。Native API 預設使用 TCP 6053，管理網段與防火牆只需開放 Home Assistant、維護主機與必要節點之間的路徑，不必把裝置直接暴露到外網。若使用 DHCP，至少在路由器保留租約或以清楚主機名稱辨識；如果交換器 VLAN、無線用戶隔離或防火牆政策會阻擋雙向連線，應先在桌面環境驗證，再搬到正式網段。節點顯示已連上 Wi-Fi，不代表 API 路徑必然可達。

升級也採單一變更原則。先選一個非關鍵節點，記錄升級前的廣告更新、主動控制、可用記憶體與重啟狀態，再更新 ESPHome 或 Home Assistant 其中一邊。通過原本觀察窗後，才推到其他節點。遠端 package 若沒有鎖定審查過的版本，日後重新編譯可能引入上游變更；正式部署應保存當時可重建的設定與版本，而不是只留裝置目前還能運作的印象。

Wi-Fi 版本：原版 ESP32 與 ESP-IDF

active: true 允許 GATT 主動連線，不等於強制 tracker 永遠主動掃描。三槽是此版本的保守起點；先以責任表及壓力測試確認需求，再評估是否調整。

Ethernet 版本：WT32-ETH01 精確 pin map

這份設定不可再同時加入 wifi:。GPIO0 在設定檢查時會出現 strapping pin 警告；此處是該板 Ethernet 外部時脈的已知用途，不代表可忽略實體板級差異，也不要自行外加不明的上下拉。若模組版本、時脈或 PHY 線路無法核對，就停下來查資料，不猜 pin。

兩個程式碼區塊是從本文最終 Markdown 精確抽取，並以 ghcr.io/esphome/esphome:2026.7.4 執行 esphome config。兩份皆通過設定與 schema 檢查；這不等於已完成編譯、燒錄、供電、RF 或特定裝置的實機測試。

先寫好回滾條件

若新節點造成原裝置更不穩、Proxy 頻繁重啟、網路中斷或控制成功率下降，先回到上一份已知良好設定與位置。不要在第一晚移除原 adapter。技術交接至少要有韌體版本、YAML、安裝位置、責任表、驗收資料及可用的實體序列救援方式；若遠端 OTA 失敗，仍能接回桌面處理。

第七步：照責任鏈排錯，再按順序驗收

排錯順序不可倒過來

1. BLE 裝置：檢查電池、裝置狀態、廣播規律、主動需求與精確整合。
2. Proxy：檢查在線時間、重啟原因、記憶體、日誌及主動連線占用。
3. Backhaul：檢查 Wi-Fi 或 Ethernet、DHCP、封包遺失及網路設備變更。
4. Home Assistant：檢查 Bluetooth、ESPHome integration、diagnostics、事件時間與版本變更。
5. RF 與位置：最後回查牆、金屬、AP、USB 3.x、天線方向及 A/B 測點。

Home Assistant 的 Bluetooth 設定可查看 Adapters、Connections、Advertisements 與路徑資訊。先確認是哪一層、哪個時間點開始出錯，再動設定。若最佳訊號落在表現較差的舊 adapter，可能拖慢整體主動操作；停用或移除前仍要完成對照測試，避免把唯一可用的備援一起關掉。

驗收順序：資料、控制、節點、故障、回滾

測試故障時要有順序。先確認正常觀察窗，再斷一台 Proxy，觀察其他接收端是否真的覆蓋目標；接著分別測試關閉 AP 或拔網線、重新啟動 Home Assistant、讓一個長連線裝置占槽，以及同時操作多個 GATT 裝置。斷網與重啟期間的廣告缺口要如實記錄，不假設復線後會補傳。若自動化依賴即時事件，應另外設計逾時與安全狀態。

觀察窗要依裝置用途設定。定期環境資料可對照原本的廣播與整合更新規律，門鎖或燈具則應涵蓋早晚常用時段與連續操作。記錄時同時保存時間戳、實際動作、介面結果及相關日誌，避免只截一張顯示「可用」的畫面。若改善只出現在某個時段，還要比對 AP 流量、家電運轉與人員移動，不急著宣告完成。

完成正常測試後，再安排可控的故障注入。拔線或斷電前先告知使用者，避開門禁、照明或照護等高風險時段，並備妥恢復步驟。測試結束要確認每個裝置回到預期路徑、長連線槽已釋放、節點沒有進入重啟循環。若實際影響超出責任表，就更新表格與回滾條件，而不是把差異留給下一次故障才發現。

部署驗收清單

• [ ] 已用 A/B 測試證明問題與位置或覆蓋相關。
• [ ] 已確認每個目標裝置使用被動廣播、主動掃描所需資料、主動 GATT 連線，或兼具數種需求。
• [ ] 已填寫 Proxy—裝置—功能責任表及單點故障影響。
• [ ] 已核對精確板卡、模組版本、天線、供電與 backhaul。
• [ ] 已保存原設定、版本、成功韌體與實體回滾方法。
• [ ] 已先完成桌面最小安裝，再移到候選位置。
• [ ] 已一次只改一個變因，並保留相同觀察窗的基線。
• [ ] 已檢查牆、金屬、2.4 GHz 共存、天線淨空、供電及維修可達性。
• [ ] 被動更新、主動控制、Proxy 在線與網路穩定皆達到事前門檻。
• [ ] 已測試 Home Assistant、Proxy 及網路重啟後的恢復方式。
• [ ] 已測試一個接收端失效，並確認資料不保證補傳。
• [ ] 租屋部署可無痕移除；固定配線與 PoE 採符合規格的設備及安全施工。
• [ ] 技術交接包含設定、版本、位置圖、責任表、驗收數據與回滾檔。

先完成快速決策表，再做一個不改其他條件的 A/B 測點。證明失聯確實與接收位置相關後，才依通訊責任、供電與網路條件選板；最後以相同觀察窗和故障測試證明改善。這樣新增的不是一片「看似在線」的板子，而是一個責任清楚、可量測也可撤回的 BLE 端點。