後續工作規劃 — 從「Demo」升級成「Research」

🔧 三個一定要先修的問題

這三件事不修，後面的實驗數據都不能用。它們不難改，但很關鍵。

① 效能延遲「量錯了」最重要

你目前（照教材挑戰 2）是在 publish() 前後抓時間。但因為開了 loop_start()，paho 的 publish() 是「非阻塞」的—— 它只是把訊息丟進程式內部的佇列就馬上回傳（微秒級），根本還沒送到網路、更沒到對方。 所以你量到的是「丟進佇列的時間」，不是真正的端到端延遲。

# loop_start() 後 publish 非阻塞
t_start = time.time()
publish(topic, data)   # 立刻回傳
t_end = time.time()
lat = (t_end - t_start)*1000  # ≈ 0.01 ms

# 送端：送出前埋時間戳
data["t_send"] = time.time()
publish(topic, data)

# 收端（Adapter / 儀表板）：
recv = time.time()
e2e_ms = (recv - data["t_send"])*1000

② 感測值是純隨機 → 四協定「沒得比」

現在四個協定都用 random.uniform() 生資料，除了 sleep 間隔不同，本質一模一樣。 但題目是「跨協定效能橋接」——如果協定之間沒有真實差異，就沒有東西可以「比較」，研究就立不起來。

val = random.uniform(20, 40)
await asyncio.sleep(10)
# LoRa 跟 WiFi 只差 sleep 秒數

# LoRa：高延遲、會掉封包
await asyncio.sleep(net_delay["lora"])
if random.random() < loss["lora"]:
    continue   # 模擬掉包，不發送

每個協定要套不同的延遲分佈、封包遺失率、抖動（實際數值見「📐 真實數據量測」分頁，並查文獻佐證）。這樣「LoRa vs WiFi 的橋接表現」才有意義。

③ 公開 Broker 量不出可信數據 → 改本機 Docker

你在報告 slide 7 已經發現 home/# 全是「別人的流量＝雜訊」。這正是用公開 broker.emqx.io 的副作用：未知的跨流量、限流、不保證送達， 任何效能數字都無法重現。做量測前，一定要改成本機自己跑的 broker。

# 一行指令在本機跑一個 MQTT broker（裝好 Docker 後）
docker run -d --name mqtt -p 1883:1883 -p 9001:9001 eclipse-mosquitto
# 然後把程式裡的 BROKER 從 "broker.emqx.io" 改成 "localhost"

📐 要量「什麼」、怎麼量才算真實可比較

「研究」跟「Demo」最大的差別，就是你能不能拿出可信、可重現、能互相比較的數字。 這一頁告訴你：① 要量哪些指標 ② 在哪裡量 ③ 每個協定該有的真實特性 ④ 結果長什麼樣。

📍 在管線的「哪裡」量 — 四個量測點

📊 要量的指標（量測維度）

🌐 每個協定該有的「真實特性」

下面是教科書上各協定的典型數量級，請學生再查 1–2 篇文獻佐證後，把這些數字寫進模擬器的延遲/遺失模型：

→ 套進去之後，「LoRa 在橋接後延遲最大、WiFi 最小」這種結論才有真實依據，不是亂數。

📈 結果長什麼樣（範例圖＋結果表模板）

🎯 目標

建立一套可信、可重現的量測工具與環境，能正確量出端到端延遲、吞吐、抖動、遺失率、資源使用，並輸出統計（p50/p95/p99）。

✅ 任務清單

• 裝 Docker，本機跑 Mosquitto broker，程式 BROKER 改成 localhost
• 改寫延遲量測：payload 埋 t_send，收端算 t_recv − t_send（見「需要修正」①）
• 每筆訊息加序號 seq，收端數缺號算遺失率
• 用 psutil 記錄 Adapter 的 CPU / 記憶體
• 把量測寫成一個獨立模組，能自動跑 N 次、輸出 mean/median/p95/p99 到 CSV
• 跑一組「基準線（baseline）」數據，之後所有實驗都跟它比

