監視器接進 HA 的四種協定：RTSP / ONVIF / go2rtc / WebRTC

charles

「為什麼我的攝影機在 HA 裡要等十秒才出畫面？」

這題的答案在協定選擇。



四種協定的定位

一、RTSP（最基礎）

• 幾乎所有 IP 攝影機都支援
  
• 網址格式：rtsp://帳號:密碼@IP:554/路徑
  
• 路徑每家不一樣，要查說明書或社群整理
  
• 本身延遲很低（1 秒內），但瀏覽器不能直接播
  

常見的 RTSP 路徑：

1. # Hikvision
2. rtsp://user:pass@IP:554/Streaming/Channels/101    # 主串流
3. rtsp://user:pass@IP:554/Streaming/Channels/102    # 子串流
5. # Dahua
6. rtsp://user:pass@IP:554/cam/realmonitor?channel=1&subtype=0
7. rtsp://user:pass@IP:554/cam/realmonitor?channel=1&subtype=1
9. # Reolink
10. rtsp://user:pass@IP:554/h264Preview_01_main
11. rtsp://user:pass@IP:554/h264Preview_01_sub
13. # TP-Link Tapo
14. rtsp://user:pass@IP:554/stream1     # 主
15. rtsp://user:pass@IP:554/stream2     # 子

複製代碼

用 VLC 測試最快：媒體 → 開啟網路串流 → 貼上網址。
VLC 能播就代表網址對。

二、ONVIF（標準化的控制介面）

• 不只是影像，還包含控制（雲台、變焦、預置點）
  
• 可以自動發現 RTSP 網址（不用自己查）
  
• 可以接收攝影機的事件（動作偵測、越線偵測）
  
• HA 有官方的 ONVIF 整合
  

ONVIF 的價值：

1. # 雲台控制
2. - action: onvif.ptz
3.   target:
4.     entity_id: camera.front_door
5.   data:
6.     pan: RIGHT
7.     tilt: UP
8.     distance: 0.5
9.     speed: 0.5
11. # 移動到預置點
12. - action: onvif.ptz
13.   target: {entity_id: camera.front_door}
14.   data:
15.     move_mode: GotoPreset
16.     preset: "1"

複製代碼

攝影機自己的動作偵測也會變成 binary_sensor，
這比在 HA 端做偵測省資源很多。

但要注意：

• 攝影機的 ONVIF 功能常常預設是關的，要去設定裡開
  
• 有些便宜的攝影機 ONVIF 實作不完整
  
• ONVIF 需要時間同步 —— 攝影機和 HA 的時間差太多會驗證失敗
  

時間不同步是最常見的 ONVIF 問題，
症狀是「帳號密碼明明對的但一直說驗證失敗」。



三、go2rtc（延遲問題的解方）

這是 2026 年最值得知道的一個工具。

它在做什麼：接收各種來源（RTSP、ONVIF、USB、HTTP），
轉換成瀏覽器能播的格式，而且支援 WebRTC。

為什麼重要：延遲差很多

• HLS（HA 預設）—— 延遲 5-10 秒
  
• MSE / fMP4 —— 延遲 1-3 秒
  
• WebRTC —— 延遲 0.5 秒以內
  

HLS 的延遲是協定本身的特性（它把影像切成一段一段的檔案），
不是設定問題。

好消息：HA 從 2023 起就內建 go2rtc 了
（Frigate 也內建）。

設定：

1. # configuration.yaml
2. go2rtc:
3.   streams:
4.     front_door:
5.       - rtsp://user:pass@192.168.30.11:554/Streaming/Channels/101
6.     backyard:
7.       - rtsp://user:pass@192.168.30.12:554/h264Preview_01_main

複製代碼

然後在設定 → 裝置與服務 → 新增整合 → WebRTC Camera
或用 HACS 的 WebRTC Camera 自訂卡片。

儀表板卡片：

1. type: custom:webrtc-camera
2. url: front_door
3. mode: webrtc,mse
4. muted: true

複製代碼

mode 寫多個的話會依序嘗試，WebRTC 不通就退回 MSE。

