Modelo de dados do dispositivo

Os dispositivos em Matter têm um modelo de dados (DM, na sigla em inglês) bem definido, que é um modelo hierárquico dos recursos de um dispositivo. No nível superior dessa hierarquia, há um Dispositivo.

Dispositivos e endpoints

Todos os dispositivos, incluindo smartphones e assistentes para casa, são compostos por nós1. Um é 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 atributos. Por exemplo, um endpoint pode estar relacionado a uma funcionalidade de iluminação, outro está relacionado à detecção de movimento e outro trata de utilitários, como o OTA de dispositivo.

Hierarquia de dispositivos, nós e endpoints
Figura 1: dispositivos, nós e endpoints

Papéis de 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 ativação/desativação, têm o papel de controlador.
  • Controlee: 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 a função de Controlador, como o interruptor de luz de ativação/desativação. A chave de luz de ativação/desativação pode ser apenas um controle. Ele não pode ser um Controle.
  • Provedor de OTA: um nó que pode fornecer atualizações de software OTA.
  • Solicitante de OTA: um nó que pode solicitar atualizações de software OTA.

Clusters

Em um Endpoint, um nó tem um ou mais Clusters. Essas são outra etapa na hierarquia de dispositivos, porque elas agrupam funcionalidades específicas, como um cluster de liga/desliga em uma tomada inteligente ou um cluster de controle de nível em um endpoint de luz regulável.

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

Atributos

No último nível, vamos encontrar Attributes, que são estados retidos 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.

Hierarquia de nós, endpoints, atributos e comandos
Figura 2: nós, endpoints, atributos e comandos

Comandos

Além dos atributos, os clusters também têm comandos, que são ações que podem ser realizadas. Elas são o equivalente na mensagem direta do Matter de uma chamada de procedimento remoto. Os comandos são semelhantes a verbos, como lock door em um cluster de Door Lock. Os comandos podem gerar respostas e resultados. Em Matter, essas respostas também são definidas como comandos, indo na direção inversa.

Eventos

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

Exemplo completo de dispositivo
Figura 3: exemplo da hierarquia do modelo de interação de dispositivos Matter.

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ósticos e atualização de software. Por outro lado, os clusters de aplicativos oferecem suporte a ações principais, como ativar/desativar ou medição de temperatura.

Tipos de dispositivo

Ao todo, quais combinações de clusters precisam ser incluídas quando o fabricante planeja um novo dispositivo?

A especificação Matter exige que o dispositivo implemente ou estenda um ou mais tipos de dispositivo. 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 Dimmable Light, Door Lock ou Video Player.

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 aplicativo são definidos na Biblioteca de clusters do aplicativo. 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 clusters opcionais do tipo de dispositivo, ou até mesmo clusters que não fazem parte do tipo de dispositivo.

Clientes e servidores

Os clusters podem ser de cliente ou de servidor. Enquanto um servidor é com estado e tem atributos, eventos e comandos, um cliente é sem estado e tem a responsabilidade de iniciar interações com um cluster de servidor remoto, executando assim:

  • e grava nos atributos remotos.
  • leituras de eventos remotos.
  • invocação dos comandos remotos.

Embora o DM seja hierárquico em um nó, a relação entre nós não é. Os nós em Matter não têm relações controlador/periférico vertical ou líder/seguidor. Pelo contrário, a relação é horizontal: qualquer cluster pode ser Servidor ou Cliente. Assim, um nó pode ser de servidor e cliente no que diz respeito a diferentes clusters e funcionalidades.

Por exemplo, podemos ter duas luminárias de mesa: Nó A e Nó B. Ambos os nós implementam um tipo de dispositivo Luz de ativação/desativação. Esse tipo de dispositivo inclui um cluster de servidor ativado/desativado que controla as respectivas saídas de luz físicas.

No entanto, como as luminárias de mesa típicas, nossos dispositivos físicos também incluem um tipo de dispositivo interruptor de luz de ativação/desativação para os interruptores de ativação/desativação locais. Esse tipo de dispositivo precisa implementar um cluster de cliente ativado/desativado para controlar os clusters de servidor.

Lâmpadas que implementam a opção de ligar/desligar e o interruptor de luz
Figura 4: clusters de cliente e 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, detalhamos 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 o seguinte:

  • Clusters de servidor.
  • Clusters de cliente.
  • Tipos de dispositivo.
  • Endpoints adicionais, conhecidos como peças.

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

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

Clusters de servidor

O atributo ServerList lista os servidores de cluster no endpoint.

Clusters de cliente

O atributo ClientList lista os clientes do 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, exceto ele mesmo (Endpoint 0).

O PartsList de outros endpoints geralmente estará vazio. Por exemplo, um sensor de temperatura exige um cluster de 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 do tipo de dispositivo. Por exemplo, um tipo de dispositivo de player de vídeo pode ser composto por TV, player de vídeo, alto-falante e diferentes tipos de dispositivo de app de conteúdo, cada um em um endpoint diferente.


  1. A especificação Matter determina que um dispositivo pode ter vários nós. Por exemplo, os smartphones podem ter vários apps, cada um sendo um nó diferente. Para os fins deste guia, todos os dispositivos conterão um único nó. Espera-se que a maioria dos dispositivos físicos siga esse padrão.