デバイスのデータモデル

Matter のデバイスには、デバイスの機能を階層的にモデリングした明確なデータモデル（DM）があります。この階層の最上位レベルには [デバイス] があります。

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

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

ノードは エンドポイントの集合です。各エンドポイントは特徴セットを囲みます。たとえば、エンドポイントは照明機能に関連するものもあれば、モーション検知に関連するものもあります。また、デバイス OTA などのユーティリティを扱うものもあります。

ノードのロール

ノードロールは、関連する一連の動作です。各ノードには 1 つ以上のロールがあります。ノードロールには次のものがあります。

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

クラスタ

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

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

属性

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

コマンド

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

イベント

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

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

デバイスタイプ

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

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

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

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

クライアントとサーバー

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

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

DM はノード内で階層化されていますが、ノード間の関係は階層化されていません。Matter 内のノードには、垂直コントローラ/ペリフェラルまたはリーダー/フォロワーの関係はありません。むしろ、関係は水平です。任意のクラスタは、サーバーまたはクライアントのいずれかになります。したがって、ノードは、さまざまなクラスタと機能に応じて、サーバーとクライアントの両方になる場合があります。

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

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

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

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

記述子クラスタ

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

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

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

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

サーバー クラスタ

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

クライアント クラスタ

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

デバイスタイプリスト

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

パーツリスト

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

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

通常、他のエンドポイントの PartsList は空になります。たとえば、温度センサーには温度測定サーバー クラスタのみが必要です。

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