Modelo de dados do dispositivo

Os dispositivos em Matter têm um modelo de dados (DM) bem definido, que é uma modelagem hierárquica dos recursos de um dispositivo. No nível mais alto dessa hierarquia, há um Device.

Dispositivos e endpoints

Todos os dispositivos, incluindo smartphones e assistentes domésticos, são compostos de nós¹. Um nó é um recurso exclusivo identificável e endereçável em uma rede que um usuário pode perceber como funcionalmente inteiro. A comunicação de rede em Matter se origina e termina em um nó.

Os nós são uma coleção de Endpoints. Cada endpoint inclui um conjunto de recursos. Por exemplo, um endpoint pode estar relacionado a uma funcionalidade de iluminação, enquanto outro está relacionado à detecção de movimento e a outro se refere a utilitários como o OTA do dispositivo.

Papéis do nó

Um papel de nó é um conjunto de comportamentos relacionados. Cada nó pode ter um ou mais papéis. Os papéis de nó incluem:

• Comissário: um nó que realiza comissionamento.
• Controlador: um nó que pode controlar um ou mais nós. Os exemplos incluem Google Home app (GHA), Google Assistant e Google Nest Hub (2nd gen). Alguns tipos de dispositivos, como a chave de luz ativada/desativada, têm o papel de controlador.
• Controle: um nó que pode ser controlado por um ou mais nós. A maioria dos tipos de dispositivo pode ser um controle, exceto alguns que têm o papel de controlador, como o interruptor de ativação/desativação. O interruptor de luz ativada/desativada pode ser apenas um controlador. Não pode ser um controle.
• Provedor de OTA: um nó que pode fornecer atualizações de software OTA.
• Solicitante OTA: um nó que pode solicitar atualizações de software OTA.

Clusters

Em um Endpoint, um nó tem um ou mais clusters. Elas são outra etapa na hierarquia de dispositivos, porque agrupam funcionalidades específicas, como um cluster de ativação/desativação em um plugue inteligente ou um cluster de controle de nível em um endpoint com luz diminuível.

Um nó também pode ter vários endpoints, cada um criando uma instância da mesma funcionalidade. Por exemplo, uma luminária pode expor controle independente de lâmpadas individuais, ou uma tomada pode expor o controle de tomadas individuais.

Atributos

No último nível, encontramos Atributos, que são estados mantidos pelo nó, como o atributo de nível atual de um cluster de controle de nível. Os atributos podem ser definidos como diferentes tipos de dados, como uint8, strings ou matrizes.

Comandos

Além dos atributos, os clusters também têm comandos, que são ações que podem ser realizadas. Elas são equivalentes na mensagem direta do Matter de uma chamada de procedimento remoto. Os comandos são semelhantes a verbo, como porta de bloqueio, em um cluster de porta de bloqueio. Os comandos podem gerar respostas e resultados. No Matter, essas respostas também são definidas como comandos, na direção inversa.

Eventos

Por fim, os clusters também podem ter Eventos, que podem ser considerados como um registro de transições de estado anteriores. Embora os atributos representem os estados atuais, os eventos são um diário do passado e incluem um contador monotonicamente crescente, um carimbo de data/hora e uma prioridade. Eles permitem capturar transições de estado, bem como modelagem de dados que não é prontamente alcançada com atributos.

O Endpoint 0 é reservado para os Clusters de utilitários. Clusters de utilitários são clusters específicos que incluem funcionalidades de serviço em um endpoint, como descoberta, endereçamento, diagnóstico e atualização de software. Por outro lado, os clusters de aplicativos são compatíveis com ações principais, como ativação/desativação ou medição de temperatura.

Tipos de dispositivo

No total, quais combinações de cluster precisam ser incluídas quando um fabricante de dispositivos planeja um novo dispositivo?

A especificação Matter requer que o dispositivo implemente ou estenda um ou mais Tipos de dispositivos. Um tipo de dispositivo é uma coleção de clusters obrigatórios e opcionais que definem os atributos de nível superior de um dispositivo físico, como luz diminuível, porta ou player de vídeo.

