The Device Data Model

Devices in 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.

Devices and Endpoints

All Devices, including smartphones and home assistants, are composed of Nodes1. A Node is a unique identifiable and addressable resource in a network that a user can perceive as functionally whole. Network communication in Matter originates and terminates at a Node.

Nodes are a collection of Endpoints. Each Endpoint encloses a feature set. For instance, an Endpoint might relate to a lighting functionality, while another relates to motion detection, and another deals with utilities such as Device OTA.

Hierarchy of Devices, Nodes and Endpoints
Figure 1: Devices, Nodes and Endpoints


Within an Endpoint a Node has one or more Clusters. These are another step in the Device hierarchy, as they group specific functionality such as on/off cluster on a smart plug, or level control cluster on a dimmable light endpoint.

A Node may also have several Endpoints, each creating an instance of the same functionality. For example a light fixture may expose independent control of individual lights or a power strip may expose control of individual sockets.


At the last level we'll find Attributes, which are states held by the node, such as the current level attribute of a level control cluster. Attributes may be defined as different data types such as uint8, strings or arrays.

Hierarchy of Nodes, Endpoints, Attributes and Commands
Figure 2: Nodes, Endpoints, Attributes and Commands


Besides Attributes, Clusters also have Commands, which are actions that may be performed. They are the equivalent in Matter's DM of a remote procedure call. Commands are verb-like, such as lock door on a Door Lock cluster. Commands may generate responses and results; in Matter, such responses are also defined as Commands, going in the reverse direction.


Lastly, Clusters may also have Events, which can be thought of as a record of past state transitions. While Attributes represent the current states, events are a journal of the past, and include a monotonically increasing counter, a timestamp and a priority. They enable capturing state transitions, as well as data modeling that is not readily achieved with attributes.

Full sample device
Figure 3: A sample of the hierarchy of Matter Devices interaction model

The Endpoint 0 is reserved for the Utility Clusters. Utility Clusters are specific Clusters that enclose servicing functionality on an Endpoint, such as discovery, addressing, diagnostics and software update. On the other hand, the Application Clusters support primary actions such as on/off or temperature measurement.

Device Types

Altogether, which Cluster combinations should be included as a device manufacturer plans a new Device? While any combination of Clusters may be used, the general practice is to implement and extend a few Device Types. A Device Type is a collection of mandatory and optional Clusters on one or more Endpoints that define the top-level attributes of a physical Device, such as Dimmable Light, Door Lock, or Video Player.

While endpoints have a weak requirement that they should implement a cohesive functionality, the Device Types are a strong requirement. If a Node implements a Device Type, it must include a set of Clusters on one or more endpoints to define a distinct, cohesive behavior, such as a Color Dimmer Switch or Light Sensor.

The Device Types are not specified by the Matter specification main document, but by an accompanying document: the Device Library. Similarly, all Application Clusters are defined at the Application Cluster Library. These three documents can be found on the CSA's members website.

Clients and Servers

Clusters might be either a Client Cluster or a Server Cluster. While a Server is stateful and holds Attributes, Events and Commands, a Client is stateless and its responsibility is to initiate Interactions with a remote Server Cluster, thus performing

  • reads and writes its remote Attributes
  • reads of its remote Events
  • invocation of its remote Commands.

While the DM is hierarchical within a Node, the relationship between Nodes is not. Nodes in Matter do not have vertical controller/peripheral or leader/follower relationships. On the contrary, the relationship is horizontal: Any Cluster may be either Server or Client. Thus a Node may be both Server and Client with regards to different Clusters and functionalities.

For instance, we may have two table lamps: Node A and Node B. Both nodes implement an On/Off Light Device Type. This Device Type includes an On/Off Server Cluster that controls their respective physical light outputs.

But, as typical table lamps do, our physical device will also include an On/Off Light Switch Device Type for their local on/off switch. This Device Type must implement an On/Off Client Cluster so it may control the Server Clusters.

Lamps implementing both On/Off Light and Light Switch
Figure 4: Client and Server Clusters

In this sample, the On/Off Client Cluster on Node A is changing the attributes of the On/Off Server Cluster on Node A and Node B, while the Node B's Client Cluster is only changing the Server Cluster on Node B itself.

In the next section we'll detail how Client and Server Clusters interact: The Interaction Model.

  1. The Matter specification determines that a Device may have multiple Nodes. For example this is the case of smartphones, that may have multiple apps, each app being a different Node. For the purposes of this primer all Devices will contain a single Node. It's expected that most physical devices will follow this pattern.