Das Gerätedatenmodell

Geräte in Matter haben ein genau definiertes Datenmodell (DM), das eine hierarchische Modellierung der Funktionen eines Geräts ist. Auf der obersten Ebene dieser Hierarchie befindet sich ein Gerät.

Geräte und Endpunkte

Alle Geräte, einschließlich Smartphones und Home-Assistenten, bestehen aus Knoten1. Ein Knoten ist eine eindeutig identifizierbare und erreichbare Netzwerkressource, die von einem Nutzer als vollständige Funktionseinheit wahrgenommen wird. Die Netzwerkkommunikation in Matter beginnt und endet an einem Knoten.

Knoten sind eine Sammlung von Endpunkten. Jeder Endpunkt umfasst ein Feature-Set. Ein Endpunkt kann sich beispielsweise auf eine Beleuchtungsfunktion beziehen, während ein anderer auf die Bewegungserkennung und ein weiterer auf Dienstprogramme wie Geräte-OTA.

Hierarchie von Geräten, Knoten und Endpunkten
Abbildung 1: Geräte, Knoten und Endpunkte

Knotenrollen

Eine Knotenrolle ist eine Reihe verwandter Verhaltensweisen. Jeder Knoten kann eine oder mehrere Rollen haben. Zu den Knotenrollen gehören:

  • Commissioner: Ein Knoten, der die Inbetriebnahme durchführt.
  • Controller: Ein Knoten, der einen oder mehrere Knoten steuern kann. Beispiele sind Google Home app (GHA), Google Assistant und Google Nest Hub (2nd gen). Einige Gerätetypen wie der Ein/Aus-Licht schalter haben die Rolle „Controller “.
  • Controlee: Ein Knoten, der von einem oder mehreren Knoten gesteuert werden kann. Die meisten Gerätetypen können „Controlee“ sein, mit Ausnahme einiger Gerätetypen die die Rolle „Controller“ haben, z. B. der Ein/Aus-Licht schalter. Der Ein/Aus-Lichtschalter kann nur ein Controller sein. Er kann nicht „Controlee“ sein.
  • OTA-Anbieter: Ein Knoten, der OTA-Softwareupdates bereitstellen kann.
  • OTA-Anforderer: Ein Knoten, der OTA-Software updates anfordern kann.

Cluster

Innerhalb eines Endpunkts hat ein Knoten einen oder mehrere Cluster. Diese stellen einen weiteren Schritt in der Gerätehierarchie dar, da sie bestimmte Funktionen gruppieren, z. B. einen Ein/Aus-Cluster auf einer Smart-Steckdose oder einen Cluster zur Steuerung der Helligkeit auf einem dimmbaren Lichtendpunkt.

Ein Knoten kann auch mehrere Endpunkte haben, die jeweils eine Instanz derselben Funktion erstellen. Beispielsweise kann eine Leuchte die unabhängige Steuerung einzelner Lampen ermöglichen oder eine Mehrfachsteckdose die Steuerung einzelner Steckdosen.

Attribute

Auf der letzten Ebene finden wir Attribute, die Zustände des Knotens darstellen, z. B. das Attribut Aktuelle Helligkeit eines Clusters zur Steuerung der Helligkeit. Attribute können als verschiedene Datentypen definiert werden, z. B. als 8-Bit-Ganzzahlen ohne Vorzeichen, Strings oder Arrays.

Hierarchie von Knoten, Endpunkten, Attributen und Befehlen
Abbildung 2: Knoten, Endpunkte, Attribute und Befehle

Befehle

Neben Attributen haben Cluster auch Befehle, die Aktionen darstellen, die ausgeführt werden können. Sie sind im Datenmodell von Matter das Äquivalent eines Remote-Prozeduraufrufs. Befehle sind Verben, z. B. Tür abschließen in einem Türschloss-Cluster. Befehle können Antworten und Ergebnisse generieren. In Matter, werden solche Antworten auch als Befehle definiert, die in umgekehrter Richtung gesendet werden.

Ereignisse

Schließlich können Cluster auch Ereignisse haben, die als Aufzeichnung vergangener Zustandsübergänge betrachtet werden können. Während Attribute die aktuellen Zustände darstellen, Ereignisse ein Protokoll der Vergangenheit sind und einen monoton steigenden Zähler, einen Zeitstempel und eine Priorität enthalten. Sie ermöglichen die Erfassung von Zustandsübergängen sowie die Datenmodellierung, die mit Attributen nicht ohne Weiteres möglich ist.

Vollständiges Beispielgerät
Abbildung 3: Beispiel für die Hierarchie des Interaktionsmodells von Matter Geräten

Endpunkt 0 ist für die Utility-Cluster reserviert. Utility-Cluster sind spezielle Cluster, die Dienstfunktionen für einen Endpunkt umfassen, z. B. Erkennung, Adressierung, Diagnose und Softwareupdate. Die Application-Cluster unterstützen dagegen primäre Aktionen wie Ein/Aus oder Temperaturmessung.

Gerätetypen

Welche Clusterkombinationen sollten insgesamt berücksichtigt werden, wenn ein Gerätehersteller ein neues Gerät plant?

Die Matter Spezifikation erfordert, dass das Gerät einen oder mehrere Gerätetypen implementiert oder erweitert. Ein Gerätetyp ist eine Sammlung obligatorischer und optionaler Cluster, die die Attribute der obersten Ebene eines physischen Geräts definieren, z. B. Dimmbare Leuchte, Türschloss oder Videoplayer.

