ペットフィーダーカメラはすべてクラウドロック

うちには2匹のキジトラがいる。aki と kuro だ。前回の記事ではリビングの Tapo C210 を Frigate に接続して、録画の振り返り・猫日記・毎日のハイライト動画を作った。だが C210 は壁掛けでリビング全景を撮っていて、きゅうじエリアがちょうど死角になっていた。

カメラと自動給餌機能を兼ね備えたデバイスを探して、この視角を補いたかった。シンプルに見えた——ペットフィーダーカメラ1台、映像ストリームを Frigate に取り込めればいい。

結果、10ブランドを調べてようやくひとつの事実がわかった：この製品カテゴリには映像ストリーミングを開放している機種が1台もない。一部が RTSP 非対応なのではなく、カテゴリの構造としてそうなっている。

すべてクラウドロック——偶然ではない#

最初に見たのは米家スマートペットフィーダー 2 カメラ付きモデル。2026年3月にクラウドファンディングで発売、500万画素・150°超広角・940nm赤外線ナイトビジョン・5Lタンク・しょうりょう機能付き。しかも go2rtc のソースコードで、xiaomi ソースのデバイスフィルター条件に .feeder. が明示的に含まれている——完璧に見えた。

ところが go2rtc の xiaomi モジュールのソースを読み込むと問題が見つかった。映像伝送の経路は2つしかない——Xiaomi 独自のクラウドリレー（CS2）か ThroughTek Kalay（TUTK）P2P で、どちらもクラウド経由。「鍵交換がオンライン、映像は LAN」ではなく、映像自体がクラウドを通る。外部接続を遮断するとストリームが即座に切れる。

比較対象として既に使っている C210：Tapo の RTSP は純粋な LAN 通信で、ルーターの外部接続を切っても録画・検知はすべて正常に動く。Xiaomi のカメラはアーキテクチャ的にまったく別物だ。

台湾ではカメラなしの標準版しか公式販売されていない。カメラ付きは中国版（人民元449 ≈ NT$2,000）で、淘宝か代購が必要、保証なし。加えて Xiaomi のセキュリティ実績——2020年に Google Nest Hub で他人の Xiaomi カメラ映像が表示される事件、2021年に ThroughTek Kalay の CVSS 9.6 のぜいじゃくせいが公開（約8,300万台に影響）——買わないことにした。

PETKIT + LocalKit：クラウドフリー化の代償#

次に見つけたのは PETKIT YumShare Dual Gen2（P592）。ローカルストリーミングには非対応だが、GitHub に LocalKit というサードパーティプロジェクトがあり、PETKIT デバイスを完全にクラウドフリー化できると謳っている（カメラストリーミング含む）。

デプロイドキュメントを読んで諦めた。必要なもの：

1. DNS リライト——PETKIT のクラウドドメインをローカルサーバーに向け、デバイスにメーカーに接続していると思わせる
2. 証明書信頼の変更——デバイスに cert pinning があり、証明書信頼チェーンを変更する必要がある
3. ローカル MQTT broker——コンテナで PETKIT のクラウド broker をエミュレートする
4. デバイス上で go2rtc を実行——カメラ付きの各デバイスで go2rtc を個別に実行
5. ファームウェアをバージョン 895 に固定——インストールスクリプトが特定バージョンのみ対応、PETKIT の自動更新を許可できない

しかも1人でメンテナンスしているプロジェクトだ。Tapo の RTSP はメーカー公式の機能。PETKIT のローカルストリーミングはメーカーの見落としに乗っかった一時的な足場——メーカーが OTA を出せば全部崩壊しうる。

P592 の台湾価格は約 NT$5,000。ファームウェアを固定して DNS リライトが必要なフィーダーにその金額を出すのは、方向性が違う気がした。

構造的な理由：なぜどのメーカーも開放しないのか#

数台を調べ終えて、このカテゴリ全体が映像ストリーミングを開放しない理由が理解できるようになった。

カメラブランド（Tapo、Reolink、EZVIZ、Imou）はハードウェアで稼ぐので、RTSP 開放はセールスポイントになる。フィーダーブランドが頼りにしているのはアプリのスティッキネスとクラウドサブスクリプション——クラウドストレージ、AI ペット認識、リモート視聴、すべて自社アプリにかこいこみ。ストリーミングを開放すればユーザーをサードパーティ NVR に追いやることになり、サブスク契約は売れなくなる。

購入前にどう判断するか：APK を解体して映像 SDK を見る#

