デバイスデータモデル

Matter have a well-defined data model (DM), which is a hierarchical modeling of a Device's features. At the top level of this hierarchy there is a Device. にあるデバイス

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

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

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

クラスタ

Endpoint 内には、1 つのノードに 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 は通常、空です。たとえば、温度センサーは、温度測定サーバー クラスタを要求し、それ以外は何もしません。

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