家裡有兩隻虎斑貓,aki 和 kuro。上一篇把客廳的 Tapo C210 接進 Frigate,做出錄影回看、貓咪日記和每日精華影片,結尾留了一個尾巴:我在找一台有鏡頭的自動餵食器。原本是想補 C210 拍不到的地板死角,分貓失敗之後它又多了一個任務,因為貓吃飯時離鏡頭只有幾十公分,剛好是分貓需要的近拍。
我以為這是最簡單的一段,買一台能把影像接進 Frigate 的餵食器就好。結果查了十個品牌,沒有一台有開放影像串流,最後是買了一台、自己把它的私有串流逆出來才接上的。現在影像和錄影在 Frigate 裡、餵食控制和即時收音在 Home Assistant 裡,月費 0 元。沒做成的是從瀏覽器直接對講,目前用按鈕播預錄的提示音代替。分貓則是「認得出名字」的比例高很多,但準不準還沒驗。
這篇照順序記錄:我查了哪些餵食器、為什麼它們都接不出來、買之前怎麼用 App 安裝檔判斷有沒有機會、怎麼找到這台的影像串流(go2rtc 設定附在那一段,IP 換成自己的就能用)、餵食控制和音訊怎麼橋接進 HA,最後是分貓的現況和跟 Furbo 的比較。
IMPORTANT
餵食控制走的是廠商的雲端,這篇只寫我做出了什麼,不寫雲端端點、認證流程和指令格式。那些東西公開出去,影響的是其他使用者的裝置。
米家和 PETKIT 都不行#
最先看的是米家智慧寵物餵食器 2 可視版,2026 年 3 月眾籌上市,500 萬畫素、150° 超廣角、940nm 紅外夜視、5L 糧倉,還有秤重。 有 xiaomi 來源,原始碼裡的裝置過濾條件還明確寫了 .feeder.,我一度以為就是它了。
讀完那個模組的原始碼才發現,它的影像只有兩條路可走:小米自家的雲端中繼(CS2),或 ThroughTek Kalay(TUTK)的 P2P,兩條都經過雲端。連影像本身都走雲端,擋掉外網串流就斷。我客廳的 C210 用的 是純區網的,路由器斷了外網照樣錄影偵測,兩者在架構上差很多。go2rtc 的 xiaomi 支援清單裡有 50 幾台攝影機的回報,餵食器一台都沒有,作者自己的說法是:「If a camera isn't on the list, don't ask if it works. No one knows until you try it.」
另外台灣官方只賣無鏡頭的標準版,可視版是中國機(人民幣 449,約 NT$2,000),要淘寶或代購、沒有保固。再加上小米攝影機的資安紀錄:2020 年有人在 Google Nest Hub 上看到別人家的小米攝影機畫面,2021 年 ThroughTek Kalay 被揭露 CVSS 9.6 的漏洞(CVE-2021-28372,影響約 8,300 萬台裝置)。我就沒買了。
接著看 YumShare Dual Gen2(P592)。它本身不支援本地串流,但 GitHub 上有個叫 LocalKit 的第三方專案,說能把 PETKIT 的裝置完全去雲端化,包含攝影機。看完部署文件我就放棄了,它要:
- 改 DNS,把 PETKIT 的雲端網域導到自己的伺服器
- 改裝置的憑證信任鏈(裝置有 cert pinning)
- 跑一個容器假裝成 PETKIT 的 MQTT broker
- 在每台有鏡頭的裝置上跑 go2rtc
- 韌體鎖在 895 版,不能讓它自動更新
而且是一個人在維護。Tapo 的 RTSP 是原廠支援的功能,LocalKit 則是靠原廠沒防到的地方撐起來的,原廠推一次 OTA 就可能整套失效。P592 在台灣大約 NT$5,000,花這個錢買一台要鎖韌體的餵食器,我覺得不划算。
查到這裡我大概懂為什麼整個品類都這樣了。攝影機品牌(Tapo、Reolink、EZVIZ、Imou)靠賣硬體賺錢,開放 RTSP 是賣點;餵食器品牌靠的是 App 和雲端訂閱,雲端錄影、AI 寵物辨識、遠端觀看都綁在自家 App 裡,開放串流等於把使用者送去用第三方 NVR。連有 RTSP 傳統的廠商做到餵食器也一樣:Imou(大華的消費線)的 PF1 餵食器攝影機,我在 iSpy 的 Imou 裝置表、HA 的 imou_life 整合和 Frigate 社群三個地方都找不到它支援 RTSP 的紀錄,而且台灣也沒有賣。
買之前拆 APK#
既然賣場頁面不會寫「支援本地 RTSP」,我改用另一個方法判斷:下載 App 的安裝檔,看它用了哪一家的影像 SDK。
其實就是 ZIP 檔,解壓縮之後 lib/ 資料夾裡的原生函式庫(.so 檔)會透露它用了哪家的影像傳輸 SDK。不用反編譯也不用安裝,看檔名就好:
| 看到這些函式庫 | 代表用了 | 能接進 Frigate 嗎 |
|---|---|---|
libtuya_*.so | 塗鴉(Tuya) | go2rtc 有 tuya://,但信令走雲端 |
libmiot*.so、libmiss*.so | 米家 | go2rtc 有 xiaomi://,影像強制走雲端 |
libIOTCAPIs.so、libAVAPIs.so | ThroughTek Kalay(TUTK) | go2rtc 沒有 tutk,要自己逆向 |
libagora-*.so | 聲網(Agora) | 商用雲端 RTC,沒有本地路徑 |
看到 TUTK 還不夠,還要看 App 有沒有呼叫 SDK 裡的區網直連功能。有些 App 包了 TUTK,卻只走雲端中繼,從來不試區網。這一步要再往下看 dex 位元組碼裡的呼叫,不過拿來分「完全沒機會」和「可能有機會」已經夠用。
我用這個方法掃了十個台灣買得到(或能代購)的品牌:
展開
| 品牌 | App 套件名 | 影像 SDK | App 有呼叫區網直連 | 判斷 |
|---|---|---|---|---|
| FurSpark | com.ddpai.cpp_overseas | TUTK Kalay | 有(12 處) | 有機會 |
| Dogness 多尼斯 | — | TUTK Kalay | 有(17 處) | 有機會 |
| CATLINK | — | TUTK Kalay | 有(15 處) | 台灣只賣無鏡頭款 |
| 小米米家 | — | TUTK + CS2 | 有 | 影像強制走雲端 |
| PETLIBRO | — | TUTK | 沒有 | 只走雲端中繼 |
| Petwant | — | TUTK | 沒有 | 只走雲端中繼 |
| PETKIT | — | Agora RTC | — | App 端沒有本地路徑 |
| Petoneer | — | Agora RTC | — | 同上 |
| Hama Home(德國) | — | Tuya | — | App 底層全是 Tuya |
| maoxga 喵享家 | — | Agora RTC | — | 鏡頭確定接不出來 |
有幾個是拆了才知道的。PETKIT 用的是 Agora 而不是 TUTK,我原本以為它跟 PETLIBRO 一樣走 Kalay,這也說明了 LocalKit 為什麼非得改機器本身:App 端根本沒有區網路徑可用。德國 Hama 的自有 App 底層整個是 Tuya,從外面完全看不出來。喵享家的 App 裡則意外包了 Matter SDK,餵食的部分也許支援 Matter,但攝影機是 Agora,一樣接不出來。
要注意的是,App 有呼叫區網直連,只代表開發者寫了這段程式,裝置的韌體有沒有對應的處理,要機器到手才知道。反過來就很可靠:App 完全沒有區網直連的呼叫,就可以直接排除。
最後選 FurSpark#
篩完剩兩台有機會,Dogness F10 和 FurSpark Big Eye,我把原本考慮的 P592 也放進來比:
| FurSpark Big Eye | Dogness F10 | PETKIT P592 | |
|---|---|---|---|
| 解析度 | 2K | 1080P | 1080P |
| 視角 | 廣角(官方沒公布數值) | 165° | 140° |
| 糧倉 | 3.7L | 3.6L | 雙料倉 |
| 儲存 | 內建 64GB、48 小時回放 | — | — |
| 特殊功能 | 機械眼瞼實體遮住鏡頭 | 乾電池備援 | 貓臉辨識 |
| 影像 SDK | TUTK(有區網直連) | TUTK(有區網直連) | Agora(沒有本地路徑) |
| 接進 Frigate | 要自己逆向 | 要自己逆向 | 要靠 LocalKit 改機 |
| 台灣最低價 | NT$3,990 | NT$4,200(momo 促銷) | 約 NT$5,000 |
FurSpark 硬體最好也最便宜。App 的套件名 com.ddpai.cpp_overseas 還透露了開發商是深圳的盯盯拍(DDPai),一家做行車記錄器的公司,「美國 Furspark」只是行銷包裝。這對我來說反而是好消息,DDPai 的行車記錄器有人公開拆解過,有本地 HTTP 介面的前例,代表除了 TUTK 之外可能還有別條路。
老實說買的時候我沒把握一定接得進 Frigate,資料都指向「有機會」,但沒有人做過。會下單是因為就算失敗,它照樣是一台能定時餵、能用 App 看的餵食器,我也不打算改韌體,最壞就是家裡多一台普通的餵食器。
影像:TCP 6200#
2026 年 9 月 13 日餵食器到貨,裝好、餵完貓、連上 Wi-Fi,開始找影像。
找串流#
先用 nmap 掃開放的埠,554 上跑著 Hisilicon RTSP Streaming Media Server/1.0.0,看起來很有希望,結果試了十幾條路徑全部回 400 或 500。中間我還犯了一個低級錯誤:RTSP 請求要用絕對 URI(rtsp://host:554/path),我送了相對路徑,被回 400 還以為是伺服器壞了。改對之後 OPTIONS 正常回 200,但 DESCRIBE 只有一條路徑回 500(認得、但拿不到媒體),其他都是 400(不認得)。RTSP 服務是活的,只是沒有媒體源掛在上面。
這台也沒有 ONVIF。裝置回報的型號是 DDPaiQ3,晶片是 Rockchip RV1126,hostname 還留著原廠預設的 RV1126_RV1109。
接著試其他埠,TCP 6200 一連上就開始吐二進位資料。用十六進位看,每段資料前面都有 8 bytes 的標頭:
0a 0b 0c 00 [4 bytes 大端長度] → 關鍵幀(I-frame)
0a 0b 0c 01 [4 bytes 大端長度] → 一般幀(P-frame)
前三個 byte 固定是 0a 0b 0c,第四個區分幀的類型,後面四個是這一段 H.264 的長度。我本來寫了一支腳本把標頭剝掉再交給 ffmpeg,後來發現不用剝:ffmpeg 讀 H.264 時是靠資料裡的起始碼找每一幀,這 8 bytes 會被當成雜訊跳過,直接讀也是零解碼錯誤。
用 ffprobe 量到的規格:
| 項目 | 值 |
|---|---|
| 解析度 | 1664 × 2224(直式) |
| 幀率 | 25 fps |
| 編碼 | H.264 High profile, level 5.0 |
| 碼率 | 約 2530 kbps(一天約 15 GB) |
| 音訊 | 沒有 |
| 關鍵幀間隔 | 4 秒 |
畫面是直的。官方頁面寫新款「expanding the upper and lower visual range from the previous 16:9 aspect ratio」,我猜是把行車記錄器的感光元件轉 90° 裝,換取上下的視野。
這組規格不是固定的。我回頭用 ffprobe 量歷史錄影,第一天是 576×768、level 3.1,隔天變成 1664×2224、level 5.0,應該是 App 裡的「視頻品質」被改過(現在設在「超清」)。Frigate 的 detect 解析度要跟著改,不然偵測時會被縮放,影響準確度。
go2rtc 設定#
整條路是這樣接的:
主機上的 go2rtc 負責連裝置,Frigate 從它拉一份來偵測和錄影,手機和瀏覽器看的則是 Frigate 轉出來的 restream,再合上音訊。繞這一圈是因為 6200 只能有一條連線,我跟 C210 用的是同一套做法。設定如下,IP 換成你自己的:
rtsp:
listen: ":8554"
streams:
# 連裝置的唯一一條連線
weishiqi: "exec:ffmpeg -hide_banner -v error -f h264 -i tcp://192.168.x.x:6200 -c copy -user_agent ffmpeg/go2rtc -rtsp_transport tcp -f rtsp {output}"Frigate 那邊照一般的 RTSP 鏡頭設,來源填 rtsp://<主機>:8554/weishiqi,roles 寫 [record, detect],因為這台只有一條串流,錄影和偵測只能共用。
幾個踩過的地方:
- 6200 只能開一條連線。 同時開第二條,camera_fps 會衝到 100 以上、冒出一堆 NAL 錯誤,整條串流壞掉。手機 App 連上去看的時候也可能搶到。
-f h264要自己加。 用 go2rtc 內建的ffmpeg:tcp://…寫法時,ffmpeg 要先猜輸入格式,剛連上常常猜不出來,一直報Invalid data found when processing input重試。有兩次裝置斷線回來後黑了大約 5 分鐘,同一時間我手動ffprobe -f h264一次就讀到畫面。所以改成exec:自己寫 ffmpeg 指令,參數照抄 go2rtc 原本產生的那串,只多加-f h264。listen要綁全部介面,再用防火牆擋。 go2rtc 的 ffmpeg 來源在內部會把串流推回127.0.0.1的 8554,loopback 沒在聽就會失敗;Frigate 容器也要從主機拉。所以我綁:8554,再用 ufw 只放行 Frigate 容器的網段,其他一律拒絕。少了拒絕那條,區網裡任何裝置都看得到這顆鏡頭。- 浮水印不用遮。 畫面左下角有「Forspark Big Eye」和逐秒跳的時間戳,但縮到 Frigate 偵測動作的解析度之後只剩大約 1 個像素,比
contour_area的門檻小很多,自己就被濾掉了。上一篇的 C210 就沒這麼幸運,時間戳得遮掉。
開畫面要等 3 秒#
這台的關鍵幀固定每 4 秒一個,新連線要等到下一個關鍵幀才能開始解碼,平均等 2 秒、最久 4 秒。C210 大約 0.1 到 1.7 秒,App 裡也沒有能調關鍵幀間隔的選項。
後來加上音訊又多慢了 3 秒:ffmpeg 預設會先花大約 3.2 秒探測輸入格式,而 go2rtc 是一個來源接一個來源依序啟動的,這 3 秒會直接加在開畫面上。音訊那條加上 -f aac -probesize 32 -analyzeduration 0 之後降到 0.2 秒,現在開畫面大約 3 秒。
餵食控制#
影像走本地,餵食控制則走雲端,兩條路完全分開。裝置的狀態和指令都經過廠商自己的 broker。我從 App 裡逆出連線方式和指令格式,寫了一支 Python daemon(furspark_ha.py),一邊連廠商的 MQTT 讀狀態,一邊用 MQTT discovery 把東西推進本地的 Home Assistant。
最後在 HA 裡長出 22 個 entity,全掛在同一台裝置底下:
| 類型 | 項目 |
|---|---|
| sensor | 餘糧等級、餵食計劃、今日計劃出糧份數、下次投餵時間、乾燥劑剩餘天數、儲存空間剩餘與使用率、視訊品質、韌體版本 |
| binary_sensor | 線上狀態、故障 |
| switch | 攝影機開關、指示燈、童鎖、麥克風、餵食提醒、餵食語音 |
| number | 喇叭音量、按鍵每次份數、餵食份量 |
| button | 立即餵食、餵 1 份 |
| text + button | 計劃編輯器(格式 07:30x40, 18:00x2)、套用計劃、啟用計劃 |
幾個一開始搞錯的:
- 餘糧是等級,不是百分比。 裝置回傳 0(充足)、1(偏少)、2(耗盡),我一開始當成 0 到 100 在用,結果剛裝滿的時候 HA 顯示 0%。
- 1 份大約 1 克。 這是我自己秤出來的,說明書只寫「隨飼料密度變動、不可調」。兩隻貓早上吃 40 克,所以計劃設 40 份。我原本把 HA 上限設成 10,後來試過裝置接受到 99 份都沒問題。
- 只有常駐模式(
--daemon)才會推開關和按鈕。 單次執行只推 sensor,因為開關和按鈕要有人在聽指令才有用。
daemon 裝成 systemd 服務開機自動啟動,每 10 分鐘輪詢一次狀態。在 HA 裡切開關是即時的,指示燈和攝影機開關我都試過,按下去到裝置反應不到一秒。餵食按鈕我沒有特別測,按了會真的出糧,留給需要時手動按。
收音和對講#
6200 那條串流沒有音軌,但裝置自己的錄影檔裡有 AAC 音訊,所以麥克風是好的,只是聲音不在那條路上。
TUTK 橋接#
聲音走的是 TUTK 的 P2P,go2rtc 支援的 41 種來源裡沒有它,只能自己接。我的做法是從 App 的 APK 裡拿出 arm64 版的 TUTK 函式庫(libIOTCAPIs.so、libAVAPIs.so 等),用 在 x86 的伺服器上跑,再用 Python 的 ctypes 呼叫裡面的函式建立連線、收音訊。
這是整件事裡最花時間的一段。這些函式庫是為 Android 編譯的,Android 的 C 函式庫(bionic)跟一般 Linux 的(glibc)有好幾個地方不相容,每一個都會讓程式直接崩潰,只能一個一個寫 shim 攔下來:
展開
| 問題 | 症狀 | 解法 |
|---|---|---|
pthread_mutex_t 大小不同 | bionic 4 bytes、glibc arm64 48 bytes,TUTK 的 FIFO 內嵌 bionic 大小的 mutex,segfault | shim 攔截 pthread_mutex_*,用物件位址當 key,另外維護真正的 glibc mutex |
struct addrinfo 欄位順序不同 | bionic 的 ai_canonname 和 ai_addr 位置對調,變成野指標 | shim 攔截 getaddrinfo,轉成 bionic 的排列 |
| init_array 裡有 null | bionic 的 linker 會跳過,glibc 直接呼叫位址 0,segfault | 掃過每個函式庫,全是 null 的 init_array 把 DT_INIT_ARRAYSZ 歸零 |
__errno 名稱不同 | bionic 叫 __errno,glibc 叫 __errno_location | shim 轉接 |
_ctype_ 型別不同 | bionic 的 _ctype_ 是 const char*,給陣列會被當成野指標 | shim 提供指標版本 |
橋接程式是一個按需啟動的 TCP 服務:go2rtc 連進來(有人在看畫面)時才去連裝置、開始收音訊、輸出 AAC;沒人看就把連線放掉,不佔裝置的 P2P 連線數。go2rtc 那邊把它當第二個來源,跟影像合在一起:
weishiqi_view:
- "rtsp://<Frigate 容器 IP>:8554/weishiqi"
- "exec:ffmpeg -hide_banner -v error -fflags nobuffer -probesize 32 -analyzeduration 0 -f aac -i tcp://<橋接 IP>:6202 -map 0:a:0 -c:a:0 libopus -application:a:0 lowdelay -min_comp 0 -map 0:a:0 -c:a:1 aac -vn -rtsp_transport tcp -f rtsp {output}"平常跑起來 CPU 大約 5%(一顆核心)、記憶體 67MB、音訊流量約 65kbps。我原本擔心 24 小時跑 qemu 會很吃資源,實際上吃資源的只有建置那一下,平常很輕。
踩到的坑#
連線密碼會過期。 這個密碼是透過雲端 API 算出來的,幾天就失效。失效時連線會默默失敗,錯誤碼還是「逾時」而不是「密碼錯誤」,我花了不少時間才發現是密碼的問題。現在用 crontab 每 6 小時重算一次。
音訊斷掉會連影像一起黑掉。 go2rtc 合併多個來源時,只要其中一個起不來,整條串流就起不來。有一次裝置端的音訊服務沒回應,餵食器的畫面就跟著全黑,go2rtc 還一直重試。後來改成橋接只要有人連著就一定吐得出音軌:真的音訊斷超過 600ms 就補靜音,連不上裝置就用指數退避慢慢重試。
外網要有 Opus 才順。 一開始只轉出 AAC,在家看沒問題,出門用手機看就一直卡。原因是 WebRTC 不支援 AAC,HA 的播放卡片會優先挑「影像加聲音都有」的那一種,結果選了走 WebSocket 的 MSE,外網一卡就看得出來。現在同時轉出 Opus 給 WebRTC、AAC 給 Safari 這類用 MSE 的,16kHz 單聲道的轉檔成本可以忽略。
對講#
送話的方向我也逆出來了,裝置收的是 AAC-LC 16kHz 單聲道 ADTS,跟收音的格式一樣。找出這個格式的方法很土:四種候選格式各配一個嗶聲次數不同的音檔(1 到 4 聲),一次全部送出去,我站在餵食器旁邊數聽到幾聲,聽到三聲就是第三種。
中間卡了六天,一直以為是格式錯,四輪試了不同的編碼都沒聲音。最後發現是 Python 的 struct.pack 把毫秒時間戳塞進有號 int32,數字超過 2^31 就丟 struct.error,程式在送出第一幀之前就掛了,前面四輪其實一幀都沒送出去過。
從瀏覽器麥克風直接對講則沒做成。go2rtc 的 exec: 來源理論上支援反向的音訊通道,但瀏覽器切到對講模式時 go2rtc 一直沒有啟動那條連線,換了幾種音訊格式和接法都一樣,我沒找到原因。現在的做法是在 HA 放一個按鈕,按了播一段預錄的提示音,叫貓來吃飯夠用了。
分貓有沒有變準#
這是上一篇留下來的問題。餵食器的鏡頭在機器上方,不鏽鋼碗在畫面最下緣,貓吃飯時臉正對鏡頭,距離大約 40 公分,臉佔畫面寬度約 37%,客廳 C210 從 3 公尺外拍只有 6%。
我先在 Frigate 裡畫了一個 feeder_bowl 區域,蓋住畫面最下面 5%,貓在裡面待滿 10 秒才算一次「到訪」。這個範圍是拿歷史事件抽樣定的:偵測框底邊座標 ≥ 0.95(貼著畫面最下緣)的事件抽 8 張,8 張都在吃;0.88 到 0.95 之間抽 8 張,只有 2 張在吃。還沒加區域之前,daemon 算的是貓在整個畫面停留 10 秒以上,一天會冒出 30 幾次,大多是貓在餐桌或櫃子上;加了之後每天大約 7.5 次,比較合理。Frigate 常把一頓飯切成好幾個事件,所以同一隻貓兩筆間隔不到 2 分鐘的,我合併成一次。HA 裡因此有兩個 sensor:aki 和 kuro 今天各來了幾次。
我刻意叫它「到訪」而不是「進食」。鏡頭只能確定貓在碗前面待了多久,不能確定牠真的在吃,也可能只是蹲著或在理毛。
至於分得出是誰,要分兩件事講。第一件是 Frigate 願不願意給名字:我拿裝好後頭兩天的 121 筆貓事件,照貓在畫面裡的大小分組算過,貓只佔畫面一角的事件,有標上 aki 或 kuro 的只有 29%;佔畫面 12% 以上的近拍,標上名字的比例是 90%,在碗前待超過 30 秒的 10 筆全部都有名字,信心分數中位數 0.97。沒標上名字的幾乎都是背景走過去幾秒的小影子,近拍確實讓模型有把握得多。
第二件是標得對不對,這個我還沒驗。上一篇的教訓就是模型很有把握、結果比亂猜還差,所以 90% 只能說明它敢給名字,不能說明它認對了。要驗還是得用上一篇的同框方法,或是我自己看著畫面一筆一筆對,資料累積夠了再補上。
跟 Furbo 比#
| Furbo 360° + 寵物保姆訂閱 | 這套 | |
|---|---|---|
| 硬體 | NT$5,399(不綁約單機) | NT$3,990(餵食器本身也能餵) |
| 年費 | NT$1,840 起 | 0 |
| 錄影 | AI 判斷的片段,保留 3 到 7 天 | 連續錄影,天數看硬碟(我設 3 天) |
| 雙向通話 | 有 | 只能播預錄提示音 |
| 丟零食 | 有 | 沒有,改成定時餵食 |
| 分辨每一隻 | 訂閱功能(多寵辨識) | 近拍標名字的比例 90%,正確率還沒驗 |
| 資料放哪 | Furbo 雲端 | 家裡的硬碟 |
現在家裡有兩顆鏡頭進 Frigate,餵食器這顆一天大約 15GB 錄影,跟 C210 的 10GB 放在同一顆硬碟上;GPU 使用率大約 6%。常駐的服務多了三個:furspark-ha(餵食控制)、tutk-audio-bridge(音訊)和主機上的 go2rtc。
還有一件事沒做。這台的 RTSP 服務是活的,只是沒有媒體源,我在社群公開的行車記錄器韌體字串表裡找到兩個看起來像「開啟 RTSP」的指令,試了也許能直接拿到帶聲音的 RTSP 串流,整個 TUTK 橋接就能省掉。不過那會改到裝置的狀態,我不想冒險弄壞現在已經穩定的 6200,所以先放著,等哪天韌體更新把什麼東西弄壞、反正得重新設定的時候再試。