ショッピングページに「ローカル RTSP 対応」とは書いてない。では購入前にフィーダーの映像を取り出せるかどうか、どう判断するか？

方法は実にシンプル：アプリのインストールファイルをダウンロードし、解凍してどの映像 SDK を使っているか見る。

APK は本質的に ZIP ファイルで、lib/ フォルダ内のネイティブライブラリ（.so ファイル）がどの映像伝送 SDK を使っているか暴露する。デコンパイル不要、インストール不要、ファイル名を見るだけ：

「TUTK ライブラリがある」だけでは不十分。鍵は、アプリが SDK のLAN 直接接続機能を呼び出しているかどうかだ——TUTK SDK を含んでいてもクラウドリレーしか使わず、LAN 接続を試みないアプリもある。これをさらに深く dex バイトコードの呼び出しを見て判断する必要があるが、「まったく無理」vs「可能性あり」の判断には十分だ。

これがゼロコストの購入前スクリーニング#

この方法で台湾で購入可能（または代購可能）な10ブランドをスキャンした：

いくつかの意外な発見があった：

• PETKIT が使っているのは Agora であり、TUTK ではない。最初は PETLIBRO と同じ Kalay だと思っていたが、まったく違った——これは LocalKit がデバイスに直接入る必要がある理由も説明している：App 側に LAN パスがまったくないのだ。
• ドイツの Hama の独自 App は中身が 100% Tuya。外からは見分けがつかないが、中を開けば一目瞭然。「Tuya かどうか調べられない」のは事実だが、「調べる方法がない」のは嘘だ。
• maoxga の App で Matter SDK が偶然見つかった。給餌側は Matter 対応の可能性がある。だがカメラ部分は Agora なので、ローカルパスがないのは確実。

最終的に FurSpark を選んだ#

ふるいにかけて残ったのは2台：Dogness F10 と FurSpark Big Eye。

FurSpark はハードウェアが最も良く、価格が最も安い。しかも App のパッケージ名 com.ddpai.cpp_overseas が面白い事実を明かしている：開発元はシェンジェンの盯盯拍（DDPai）、ドライブレコーダーの会社だ。「アメリカの Furspark」はマーケティング上の包装に過ぎない。

これはむしろ好材料だ——DDPai のドライブレコーダーは公開分解の前例があり、ローカル HTTP インターフェースの実績がある。つまり TUTK P2P 以外にも第二の経路がありうる。

映像接続：ひとつの独自 TCP ポート#

2026年9月13日、フィーダーが届いた。セットアップして猫にごはんをあげて、Wi-Fi に接続してから映像を探し始めた。

RTSP はないが、daemon は生きている#

nmap でデバイスの開放ポートをスキャンすると、554 で Hisilicon RTSP Streaming Media Server/1.0.0 が動いていた。しかし十数パスを試してもすべて 400 か 500 が返ってくる——メディアソースがマウントされていない。RTSP daemon は生きているが、コンテンツを供給している者がいない。

ONVIF はなし。デバイスが報告する型番は DDPaiQ3、SoC は Rockchip RV1126——hostname はメーカーの RV1126_RV1109 がそのまま残っていた。

独自 TCP 6200#

他のポートに目を向けた。TCP 6200 に何かある：接続するとバイナリデータが流れ始めた。各パケットの先頭に 8 バイトのヘッダがあり、16進数で見ると：

0a 0b 0c は固定のマジックバイト、4バイト目がフレームタイプを区別し、続く4バイトがこの NAL ユニットの長さ。ヘッダを剥がして残りをそのまま ffmpeg に渡すと、デコードエラーゼロ。

ffprobe で計測したスペック：

ポートレート映像。公式ページに「expanding the upper and lower visual range from the previous 16:9 aspect ratio」との記述がある——前世代は 16:9、新型はイメージセンサーを90°回転させて搭載し、上下方向の視野を拡大。ドライブレコーダーの部品からの転用だ。

アーキテクチャ：デバイス → go2rtc → Frigate#

go2rtc は exec:ffmpeg ソースでデバイスの TCP 6200 に接続し、ffmpeg が生の H.264 バイトストリームを受信して RTSP に変換する。Frigate は go2rtc から RTSP をプルし、検知と録画を担当。ブラウザは WebRTC で go2rtc から直接映像を取得する。

いくつかの落とし穴：

