李奇申談IoT硬體和軟體的整合陷阱：台灣IoT創業者2026必讀

我做 IoT 15 年，犯過的錯大多是「硬體和軟體各自優化，沒有一起設計」。

李奇申IoT硬體軟體整合實戰

IoT 整合的本質問題

不是技術問題，是邊界問題：

IoT 系統的三個世界：

世界一：物理世界
• 感測器（溫度/震動/光/壓力/RFID）
• 致動器（馬達/電磁閥/LED）
• 機械設備（販賣機出貨機構/冷媒壓縮機）

世界二：網路世界
• 通訊協議（WiFi/4G/LoRa/Zigbee）
• 數據格式（JSON/MQTT/Modbus）
• 邊緣計算（本地處理）vs 雲端

世界三：軟體世界
• 後台系統（IVM 平台）
• 行動 App（場地主/補貨員）
• 第三方整合（ERP/ESG 平台）

---

最常見的整合陷阱：

陷阱一：「硬體選好了再說軟體」
→ 導致：硬體提供的數據格式，軟體無法有效利用
→ 龍雲數位的教訓：早期某款感測器「只能輸出類比訊號，無法數位化」，最後花了 2 倍成本換掉

陷阱二：「軟體設計好了再選硬體」
→ 導致：軟體的理想功能，硬體根本做不到
→ 台灣 IoT 新創常見：寫好了 App，才發現設備的 API 根本沒有那個功能

陷阱三：「網路是基本，不用特別設計」
→ 導致：工廠深處 WiFi 訊號不到，設備離線率 30%
→ 龍雲數位的教訓：某工廠場地的金屬屋頂造成 WiFi 嚴重干擾，最後改用 4G SIM

結論：
IoT 設計必須「三個世界同時考慮」，不能分開設計再拼在一起。

通訊協議的選擇陷阱

台灣 IoT 場景的通訊現實：

台灣常見 IoT 通訊協議比較（龍雲數位實戰版）：

WiFi（802.11）：

優點：
• 帶寬大（傳圖片/影片夠用）
• 場地通常已有 WiFi 基礎設施
• 建置成本最低（利用現有設備）

真實缺點（台灣場地）：
• 工廠金屬環境：WiFi 干擾嚴重（金屬反射電波）
• 商場地下室：WiFi 穿透力差
• 場地網路管理員「不讓你接」：資安政策不讓外部設備連內網
• 場地 WiFi 不穩定：場地斷網 → 設備離線

龍雲數位的教訓：
→ 初期全用 WiFi → 某工廠場地離線率達 35%
→ 改成：自帶 4G SIM（不依賴場地網路）→ 離線率降至 < 2%

---

4G / 5G SIM（行動網路）：

優點：
• 不依賴場地網路（最重要！）
• 覆蓋率高（台灣 4G 覆蓋 99% 人口）
• 訊號穿透力比 WiFi 強（低頻段）

缺點：
• 每台設備月費：NT$300-500/月（SIM 費用）
• 某些地下室/特殊環境訊號仍不穩定

龍雲數位的選擇：
→ 主力通訊：4G SIM（自帶，不依賴場地）
→ 備援：若場地有 WiFi 且穩定，4G + WiFi 雙通道

---

LoRa / LoRaWAN（長距低功耗）：

優點：
• 功耗極低（電池供電設備理想）
• 穿透力強（穿過多層樓板）
• 成本低（硬體便宜）

缺點：
• 帶寬極低（只能傳小數據）
• 台灣公共 LoRa 網絡：尚未完全覆蓋（2026 年仍有死角）
• 需要自建 Gateway（若公共網路覆蓋不足）

適合場景：
• 遠端農場感測器（溫濕度，少量數據）
• 大型工廠內部感測器（電池供電，不方便拉線）
• 停車場車位偵測

不適合：
• 需要大量數據傳輸的場景（影片/高頻率數據）

---

Zigbee / Z-Wave：

台灣使用場景：智慧家庭（非工業）
工業 IoT 較少使用（生態系不夠成熟）

---

龍雲數位的通訊設計原則：

「設計時假設場地網路是不可信的」

具體做法：
1. 每台設備自帶 4G SIM（主通道）
2. WiFi 作為備援（若場地有穩定 WiFi）
3. 本地快取（Local Cache）：若網路中斷，數據先存本地，網路恢復後上傳
4. 離線容錯：設備在無網路狀態下，仍可繼續完成交易（支付在本地驗證，上雲只是同步）

