1. 資料輪詢機制：是否需要自動 Polling？
測試數據對比（最佳狀態）
| 輪詢方式 | 響應時間 (Response Time) | 適合場景 |
|---|---|---|
| 主機端主動發送單命令 (Master Request) | 200 ~ 500 ms | 高即時性需求 |
| MCU 端自動 Polling 並 Notify | 900 ~ 1000 ms | 低即時性、節省主機效能 |
- 0616早上測試，如把藍芽拉到外面可以更快。
建議
- 根據實際測試結果，主機端自行發送單命令的響應速度明顯優於 MCU 端 Notify（快約 2 至 5 倍）。
- 如設備不同藍芽端不能根據設備接收量降低，會導致15kW等多櫃設備數據截斷，實務上不好達成。
- 若系統對即時性（Real-time）有要求，建議採用由主機端自行發送（Active Polling）的架構。
2. JSON 資料格式通訊協定討論
命令發送與暫存器定義方案
為了提高寫入效率與前端視覺化元件的整合度，目前規劃的可行方案如下：
- 暫存器分類優化：將 JSON 內的暫存器（Registers）明確區分為
Holding Registers（唯讀/保持）與Write Registers（可寫），以利於進行精準的寫入控制。 - 資料型態擴充：
- 在欄位屬性中加入
Boolean型態。 - 前端可直接解析此布林值，自動生成對應的控制按鈕（Button/Switch），簡化 UI 渲染邏輯。
- 在欄位屬性中加入
- 多樣化支援：此處根據實際討論實際實驗後，補充不同設備或不同通訊協定的欄位差異
待討論事項： 針對不同設備其 JSON 階層結構該如何統一定義？
3. Wi-Fi 命令是否全權交給 MCU
- 議題：Wi-Fi 相關的設備連網、斷網、重置網路設定與資料封包處理命令，是否全權交由 MCU 端處理？
- 決議：交由阿傑詳細解釋與說明。
4. Modbus格式其實不適合Notify
- 重點問題：如果想做變動時就即時推播的格式，那Modbus的回覆格式相當不適合需另外定義型態。
- 決議：後續討論是否有需要或只需要輪播
- 03 xx xx [DATA…] CRC CRC
- 06 xx xx [DATA…] CRC CRC
5. 額外討論
- 重點：格式變動 藍芽格式探討