• 接続は1本しか開けない。 TCP 6200 に同時に2本目の接続を開くと、camera_fps が 100 以上に跳ね上がり、NAL エラーが出て、ストリーム全体が壊れる。スマホアプリの接続時も同様の競合が起きうる。
• go2rtc は全インターフェースにバインドする必要がある（:8554）。 ffmpeg producer が内部でメディアを rtsp://127.0.0.1:${port} にパブリッシュするため、loopback がリッスンしていないとセルフループが失敗する。ファイアウォールルールで保護する——Frigate コンテナのネットワークセグメントのみ RTSP プルを許可し、他は拒否。
• ウォーターマークはマスク不要。 画面左下に「Forspark Big Eye」と秒単位のタイムスタンプがあるが、Frigate のモーション検知解像度に縮小すると約1ピクセルの面積しかなく、contour_area の閾値よりはるかに小さいため自動的にフィルタされる。

映像表示まで数秒かかる#

デバイスのキーフレーム間隔は固定4秒で、新しい接続は次のキーフレームを待ってからデコードを開始する。平均待ち時間2秒、最悪4秒。C210 は約 0.1〜1.7 秒。App にキーフレーム間隔を調整するオプションはない。

音声側の ffmpeg が入力フォーマットをプローブするのも映像表示を遅くする（go2rtc は producer を順番に起動する）。-f aac -probesize 32 -analyzeduration 0 を追加したところ、~3.2 秒から 0.2 秒に短縮。合計で映像表示まで約3秒。

給餌制御：クラウド MQTT を Home Assistant にブリッジ#

映像はローカル、給餌制御はクラウド。2つの経路は完全に分離している。

デバイスのリアルタイム状態と制御コマンドはメーカー独自の MQTT broker を使っている。App から接続方法とコマンド形式をリバースエンジニアリングし、Python daemon（furspark_ha.py）を書いた。メーカーの MQTT に接続して状態を読みつつ、MQTT discovery でローカルの Home Assistant にプッシュする。

22 エンティティ、すべて同一デバイスの配下#

間違えやすいポイント：

• 残量はレベルであってパーセンテージではない。 デバイスが返す値は 0（十分）、1（やや少ない）、2（空）であり、0–100 ではない。最初パーセンテージとして使ったところ、「満タンなのに 0% 表示」になった。
• 1分 ≈ 1グラム。 実測による。説明書には「フード密度により変動・調整不可」とある。2匹の猫が朝40グラム食べるので、40分に設定。上限は実測で 99 まで受け付けた。
• 常駐モード（--daemon）でのみ制御項目をプッシュする。 ワンショットモードは sensor のみプッシュ——スイッチやボタンはコマンドをリッスンする相手がいないと意味がないため。

daemon は systemd サービスとしてインストールし、起動時に自動実行。10分ごとに状態をポーリング。HA でスイッチを切り替えると即時反映——インジケータライトとカメラスイッチで実測済み、コマンド送信からデバイス状態変更まで1秒未満。給餌ボタンは実テストしていない（実際にフードが出る）ので、手動操作に任せた。

リアルタイム音声と双方向通話#

TCP 6200 のストリームには音声トラックがない。しかしデバイスの録画ファイルには AAC 音声が含まれている。マイクは正常——音声がこのパスに乗っていないだけだ。

TUTK P2P ブリッジ#

音声は ThroughTek Kalay（TUTK）の P2P プロトコルを使っている。go2rtc の41種のソースプロトコルには tutk がないため、自力でブリッジを構築する必要がある。

App の APK から arm64 版の TUTK SDK ライブラリ（libIOTCAPIs.so、libAVAPIs.so 等）を抽出し、qemu-user-static で x86 ホスト上で実行。Python の ctypes で SDK 関数を呼び出して P2P セッションを確立し、音声を受信する。

これがプロジェクト全体で最も困難な部分だった。TUTK SDK は Android（bionic libc）向けにコンパイルされており、Linux（glibc）で動かすには複数の ABI 非互換性を shim でう かいする必要がある：

ブリッジのアーキテクチャはオンデマンド TCP サーバー。go2rtc が接続してきた（誰かが映像を見ている）時だけ TUTK に接続し、音声受信を開始して AAC-ADTS を出力。誰も見ていない時はセッションを解放し、デバイスの P2P 接続数の占有を避ける。

定常状態のリソース消費：CPU ~5%（1コア）、RAM 67MB、音声トラフィック ~65kbps。「24時間365日 qemu ブリッジを動かすとリソースを食う」という心配は杞憂だった——それはビルド時の瞬間的なピークであり、定常状態では極めて軽い。

