Modelo de datos del dispositivo

Los dispositivos en Matter tienen un modelo de datos (MD) bien definido, que es un modelado jerárquico de las funciones de un dispositivo. En el nivel superior de esta jerarquía, hay un dispositivo.

Dispositivos y Endpoints

Todos los dispositivos, incluidos los smartphones y los asistentes para la casa, se componen de nodos¹. Un nodo es un recurso identificable de manera inequívoca y direccionable en una red que un usuario puede percibir como totalmente funcional. La comunicación de red en Matter se origina y termina en un nodo.

Los nodos son una colección de Endpoints. Cada extremo incluye un conjunto de atributos. Por ejemplo, un Endpoint podría relacionarse con la función de iluminación, mientras que otro se relaciona con la detección de movimiento y otro se ocupa de las utilidades, como la OTA del dispositivo.

Roles de nodos

Un rol de nodo es un conjunto de comportamientos relacionados. Cada nodo puede tener uno o más roles. Los roles de nodo incluyen lo siguiente:

• Comisionado: Es un nodo que realiza la puesta en marcha.
• Controlador: Es un nodo que puede controlar uno o más nodos. Entre los ejemplos, se incluyen Google Home app (GHA), Google Assistant y Google Nest Hub (2nd gen). Algunos tipos de dispositivos, como el interruptor de luz de encendido/apagado, tienen el rol de controlador.
• Controlado: Es un nodo que puede ser controlado por uno o más nodos. La mayoría de los tipos de dispositivos pueden ser Controlee, excepto algunos que tienen el rol de Controller, como el interruptor de luz de encendido/apagado. El interruptor de luz solo puede ser un controlador. No puede ser un Controlee.
• Proveedor de OTA: Es un nodo que puede proporcionar actualizaciones de software OTA.
• OTA Requestor: Es un nodo que puede solicitar actualizaciones de software OTA.

Clústeres

Dentro de un Endpoint, un nodo tiene uno o más Clusters. Estos son otro paso en la jerarquía de dispositivos, ya que agrupan funcionalidades específicas, como un clúster de encendido/apagado en un enchufe inteligente o un clúster de control de nivel en un extremo de luz regulable.

Un nodo también puede tener varios extremos, cada uno de los cuales crea una instancia de la misma funcionalidad. Por ejemplo, una lámpara puede exponer el control independiente de las luces individuales, o bien una regleta puede exponer el control de los enchufes individuales.

Atributos

En el último nivel, encontraremos Atributos, que son estados que mantiene el nodo, como el atributo nivel actual de un clúster de control de nivel. Los atributos se pueden definir como diferentes tipos de datos, como uint8, cadenas o arrays.

Comandos

Además de los atributos, los clústeres también tienen comandos, que son acciones que se pueden realizar. Son el equivalente en el DM de Matter a una llamada de procedimiento remoto. Los comandos son similares a verbos, como trabar la puerta en un clúster de cerradura de puerta. Los comandos pueden generar respuestas y resultados. En Matter, estas respuestas también se definen como comandos, pero en la dirección inversa.

Eventos

Por último, los clústeres también pueden tener eventos, que se pueden considerar como un registro de las transiciones de estado anteriores. Si bien los atributos representan los estados actuales, los eventos son un registro del pasado y, además, incluyen un contador que aumenta de forma monótona, una marca de tiempo y una prioridad. Permiten capturar transiciones de estado, así como el modelado de datos que no se logra fácilmente con atributos.

El extremo 0 está reservado para los clústeres de utilidad. Los clústeres de utilidad son clústeres específicos que incluyen la funcionalidad de servicio en un extremo, como el descubrimiento, la dirección, el diagnóstico y la actualización de software. Por otro lado, los clústeres de aplicaciones admiten acciones principales, como encender/apagar o medir la temperatura.

Tipos de dispositivos

En total, ¿qué combinaciones de clústeres se deben incluir cuando un fabricante de dispositivos planea un dispositivo nuevo?

La especificación Matter requiere que el dispositivo implemente o extienda uno o más tipos de dispositivos. Un tipo de dispositivo es una colección de clústeres obligatorios y opcionales que definen los atributos de nivel superior de un dispositivo físico, como Luz regulable, Cerradura de puerta o Reproductor de video.