四、WebRTC（最低延遲）

• 原本是給視訊通話用的協定
  
• 延遲可以低到 0.5 秒以內
  
• 支援雙向音訊（對講）
  
• 但需要 STUN / TURN 伺服器才能跨網路使用
  

內網使用：通常不用額外設定。

外網使用：需要 STUN（找到彼此的公網位址）
或 TURN（中繼）伺服器。

1. go2rtc:
2.   webrtc:
3.     candidates:
4.       - 192.168.1.50:8555      # 內網位址
5.       - stun:8555              # 讓它自己用 STUN 找公網位址

複製代碼

Matter 1.5 也選了 WebRTC

值得一提：Matter 1.5 新增的攝影機裝置類型，
就是用 WebRTC 做即時影音串流，
而且用標準的 STUN 和 TURN 協定支援本地和遠端存取。
規範還強制要有 WebRTC Transport Provider / Requestor 叢集來安全管理連線。

所以 WebRTC 基本上是智能家居攝影機的未來標準。



怎麼選：實際建議

只是想看畫面：

• RTSP + HA 的 Generic Camera 整合
  
• 延遲 5-10 秒，但設定最簡單
  

想要低延遲（門鈴、對講）：

• go2rtc + WebRTC
  
• 延遲 0.5 秒，體驗完全不同
  

想要雲台控制和攝影機事件：

• ONVIF 整合
  
• 記得確認時間同步
  

想要影像辨識：

• Frigate（內部就是用 go2rtc）
  
• 前面有一篇專門講
  

最完整的組合：

1. 攝影機（RTSP + ONVIF）
2.    ├── 子串流 → Frigate（物件偵測）
3.    ├── 主串流 → Frigate（錄影）
4.    ├── go2rtc → WebRTC（即時觀看，低延遲）
5.    └── ONVIF → HA（雲台控制、攝影機事件）

複製代碼

買攝影機的建議（再強調一次）

• 一定要有 RTSP —— 沒有的話就被鎖死在廠商生態裡
  
• 最好有 ONVIF —— 多一層控制能力
  
• 優先 PoE —— 一條線供電加網路，比 Wi-Fi 穩太多
  
• 要能關掉雲端上傳
  
• 主串流和子串流都要有 —— 偵測用子串流是必要的
  

幾個實務上的坑

坑一：H.265 的瀏覽器相容性

很多新攝影機預設用 H.265（HEVC），壓縮率比 H.264 好，
但瀏覽器支援度差很多。

症狀：在 HA 裡看不到畫面，或者 CPU 飆高（因為要轉碼）。

解法：

• 在攝影機設定裡把編碼改成 H.264
  
• 或者讓子串流用 H.264、主串流用 H.265
  

坑二：密碼裡有特殊字元

RTSP 網址裡的密碼如果有 @ / : / # 這些字元，
網址會被解析錯。

解法：做 URL 編碼，或者乾脆把攝影機密碼設成只有英數字。

坑三：連線數限制

很多攝影機同時只能接受 2-4 個 RTSP 連線。

如果 Frigate 接兩條、HA 再接一條、你又用 VLC 看一條 ——
就滿了，後面的會失敗。

解法：用 go2rtc 當中繼。
它只跟攝影機建立一條連線，然後分發給多個客戶端。

1. go2rtc:
2.   streams:
3.     front_door:
4.       - rtsp://user:pass@192.168.30.11:554/Streaming/Channels/101
6. # 其他服務改成連 go2rtc 而不是直接連攝影機
7. # rtsp://192.168.1.50:8554/front_door

複製代碼

這個技巧解決了很多「攝影機一多就不穩」的問題。

---

我自己的設定是：

• 攝影機 → go2rtc（統一入口）
  
• go2rtc → Frigate（偵測和錄影）
  
• go2rtc → WebRTC 卡片（即時觀看）
  
• ONVIF → HA（雲台和事件）
  

門鈴按下去到手機上看到畫面，大概 1 秒。

換成這個架構之前是 8 秒 —— 人都走了。