Die Gerätetypen werden nicht im Matter Hauptdokument der Spezifikation, sondern in einem Begleitdokument angegeben: der Geräte Bibliothek. Ebenso werden alle Application-Cluster in der Application-Cluster-Bibliothek definiert. Diese drei Dokumente finden Sie auf der Connectivity Standards Alliance (Alliance) Mitglieder-Website.

Jeder Endpunkt, der einen Gerätetyp implementiert, muss die obligatorischen Cluster implementieren, die diesen Gerätetyp definieren. Zusätzlich zu den obligatorischen Clustern kann der Endpunkt weitere Cluster implementieren, einschließlich eines oder mehrerer optionaler Cluster des Gerätetyps oder sogar Cluster, die nicht Teil des Gerätetyps sind.

Clients und Server

Cluster können entweder Client-Cluster oder Server-Cluster sein. Während ein Server zustandsbehaftet ist und Attribute, Ereignisse und Befehle enthält, ist ein Client zustandslos und seine Aufgabe besteht darin, Interaktionen mit einem Remote-Server-Cluster zu initiieren. Er führt also Folgendes aus:

  • Lesen und Schreiben seiner Remote-Attribute.
  • Lesen seiner Remote-Ereignisse.
  • Aufrufen seiner Remote-Befehle.

Während das Datenmodell innerhalb eines Knotens hierarchisch ist, ist die Beziehung zwischen Knoten nicht hierarchisch. Knoten in Matter haben keine vertikalen Beziehungen zwischen Controller und Peripheriegerät oder zwischen Leader und Follower. Im Gegenteil, die Beziehung ist horizontal: Jeder Cluster kann entweder Server oder Client sein. So kann ein Knoten in Bezug auf verschiedene Cluster und Funktionen sowohl Server als auch Client sein.

Nehmen wir beispielsweise zwei Tischlampen: Knoten A und Knoten B. Beide Knoten implementieren einen Gerätetyp Ein/Aus-Leuchte. Dieser Gerätetyp enthält einen Ein/Aus-Server-Cluster , der die jeweiligen physischen Lichtausgaben steuert.

Wie typische Tischlampen enthalten unsere physischen Geräte aber auch einen Gerätetyp Ein/Aus-Lichtschalter für ihre lokalen Ein/Aus-Schalter. Dieser Gerätetyp muss einen Ein/Aus-Client-Cluster implementieren, damit er die Server-Cluster steuern kann.

Lampen, die sowohl „On/Off Light“ als auch „Light Switch“ implementieren
Abbildung 4: Client- und Server-Cluster

In diesem Beispiel ändert der Ein/Aus-Client-Cluster auf Knoten A die Attribute des Ein/Aus-Server-Clusters auf Knoten A und Knoten B, während der Client-Cluster von Knoten B nur den Server-Cluster auf Knoten B selbst ändert.

Im nächsten Abschnitt wird detailliert beschrieben, wie Client- und Server-Cluster interagieren: das Interaktionsmodell.

Deskriptor-Cluster

Wie der Name schon sagt, stellt der Deskriptor-Cluster-Server Introspektionsinformationen bereit. Er beschreibt den Endpunkt und listet Folgendes auf:

  • Server-Cluster
  • Client-Cluster
  • Gerätetypen
  • Zusätzliche Endpunkte, die als Teile bezeichnet werden

Für jeden Gerätetyp ist die Implementierung von Deskriptor-Clustern erforderlich. Der Root-Gerätetyp wird auf Endpunkt 0 definiert. Wenn der Deskriptor-Cluster gelesen wird, kann der Client den gesamten Baum der verfügbaren Endpunkte durchlaufen und die entsprechenden Vorgänge ausführen.

Das Commissioner- oder Steuergerät, z. B. ein Smartphone oder Hub, kann die Informationen im Deskriptor-Cluster verwenden, um das Gerät (Leuchte, Schalter, Pumpe, Thermostat) und bestimmte Funktionen zu modellieren, die von dieser bestimmten Instanz des Geräts implementiert werden, und dem Nutzer die richtige Benutzeroberfläche anzuzeigen.

Server-Cluster

Das Attribut ServerList listet die Cluster-Server im Endpunkt auf.

Client-Cluster

Das Attribut ClientList listet die Cluster-Clients im Endpunkt auf.

Gerätetypliste

Das Attribut DeviceTypeList ist eine Liste der vom Endpunkt unterstützten Gerätetypen mit den jeweiligen Revisionen. Es muss mindestens einen Gerätetyp enthalten.

Teileliste

Die PartsList enthält die Liste der Endpunkte, die zur Implementierung dieses Gerätetyps verwendet werden.

Die PartsList von Endpunkt 0 (Root-Knoten) enthält alle Endpunkte des Geräts außer Endpunkt 0 selbst.

Die PartsList anderer Endpunkte ist in der Regel leer. Für einen Temperatursensor ist beispielsweise ein Server-Cluster für die Temperaturmessung erforderlich, aber nichts weiter.

Andere Gerätetypen können in einer Baumstruktur aus mehreren Gerätetypinstanzen bestehen. Ein Gerätetyp „Videoplayer“ kann beispielsweise aus den Gerätetypen „TV“, „Videoplayer“, „Lautsprecher“ und verschiedenen „Content-App“-Gerätetypen bestehen, die jeweils auf einem anderen Endpunkt vorhanden sind.


  1. Die Matter Spezifikation legt fest, dass ein Gerät mehrere Knoten haben kann. Smartphones können beispielsweise mehrere Apps haben, wobei jede App einen anderen Knoten darstellt. Für die Zwecke dieser Einführung enthalten alle Geräte einen einzelnen Knoten. Es wird erwartet, dass die meisten physischen Geräte diesem Muster folgen.