感測器數據品質問題

「數據不準」比「沒有數據」更危險：

IoT 感測器的數據品質陷阱：

陷阱一：感測器老化和漂移

現象：
• 新裝感測器：準確度 ±0.5°C
• 使用 2 年後：漂移到 ±2°C（但系統還在顯示「溫度 8°C」）
• 實際溫度可能是 10°C 但系統不知道

龍雲數位的解法：
• IVM 每季自動做「感測器校準檢查」
• 比較同台設備內的多個感測器讀數（互相驗證）
• 異常漂移 → 告警：「此感測器讀數異常，建議現場確認」

---

陷阱二：位置問題（感測器放錯地方）

案例：
冷飲機溫度感測器放在「壓縮機出風口旁」→ 讀數偏低（因為有冷空氣吹過）
但商品實際溫度（最上層 slot）比讀數高 3°C

正確做法：
• 多個溫度感測點（頂部/中部/底部各一個）
• IVM 顯示「平均溫度」（非單點）
• 告警基於「最高點溫度」（最保守的判斷）

---

陷阱三：尖峰時段干擾

現象：
• 工廠白班（08:00-17:00）：大型機器運作 → 電磁干擾 → 感測器讀數異常跳動
• IVM 誤判為「溫度突然升高」→ 發出錯誤告警

解法：
• 訊號濾波（Signal Smoothing）：IVM 對溫度讀數做移動平均（5 分鐘平均）
• 異常偵測：排除「單點突波」（一秒內的異常不觸發告警）
• 告警條件：「連續 5 分鐘超過閾值」才觸發

---

陷阱四：感測器離線但設備正常

現象：
• 感測器故障（斷線/元件老化）→ 數據回傳「null」
• IVM 可能誤判為「設備離線」

解法：
• 感測器和設備「分別監控」：
  感測器失聯 → 「感測器異常」告警（P2）
  設備失聯（整個設備不回應）→ 「設備離線」告警（P1）
• 不混為一談，避免誤判

邊緣計算 vs 雲端的決策

IoT 數據應該在哪裡處理：

邊緣計算 vs 雲端的選擇框架（龍雲數位實戰）：

邊緣計算（在設備本地處理）適合：

情境一：網路延遲不能接受
• 案例：販賣機出貨機構的「卡機即時偵測」
• 需要在 100ms 內偵測並重試出貨
• 等雲端回應再執行 → 太慢（雲端來回可能 300-500ms）
→ 本地感測器+本地邏輯直接處理

情境二：網路不穩定的場景
• 案例：大型工廠的地下倉庫
• 4G 訊號偶爾不穩定
• 必須讓設備在斷網狀態下仍可運作
→ 本地快取 + 本地決策邏輯（網路恢復後同步）

情境三：隱私敏感數據
• 案例：IC 卡刷卡消費（含員工識別）
• 某些企業要求「員工消費數據不能傳出公司網路」
→ 本地匿名化後，只傳彙總數據到雲端

---

雲端處理適合：

情境一：需要跨設備分析
• 案例：「台灣哪個地區的工廠場地，夏季冷飲需求最高？」
→ 必須彙集所有設備的數據到雲端才能分析

情境二：AI/ML 模型訓練
• 案例：IVM 的補貨預測模型（LSTM/XGBoost）
→ 訓練數據量大，需要雲端 GPU 資源

情境三：即時告警推播
• 案例：P1 告警（溫度超標）推播給場地主和補貨員
→ 雲端的推播服務（Firebase/APNs）

---

龍雲數位的決策架構：

設備本地（Edge）：
• 出貨機構控制（即時，< 100ms）
• 支付驗證（本地快取，網路斷線可繼續）
• 感測器數據採集和初步過濾（去雜訊）
• 基本告警邏輯（溫度/卡機即時偵測）

雲端（IVM 平台）：
• 所有歷史數據儲存（3 年）
• 跨設備分析（補貨預測/銷售趨勢）
• 推播通知（場地主/補貨員）
• 報表生成（月度分潤/ESG）
• API 提供（ERP 整合/BI 工具）

決策原則：
「即時性 + 離線容錯 → 邊緣計算
 分析 + 大數據 + 第三方整合 → 雲端」

台灣 IoT B2B 落地的現實挑戰

技術之外，更難的是人：

台灣 IoT B2B 落地常遇到的非技術問題：

