條件監控通知器：設備數值一超標就發 LINE，不重複吵、資料斷了也提醒

驗證狀態：這是新做的自有作品，還沒有在實際設備或客戶環境使用過。目前只用虛構的 3 台設備、2 小時資料（300 筆）重播，加上 21 項自動測試驗證。LINE、Telegram 推播與台股公開行情只寫了程式，還沒有實際連線測試。

設備會把溫度、壓力、計數寫進紀錄檔，系統也會把佇列長度、錯誤數放在 API 上。數字都在，問題是沒人一直盯著。等到有人發現，常常已經過了半個班。

最直覺的做法是寫個迴圈，數值超標就發通知。實際上線後通常會遇到三種狀況：

數值在門檻附近抖動，手機一直響。 響到第三次就沒人看了。
設備當機、紀錄檔停止更新，程式什麼都不說。 沒有新資料，就沒有超標，看起來一切正常。
程式重開，同一件事再通知一次。

這個工具處理的就是這三件事。

它做什麼

範例執行結果可以直接打開看。重點如下：

情況	它的反應
數值從正常變成超標	通知一次：哪台設備、哪個條件、目前數值、資料時間
持續超標	不再通知
回到正常	可選擇通知「已恢復」
冷卻時間內又超標	不通知，只寫進紀錄檔
某台設備超過 N 分鐘沒有新資料	通知「資料停止更新」，恢復後再通知一次
紀錄檔讀不到、API 連不上	連續失敗幾次才通知，避免網路閃一下就叫
下班時間	可以設定只在上班時段檢查資料中斷

範例資料裡有一段溫度在 200°C 上下來回跳了 5 次。逐次通知的話，9 分鐘內會收到 10 則訊息；這個工具只送 2 則，也就是第一次過熱，加上它的恢復。

條件寫在設定檔

不用改程式，品保或設備工程師自己就能調整：

rules:
  - id: oven_overheat
    target: "*"            # 所有設備
    message: 溫度過高
    level: critical
    notify_recover: true
    all:
      - { field: temp, op: ">=", value: 200 }

  - id: pump_pressure_low
    target: PUMP-01
    message: 壓力跌破下限
    all:
      - { field: pressure, op: cross_below, value: 0.8 }

兩種判斷方式：大於、小於門檻（>=、<），或「穿越」（cross_above、cross_below）。「穿越」只在跨過門檻的那一刻成立，適合「跌破下限」這種只想知道「發生那一刻」的情況。
組合條件：寫在 all: 底下是全部成立才通知，寫在 any: 底下是任一成立就通知。
冷卻時間：全域預設 30 分鐘，每條規則可以另外設定。

資料從哪裡來

來源	適合
CSV 紀錄檔	設備或測試程式持續寫入的 log，只讀新增的列，寫到一半的列會等下一輪
HTTP JSON	內部系統、IoT 閘道器、自己寫的 API
台股公開行情	同一套引擎換資料來源的示範，只做個人通知，不提供投資建議、不下單

欄位名稱由資料決定，溫度、壓力、良率、庫存量都可以。

通知送到哪裡

LINE 官方帳號（Messaging API）。LINE Notify 已在 2025 年 3 月底結束服務（數位時代報導），現在要用官方帳號推播。
Telegram。
只顯示在電腦畫面上（測試時用）。

送出失敗會重試；還是失敗就記成「未送達」，監控不會中斷。所有通知都存在本機，雙擊就能匯出成 Excel 可以打開的 CSV。

可以直接導入

這是產品化的版本，不是一次性的程式：

一個設定檔管資料來源、規則、通知管道，金鑰放在環境變數，不寫進檔案
Windows 雙擊執行，第一次會自動安裝需要的套件；可以設定開機自動執行
附使用手冊、範例資料、執行紀錄檔

把你們的一份紀錄檔（或 API 回應範例）給我，順便說明想知道哪些狀況，我先套上你們的資料，用重播模式跑給你看會收到哪些通知，確認沒問題再談導入。需要接資料庫或工業通訊協定（例如 OPC UA），或每天另外寄一份彙整報表，可以再延伸。

設計細節寫在技術筆記〈設備異常通知一直狂發？邊緣觸發、冷卻時間與資料中斷偵測〉。

← 回到作品