Matter のデバイスには、明確に定義されたデータモデル (DM)があります。これは、デバイスの機能の階層型モデリングです。この階層の最上位にはデバイス があります。
デバイスとエンドポイント
スマートフォンやホーム アシスタントなど、すべてのデバイスは複数の ノード1で構成されます。ノード は、ユーザーから見た機能全体であり、ネットワーク内で一意に識別できるアドレス指定可能なリソースです。におけるネットワーク通信は、 Matterノードで開始されノードで終了します。
ノードはエンドポイント の集まりです。各エンドポイントには機能セットが含まれています。 たとえば、あるエンドポイントは照明機能に関連し、別のエンドポイントはモーション検知(機能)に関連し、別のエンドポイントはデバイス OTA などのユーティリティを処理します。
ノードの役割
ノードの役割 は、関連する動作のセットです。各ノードには 1 つ以上の役割があります。ノードの役割は次のとおりです。
- コミッショナー: コミッショニングを実行するノード。
- コントローラ: 1 つ以上のノードを制御できるノード。 例としては、Google Home app (GHA)、 Google Assistant、Google Nest Hub (2nd gen)などがあります。オン オフ ライト スイッチなどの一部のデバイスタイプには、コントローラ ロールがあります。
- 制御対象: 1 つ以上の ノードで制御できるノード。ほとんどのデバイスタイプは制御対象にできますが、コントローラ ロールを持つ一部のデバイスタイプ は除きます。たとえば、オン/オフ ライト スイッチなどです。オン/オフ ライト スイッチはコントローラにのみ使用できます。 制御対象にすることはできません。
- OTA プロバイダ: OTA ソフトウェア アップデートを提供できるノード。
- OTA リクエスタ: OTA ソフトウェア アップデートをリクエストできるノード。
クラスタ
エンドポイント 内のノードには 1 つ以上のクラスタ があります。これらはデバイス階層の別のステップです。スマートプラグの オン/オフ クラスタや、調光可能なライト エンドポイントの レベル制御 クラスタなど、特定の機能をグループ化します。
ノードには複数のエンドポイントがあり、それぞれが同じ機能のインスタンスを作成します。たとえば、照明器具は個々の照明の独立した制御を公開し、電源タップは個々のソケットの制御を公開します。
属性
最後のレベルには属性があります。これは、ノードが保持する状態です。たとえば、レベル制御クラスタの現在のレベル属性などです。属性は、uint8、文字列、配列などのさまざまなデータ型として定義できます。
コマンド
クラスタには、属性の他にコマンド もあります。これは、実行できる アクションです 。これらは、Matter's DM における リモート プロシージャ コールに相当します。コマンドは、ドアロッククラスタのドアをロックなど、動詞のようなものです。コマンドはレスポンスと結果を生成する場合があります。in Matter では、このようなレスポンスもコマンドとして定義され、going 逆方向に進みます。
イベント
最後に、クラスタにはイベントが含まれる場合があります。これは、過去の状態遷移の記録 と考えることができます。属性は現在の状態を表しますが、 イベントは過去のジャーナルであり、単調増加 カウンタ、タイムスタンプ、優先度が含まれます。これにより、状態遷移のキャプチャや、属性では簡単に実現できないデータ モデリングが可能になります。
エンドポイント 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 は空です。たとえば、温度センサーには温度測定サーバー クラスタのみが必要です。
他のデバイスタイプは、複数のデバイスタイプ インスタンスのツリー構造で構成される場合があります。たとえば、動画プレーヤー デバイスタイプは、TV、動画プレーヤー、スピーカー、さまざまなコンテンツ アプリ デバイスタイプで構成され、それぞれが異なるエンドポイントに配置されます。
-
Matter 仕様では、デバイスに複数のノードを含めることができます。 たとえば、スマートフォンには複数のアプリがあり、各アプリが異なるノードになります。この入門ガイドでは、すべてのデバイスに単一のノードが含まれます。ほとんどの物理デバイスはこのパターンに従うことが想定されています。 ↩