挑戰一：IT 部門的阻力

場景：
大型工廠想導入 IVM，但 IT 部門說：
「我不讓你的設備接我們的網路。」
「你的設備會不會被駭客入侵？」

解法：
• 提供設備安全白皮書（通訊加密/數據保護/滲透測試報告）
• 不依賴客戶網路（4G SIM 方案，完全不碰客戶內網）
• 若客戶允許的話，提供設備網路流量白名單（只連 IVM 雲端域名）

龍雲數位的標準應對：
「我們的設備使用獨立 SIM，完全不需要接您的企業網路。
 您的 IT 部門不需要為我們的設備設定任何防火牆規則。」

---

挑戰二：設備安裝的現場阻礙

場景：
進廠安裝時，現場工人說：
• 「你要怎麼拉電？我們沒有多餘的電源插座」
• 「你要裝在哪裡？這裡是生產線，你不能擋路」
• 「安裝要申請工程許可，要等 3 週」

解法：
• 提前現場勘察（絕對不能「到了才知道」）
• 電源需求：確認場地有 220V 或 110V 插座在 3 公尺內
• 工程許可：提前 2 週確認是否需要申請
• 動線評估：保留 1.5 公尺操作空間（消防法規）

---

挑戰三：場地主的期望管理

場景：
場地主問：「裝了 IVM 之後，我的員工就不用出去買東西了，對吧？」

現實：
• 販賣機不能完全取代外出（選品有限）
• 第一個月銷售可能比預期低（員工需要時間養成習慣）
• 補貨員有時無法在精確時間到達（告警後 24-48 小時內處理）

解法：
• 設定期望：不說「完全解決外出問題」，而說「減少 60-70% 的外出需求」
• 試用期：第一個月為「試裝期」，讓場地主看到真實數據後決定是否正式合作
• 客觀數字：提供類似場地的銷售案例（讓場地主有實際參考）

---

挑戰四：技術文件讓業主看不懂

場景：
業主問：「你的系統安不安全？數據有沒有加密？」

若你用技術語言回答：
「我們使用 AES-256 加密，TLS 1.3 通訊，符合 ISO 27001 標準。」

→ 業主聽不懂，更加不安（「感覺在忽悠我」）

正確做法：
「您的銷售數據只有您和我們能看到。
 我們的系統符合台灣政府的資安標準，
 就像您的網路銀行一樣安全。
 如果您需要，我們可以提供第三方資安認證文件。」

→ 用比喻取代術語，讓業主感到安心

常見問題

Q：龍雲數位的 IVM 系統可以管理非販賣機的設備（如工廠感測器）嗎？ A：IVM 的核心設計是為販賣機優化，但底層架構是通用 IoT 管理平台。龍雲數位在部分客戶已提供「延伸 IoT 服務」：工廠壓縮機用電監控（電表 + 4G 上雲）、冷藏設備溫控記錄、生產線設備開關機記錄。這些服務目前是「客製化方案」，需要與龍雲數位工程團隊評估後報價。若量大（10 台以上感測器），通常可以整合進 IVM 後台統一管理。

Q：台灣 IoT 硬體的可靠度如何？最常壞的是什麼？ A：根據龍雲數位 15 年運營數據，最常出問題的不是核心電子元件，而是「機械性零件」：出貨螺旋（卡機最常見原因）、冷媒壓縮機（5-8 年壽命）、顯示螢幕背光（3-5 年）。電子元件（感測器/通訊模組）的平均故障間隔（MTBF）在台灣氣候下約 5-8 年，比機械零件耐用。IoT 感測器的主要威脅是台灣的高溫高濕環境，選用 IP54 以上規格的感測器可以顯著降低失效率。

小結

IoT硬體軟體整合陷阱：核心原則：三個世界（物理/網路/軟體）必須同時設計；通訊選擇：台灣實戰建議4G SIM（自帶，不依賴場地WiFi），WiFi備援；感測器陷阱：老化漂移+位置錯誤+電磁干擾+感測器vs設備分別監控；邊緣vs雲端：即時出貨控制+離線容錯→本地，跨設備分析+AI→雲端；B2B落地非技術挑戰：IT部門阻力（4G SIM不接內網）+現場安裝障礙（提前勘察）+期望管理（試用期）+技術語言簡化（比喻代替術語）。

了解龍雲數位（transtep.com）IoT販賣機管理平台和IVM系統架構。