常見問題
關於充電樁使用、平台維運、協議整合與業務合作的常見問題解答。如未找到答案，歡迎聯絡我們。
一、用戶端（APP 使用者）常見問題
APP 上顯示充電樁「空閒」，到了現場卻充不了電，怎麼回事？ ▾
這通常涉及狀態同步延遲或「軟故障」。OCPP 1.6 依賴 StatusNotification 上報連接器狀態，若網路抖動或心跳中斷，平台可能仍顯示舊狀態；OCPP 2.0.1 雖然透過 TransactionEvent 和更細粒度的監控改善了這一點，但若樁端檢測到故障（如急停按下、槍鎖故障）且未及時上報 NotifyEvent，APP 端仍可能誤判為可用。建議在 APP 詳情頁增加「最後一次狀態更新時間」提示。
為什麼掃碼後啟動很慢，有時候要等十幾秒？ ▾
啟動延遲通常發生在 Authorize 鑑權與 StartTransaction（1.6）或 TransactionEvent(Started)（2.0.1）的往返過程中。若平台與樁之間的 WebSocket 心跳不穩定，或樁端訊號弱，指令下發會重試。OCPP 1.6 的 StartTransaction 需要等待平台回傳事務 ID 才能閉合，而 2.0.1 的事件驅動模型理論上更快，但若樁端韌體對 TransactionEvent 處理不當，也可能造成卡頓。
充電中途停止，APP 顯示「充電中」，樁卻已經停了？ ▾
這是典型的狀態不同步。OCPP 1.6 下，若樁因過溫、漏電保護或槍被拔（但未正常發送 StopTransaction）而停止，平台可能因未收到 StatusNotification(Faulted/Available) 而維持充電中狀態。OCPP 2.0.1 的 TransactionEvent(Ended) 設計更嚴謹，但需要樁端正確實現。平台側可設定「心跳逾時自動結束本地訂單」的兜底邏輯。
同一個充電樁，為什麼有時候 APP 顯示支援即插即充，有時候不行？ ▾
即插即充（PnC/ISO 15118）是 OCPP 2.0.1 的原生能力，而 OCPP 1.6 不支援標準 PnC。如果平台接入了兩種協議的樁，APP 應根據樁的實際協議版本和配置動態展示功能標籤。若 2.0.1 樁的憑證鏈未正確配置，PnC 也會失效，此時 APP 應回退提示「請掃碼啟動」。
二、營運/維運端常見問題
平台上有些樁顯示離線，但現場看樁螢幕是亮的，怎麼排查？ ▾
按網路層→WebSocket 層→OCPP 層順序排查：①檢查樁是否能存取平台 wss:// 位址（DNS、防火牆、443 埠）；②檢查 Charge Point Identity 與 URL 路徑是否完全匹配（例如 /ocpp/CP001 中的 ID 大小寫或後綴錯誤）；③OCPP 1.6 查看 Heartbeat 是否正常，OCPP 2.0.1 查看 BootNotification 後的 Heartbeat 與安全事件日誌。若樁本地螢幕正常但 OCPP 離線，通常是樁端 OCPP 模組當機或 SIM 卡流量耗盡。
OCPP 1.6 和 2.0.1 的樁混用，平台需要做兩套對接邏輯嗎？ ▾
需要，但可抽象。兩者訊息不相容：1.6 用 StartTransaction/StopTransaction，2.0.1 用 TransactionEvent；1.6 配置靠 ChangeConfiguration 鍵值對，2.0.1 用結構化的 SetVariables/GetVariables 設備模型。建議平台在協議層之上建立統一「充電會話」模型，將兩種協議的訊息映射到同一業務物件，避免上層業務重複開發。
遠端重啟/遠端停充指令經常失敗，可能是什麼原因？ ▾
OCPP 1.6 的 RemoteStartTransaction 要求樁端在收到後先做本地鑑權（如 Authorize），若樁的本地白名單快取過期或 AuthorizeRemoteTxRequests 配置不當，會拒絕執行。OCPP 2.0.1 的 RequestStartTransaction 邏輯更嚴格，需要平台先確保 EVSE 和 Connector 的 AvailabilityState 為 Operative。此外，若 WebSocket 連線假死（TCP 通但應用層無響應），指令會逾時，需依賴 TriggerMessage 或心跳逾時檢測來重置連線。
韌體升級用 OCPP 1.6 還是 2.0.1 更可靠？ ▾
OCPP 2.0.1 的韌體管理更安全、可追溯。1.6 的 UpdateFirmware 通常是「下發 URL → 樁下載 → 樁重啟」，平台難以獲知下載進度和校驗結果；2.0.1 的 PublishFirmware 配合 UpdateFirmware 支援分塊下載、安全校驗和狀態上報，更適合大規模維運。若平台仍以 1.6 為主，建議升級流程中增加「升級後 BootNotification 校驗版本號」的步驟。
三、協議與技術整合常見問題
樁支援 OCPP 1.6，平台也支援，為什麼接上來還是失敗？ ▾
「支援 OCPP 1.6」不等於「即插即用」。常見斷點包括：WebSocket 位址格式（末尾斜線、路徑大小寫、是否用 wss）、Charge Point Identity 不匹配、訊息子協議未協商（ocpp1.6）、TLS 憑證不被樁信任（老舊韌體不認新 CA）。OCPP 2.0.1 還額外要求安全設定檔（Security Profile）匹配，若平台強制 TLS 而樁僅支援基礎認證，握手會直接失敗。
我的平台同時支援 1.6 和 2.0.1，一個樁能自動切換嗎？ ▾
不能自動切換。OCPP 版本在 WebSocket 交握階段透過子協議（如 ocpp1.6、ocpp2.0.1）確定，樁端韌體通常只實現其中一個版本。平台需要根據樁的 BootNotification 或連線 URL 中的標識來路由到對應的協議處理器。同一個物理樁無法在執行中從 1.6 「升級」到 2.0.1，除非更換韌體並重新配置。
OCPP 2.0.1 的「設備模型」對平台開發有什麼實際影響？ ▾
1.6 下，平台想知道樁支援什麼功能，往往靠 GetConfiguration 拉取一堆廠商自訂鍵；2.0.1 的設備模型用樹狀結構標準化了 EVSE → Connector → Component → Variable，平台可以精確讀寫某個槍的溫度閾值、某個繼電器的狀態。這對精細化維運和遠端診斷是質的提升，但要求平台後端重構配置管理模組，不能沿用 1.6 的扁平鍵值儲存。
智慧充電（負載均衡）在兩種協議下有什麼差異？ ▾
1.6 支援基礎的 SetChargingProfile（靜態或基於時間的簡單曲線），但缺乏電網協同和動態調整能力。2.0.1 的智慧充電更完整，支援 ChargingStationExternalConstraints、動態功率上限下發和多樁叢集調度，且與 ISO 15118 的 ChargeParameterDiscovery 可聯動。若場站要做「有序充電」或「需量控制」，2.0.1 樁是更好的選擇，但平台側的充電計畫引擎需要相應升級。
四、業務合作
如何與 LinkChargeHub 開展業務合作？ ▾
我們提供加盟合作、設備採購、場地營運與企業定制四種合作模式，覆蓋代理商、物業與地產商、車隊營運方等不同角色。提交合作意向告訴我們您的場地情況與合作意向，商務團隊將在 24 小時內與您聯繫，並提供方案測算與現場勘測支援；您也可以透過「聯絡我們」頁面直接發送郵件諮詢。