デバイスデータモデル

Matter 内のデバイスには、明確に定義されたデータモデル（DM）があります。これは、デバイスの機能の階層型モデリングです。この階層の最上位にはデバイスがあります。

デバイスとエンドポイント

スマートフォンやホーム アシスタントを含むすべてのデバイスは、ノード¹で構成されます。ノードは、機能的に全体としてユーザーが認識できるネットワーク内の一意で特定可能なアドレス指定リソースです。Matter のネットワーク通信は、ノードで開始され、ノードで終了します。

ノードはエンドポイントのコレクションです。各エンドポイントは機能セットを包含します。たとえば、エンドポイントはライティング機能に関連し、別のエンドポイントはモーション検出に関連し、別のエンドポイントはデバイス OTA などのユーティリティに関連する場合があります。

ノードのロール

ノードロールとは、関連する動作のセットです。各ノードには 1 つ以上のロールを設定できます。ノードの役割は次のとおりです。

• コミッショナー: コミッショニングを行うノード。
• コントローラ: 1 つ以上のノードを制御できるノードです。たとえば、Google Home app (GHA)、Google Assistant、Google Nest Hub (2nd gen) などがあります。オン/オフライト スイッチなど、一部のデバイスタイプにはコントローラ ロールがあります。
• コントロール対象者: 1 つ以上のノードで制御できるノード。ライト スイッチのオン/オフなど、コントローラ ロールを持つ一部のデバイスタイプを除き、ほとんどのデバイスタイプはコントローラにすることができます。オン/オフライト スイッチは、コントローラのみにすることができます。管理者にはできません。
• OTA プロバイダ: OTA ソフトウェア アップデートを提供できるノード。
• OTA リクエスト元: OTA ソフトウェア アップデートをリクエストできるノード。

クラスタ

Endpoint には、ノードに 1 つ以上のクラスタがあります。デバイス階層のもう 1 つのステップは、スマートプラグのオン/オフ クラスタや、調光可能なライト エンドポイントのレベル コントロール クラスタなど、特定の機能をグループ化したものです。

ノードには、同じ機能のインスタンスを作成するエンドポイントも複数含まれることがあります。たとえば、照明器具は個々の照明の独立した制御を公開したり、電源ストリップは個々のソケットの制御を公開したりします。

属性

最後のレベルには [属性] があります。これは、ノードが保持する状態（レベル管理クラスタの現在のレベル属性など）です。属性は、uint8、文字列、配列などのさまざまなデータ型として定義できます。

コマンド

クラスタには、属性以外にもコマンドがあり、アクションを実行できます。これは、リモート プロシージャ コールの Matter の DM に相当します。ドアロック クラスタに対するロックドアなどのコマンドは、動詞に似ています。コマンドはレスポンスと結果を生成する場合があります。Matter では、このようなレスポンスはコマンドとして逆方向に定義されます。

イベント

最後に、クラスタには過去のイベント遷移の記録と考えることができるイベントもあります。属性は現在の状態を表しますが、イベントは過去のジャーナルであり、単調に増加するカウンタ、タイムスタンプ、優先度が含まれます。これにより、状態遷移のキャプチャや、属性では容易に実現できないデータ モデリングが可能になります。

エンドポイント 0 はユーティリティ クラスタ用に予約されています。ユーティリティ クラスタは、検出、アドレス指定、診断、ソフトウェア アップデートなどのサービス機能をエンドポイントで囲む特定のクラスタです。一方、アプリケーション クラスタは、オン/オフや温度測定などの主要なアクションをサポートしています。

デバイスタイプ

デバイス メーカーが新しいデバイスを計画する際は、どのクラスタの組み合わせを含めるべきですか。クラスタの任意の組み合わせを使用できますが、一般的な方法は、いくつかのデバイスタイプを実装して拡張することです。デバイスタイプは、1 つ以上のエンドポイントに必須またはオプションのクラスタのコレクションです。調光可能ライト、ドアロック、動画プレーヤーなど、物理デバイスの最上位属性を定義します。

エンドポイントには包括的な機能を実装するという弱い要件がありますが、デバイスタイプは強固な要件です。デバイスタイプを実装するノードには、カラーディマー スイッチや光センサーなど、明確な統合動作を定義する 1 つ以上のエンドポイントに一連のクラスタを含める必要があります。

