Modelo de datos del dispositivo

Los dispositivos en Matter tienen un modelo de datos (DM) 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 extremos

Todos los dispositivos, incluidos los smartphones y los asistentes de 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 ser percibirse como totalmente funcional. La comunicación de red en Matter se origina y termina en un nodo.

Los nodos son una colección de extremos. Cada extremo incluye un conjunto de funciones. Por ejemplo, un extremo podría relacionarse con una función de iluminación , mientras que otro se relaciona con la detección de movimiento y otro se ocupa de 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 nodos incluyen lo siguiente:

• Commissioner: Es un nodo que realiza la puesta en servicio.
• 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.
• Controlee: Es un nodo que puede ser controlado por uno o más nodos. La mayoría de los tipos de dispositivos pueden ser un Controlee, excepto algunos tipos de dispositivos que tienen el rol de controlador, como el interruptor de luz de encendido/apagado. El interruptor de luz de encendido/apagado solo puede ser un controlador. No puede ser un Controlee.
• Proveedor de OTA: Es un nodo que puede proporcionar actualizaciones de software OTA.
• Solicitante de OTA: Es un nodo que puede solicitar actualizaciones de software OTA.

Clústeres

Dentro de un extremo , un nodo tiene uno o más clústeres. Estos son otro paso en la jerarquía de dispositivos, ya que agrupan funciones 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 luces individuales, o bien una regleta puede exponer el control de enchufes individuales.

Atributos

En el último nivel, encontraremos atributos, que son estados que mantiene el nodo, como el atributo de 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 Matter's DM de una llamada de procedimiento remoto. Los comandos son similares a los verbos, como bloquear puerta en un clúster de bloqueo de puerta. Los comandos pueden generar respuestas y resultados. En Matter, esas respuestas también se definen como comandos, que van en la dirección inversa.

Eventos

Por último, los clústeres también pueden tener eventos, que se pueden considerar como un registro de 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 monotónica, 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 los 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, el direccionamiento, el diagnóstico y la actualización de software. Por otro lado, los clústeres de aplicaciones admiten acciones principales, como el encendido/apagado o la medición de temperatura.

Tipos de dispositivos

En conjunto, ¿qué combinaciones de clústeres se deben incluir cuando un fabricante de dispositivos planifica 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, bloqueo de puerta o reproductor de video.

Los tipos de dispositivos no se especifican en el Matter documento principal de la especificación, 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 pueden encontrar en el Connectivity Standards Alliance (Alliance) sitio web de los miembros.

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 tiene estado y contiene atributos, eventos y comandos, un cliente no tiene estado y su responsabilidad es iniciar interacciones con un clúster de servidor remoto, por lo que realiza lo siguiente:

• Lecturas y escrituras 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 o 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 servidor y 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 de luz de encendido/apagado. Este tipo de dispositivo incluye un clúster de servidor de encendido/apagado que controla sus respectivas salidas de luz física.

Sin embargo, como lo hacen las lámparas de mesa típicas, nuestros dispositivos físicos también incluirán un tipo de dispositivo de 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 que pueda controlar los clústeres de servidores.

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 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 descriptor

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

• Clústeres de servidores
• Clústeres de clientes
• Tipos de dispositivos
• Extremos adicionales, conocidos como piezas

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

El dispositivo de comisionado o de control, como un teléfono o un hub, 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, lo que muestra la IU correcta al usuario.

Clústeres de servidores

El atributo ServerList muestra los servidores de clúster en el extremo.

Clústeres de clientes

El atributo ClientList muestra los clientes de 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

PartsList contiene la lista de extremos que se usan para implementar este tipo de dispositivo.

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

PartsList de otros extremos suele estar vacío. Por ejemplo, un sensor de temperatura exige un clúster de servidor de medición de temperatura y nada más.

Otros tipos de dispositivos se pueden componer en una estructura de árbol de más de una instancia de tipo de dispositivo. Por ejemplo, un tipo de dispositivo de 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.