「這台機器有沒有辦法把資料拉出來？廠商說要另外買他們的雲端方案。」
這句話我們聽過太多次了。太陽能逆變器、產線設備、環境感測器、電表 —— 買的時候是你的，資料卻在廠商的 App 裡。想接進自己的系統做分析、告警、報表，答案往往是「要加購」。
這篇講一個我們自己跑完的實例：把一台沒有任何文件的太陽能逆變器逆向出來，讓發電、儲能、電芯、電表四種設備的資料，全部進到我們自己的資料庫。
重點不在太陽能。重點在方法可以複製。
一、先確認：協定看起來標準，其實不標準 #
設備規格書寫著「支援 Modbus TCP」。實際接上去，標準的 Modbus TCP 函式庫卻讀不到東西。
原因是它跑的是 Modbus RTU over TCP —— 資料內容是 RTU 格式（尾端帶 CRC16 校驗），只是用 TCP 當通道送出去。跟標準 Modbus TCP 的差別在封包開頭：標準 TCP 版有一段 MBAP header 且不帶 CRC，RTU-over-TCP 沒有 header、必須自己算 CRC16。
差這一段，現成函式庫就完全對不上。
這類「看起來標準、其實有自己習慣」的情況非常普遍。 判斷方式很直接：抓一包實際流量下來，看開頭有沒有 header、尾端有沒有校驗碼，兩三包就能認出來。
二、寄存器沒有文件，就用面板當答案卷 #
協定通了，接著是更繁瑣的一步：哪個寄存器代表什麼？
沒有文件的情況下，設備自己的操作面板就是最好的對照表。做法很土但有效：
- 把一段連續的寄存器全部讀回來
- 對照面板上當下顯示的數值（發電功率、電池電壓、溫度、市電狀態）
- 找出數值吻合的位址，記下來
- 改變設備狀態（例如讓它切換到市電），看哪些位址跟著變
逐一比對之後，發電、負載、電池電壓電流、溫度、充放電狀態、市電切換狀態全部對應出來了。
還要注意倍率。這台機器的電壓類寄存器倍率是 0.1V，而且是以單顆電池模組為單位回報 —— 48V 系統要再乘以 4 才是整組電壓。沒發現這件事，讀出來的數字會全部小一截，而且看起來還很合理，這種錯最難抓。
三、最意外的一關：廠家鎖死了一組沒人告訴你的規則 #
讀出來只是一半，我們還要能寫回去（調整充電上限、市電切換點這些參數）。
結果一寫就被設備拒絕，回一個 Illegal Data Value。值明明在合理範圍內。
實測推導之後才發現：廠家在韌體裡鎖死了各參數之間的相對關係，例如——
低電壓警告值 必須嚴格大於 市電切換電壓
過放保護值 必須小於等於 市電切換電壓
逆變回切電壓 必須高於市電切換電壓一段差距（避免來回抖動）
也就是說，要調高市電切換點，得先調高低電壓警告值；順序反了就寫不進去。而且這個限制不只擋 Modbus 寫入，連在設備面板上手動改也一樣卡住。
這種規則不會出現在任何文件裡。它是廠商為了防止使用者把電池設定成互相矛盾的狀態而做的保護 —— 立意是好的，但沒有文件，就只能靠「改一個值、被拒絕、換順序再試」逼出來。
實務建議：遇到寫入被拒，先假設不是你的值錯，而是你動的順序錯。 把相關參數全部讀出來排一排，通常就會看出被鎖住的相對關係。
四、資料拿到之後，真正的工程才開始 #
很多人以為打通協定就結束了。其實資料進來之後，才是判斷準不準的問題。
這台逆變器自己回報的電池 SOC（電量百分比）是錯的。 直接拿來用，決策全部會歪。
我們的處理方式是建立一個單一真理來源：不信設備回報的百分比，改用實際的邊界電壓回推 ——
- 逆變器自動切換到市電的那個電壓 = 使用者感受上的 0%
- 充電上限電壓 = 100%
- 中間依實際可用電量換算
過程中我們也用過幾個「想當然耳」的換算公式，結果多算了 5%。5% 聽起來不多，但它會讓你在電池其實快沒電的時候以為還有餘裕。
最後定案的做法有兩個重點：
- 自動校準 —— 每當系統偵測到一次完整的充放電循環，就用實際數據回推可用容量，取代預設值。電池會老化，寫死的容量遲早失真。
- 前後端共用同一份換算邏輯 —— 後端 Python 與前端 TypeScript 各有一份實作，但公式與邊界值必須一致。同一顆電池在儀表板和在告警邏輯裡不能是兩個數字，這種不一致的 bug 極難追。
五、看電芯，不要只看總電壓 #
整組電池電壓正常，不代表電池健康。
接上 BMS 之後，我們讀的是每一顆電芯的電壓，真正在盯的指標是同一組電池裡最高與最低電芯的壓差。壓差開始擴大，是電池失衡與老化的早期訊號 —— 比等到總電壓掉下來才發現，早非常多。
這是「有資料」和「有洞察」的差別。總電壓是設備願意給你的數字，電芯壓差是你把資料拿回來之後才能自己算出來的東西。
六、同一套工法，不只用在太陽能 #
把這個案子抽象一層，流程是這樣：
| 步驟 | 做什麼 | 通用性 |
|---|---|---|
| 1 | 抓封包，判斷實際協定變體 | 任何工業設備 |
| 2 | 用設備面板反推寄存器對應 | 任何有顯示面板的設備 |
| 3 | 實測逼出廠商的隱藏限制 | 任何可寫入參數的設備 |
| 4 | 建立單一真理來源與自動校準 | 任何會隨時間漂移的量測 |
| 5 | 從原始資料算出設備不給的洞察 | 任何監控場景 |
工廠的產線設備、機房的環境監控、智慧建築的空調與電力 —— 遇到的是同一組問題：設備是你的，資料卻不是。
我們在自家機房把這套跑通了（3Q 的伺服器就靠太陽能加電池供電，做不好第一個受害的是自己）。設備換一種，前面兩步要重做，後面三步的工法完全一樣。
需要把設備資料解放出來嗎 #
如果你手上有這些情況：
- 設備資料被鎖在廠商 App 或雲端，要匯出得另外付費
- 多套設備各有各的介面，沒辦法放在一起看
- 想做告警、趨勢分析、自動控制，但拿不到原始資料
- 廠商已經不提供支援，或系統老到沒人維護
這些都是可以處理的。先確認能不能讀，再談要做多大 —— 通常花半天做可行性確認，就能知道整件事值不值得投入。
歡迎直接跟我們說你手上是什麼設備、卡在哪一段。