デバイスのデータモデル

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) メンバーのウェブサイトで確認できます。

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

クライアントとサーバー

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

• リモート属性からの読み取りと書き込みを行います。
• read を実行します。
• 呼び出す必要があります。

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

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

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

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

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

記述子クラスタ

その名前が示すように、Descriptor Cluster Server はイントロスペクション情報を提供します。これは、以下を列挙するエンドポイントを記述します。

• サーバー クラスタ
• クライアント クラスタ。
• デバイスタイプ
• パートと呼ばれる追加のエンドポイント。

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

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

サーバー クラスタ

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

クライアント クラスタ

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

デバイスタイプのリスト

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

パーツリスト

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

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

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

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