なぜスマートホームサーバーは複数のMatterコントローラーに依存するのですか？

スマートホームサーバーは、複数のプラットフォームが独立した信頼、ローカル制御、自動化、またはユーザーアクセスを必要とする場合にのみ、複数のMatterコントローラーに依存します。

MatterはApple Home、Google Home、Home Assistant、その他のエコシステムを1つの共有コントローラーに統合するわけではありません。各プラットフォームは通常、自身のファブリックを作成・管理し、デバイスはMulti-Admin共有を通じて追加のファブリックに参加します。したがって、独自のローカルルールを実行する必要があるホームサーバーは、他のプラットフォームのダッシュボードを借りるのではなく、自身のコントローラーメンバーシップを持つ必要があります。以下のセクションでは、なぜコントローラーが増えるのか、各ファブリックが何を保存するのか、そして同じデバイスが複数のアプリに表示されてもどの責任が分離されているのかを説明します。

各プラットフォームは独自のコントローラー役割を使用する

Matterコントローラーは、自身のファブリックに属するデバイスに操作コマンドを送信します。コントローラーはハブ、スマートスピーカー、電話、サーバープロセス、またはアプリケーションで動作することがありますが、プラットフォームが管理するセキュリティと権限モデルの中で機能します。

Connectivity Standards AllianceはMatterコントローラーを、接続されたデバイスを制御するエンティティとして定義しています。通常、1つの会社のコントローラーはその会社のプラットフォームにサービスを提供するため、別のプラットフォームは独自のコントローラー関係を必要とします。

このため、HomePodはApple Homeにライトを公開しても、自動的にHome Assistantサーバーにそのライトの権限を与えるわけではありません。両プラットフォームはMatterを理解していますが、デフォルトでは1つのコントローラーIDを共有しません。

Multi-Adminはデバイスを複数のファブリックに追加する

Matter Multi-Adminは、すでにコミッショニング済みのデバイスが別の管理者のためにコミッショニングウィンドウを開くことを可能にします。2つ目のエコシステムは独自の認証情報を確立し、デバイスを別のファブリックに追加し、最初のプラットフォームを通じてリモート操作するのではありません。

Home Assistantは複数のMatterファブリックを、同じデバイスがGoogle Home、Apple Home、Home Assistantに同時に参加できる仕組みとして説明しています。各ファブリックは独立した信頼ドメインのままです。

デバイスは各メンバーシップのためにファブリック認証情報、アクセス制御情報、操作状態を保存する必要があります。したがって、Multi-Adminは直接的なローカルアクセスを拡大しますが、コミッショニング、削除、バックアップ、トラブルシューティングのためのコントローラー関係も増やします。

表示されるアプリの数が必ずしも物理的なハブの数と一致するわけではありません。常時稼働の1台のデバイスが複数のコントローラー機能をホストすることもあれば、1つのエコシステムが可用性や便利な制御のために同じファブリック上で複数のコントローラーを使うこともあります。

ホームサーバーはローカル自動化のために独自のファブリックを必要とする

サーバーは認証し制御できるデバイスに対してのみ直接的なMatter自動化を実行できます。別のエコシステムのアプリでデバイスが見えても、サーバーにローカルコマンドを発行するための鍵や権限は与えられません。

Home AssistantはHome Assistantファブリックがデバイスを直接コミッショニングするか、別のファブリックからの共有を受け入れることができると説明しています。一度参加すると、サーバーはそれらのエンティティを自身の自動化に公開でき、すべてのコマンドをApple、Google、または他のクラウドサービス経由でルーティングする必要がなくなります。

ZimaSpaceのアーキテクチャガイドはコントローラーを安定したローカルサービスとして扱い、MQTT、ストレージ、カメラ、オプションのAIから分離しています。そのローカル制御プレーンは、別のプラットフォームや実験的サービスがオフラインでも決定論的な家庭内ルールを維持します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

ThreadボーダールーターはMatterコントローラーの代わりにはならない

Matter-over-Threadデバイスもネットワーク到達性を必要としますが、Threadパケットをルーティングするコンポーネントが必ずしもデバイスの所有者であるとは限りません。コントローラーとボーダールーターは1つの製品に統合されることもあれば、LAN内で分離されることもあります。

Threadボーダールーターは、暗号化されたMatterコマンドを解釈せずにThreadメッシュとホームネットワーク間でIPv6パケットを転送します。コントローラーはファブリック関係を確立し、デバイスモデルを理解します。

したがって、スマートホームサーバーは純粋にトランスポート用にサードパーティのボーダールーターを使用しつつ、自身のMatterファブリックを維持できます。逆に、Matterコントローラーを所有していても、対応するボーダールーターが到達可能でなければサーバーはThread無線アクセスを得られません。

複数のコントローラーはデバイスを共有するが、すべてのプラットフォーム状態を共有するわけではない

Multi-Admin共有後、複数のプラットフォームが同じデバイスに対してサポートされるMatterコマンドを発行できます。しかし、すべての部屋名、シーン、自動化、履歴記録、音声アシスタントの設定、ダッシュボード、ベンダー固有の機能が自動的に統合されるわけではありません。

CSAはMulti-Admin制御をエコシステム間の同時ローカルアクセスとして説明しています。相互運用性の境界は標準化されたMatterデバイスモデルであり、プラットフォームのデータベースや自動化ロジックは分離されたままです。

この分離は有用です。Apple Homeは家族の音声制御を提供し、Google Homeは別のインターフェースを提供し、Home Assistantは詳細なローカル自動化を実行できます。また、削除やリセットの手順は慎重に行う必要があります。なぜなら、1つのファブリックからデバイスを削除しても他のファブリックからは必ずしも削除されないからです。

家庭内のMatterデバイス、参加しているすべてのファブリック、各ファブリックを管理するコントローラー、利用可能なボーダールーター、各プラットフォームに依存する自動化をリストアップして監査してください。サーバーは、独立したアクセス経路が実際に価値を提供する場合にのみ複数のコントローラーに依存します。

FAQ

すべてのMatterコントローラーに独自のThreadボーダールーターが必要ですか？

いいえ。複数のコントローラーが互換性のあるボーダールーターを通じて同じThreadネットワークにアクセスできます。コントローラーはMatterの信頼と制御を提供し、ボーダールーターはネットワークトランスポートを提供します。

1つのMatterデバイスがApple HomeとHome Assistantの両方に属することはできますか？

はい。デバイスがMulti-Adminをサポートし、両方のファブリックに共有されている場合です。その場合、各プラットフォームは独自のコントローラー関係を維持します。

複数のコントローラーは重複した自動化を作成しますか？

作成する可能性があります。各プラットフォームは独自のルールを実行できるため、所有権が明確に計画されていないと、競合するシーンやスケジュールが異なるコマンドを発行することがあります。