いくつかの落とし穴#

認証が期限切れになる。 接続に必要なパスワードはクラウド API から算出され、数日で失効する。失効すると DTLS ハンドシェイクが静かに失敗し、エラーコードは「タイムアウト」であって「パスワード不正」ではない——認証の問題とはまったくわからない。現在は crontab で6時間ごとに再計算している。

音声が切れると映像も道連れになる。 go2rtc のマルチソースマージは「全か無か」で、音声ソースが接続できないとストリーム全体が立ち上がらず、映像まで真っ暗になる。修正方法はブリッジを「クライアントがいる限り常に音声トラックを出力できる」ようにすること——実音声が600ms以上途切れたら無音フレームを補填し、TUTK 接続失敗は指数バックオフでリトライ。

WebRTC には Opus が必要。 音声を AAC のみで渡すと、WebRTC は対応できず（AAC 非サポート）、ブラウザが MSE にフォールバックし、外部ネットワークでカクつく。Opus トランスコーディングを追加したところ、WebRTC で音声が通るようになり、外部ネットワークでもスムーズになった。

双方向通話#

送話プロトコルもリバースエンジニアリングした。デバイスは AAC-LC 16kHz mono ADTS 形式の音声を受け付ける（受信側と同一）。正しいコーデックの特定方法は力技：4種類の候補フォーマットにそれぞれ異なるビープ数の音声ファイル（1/2/3/4回）を用意し、一気に送信。フィーダーのそばで人にビープ数を数えてもらう——第3組の回数だけ聞こえたら、それが正しいフォーマットだ。

リアルタイム通話（ブラウザのマイクから直接話す）は実現できなかった。go2rtc の exec: ソースには backchannel サポートがあり、理論上は可能だが、ブラウザが通話モードに切り替わっても go2rtc が producer を起動しない。各種音声フォーマットとアーキテクチャを試したが同じで、根本原因は特定できなかった。現在の代替案は HA にボタンを置き、押すと録音済みの呼び出し音を再生すること——猫をごはんに呼ぶには十分だ。

フィーダーカメラでの猫の個体識別#

フィーダーのカメラは本体上部に搭載されており、ステンレスボウルは画面の最下端にある。猫が食べている時、顔はカメラに正対しており、距離は約40cm、顔が画面に占める割合は約37%——C210 が3m離れて撮った6%よりはるかに大きい。理論上、aki と kuro の識別はもっと容易なはずだ。

ボウル前エリア#

Frigate で feeder_bowl ゾーンを定義し、画面下部5%をカバー。このゾーン内に10秒以上滞在した猫だけを「訪問」とカウントし、ボウル脇を通り過ぎるだけのケースをフィルタする。

過去のイベントでこの設定を検証：バウンディングボックス下端座標 ≥ 0.95 のイベントから8枚抽出したところ、8枚とも食事中。0.88 から 0.95 の間では、8枚中2枚だけが食事中。10秒のしきい ちとゾーン制限で、誤検知率は非常に低い。

ゾーン追加前、daemon は「リビング全体に10秒以上滞在した猫」をカウントしていた——カメラはリビング全体を捉えているため、1日30回以上に膨れ上がり、大半は猫がダイニングテーブルや棚の上にいるだけで、食事ではなかった。ゾーン追加後は1日約7.5回まで減少し、妥当な数字になった。

食事の統合#

daemon は Frigate のイベント API から「今日 feeder_bowl ゾーンで検知された猫」をプルし、同一の猫で2つのイベント間隔が2分未満のものを同一食事として統合（Frigate は1回の食事を複数のイベントに分割しがち）。HA に2つの sensor がある：aki と kuro のそれぞれの当日訪問回数。

全体が稼働している状態#

Furbo との比較：

最後にひとつ。このフィーダーの RTSP daemon は生きているが、メディアソースがマウントされていない。ファームウェアに「RTSP を有効化する」ように見えるコマンドが2つある（名前はコミュニティで公開されているドライブレコーダーのファームウェア文字列テーブルから見つけた）。試せば音声トラック付きの RTSP ストリームが直接得られるかもしれない。しかしそれはデバイスの状態を変更することになり、現在安定稼働している 6200 のライブストリームが中断するリスクがある。まだ試していない。いつかファームウェアアップデートで何かが壊れて、再設定を余儀なくされた時のために取っておく。