太陽能維運監測告警流

🎯 這條流程解決什麼

太陽能電廠最怕的不是颱風，而是「默默漏發電」。模組表面積了一層灰、某一串接頭氧化接觸不良、逆變器某個 MPPT 通道掉線、甚至草長太高遮住下排模組，這些狀況不會跳出警報，發電量只是悄悄少了 5% 到 20%。對一座 500kW 的屋頂案場來說，少發 10% 大約等於每天損失三、四百度電，以躉購費率換算一個月就是上萬元蒸發，而且發現得越晚、累積損失越大。

問題在於人工巡檢根本追不上案場數量。一家中型維運商手上動輒管理三、五十個案場，維運人員每天早上要逐一登入監測平台、把每個案場的發電曲線點開、和昨天比、和隔壁同型案場比、再憑經驗判斷哪個「怪怪的」。光是把所有案場看過一輪就要兩到三小時，而且人眼很難在密密麻麻的曲線裡抓出「衰退 8%」這種不明顯的訊號。多數團隊的真實情況是：等到客戶看到自家後台發現整月少發很多打電話來抱怨，才知道某串故障已經拖了三個禮拜。這段「故障到發現」的空窗期，就是純人工監測最貴的成本。

導入後的改變

導入前，維運靠「人記得去看」，每天耗掉一名工程師兩到三小時做重複的看圖工作，故障平均要三到十四天才被發現，發電損失難以追回，客戶月底才收到一份手工貼圖的報表、信任度也低。

導入後，系統每天（或每小時）自動把所有案場的數據拉一遍，AI 用同一套標準同時比對幾十個案場，幾分鐘內就把「今天哪幾個案場異常、嚴重程度排序」整理好推到維運群組。合理估算下，每日人工巡檢時間可從兩三小時壓到二、三十分鐘的重點複核，省下約八成的看圖工時；故障發現時間從以週為單位縮短到當天或隔天，把可追回的發電損失大幅拉高。對維運商而言，這不只是省人力，更是把「漏發電」這個隱形破口堵住，直接反映在每月結算的發電收益與合約 KPI 達成率上。客戶每月自動收到專業報表，續約與口碑也跟著穩。

流程怎麼運作

第一步「定時擷取」對應觸發節點：依排程（建議發電時段每小時、或每日清晨彙整前一日全天）呼叫各監測平台 API，把每個案場的逆變器發電量、各串電壓電流、即時功率與在線狀態拉回來，統一寫進 Google Sheet 當資料中台。

第二步「比對預期值」：系統先取得當地當日的日照／PR（系統表現比）基準，再用每個案場的裝置容量推算「這個天氣下應該發多少」，和實際發電量相減算出落差百分比。同時也做案場橫向比較——同一片雲下、規格相近的鄰近案場若大家都掉、那是天氣；若只有一個掉、那就是設備問題。

第三步「AI 判斷異常」對應 AI 節點：把落差數據、各串表現與歷史趨勢餵給 AI，讓它辨識異常型態並給初判——是「整場持續緩降」（多半是模組髒污或老化）、「單一串突然歸零」（接頭或保險絲）、「某逆變器離線」（通訊或硬體故障），還是「下午特定時段掉電」（局部遮蔭）。AI 同時依損失大小排優先序。

第四步「自動開工單」：對判定異常的案場生成維運工單，自動帶入案場名稱、異常型態、初判原因、預估日損失與建議檢查項目，推進工單系統並指派區域維運人員。第五步「告警與報表」：即時把高優先告警用 LINE／Email 通知維運人員與該案場客戶，並在每月初自動彙整各案場發電量、PR 值、異常事件與處理紀錄產出月報。

需要的工具與串接重點

平台用 n8n 或 Make 當排程與串接中樞。監測平台 API 是資料源頭，注意各家逆變器廠牌（SMA、Huawei、SolarEdge、Goodwe 等）的 API 格式與權杖刷新機制不同，建議在 n8n 裡每個廠牌包一個子流程統一輸出欄位。Google Sheet 當輕量資料庫存歷史基準與當日數據，案場多時可改接資料庫。AI 異常偵測節點負責型態判讀與優先排序，提示詞裡要明確界定各類異常的判準與「只做初判、不下維修結論」。工單系統與 LINE／Email 負責把結果落地成行動。串接重點：API 拉取要做失敗重試與漏抓補拉，避免某次斷線就漏掉一天數據；告警要設「同一案場同一問題去重」，否則每小時都重複告警會讓人麻痺而忽略真正的新事件。

常見錯誤與注意事項

最關鍵的一點：AI 告警只負責篩選與排序，絕不取代現場專業診斷。發電異常成因複雜，實際的故障定位、登頂檢修、開啟匯流箱與任何帶電作業，務必由具備電匠或相關證照的維運技師到場處理，嚴禁未受訓人員自行排除電氣故障，否則有觸電、墜落與火災風險。其次，門檻別設太敏感，把每天的天氣波動都當異常會製造大量假警報、反而讓團隊失去信任。客戶案場的發電數據屬於商業資訊與個資範疇，Google Sheet 與報表須限定權限存取、不可外流。月報中的數據以監測平台為準，若涉及躉購結算金額，仍須以台電正式計量為依據，AI 彙整不取代正式帳務。

台灣中小企業情境案例

台南一家做屋頂租賃與維運的能源公司，手上管理約四十個工商屋頂案場，總裝置容量近 6MW。導入前兩名工程師每天早上輪流看後台，常常忙到中午還沒看完，去年有一個案場的兩串模組接頭氧化，整整二十多天每天少發近百度才被客戶發現，事後賠了一筆發電損失還差點掉約。導入這條監測告警流後，系統每天清晨七點把四十個案場全部掃一遍，AI 把當日異常案場排好序推到 LINE 群，工程師只要看排在前面的三、五個重點處理。上線兩個月，他們抓到一次逆變器 MPPT 通道在故障當天就派工、一次草木遮蔭提前安排除草，估算每月多追回的發電收益遠超過這套系統的建置成本，工程師也從「天天看圖看到眼花」變成「看告警去現場」，省下的時間拿去接更多新案場的並聯與維護。

延伸應用

這條流程的骨架可以再往兩端擴充。往前，可把監測門檻分級成「黃燈追蹤、紅燈派工」，黃燈案場先自動加入觀察清單連看三天確認趨勢再決定是否派工，減少誤判。往後，可結合 自動化排程 把確認的工單依地理位置與技師排班自動排出最省車程的巡檢路線，並承接 太陽能施工排程派工流 完工啟用的新案場自動納管。日常報表面，可搭配 報表彙整配方 把每月發電量、異常處理率與 PR 值做成客戶版儀表板，讓維運成效一目了然，也讓續約談判更有底氣。

流程圖

用到的工具

更多「工程裝修」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →