デバイスのデータモデル

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

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

スマートフォンやホーム アシスタントなど、すべてのデバイスは複数のノード¹で構成されます。各ノードは、ユーザーから見た機能全体であり、ネットワーク内で一意に特定可能なアドレス指定可能なリソースです。Matter におけるネットワーク通信は、ノードで開始されノードで終了します。

ノードはエンドポイントの集合です。各エンドポイントには機能セットが含まれています。たとえば、あるエンドポイントは照明機能に関連し、別のエンドポイントはモーション検知に関連し、さらに別のエンドポイントはデバイス OTA などのユーティリティを処理します。

ノードのロール

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

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

クラスタ

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

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

属性

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

コマンド

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

イベント

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

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

デバイスタイプ

デバイス メーカーが新しいデバイスを計画する際に、どのクラスタの組み合わせを含める必要がありますか。

Matter 仕様では、デバイスが 1 つ以上のデバイスタイプを実装または拡張する必要があります。デバイスタイプは、必須クラスタとオプション クラスタのコレクションであり、実機の最上位属性（調光ライト、ドアロック、動画プレーヤーなど）を定義します。

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

デバイスタイプを実装する各エンドポイントは、そのデバイスタイプを定義する必須のクラスタを実装する必要があります。エンドポイントは、必須のクラスタに加えて、デバイスタイプのオプションのクラスタ（1 つ以上）や、デバイスタイプに含まれていないクラスタなど、追加のクラスタを実装できます。

クライアントとサーバー

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

• リモート属性の読み取りと書き込み。
• 読み取り。
• 呼び出し。

DM はノード内で階層構造になっていますが、ノード間の関係は階層構造ではありません。Matter のノードには、垂直コントローラ/ペリフェラルまたはリーダー/フォロワーの関係はありません。それどころか、関係は水平です。どのクラスタもサーバーまたはクライアントのいずれかになります。したがって、ノードは、異なるクラスタと機能に関してサーバーとクライアントの両方になることができます。

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

ただし、一般的なテーブルランプと同様に、物理デバイスにはローカルのオン/オフ スイッチ用のオン/オフ ライト スイッチ デバイスタイプも含まれます。このデバイスタイプは、サーバー クラスタを制御できるように、オン/オフ クライアント クラスタを実装する必要があります。

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

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

記述子クラスタ

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

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

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

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

サーバー クラスタ

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

クライアント クラスタ

ClientList 属性には、エンドポイントのクラスタ クライアントが一覧表示されます。

デバイスタイプ リスト

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

パーツリスト

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

エンドポイント 0（ルートノード）の PartsList には、それ自体（エンドポイント 0）を除くデバイスのすべてのエンドポイントが含まれます。

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

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