Os tipos de dispositivos não são especificados pelo documento principal de especificação Matter, mas por um documento complementar: a Biblioteca de dispositivos. Da mesma forma, todos os clusters de aplicativos são definidos na biblioteca de clusters de aplicativos. Esses três documentos podem ser encontrados no site dos membros do Connectivity Standards Alliance (Alliance).

Cada endpoint que implementa um tipo de dispositivo precisa implementar os clusters obrigatórios que definem esse tipo de dispositivo. Além dos clusters obrigatórios, o endpoint pode implementar outros clusters, incluindo um ou mais dos clusters opcionais do tipo dispositivo, ou até mesmo clusters que não fazem parte do tipo de dispositivo.

Clientes e servidores

Os clusters podem ser um cluster de cliente ou um cluster de servidor. Enquanto um servidor está com estado e mantém atributos, eventos e comandos, um cliente é sem estado e a responsabilidade dele é iniciar interações com um cluster de servidor remoto, realizando assim:

• reads e writes nos atributos remotos.
• leituras dos eventos remotos.
• invocação de seus comandos remotos.

A mensagem direta é hierárquica dentro de um nó, mas a relação entre eles não é. Os nós em Matter não têm relações de controlador/periférico vertical ou de líder/seguidor. Pelo contrário, o relacionamento é horizontal: qualquer cluster pode ser Server ou Client. Assim, um nó pode ser servidor e cliente em relação a diferentes clusters e funcionalidades.

Por exemplo, podemos ter dois luminárias de tabela: Node A e Node B. Ambos os nós implementam um tipo de dispositivo On/Off Light. Esse tipo de dispositivo inclui um cluster de ativação/desativação do servidor que controla as respectivas saídas de luz física.

Mas, como é o caso das luminárias comuns, nossos dispositivos físicos também incluem um tipo de dispositivo de chaves de ativação/desativação para os interruptores locais. Esse tipo de dispositivo precisa implementar um cluster On/Off Client para que possa controlar os clusters de servidor.

Neste exemplo, o cluster de cliente ativado/desativado no nó A está alterando os atributos do cluster de servidor ativado/desativado no nó A e no nó B, enquanto o cluster de cliente do nó B está alterando apenas o cluster de servidor no próprio nó B.

Na próxima seção, detalharemos como os clusters de cliente e servidor interagem: o Modelo de interação.

Cluster do descritor

Como o nome indica, o servidor de cluster do descritor fornece informações de introspecção. Ele descreve o endpoint enumerando:

• Clusters de servidor.
• Clusters de cliente.
• Tipos de dispositivos.
• Endpoints adicionais, conhecidos como Peças.

Cada tipo de dispositivo requer a implementação de clusters do descritor. O tipo de dispositivo raiz é definido no endpoint 0. A leitura do cluster de descritor proporcionará ao cliente a visibilidade para atravessar toda a árvore de endpoints disponíveis e realizar as operações aplicáveis.

O comissário ou dispositivo de controle, como um smartphone ou hub, pode usar as informações encontradas no cluster de descritor para modelar o dispositivo (luz, interruptor, bomba, termostato) e recursos específicos implementados por essa instância específica do dispositivo, mostrando a IU correta para o usuário.

Clusters de servidor

O atributo ServerList lista os servidores de cluster no endpoint.

Clusters de cliente

O atributo ClientList lista os clientes de cluster no endpoint.

Lista de tipos de dispositivos

O atributo DeviceTypeList é uma lista de tipos de dispositivos compatíveis com o endpoint e as respectivas revisões. Ele precisa conter pelo menos um tipo de dispositivo.

Lista de peças

O PartsList contém a lista de endpoints usados para implementar esse tipo de dispositivo.

O PartsList do endpoint 0 (nó raiz) contém todos os endpoints do dispositivo separados dele (endpoint 0).

O PartsList de outros endpoints geralmente estará vazio. Por exemplo, um Sensor de temperatura exige um cluster do Servidor de medição de temperatura e nada mais.

Outros tipos de dispositivos podem ser compostos em uma estrutura de árvore de mais de uma instância de tipo de dispositivo. Por exemplo, um tipo de dispositivo de player de vídeo pode ser composto de TV, player de vídeo, alto-falante e diferentes tipos de dispositivos de apps de conteúdo, cada um em um endpoint diferente.