YOGYUI
Matter - Data Model (Node, Endpoint, Cluster, Attribute, Command) 본문
Matter - Data Model (Node, Endpoint, Cluster, Attribute, Command)
요겨 2023. 5. 4. 09:41
Introduction to Matter Data Model (Node, Endpoint, Cluster, Attribute, Command)
Connectivity Standards Alliance(CSA)의 Matter는 IoT 디바이스간 유무선 통신(Ethernet, Bluetooth, Wi-Fi, OpenThread 등), 보안, 관리 등에 대한 표준을 오픈소스로 공개했기 때문에 IoT 디바이스 (펌웨어) 개발자는 이것과 관련된 개발에 신경쓰지 않아도 되는 것이 가장 큰 장점이다
- 좁은 범위에서 말하자면 Matter는 단지 네트워크 레이어 상의 인터넷 프로토콜일 뿐이다
따라서, Matter 디바이스 개발자는 디바이스가 Matter 에코시스템 상에서 받은 명령을 어떻게 처리하고, 디바이스의 상태를 어떻게 알려줄지에 대해서만 중점적으로 역량을 투자하면 되는데, 이를 위해서는 Matter의 데이터 모델(Data Model), 즉 Endpoint, Cluster, Attribute, Command에 대한 기초적인 이해가 필요하다
※ 사실 예제코드만 따라해도 금방 이해된다
CSA의 Matter 1.0 표준 공식 문서에 해당 내용이 기재되어 있으니, 이해에 필요한 부분만 발췌해서 설명해보도록 한다
문서명: 22-22349-001 Matter Specification Version 1.0
※ 2023년 3월 기준 Matter 소스코드의 공식 릴리즈 버전은 v1.0.0.2이며, 조만간 대대적으로 내용이 수정된 신규버전이 릴리즈될 예정이다
※ Zigbee 기기 개발 경험이 있다면 모두 다 익숙한 내용
1. 개요
- Matter 기기는 1개 이상의 Node로 구성된다
- 각각의 Node는 1개 이상의 Endpoint들로 구성된다
- 각각의 Endpoint는 1개 이상의 Cluster로 구성된다
- 각각의 Cluster는 1개 이상의 Attribute와 1개 이상의 Command로 구성된다
이 외에도 Matter Data Model은 Fabric, Access, Event 등 다른 카테고리들도 있는데, 기기 개발자 입장에서 주요하게 알아줘야 할 건 앞서 언급한 5개 항목들이다
※ 다른 녀석들은 Matter device간 Commisioning 및 상호작용(interaction)에 관한 내용으로, Matter SDK에서 제공하는 API를 활용하면 쉽게 기기간 통신을 구축할 수 있다
2. Specification
2.1. Node
[Specification 원문 - 7.8.]
A Node encapsulates an addressable, unique resource on the network that has a set of functions and capabilities that a user recognizes distinctly as a functional whole.
This distinction is usually physical, such as the physical device itself, or a logical instance of a physical device.
A node is the highest or outermost first order element in the data model. A node is the outermost unique addressable element of the data model.
A node MAY have multiple node IDs, each ID scoped to a particular fabric. When a node ID is used as the target address of an interaction, the fabric under which the node ID is scoped, is the accessing fabric for the interaction.
The lower layers in a communication stack supporting this data model SHALL support interactions between nodes on a logical inter-network of nodes.Please see the Interaction Model and System Model specifications that describe relationships and interactions between nodes and data model elements on each node.
It is possible for parts of a node to reside on different processors (e.g. separate application and network processors).
A single physical product may support more than one node.
2.2. Endpoint
[Specification 원문 - 7.9.]
A node is composed of one or more endpoints. An endpoint is an instance of something that could be a service or virtual device as indicated by a device type.
Each endpoint conforms to one or more device type definitions that define the clusters supported on the endpoint. Clusters are object classes that are instantiated on an endpoint.
The word 'device', depending on the context, may be used as shorthand to denote the device type definition as represented by a device type ID, a device type implementation, or an endpoint (device type instance).
There are also many examples in specification text where 'device' is used, when it would be better, and more accurate to use 'node', 'physical device', or 'product'.
The word 'device' may also be used in cluster specifications to describe application software that is supporting an instance of a cluster server or client. In this case, it would be better, and more accurate to use either 'client' or 'server'.
One must be careful to make sure there is no ambiguity when using the word 'device' in specification text, or better yet, use another word.
2.3. Cluster
[Specification 원문 - 7.10.]
Clusters are the functional building block elements of the data model. A cluster specification defines both a client and server side that correspond with each other through interactions. A cluster may be considered an interface, service, or object class and is the lowest independent functional element in the data model. Each cluster is defined by a cluster specification that defines elements of a cluster including attributes, events, commands, as well as behavior associated with interactions with these elements. Cluster attributes, events, commands and behaviors are mandatory or optional depending on the definition of the cluster. Optional items may have dependencies.
A cluster specification SHALL list one or more Cluster Identifiers. A Cluster Identifier SHALL reference a single cluster specification and SHALL define conformance to that specification. A cluster instance SHALL be indicated and discovered by a Cluster Identifier on an endpoint. A Cluster Identifier also defines the purpose of the instance.
The server cluster supports attribute data, events and cluster commands. The client cluster initiates interactions, including invocation of cluster commands.
2.4. Command
[Specification 원문 - 7.11.]
A cluster command is a set of data fields, each of a data type that is conveyed between client and server cluster instances to invoke a behavior on the receiver of the command.
Each command SHALL be listed in a table with data quality columns: ID, Name, Direction, Response, Access, Conformance.
The command table SHALL define the direction of the command as either client to server or server to client. The command table SHALL define the access privileges for each request command or omit the privileges for the default (see default access privileges). The command table SHALL NOT define privileges for a response command. The command table SHALL define a possible response to the command, if any. The command table SHALL define conformance for each command.
A command that is not a response (in the Response column) is a request command. Conformance for a client to server command means the server SHALL recognize and support the client to server command and generate responses as defined. Conformance for a server to client command means the server SHALL send the command as cluster behavior defines, such as in response to a client to server command. Conformance for a command can depend on supported server features. A client SHALL NOT be required to support optional commands or commands depending on an optional feature. A command description SHALL define when a command is generated.
A command description SHALL define the effect upon receipt of a command which may be:
• a response command
• a success status response
• an error status response
• no response
A command definition SHALL clearly define any side-effects on fabric-scoped data, if applicable.
A command is identified and indicated with a command ID that SHALL be unique to the cluster*.
2.5. Attribute
[Specification 원문 - 7.12.]
An attribute is cluster data. Each attribute SHALL be listed in a table with data quality columns: ID, Name, (Data) Type, Constraint, other Quality, Access, Default (value), and Conformance. An attribute SHALL also define its associated semantics and behavior. Attributes reflect queryable/settable state, configuration and capabilities of a device. If no privileges are explicitly defined for an attribute, then default access privileges take effect. Attribute data MAY also have these other qualities:
Quality Short Description Scene S indicates that the data is part of a scene Persistent N indicates that the data value is persistent across restarts Fixed F indicates that the read only data value will never change Nullable X indicates that the data may have a value of null
3. Implementation Example
위 그림은 단일 디바이스에 두 종류의 조명을 구축한 예시를 보여준다
하나의 조명은 밝기 조절이 가능한 Dimmable Light이며 다른 하나는 켜고 끄는 기능만 있는 단순한 On/Off 조명이다
해당 디바이스는 하나의 Node로 구성되어 있으며, 3개의 Endpoint가 내부에 존재하게 된다
※ Endpoint 0는 모든 Matter Node가 갖춰야 할 필수 endpoint (device type: root node)이며, 이에 대해서는 다른 포스팅에서 자세히 다뤄볼 예정
두 개의 조명은 개별 Endpoint로 구성되며, Dimmable Light 조명은 Endpoint 1에서 On/Off 및 Level Control Cluster 두 개를 통해 켜고 끄는 동작 및 밝기 조절 동작을 갖고 있으며, On/Off 조명은 On/Off Cluster만 갖추고 있으면 된다
각각의 Cluster가 정상적으로 동작하기 위해서는 필수적(mandatory)으로 갖춰야 하는 속성(attribute)과 명령(command)들이 있는데, 해당 내용은 specification 문서에서 찾을 수 있다
On/Off Cluster: Matter Specification - On/Off Cluster
Level Control Cluster: Matter Specification - Level Control Cluster
4. Bridge for non-Matter Devices
Aggregator와 Bridged Node Endpoint를 사용하면 Matter 기기가 아닌 다른 디바이스들과 상호작용하는 Matter Bridge 디바이스로 사용할 수 있다
최근에 개발을 완료한 홈네트워크 월패드 RS-485를 Matter와 연동하는 프로젝트에서도 Bridged Node 엔드포인트를 적극적으로 활용한 바 있다
이에 대해서는 다른 글에서 다뤄볼 예정
'홈네트워크(IoT) > Matter' 카테고리의 다른 글
| Matter Specification - Basic Information Cluster (0) | 2023.05.04 |
|---|---|
| Matter Specification - Root Node Endpoint (0) | 2023.05.04 |
| Matter Specification - Administrator Commissioning Cluster (0) | 2023.04.26 |
| Matter - Device Type (0) | 2023.04.17 |
| Matter Specification - Color Control Cluster (0) | 2023.04.10 |
