# 📡 MQTTLogAgent — MQTT 通訊監察

**駐地專案**:pms-mqtt-bridge / AWS IoT(ap-southeast-2)
**狀態**:🟢 部分落地(規則式 + LLM 分析)

## 規劃職能(拓撲圖)
MQTT 通訊封包流速監控與異常警告、設備離線狀態預測。

## 目前真實執行項目
- **訊息量監測(mqttLogAgent.js,2026-08-07 上線)**:每 30 分鐘抓 CloudWatch AWS/IoT 指標(PublishIn/Out.Success、Connect.Success,MQTT 維度),比對「最近整點時段 vs 前 24 小時均值 2 倍」與「200k 則/時絕對上限」雙門檻,異常即交 MasterBrain(Gemini)分析後推播 LINE 告警(冷卻 2 小時)
- 每日 09:00 摘要附 IoT 昨日訊息量、月估算量與訊息費估算
- pms-mqtt-bridge 常駐轉發(既有)、api_logs 落庫(既有)

## 監測基線(2026-08-07 實測)
- PublishIn ≈ 43.4 萬則/日(≈18k/時,極穩定)、PublishOut ≈ 130 萬則/日(**訂閱乘數 3 倍**)、Connect ≈ 2.3 萬次/日
- 月估算 ≈ 52 百萬則 ≈ US$52/月(僅訊息費)——與 IoT 佔帳單 76% 吻合
- **省錢主攻方向**:降低發送頻率與訂閱端數量(見「費用暴增原因/處理的方式」的 Lifecycle Events 方案)

## 尚未落地
- 設備離線狀態預測(需逐設備 clientId 維度分析)

## 工作日誌
- 2026-08-07:CloudWatch 指標接入(IAM Role 加 CloudWatch 唯讀)、雙門檻告警 + LLM 分析上線、摘要 IoT 用量列上線

## ⑤ IoT 訊息量優化計畫(2026-08-07 排入,待執行)
**目標**:把月約 52 百萬則(≈US$52 訊息費,IoT 佔帳單 76%)壓下來。依「費用暴增原因/處理的方式」文件的 Lifecycle Events 方案,具體步驟:

1. **盤點訂閱端**(最快見效):PublishOut 是 PublishIn 的 3 倍 → 找出 3 個訂閱來源(後端/網頁/測試程式),關掉重複或閒置的訂閱,理論上最多可砍 2/3 的傳出訊息費
2. **設備端降頻**:存活確認改用 MQTT Keep-Alive(PINGREQ 免訊息費),資料發送從每 5 秒改為變化才發(delta-based)或 60 秒批次
3. **改用 Lifecycle Events**:AWS IoT Rule 訂閱 `$aws/events/presence/#` 自動寫離線狀態進 Firebase,取代高頻心跳
4. **成效驗證**:本 Agent 的每日摘要就是計分板——調整後看「IoT 昨日訊息量」是否下降;每降 100 萬則/月 ≈ 省 US$1

**預估效益**:若三項全做,月訊息量可望降至 1/5 以下(≈US$10 內),整體帳單約砍半。