デバイスタイプは、Matter 仕様のメイン ドキュメントではなく、デバイス ライブラリで指定されたドキュメントで指定されます。同様に、すべてのアプリケーション クラスタはアプリケーション クラスタ ライブラリで定義されています。これら 3 つのドキュメントは、CSA のメンバーのウェブサイトで確認できます。

クライアントとサーバー

クラスタは、クライアント クラスタまたはサーバー クラスタのいずれかになります。サーバーはステートフルで、属性、イベント、コマンドを保持しますが、クライアントはステートレスであり、その役割はリモート サーバー クラスタとのインタラクションを開始することです。つまり、次の処理が行われます。

• リモートの属性に対する読み取りと書き込みを行います。
• リモート イベントを読み取ります。
• リモート コマンドの呼び出し。

DM はノード内で階層的ですが、ノード間の関係はそうではありません。Matter のノードには、垂直方向のコントローラ/周辺機器、リーダー/フォロワーの関係がありません。逆に、いずれかのクラスタが「サーバー」か「クライアント」のいずれかである、という関係が示されます。したがって、ノードは、異なるクラスタと機能に関してサーバーとクライアントの両方である可能性があります。

たとえば、ノード A とノード B という 2 つのテーブルランプがあるとします。どちらのノードも、オン/オフライトのデバイスタイプを実装しています。このデバイスタイプには、それぞれの物理光出力を制御するオン/オフ サーバー クラスタが含まれます。

ただし、通常のテーブルランプと同様に、物理デバイスにはローカルのオン/オフ スイッチ用のオン/オフライト スイッチデバイスタイプも含まれます。デバイスタイプでは、オン/オフ クライアント クラスタを実装して、サーバー クラスタを管理する必要があります。

このサンプルでは、ノード A のオン/オフ クライアント クラスタがノード A とノード B のオン/オフ サーバー クラスタの属性を変更しますが、ノード B のクライアント クラスタはノード B 自体のサーバー クラスタのみを変更します。

次のセクションでは、クライアント クラスタとサーバー クラスタの相互作用（インタラクション モデル）について詳しく説明します。

記述子クラスタ

記述子クラスタ サーバーは、その名前が示すようにイントロスペクション情報を提供します。次のものを列挙するエンドポイントを記述します。

• サーバー クラスタ。
• クライアント クラスタ。
• デバイスタイプ
• 追加のパーツ（パーツ）

どのデバイスタイプでも、記述子クラスタの実装が必要です。ルートデバイス タイプはエンドポイント 0 で定義されます。記述子クラスタを読み取ることで、クライアントは使用可能なエンドポイントの完全なツリーを走査して、該当するオペレーションを実行することを確認できます。

コミッショナーまたは制御デバイス（スマートフォンやハブなど）は、記述子クラスタの情報を使用してデバイス（照明、スイッチ、ポンプ、サーモスタット）と、デバイスのその特定のインスタンスが実装する特定の機能をモデル化し、ユーザーに正しい UI を表示できます。

サーバー クラスタ

ServerList 属性は、エンドポイント内のクラスタ サーバーを一覧表示します。

クライアント クラスタ

ClientList 属性は、エンドポイント内のクラスタ クライアントを一覧表示します。

デバイスタイプリスト

DeviceTypeList 属性は、エンドポイントでサポートされているデバイスタイプと、それぞれのリビジョンのリストです。少なくとも 1 つのデバイスタイプを含める必要があります。

パーツリスト

PartsList には、このデバイスタイプの実装に使用されるエンドポイントのリストが含まれます。

エンドポイント 0（ルートノード）の PartsList には、それ自体以外のすべてのエンドポイント（エンドポイント 0）が含まれます。

通常、他のエンドポイントの PartsList は空です。たとえば、温度センサーは温度測定サーバー クラスタを要求し、それ以外は指示しません。

他のデバイスタイプは、複数のデバイスタイプのインスタンスのツリー構造で構成される場合があります。たとえば、動画プレーヤーのデバイスタイプは、テレビ、動画プレーヤー、スピーカー、さまざまなコンテンツ アプリのデバイスタイプで、それぞれ異なるエンドポイントに構成できます。