Los tipos de dispositivos no se especifican en el documento principal de la especificación de Matter, sino en un documento complementario: la biblioteca de dispositivos. Del mismo modo, todos los clústeres de aplicaciones se definen en la biblioteca de clústeres de aplicaciones. Estos tres documentos se encuentran en el sitio web para miembros de Connectivity Standards Alliance (Alliance).

Cada extremo que implementa un tipo de dispositivo debe implementar los clústeres obligatorios que definen ese tipo de dispositivo. Además de los clústeres obligatorios, el extremo puede implementar clústeres adicionales, incluidos uno o más de los clústeres opcionales del tipo de dispositivo, o incluso clústeres que no forman parte del tipo de dispositivo.

Clientes y servidores

Los clústeres pueden ser un clúster de cliente o un clúster de servidor. Si bien un servidor es con estado y contiene atributos, eventos y comandos, un cliente es sin estado y su responsabilidad es iniciar interacciones con un clúster de servidores remoto, por lo que realiza lo siguiente:

• Lee y escribe en sus atributos remotos.
• Lecturas de sus eventos remotos
• invocación de sus comandos remotos.

Si bien el DM es jerárquico dentro de un nodo, la relación entre los nodos no lo es. Los nodos en Matter no tienen relaciones verticales de controlador/periférico ni de líder/seguidor. Por el contrario, la relación es horizontal: cualquier clúster puede ser servidor o cliente. Por lo tanto, un nodo puede ser tanto servidor como cliente con respecto a diferentes clústeres y funcionalidades.

Por ejemplo, podemos tener dos lámparas de mesa: Nodo A y Nodo B. Ambos nodos implementan un tipo de dispositivo Luz de encendido/apagado. Este tipo de dispositivo incluye un clúster On/Off Server que controla sus respectivas salidas de luz física.

Sin embargo, al igual que las lámparas de mesa típicas, nuestros dispositivos físicos también incluirán un tipo de dispositivo Interruptor de luz de encendido/apagado para sus interruptores de encendido/apagado locales. Este tipo de dispositivo debe implementar un clúster de cliente de encendido/apagado para poder controlar los clústeres de servidor.

En este ejemplo, el clúster de cliente de encendido/apagado en el nodo A cambia los atributos del clúster de servidor de encendido/apagado en el nodo A y el nodo B, mientras que el clúster de cliente del nodo B solo cambia el clúster de servidor en el propio nodo B.

En la siguiente sección, detallaremos cómo interactúan los clústeres de cliente y servidor: el modelo de interacción.

Clúster de descriptores

Como su nombre lo indica, el servidor de clústeres de descriptores proporciona información de introspección. Describe el extremo enumerando lo siguiente:

• Clústeres de servidores.
• Son clústeres de clientes.
• Tipos de dispositivos.
• Son extremos adicionales, conocidos como partes.

Cada tipo de dispositivo requiere la implementación de clústeres de descriptores. El tipo de dispositivo raíz se define en el extremo 0. La lectura de su clúster de descriptores proporcionará al cliente la visibilidad para recorrer el árbol completo de los extremos disponibles y realizar las operaciones aplicables.

El dispositivo comisionado o de control, como un teléfono o un concentrador, puede usar la información que se encuentra en el clúster de Descriptor para modelar el dispositivo (luz, interruptor, bomba, termostato) y las funciones específicas que implementa esa instancia en particular del dispositivo, y mostrar la IU correcta al usuario.

Clústeres de servidores

El atributo ServerList enumera los servidores del clúster en el extremo.

Clústeres de clientes

El atributo ClientList enumera los clientes del clúster en el extremo.

Lista de tipos de dispositivos

El atributo DeviceTypeList es una lista de tipos de dispositivos compatibles con el extremo, junto con sus revisiones respectivas. Debe contener al menos un tipo de dispositivo.

Lista de piezas

El campo PartsList contiene la lista de Endpoints que se usan para implementar este tipo de dispositivo.

El PartsList del extremo 0 (nodo raíz) contiene todos los extremos del dispositivo, excepto el extremo 0.

El PartsList de otros Endpoints suele estar vacío. Por ejemplo, un Temperature Sensor exige un clúster de servidores de medición de temperatura y nada más.

Otros tipos de dispositivos pueden componerse en una estructura de árbol de más de una instancia de DeviceType. Por ejemplo, un tipo de dispositivo Reproductor de video puede estar compuesto por TV, Reproductor de video, Bocina y diferentes tipos de dispositivos de app de contenido, cada uno en un extremo diferente.