📐 量測模組長怎樣（參考骨架）

import statistics, csv, psutil

lat = []           # 收集每筆端到端延遲
recv_seq = set()    # 收到的序號

def on_message(data):
    lat.append((time.time() - data["t_send"])*1000)
    recv_seq.add(data["seq"])

def report(total_sent):
    p = statistics.quantiles(lat, n=100)
    return {
        "p50": statistics.median(lat),
        "p95": p[94], "p99": p[98],
        "loss_%": (1 - len(recv_seq)/total_sent)*100,
        "cpu_%": psutil.cpu_percent(),
    }

📦 交付物 ＆ 完成標準

🎯 目標

把「隨機數字」升級成「有協定特性的數字」：每個協定有自己的延遲、遺失率、抖動模型。 （進階）至少接一條真實協定路徑來校準，證明你的模擬可信。

🌐 怎麼把真實特性「注入」模擬器

PROFILE = {
  "lora":   {"delay": (1.0, 3.0), "loss": 0.08},  # 高延遲、8% 掉包
  "zigbee": {"delay": (0.015,0.03),"loss": 0.02},
  "ble":    {"delay": (0.05, 0.2), "loss": 0.01},
  "wifi":   {"delay": (0.001,0.01),"loss": 0.005},
}
# 數值請以「📐 真實數據量測」的表＋文獻為準

✅ 任務清單

• 查 1–2 篇各協定文獻，整理延遲 / 遺失 / 頻寬的典型值（寫進報告當依據）
• 把參數做成 PROFILE 表，注入每個模擬器
• 用機率模擬掉包、用分佈（非固定值）模擬延遲抖動
• 進階 接一條真實路徑校準：真 CoAP server / MQTT+TLS / Zigbee2MQTT 任一種，比對模擬與真實的落差

📦 交付物 ＆ 完成標準

❓ 訂出你的研究問題（RQ）

一份研究要先問問題，再用實驗回答。建議從這三題選 1–2 題深入：

🧪 對照實驗怎麼設計

每個實驗都要分清楚三種變數：

＋ 固定變數：其它全部不動（同一台機器、同一 broker、同樣跑 N 次）。

✅ 任務清單 ＆ 交付物

• 選定 1–2 個 RQ，寫成一句話的明確問題
• 為每個 RQ 設計對照組 / 實驗組，列出自變數、應變數、固定變數
• 做一張「實驗矩陣」表（哪些設定要跑、各跑幾次）
• 實際跑實驗，數據存 CSV，畫成圖

📈 Scalability：把它操到壞，找崩潰點

裝置數 / 訊息率一路往上加（1 → 10 → 100 → 1000），看延遲在哪裡開始爆掉、吞吐在哪裡到頂。

🔍 把「資料遺失」查清楚（呼應你 slide 13）

你報告裡提到「Google Sheets 還是會掉資料」。別把它當 bug 帶過——把原因拆開、各佔多少，本身就是一段漂亮的可靠度分析。

做法：用「序號數缺號」逐一隔離各原因的貢獻度，畫成「遺失率 vs QoS / 負載」曲線。

✅ 任務 ＆ 完成標準

• 畫出「裝置數 vs 延遲 / 吞吐」曲線，標出崩潰點
• 用實驗隔離資料遺失的四個原因，量化各自佔比
• 畫「遺失率 vs QoS 等級」對照圖

📄 報告章節結構（照這個寫）

📦 可重現性套件（口試加分關鍵）

🗓️ 整體時程建議（一學期）

🏆 怎麼讓這份專題「有貢獻」

一份研究要講得出「我的貢獻是什麼」。下面四個方向，挑一個深挖當主軸，其它當輔助或未來工作即可。

⭐ 主推方向

💡 其它可選方向

🎯 一句話總結給學生