一、 韌體端（ESP32/BMS）透傳與 UUID 規劃
1. 現況與可行性
- 技術可行性：韌體端實現藍牙透傳（Transparent Gateway）技術路徑明確，難度不高。
- UUID 規劃：目前測試階段先採用暫定 UUID，待整體通訊鏈路（連線、握手、訂閱、動態解析）完整測試成功後，再行統一規範與定義生產線標準 UUID。
2. 核心注意與改善項目（共 3 項）
-
建立數據區塊化（Block-based Partitioning）規範：目前的點位表結構較為發散且存在跳號斷層。建議重新規劃 Modbus 暫存器地址地圖，將數據依功能屬性進行分區規劃（如：0x0000-0x0010 為即時監控區、0x0020-0x0030 為系統狀態與告警區、0x0040-0x0050 為統計與參數區）。
- 改善目的：避免不同類型數據（如：變動劇烈的電壓電流與靜態的系統狀態）混雜在同一個讀取區塊。透過區塊化設計，軟體端可以針對不同頻率的需求進行「精準分區讀取」，不僅能解決記憶體對齊問題，更能顯著降低藍牙通訊的頻寬負載與封包解析難度。
-
Notify 觸發邏輯收斂（主動上報 vs 被動輪詢）： 現行架構的
Notify特徵值並非「設備狀態一改變就主動推播」，而是「App 發送 Read 命令後，設備才將回覆塞進 Notify 吐回」。這本質上是假 Notify（實際為輪詢）**。- 行動方針：需團隊集體討論，此邏輯是否符合 EMS 監控系統需求？若只需被動查詢，可考慮直接將特徵值修剪為純 GATT Read；若需要告警（Alarm）即時性，則應修正韌體，讓保護狀態觸發時能「主動 Notify」。
-
導入 JSON Spec 協定驅動開發： 強烈建議軟韌體雙方以 JSON 點位表作為唯一真理源（Single Source of Truth）。軟體端不硬編碼（Hardcode）暫存器數量，而是讀取 JSON 動態計算
registerCount與解析 Byte 位移，此舉能大幅縮短雙方 Debug 與後續抽換 BMS 型號的開發時程。
二、 軟體端（App / PC）詢問與接收邏輯規劃
1. 現況與可行性
- 跨平台開發：軟體端無論是在 PC 或行動端開發皆無技術瓶頸。
- 設備安全性過濾：未來將於連線初始階段，增加審核設備廣播或服務 UUID 的機制，藉此判定是否為本公司自有產品，過濾雜訊。
2. 核心注意與改善項目（共 1 項）
- 跨平台環境的 MTU 截斷與動態分包機制： 各主流作業系統對藍牙單次接收極限（GATT MTU）硬體限制不同（Windows 可達 525 Bytes、Android 可達 517 Bytes，但 iOS 有 185 Bytes 的鐵壁限制，實際可用僅 182 Bytes）。若 BMS 數據量膨脹，極易在 iOS 端發生封包截斷或黏包。
- 解決方案：得益於我們採用 Modbus 結構，軟體端具備極佳的操控彈性。我們可以根據執行環境自動或手動調整詢問長度（Register Count）。例如在 iOS 端，將單次讀取拆分為「每 10 個暫存器一組」分批詢問，確保單包回覆永遠控制在 182 Bytes 以內，從根本上規避底層分包組裝的複雜度。