デバイスのデータモデル

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 はユーティリティ クラスタ用に予約されています。ユーティリティ クラスタは、検出、アドレス指定、診断、ソフトウェア更新などのサービス機能を Endpoint で含む特定のクラスタです。一方、アプリケーション クラスタは、オン/オフや温度測定などの主要なアクションをサポートしています。

デバイスタイプ

デバイス メーカーが新しいデバイスの計画を立てる際に含めるべきクラスタの組み合わせは、次のうちどれですか。

Matter の仕様では、デバイスで 1 つ以上のデバイスタイプを実装または拡張する必要があります。デバイスタイプとは、物理デバイスのトップレベル属性を定義する必須およびオプションのクラスタを集めたものです。たとえば、調光可能な照明、ドアロック、動画プレーヤーなどが定義されています。

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

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

クライアントとサーバー

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

• リモート属性からの読み取りとリモート属性への書き込みを行います。
• 読み取りです。
• 呼び出し。

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

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

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

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

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

記述子クラスタ

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

• 使用できます。
• クライアント クラスタ。
• デバイスタイプ。
• パーツと呼ばれる追加のエンドポイント。

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

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

サーバー クラスタ

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

クライアント クラスタ

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

デバイスタイプリスト

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

パーツリスト

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

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

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

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