segunda-feira, 27 de abril de 2020

NINA B112/B302 MESH

U-BLOX NINA  B112/B302 em MESH

O objetivo deste BLOG é mostrar que é possível implementar uma rede MESH em cima dos módulos NINA B302 e NINA B112.

 Para o NINA B112 utilizamos o EVK e para o NINA B302 o breakout.






O Bluetooth existe há algum tempo. De fato, recentemente comemorou seu 20º aniversário !
A introdução do padrão Bluetooth Low Energy (BLE) surgiu em 2010 para abordar o rápido crescimento de casos de uso no campo da Internet das Coisas (IoT), incluindo sensores, dispositivos vestíveis, dispositivos médicos etc. No entanto, uma coisa que faltava ao BLE desde o O começo era a capacidade de suportar uma topologia muitos para muitos (geralmente chamada de  malha ) , em que vários dispositivos BLE podem enviar mensagens uns aos outros e retransmitir mensagens para outros dispositivos dentro de uma rede.
Tudo isso mudou em julho de 2017, quando o Bluetooth SIG lançou o padrão de malha Bluetooth .
Abordaremos os princípios mais importantes que você precisa conhecer para entender melhor a malha Bluetooth e como ela funciona. O tópico da malha Bluetooth é extenso e não pode ser abordado em uma única postagem. Por isso, abordaremos uma série de postagens no blog. No tutorial de hoje, abordaremos os seguintes aspectos:
  • Noções básicas de malha Bluetooth
  • Terminologia:
    • Nós
    • Elementos
    • Estados
    • Propriedades
    • Mensagens
    • Endereços
    • Publicar / Assinar
    • Inundações gerenciadas
Mas primeiro, algumas notas importantes sobre a malha Bluetooth:
  • O Bluetooth SIG refere-se ao padrão como malha Bluetooth (com um "m" minúsculo na palavra "malha").
  • O padrão não faz parte do padrão Core Bluetooth (em vez disso, é definido em sua própria especificação separada).
  • Dito isto, a malha Bluetooth se baseia no BLE e utiliza muitos dos conceitos do BLE.
  • Existem dois estados principais nos quais um dispositivo BLE opera:  publicidade (ou varredura ) ou conexão . A malha Bluetooth utiliza apenas os estados de publicidade / varredura dos dispositivos BLE. Isso significa que os dispositivos que fazem parte de uma rede mesh Bluetooth não se conectam um ao outro, como os dispositivos BLE tradicionais. Mas eles transmitem informações entre si por meio de pacotes de publicidade recebidos pelos outros dispositivos via Digitalização (existe uma exceção, envolvendo o que é chamado de nó Proxy, que abordaremos em breve).
  • A malha Bluetooth suporta todas as versões do BLE (voltando à versão 4.0 do Bluetooth, que é a primeira versão da especificação Bluetooth que incluía o BLE).
  • Atualmente, no momento deste artigo (setembro de 2018), a malha Bluetooth não suporta recursos do Bluetooth 5, como extensões de publicidade e o modo de longo alcance (codificado em PHY).
  • O número máximo de nós em uma rede mesh Bluetooth (definido na versão 1.0 da especificação) é 32.767 nós .
  • O número máximo de saltos que uma mensagem pode percorrer em uma rede mesh Bluetooth (definida na versão 1.0 da especificação) é de 127 saltos .

O que é o Bluetooth Mesh?

A especificação de malha Bluetooth foi lançada em julho de 2017 com o objetivo de aumentar o alcance das redes Bluetooth e adicionar suporte para mais aplicativos industriais que utilizam o BLE.
As versões anteriores do Bluetooth suportavam duas topologias diferentes:
  • Um para um : quando dois dispositivos BLE estão conectados.
  • Um para muitos : quando os dispositivos BLE operam exclusivamente no estado Broadcast, como Beacons .
Com a malha Bluetooth, uma nova topologia é introduzida para o BLE. Agora, os dispositivos podem operar em uma topologia muitos para muitos, ou o que é chamado de malha, onde dispositivos podem configurar conexões com vários outros dispositivos na rede.
Imagem de topologias Bluetooth
Figura 1: topologias de BLE
Na página da Wikipedia sobre redes de malha :
Uma  rede mesh  é uma topologia de rede local na qual os nós da infraestrutura (pontes, comutadores e outros dispositivos de infraestrutura) se conectam direta, dinâmica e não hierarquicamente ao maior número possível de nós e cooperam entre si para rotear dados de / para clientes. Essa falta de dependência em um nó permite que todos os nós participem da retransmissão de informações. As redes de malha se organizam e se configuram dinamicamente, o que pode reduzir a sobrecarga da instalação. A capacidade de se autoconfigurar permite a distribuição dinâmica de cargas de trabalho, principalmente no caso de falha de alguns nós. Isso, por sua vez, contribui para a tolerância a falhas e custos de manutenção reduzidos.
Existem dois benefícios principais de uma rede em malha:
  • Faixa estendida:
    como os nós podem retransmitir mensagens para nós distantes através dos nós entre eles, isso permite que uma rede estenda sua faixa e expanda o alcance dos dispositivos.
  • Recursos de autocorreção:
    a autocura refere - se ao fato de que não há um único ponto de falha. Se um nó cair da rede de malha, os outros nós ainda poderão participar e enviar mensagens um ao outro. No entanto, isso é apenas parcialmente verdadeiro para a malha Bluetooth, pois possui diferentes tipos de nós na rede, dos quais outros nós podem depender.

Comparação com outras redes de malha sem fio

Existem algumas diferenças entre o protocolo de malha Bluetooth e outras redes de malha disponíveis (incluindo Thread, Zigbee e Z-Wave). Alguns dos mais importantes são:
  • A malha Bluetooth não usa o Protocolo da Internet (IP) - em vez disso, ela se baseia no BLE.
  • A malha Bluetooth usa uma técnica de inundação gerenciada em comparação com  as técnicas de roteamento usadas por outros protocolos.
  • Embora a malha Bluetooth se baseie no BLE e utilize a marca Bluetooth, na verdade é uma nova tecnologia que ainda não se comprovou no mercado.
  • O foco principal do atual padrão de malha Bluetooth ( versão 1.0 ) é para aplicativos de iluminação. Isso não quer dizer que não funcione para outras aplicações, é simplesmente mais fácil aplicá-lo atualmente a sistemas de iluminação.
Vamos examinar alguns dos conceitos mais importantes da malha Bluetooth.

Conceitos de malha Bluetooth

Existem muitos conceitos que precisamos abordar para entender melhor a maneira como a malha Bluetooth  funciona. Abordaremos todos eles começando com esta postagem e continuando nas próximas postagens desta série.

Nós

Um nó é um dispositivo que ingressou em uma rede de malha Bluetooth. Os dispositivos que não fazem parte da rede são chamados de dispositivos não provisionados . Quando um dispositivo não provisionado é provisionado, ele entra na rede e se torna um nó.
Imagem de nós e dispositivos não provisionados
Figura 2: Nós e dispositivos não provisionados

Elementos

Um nó pode conter várias partes que podem ser controladas independentemente. Por exemplo, uma luminária pode conter várias lâmpadas que podem ser ligadas / desligadas independentemente. Essas diferentes partes de um único nó são chamadas de  elementos .
Elementos dentro de uma figura de nó
Figura 3: Elementos dentro de um nó

Estados

Os elementos podem estar em várias condições, representadas por valores de estado . Por exemplo, ligar e desligar são estados de uma lâmpada dentro de uma luminária. Uma mudança de um estado para outro é chamada de transição de estado . Isso pode ser instantâneo ou ocorrer com o tempo, após o que é chamado de período de transição . Quando ocorre uma alteração de estado, é provável que cause uma alteração no comportamento de um elemento.
Alguns estados podem estar ligados entre si, o que significa que uma mudança em um estado aciona uma mudança no outro. Pode haver dois ou mais estados ligados um ao outro. Tomemos, por exemplo, um redutor de luz: ele provavelmente terá um estado de nível e um estado de ligado / desligado. Se o valor do estado do nível mudar para zero , ele acionará o estado ativado / desativado para passar para desativado . Se o valor do nível mudar de zero para um valor diferente de zero, isso aciona o estado ativado / desativado para passar para ativado .

Propriedades

Propriedades adicionam algum contexto a um valor de estado. Por exemplo, definir que um valor de temperatura é uma  temperatura externa  ou  interna . Existem dois tipos de propriedades:
  • Propriedade do fabricante : fornece acesso somente leitura
  • Propriedade Admin : fornece acesso de leitura e gravação

Mensagens

Na malha Bluetooth, todas as comunicações na rede são orientadas a mensagens e os nós enviam mensagens para controlar ou retransmitir informações entre si. As mensagens são o mecanismo pelo qual as operações nos nós são chamadas. Se um nó precisar relatar seu status, ele também o envia por uma mensagem. Um determinado tipo de mensagem representa uma operação em um estado ou coleção de vários valores de estado.
Existem três tipos de mensagens na malha Bluetooth, cada uma delas definida por um código de operação exclusivo (código de operação):
  • Uma mensagem GET : uma mensagem para solicitar o estado de um ou mais nós.
  • Uma mensagem SET : uma mensagem para alterar o valor de um determinado estado.
  • Uma mensagem de STATUS : Uma mensagem de status é usada em diferentes cenários:
    • Em resposta a uma mensagem GET, contendo o valor do estado.
    • Em resposta a uma mensagem SET reconhecida.
    • Enviado independentemente de qualquer mensagem para relatar o status do elemento. Um exemplo é uma mensagem que é acionada por um timer em execução no elemento que está enviando essa mensagem.
Algumas mensagens exigem que uma mensagem de confirmação seja enviada pelo destinatário da mensagem original. Uma mensagem de confirmação serve para dois propósitos:
  • Confirmação de recebimento da mensagem.
  • Retorno de dados relacionados à mensagem recebida.
Caso uma resposta à mensagem não seja recebida pelo remetente ou uma resposta inesperada seja recebida, o remetente poderá reenviar a mensagem. Várias mensagens reconhecidas recebidas por um nó não afetam o comportamento (é como se a mensagem tivesse sido recebida uma vez).

Endereços

As mensagens em uma rede mesh Bluetooth devem ser enviadas para e de um endereço. Existem três tipos de endereços:
  • Endereço Unicast : um endereço que identifica exclusivamente um único nó atribuído durante o processo de provisionamento (que abordaremos em uma próxima publicação).
  • Endereço do grupo : um endereço usado para identificar um grupo de nós. Um endereço de grupo geralmente reflete um agrupamento físico de nós, como todos os nós em uma sala específica. Um endereço de grupo pode ser:
    • Definido pelo Bluetooth SIG, também conhecido como Endereço de grupo fixo SIG. Isso inclui endereços de grupo Todos os proxies, Todos os amigos, Todas as retransmissões e Todos os nós.
    • Endereço de grupo dinâmico, definido pelo usuário por meio de um aplicativo de configuração.
  • Endereço virtual : um endereço que pode ser atribuído a um ou mais elementos, abrangendo um ou mais nós. Isso atua como um rótulo e assume a forma de um UUID de 128 bits ao qual qualquer elemento pode ser associado. É provável que os endereços virtuais sejam pré-configurados no momento da fabricação.

Publicar / Assinar

A maneira como as mensagens são trocadas em uma rede mesh Bluetooth é através do padrão de publicação-assinatura . Na página da Wikipedia sobre o padrão de publicação e assinatura:
Na arquitetura de software,  publicar-assinar  é um padrão de mensagens em que os remetentes de mensagens, chamados editores, não programam as mensagens a serem enviadas diretamente para receptores específicos, chamados assinantes, mas categorizam as mensagens publicadas em classes sem o conhecimento de quais assinantes, se houver. , pode ser. Da mesma forma, os assinantes expressam interesse em uma ou mais classes e recebem apenas mensagens de seu interesse, sem o conhecimento de quais editores, se houver, existem.
Publicar é o ato de enviar uma mensagem. A inscrição é uma configuração usada para permitir que mensagens selecionadas sejam enviadas para endereços específicos para processamento. Normalmente, as mensagens são endereçadas a endereços virtuais ou de grupo .
Aqui está um exemplo de uma rede de malha em uma casa composta por 6 interruptores de luz e 9 lâmpadas. A rede utiliza o método de publicação-assinatura para permitir que os nós enviem mensagens um para o outro.

Figura 4: Publicar-assinar no sistema de controle de iluminação de malha Bluetooth (Fonte: “Bluetooth Mesh - Uma introdução para desenvolvedores”)
Os nós podem se inscrever em vários endereços. Um exemplo disso é a luz nº 3 na figura acima, que é assinada pelos endereços de grupo da cozinha e da sala de jantar . Além disso, vários nós podem publicar no mesmo endereço, como os switches 5 e 6 deste exemplo. Esses dois interruptores controlam o mesmo grupo de luzes, localizado no jardim.
O benefício de usar endereços virtuais ou de grupo é que adicionar ou remover nós não requer reconfiguração de nós.

Inundações gerenciadas

Muitas redes de malha usam mecanismos de roteamento para retransmitir mensagens pela rede. O outro extremo é inundar a rede com as mensagens sendo retransmitidas sem considerar as rotas ideais que essas mensagens precisam seguir para alcançar seus destinos em perspectiva. A malha Bluetooth usa uma técnica que compromete essas duas técnicas. Essa técnica é chamada de  inundação gerenciada .
A inundação gerenciada depende da transmissão de mensagens para todos os nós dentro do alcance do nó remetente, com algumas otimizações adicionais:
  • As mensagens têm um TTL atribuído
    TTL significa  tempo de vida útil , o que limita o número de saltos que uma mensagem pode levar em vários nós na rede mesh. Um valor de zero indica que uma mensagem tem não sido secundada e deve não ser retransmitida. Isso significa que um nó pode enviar uma mensagem para outros nós que estão em seu alcance de rádio direto e indica que o (s) nó (s) de recebimento não deve retransmitir a mensagem.
    Se uma mensagem é enviada com um TTL ≥ 2, cada vez que é retransmitida, o valor do TTL é diminuído. Um valor TTL de 1  significa que a mensagem pode ter sido retransmitida pelo menos uma vez, mas que não deve ser retransmitida novamente.
  • As mensagens são armazenadas em
    cache O cache de mensagens é exigido por todos os nós e requer que as mensagens recebidas que já existem no cache sejam descartadas imediatamente.
  • As mensagens de pulsação são enviadas periodicamente As
    mensagens de pulsação são usadas para indicar a outros nós que o remetente está ativo e ativo na rede.
  • Amizade
    Amizade refere-se ao relacionamento entre dois nós. Esses dois tipos de nós são:
    • Um nó de baixa energia , ou  LPN , economiza energia e não pode receber mensagens de malha o tempo todo. Esse nó passa a maior parte do tempo com o rádio desligado.
    • Um nó energizado ao vivo chamado nó  amigo, que pode servir como um proxy para o LPN. O nó amigo armazena em cache as mensagens para que o LPN economize energia, para que o LPN possa permanecer adormecido a maior parte do tempo e acordar apenas ocasionalmente. Quando o LPN é ativado, ele pesquisa o nó amigo para ler as mensagens em cache e envia as mensagens necessárias para a rede em malha.
Existem vários outros tipos de nós em uma rede mesh que abordaremos posteriormente.

Sumário

Neste post, abordamos o básico e algumas das terminologias mais importantes na malha Bluetooth. Nas próximas postagens desta série, abordaremos mais aspectos da malha Bluetooth, incluindo:
  • A arquitetura da malha Bluetooth
  • Os tipos de nós em uma rede de malha Bluetooth
  • O processo de provisionamento
  • Segurança
Além disso, mais adiante, abordaremos alguns dos aspectos práticos do mesh Bluetooth e como implementá-lo na plataforma nórdica nRF52.





No tutorial da semana passada ( The Ultimate Bluetooth Mesh Tutorial (Parte 1) ) desta série sobre Bluetooth mesh, abordamos o seguinte:
  • Noções básicas de malha Bluetooth
  • Terminologia: nós, elementos, estados, propriedades, mensagens, endereços, publicação-assinatura e inundação gerenciada.
No tutorial desta semana, continuaremos abordando mais alguns conceitos na malha Bluetooth, incluindo:
  • Modelos
  • Cenas
  • Tipos de nós:
    • Nós de retransmissão
    • Nós de proxy
    • Nós amigos
    • Nós de baixa potência
  • A arquitetura da malha Bluetooth
Vamos analisar cada um desses detalhes com mais detalhes.

Modelos

Um termo importante definido na malha Bluetooth é o conceito de modelo . Um modelo define algumas ou todas as funcionalidades de um determinado elemento.
Existem três categorias de modelos:
  • Modelo de servidor : é uma coleção de estados, transições de estado, ligações de estado e mensagens que um elemento que contém o modelo pode enviar ou receber.
  • Modelo do cliente : não define nenhum estado; em vez disso, define apenas mensagens como as mensagens GET, SET e STATUS enviadas para um modelo de servidor.
  • Modelo de controle : contém um modelo de servidor e cliente, permitindo a comunicação com outros modelos de servidor e cliente.
Os modelos podem ser estendidos para incluir funcionalidade adicional em vez de modificar o modelo original. Um modelo que não é estendido é chamado de modelo raiz .

Cenas

Outro conceito que queremos abordar é o conceito de cenas em uma rede mesh Bluetooth. Uma cena é uma coleção armazenada de estados e é identificada por um número de 16 bits que é único na rede de malha.
As cenas permitem acionar uma ação para definir vários estados de diferentes nós. Eles podem ser acionados sob demanda ou em um horário especificado. Por exemplo, uma cena pode ser configurada para definir a temperatura de uma sala em 72 graus, a sala de estar acende um certo nível de brilho e a janela se fecha para fechar.

Tipos de nós

Todos os tipos de nós podem enviar e receber mensagens de malha. No entanto, recursos opcionais fornecem recursos especiais a nós específicos. Aqui estão os diferentes tipos de nós com os recursos opcionais ativados:
  • Nós de retransmissão
  • Nós de proxy
  • Nós amigos
  • Nós de baixa potência
Um nó pode suportar nenhum, alguns ou todos esses recursos opcionais, que podem ser ativados ou desativados a qualquer momento. Por exemplo, um único nó pode ter os recursos de um nó de retransmissão , nó proxy e nó amigo , todos ao mesmo tempo.

Nós de retransmissão

Um nó de retransmissão é aquele que suporta o recurso de retransmissão. Isso significa que ele pode retransmitir mensagens transmitidas por outros nós. Isso permite estender o alcance dessas mensagens e atravessar toda a rede além do alcance do nó transmissor original.

Figura 1: Nó de retransmissão

Nós de proxy

Para permitir a comunicação com uma rede em malha a partir de um dispositivo BLE não suportado por malha, um tipo especial de nó chamado nó proxy pode ser utilizado. Um nó proxy atua como intermediário e utiliza operações GATT para permitir que outros nós fora da rede mesh interajam e interajam com a rede.
O protocolo usado neste caso é chamado de protocolo proxy , que deve ser usado com um dispositivo habilitado para conexão (usando o GATT).
O protocolo é construído sobre o GATT e permite que um dispositivo leia e grave PDUs do protocolo proxy a partir das características do GATT expostas pelo nó proxy. O nó do proxy executa a conversão entre as PDUs do protocolo proxy e as PDUs de malha.
Por exemplo, isso permite que um smartphone que não implementa o protocolo de malha Bluetooth interaja com uma rede de malha por meio de um dispositivo proxy através das operações do GATT.
Nó de proxy
Figura 2: Nó proxy

Nós amigos e nós de baixa potência

Um nó amigo e um nó de baixa energia (LPN) estão intimamente relacionados. De fato, para que um nó de baixa energia participe de uma rede em malha Bluetooth, é necessário um relacionamento de amizade com outro nó, chamado nó amigo .
Aqui está como esses dois tipos de nós funcionam juntos:
  • Os nós de baixa energia geralmente têm fonte de alimentação limitada, como baterias, portanto, eles precisam economizar energia mantendo o rádio desligado o mais rápido possível.
  • Nós de baixa energia podem estar preocupados em enviar mensagens mais do que em recebê-las. Tomemos, por exemplo, um sensor de temperatura alimentado por uma bateria de célula tipo moeda. Pode ser necessário enviar a leitura da temperatura uma vez por minuto sempre que essa leitura estiver acima ou abaixo de um limite definido. Se o usuário decidir alterar o limite, isso será enviado em uma mensagem ao sensor de temperatura. Para que o sensor não perca esta mensagem de configuração de limite, ele precisa estar sempre ligado, o que significa que consumirá muita energia.
  • Para resolver o problema mencionado no ponto anterior, é introduzido o conceito de um nó amigo. Um nó amigo permite que o nó de baixa energia permaneça adormecido por mais tempo.
  • Os nós amigos tornam isso possível, armazenando em cache as mensagens destinadas ao nó de baixa energia. O nó de baixa energia, sob seu controle, acorda e consulta o nó amigo por essas mensagens em cache. Quando pesquisa as mensagens, também envia as mensagens necessárias para retransmitir à rede para o nó amigo.
  • O relacionamento entre um nó amigo e um nó de baixa potência é conhecido como "amizade".
  • A amizade é essencial para permitir que nós com restrição de energia participem de uma rede em malha, mantendo o consumo de energia otimizado.
Nó Amigo
Figura 3: Nós amigos e nós de baixa energia

A arquitetura do Bluetooth Mesh

A malha Bluetooth se baseia no BLE. Utiliza especificamente o estado de publicidade dos dispositivos BLE. Os dispositivos em uma rede mesh Bluetooth não se conectam como os dispositivos BLE tradicionais. Em vez disso, eles usam os estados de publicidade e verificação para retransmitir mensagens entre si. Há uma exceção a isso em um dispositivo especial que pode fazer parte da rede mesh (que abordaremos na seção “Tipos de nós”).

Figura 4: arquitetura de malha Bluetooth
Aqui está uma descrição para cada uma das camadas da arquitetura da malha Bluetooth (começando pela camada inferior):
  1. Camada Bluetooth Low Energy
    Como mencionamos anteriormente, a malha Bluetooth se baseia no BLE, portanto, é necessário que uma pilha BLE completa esteja em execução no dispositivo. Ele utiliza os estados de publicidade e varredura para enviar e receber mensagens entre dispositivos na rede mesh. Ele também suporta o estado conectado e o GATT para dispositivos especiais chamados nós proxy .
  2. Camada de suporte
    A camada de suporte define como os diferentes pacotes de malha (unidades de dados de protocolo ou PDUs) são tratados. Existem dois tipos de portadores de malha Bluetooth:
    • Portador de publicidade: esse portador utiliza os estados de publicidade e verificação dos dispositivos BLE.
    • Portador GATT: esse portador utiliza o estado de conexão dos dispositivos BLE. Ele permite que dispositivos que não sejam de malha interajam com a rede de malha por meio de operações do GATT. Isso é realizado através de um nó especial chamado nó proxy.
  3. Camada inferior de transporte
    Esta camada lida com duas tarefas principais:
    • Segmentação de pacotes da camada acima (camada de transporte superior)
    • Remontagem de pacotes da camada abaixo (camada portadora)
  4. Camada de transporte superior
    Esta camada é responsável pelas seguintes funcionalidades:
    • Criptografia
    • Descriptografia
    • Autenticação
    • Mensagens de controle de transporte (batimentos cardíacos, amizade etc.)
  5. Camada de acesso
    Esta camada define como o aplicativo usa a camada de transporte superior. Ele lida com as seguintes tarefas:
    • Formato de dados do aplicativo
    • Criptografia e descriptografia
    • Verificação de dados
  6. Camada de modelos de fundação
    Esta camada está relacionada aos modelos de configuração e gerenciamento de rede.
  7. Camada de modelos
    Esta camada aborda a implementação de modelos, incluindo comportamentos, mensagens, estados e ligações de estados.

Sumário

Neste post, abordamos algumas terminologias adicionais na malha Bluetooth, além de uma visão geral de alto nível de sua arquitetura. No próximo post, abordaremos um dos conceitos mais importantes na malha Bluetooth: o processo de provisionamento . Também abordaremos o tópico de segurança e como ele é tratado na malha Bluetooth. Continuando depois disso, começaremos a implementar uma rede de malha Bluetooth simples na plataforma da série nórdica nRF52.





Neste post, continuamos nossa série de tutoriais sobre malha Bluetooth (você pode encontrar a parte 1 aqui e a parte 2 aqui ). Este será o post final que abordará o conteúdo “somente teoria” - nas próximas postagens, começaremos a aprofundar a prática implementando um exemplo de malha Bluetooth na plataforma da série nórdica nRF52.
Nesta postagem, abordaremos o processo de provisionamento e como a segurança é tratada na malha Bluetooth.

O processo de provisionamento

O processo de provisionamento é um dos conceitos mais importantes na malha Bluetooth. É usado para adicionar dispositivos à rede mesh. Um dispositivo adicionado à rede é chamado de nó, e o dispositivo usado para adicionar um nó à rede é chamado de provisionador (geralmente um tablet, smartphone ou PC).
Esse processo envolve cinco etapas:

Etapa 1: Beaconing

A Etapa 1 envolve o que é chamado beaconing , em que o dispositivo não provisionado anuncia sua disponibilidade a ser provisionada enviando os  anúncios do beacon de malha nos pacotes de anúncios. Este é um novo tipo de tipo de dado de anúncio introduzido no padrão de malha Bluetooth. Uma maneira comum de acionar esse processo é através de uma sequência definida de pressionamentos de botão no dispositivo não provisionado.

Etapa 2: convite

Quando o provisionador descobre o dispositivo não provisionado por meio dos beacons enviados, ele envia um convite para esse dispositivo não provisionado. Isso usa um novo tipo de PDU introduzido na malha Bluetooth chamado PDU de convite de provisionamento .
O dispositivo não provisionado responde com informações sobre seus recursos em uma PDU de recursos de provisionamento , que inclui:
  • O número de elementos que o dispositivo suporta.
  • O conjunto de algoritmos de segurança suportados.
  • A disponibilidade de sua chave pública usando uma tecnologia Out-of-Band (OOB) .
  • A capacidade deste dispositivo de gerar um valor para o usuário.
  • A capacidade deste dispositivo de permitir que um valor seja inserido pelo usuário.
Figura 1: Etapa de convite de provisionamento

Etapa 3: Troca de Chave Pública

A segurança na malha Bluetooth envolve o uso de uma combinação de chaves simétricas e assimétricas, como o algoritmo de curva elíptica Diffie-Hellman (ECDH). No ECDH, as chaves públicas são trocadas entre o provedor e o dispositivo a ser provisionado. Isso é feito diretamente no BLE ou através de um canal fora da banda (OOB) .
Figura 2: Etapa de troca de chave pública

Etapa 4: autenticação

O próximo passo é autenticar o dispositivo não provisionado. Isso geralmente requer uma ação do usuário interagindo com o fornecedor e o dispositivo não provisionado. O método de autenticação depende dos recursos dos dois dispositivos usados.
Em um caso, chamado OOB de saída , o dispositivo não provisionado pode gerar um número aleatório de um ou vários dígitos para o usuário de alguma forma, como piscar um LED várias vezes. Esse número é então inserido no dispositivo de provisionamento por meio de algum método de entrada. Outros casos incluem um OOB de entrada , em que o número é gerado pelo provisionador e inserido no dispositivo não provisionado, um OOB estático ou nenhum OOB .
Independentemente do método de autenticação usado, a autenticação também inclui uma etapa de geração de valor de confirmação e uma etapa de verificação de confirmação.
Figura 3: Etapa de autenticação

Etapa 5: Fornecer distribuição de dados

Após a conclusão da autenticação, cada dispositivo obtém uma chave de sessão usando sua chave privada e a chave pública enviada a partir do outro dispositivo. A chave da sessão é então usada para proteger a conexão para troca de dados de provisionamento adicionais , incluindo a chave de rede (NetKey) , uma chave de dispositivo , um parâmetro de segurança conhecido como índice IV e um endereço unicast atribuído ao dispositivo provisionado por o provedor. Após esta etapa, o dispositivo não provisionado fica conhecido como nó .

Como é tratada a segurança no Bluetooth Mesh?

A primeira observação importante sobre segurança na malha Bluetooth é que ela é obrigatória . Isso é comparado ao BLE, onde é opcional e deixado ao desenvolvedor para decidir se o inclui ou não.
Aqui estão alguns dos princípios básicos de segurança na malha Bluetooth:
  • Todas as mensagens de malha são criptografadas e autenticadas
  • Segurança de rede, segurança de aplicativos e segurança de dispositivos são tratadas de forma independente.
  • As chaves de segurança podem ser alteradas durante a vida útil da rede mesh
Devido à separação da segurança entre os níveis de rede, aplicativo e dispositivo, existem três tipos de chaves de segurança (cada uma abordando uma preocupação específica):
  • Chave de rede (NetKey) A
    posse dessa chave compartilhada faz com que o dispositivo faça parte da rede (também conhecido como nó). Existem duas chaves derivadas da NetKey: a chave de criptografia de rede e a chave de privacidade . A posse da NetKey permite que um nó descriptografe e autentique até a camada de rede , permitindo a retransmissão de mensagens, mas sem a descriptografia de dados do aplicativo.
  • Chave do aplicativo (AppKey)
    Essa é uma chave compartilhada entre um subconjunto de nós em uma rede mesh, normalmente aqueles que participam de um aplicativo comum. Por exemplo, um sistema de iluminação AppKey seria compartilhado entre interruptores e lâmpadas, mas não com um termostato ou um sensor de movimento.
    Uma AppKey é usada para descriptografar e autenticar mensagens no nível do aplicativo, mas é válida apenas em uma rede mesh, não em várias redes.
  • Chave do dispositivo (DevKey)
    Essa é uma chave específica do dispositivo usada durante o processo de provisionamento para garantir a comunicação entre o dispositivo não provisionado e o provisionador.

Remoção de nó

Uma grande preocupação com uma rede em malha é obter acesso a uma rede por meio de um dispositivo descartado ou removido que costumava fazer parte da rede. Isso pode ser conseguido através do acesso físico às chaves armazenadas no dispositivo (geralmente chamado de ataque da lata de lixo ).
Para se proteger contra esse ataque, a malha Bluetooth define um procedimento para a remoção de um nó em que o dispositivo é adicionado a uma lista negra e as chaves são atualizadas. Esse processo distribui novas chaves de rede , chaves de aplicativos e outros dados relevantes para todos os nós, exceto os da lista negra.

Privacidade

Outra preocupação é a privacidade . A maneira como a privacidade é abordada na malha Bluetooth é através do uso de uma chave de privacidade usada para ofuscar o cabeçalho da mensagem. A chave de privacidade é derivada da chave de rede (NetKey). Por exemplo, o endereço de origem pode ser ofuscado para impedir o rastreamento de um dispositivo através de seu endereço.

Ataques de repetição

O último tópico de segurança que queremos abordar são os ataques de repetição . Um ataque de repetição ocorre quando uma ou mais mensagens são armazenadas e reproduzidas posteriormente por um dispositivo malicioso.
A malha Bluetooth fornece proteção contra ataques de repetição:
  • Utilizando um número de sequência (SEQ) . Os elementos incrementam o valor SEQ toda vez que eles publicam uma mensagem. Um nó, recebendo uma mensagem de um elemento que contém um valor SEQ menor ou igual ao da última mensagem válida, o descartará (pois é provável que esteja relacionado a um ataque de repetição).
  • Usando um índice IV incremental , que é um valor adicional que também é validado quando uma mensagem é recebida.

Sumário

Até agora, nesta série, abordamos principalmente os conceitos teóricos e principais do Bluetooth mesh. Tudo isso é bom, mas, pela minha experiência, o conhecimento e a compreensão de alguém não estão completos até você sujar as mãos com exemplos práticos e implementação em uma plataforma de desenvolvimento real. É nisso que focaremos nas próximas postagens desta série: pegaremos esse conhecimento teórico e o aplicaremos a um exemplo da vida real implementado na  plataforma da série nórdica nRF52 .
Não se esqueça de se inscrever abaixo para ser notificado quando continuarmos nossa jornada com a malha Bluetooth!





Nesta semana, continuaremos nossa série de tutoriais sobre malha Bluetooth. Aqui é onde você pode encontrar as partes 1 , 2 e 3 . Porém, antes de começarmos a implementação prática de um exemplo na plataforma da série nRF52, vamos entender melhor como a malha Bluetooth funciona na plataforma. Vamos passar por cima:
  • Noções básicas e arquitetura do nRF5 SDK for Mesh
  • Como instalar e configurar o SDK
  • Quais placas de desenvolvimento são compatíveis

nRF5 SDK para malha

Visão Geral da Arquitetura

O objetivo de um SDK é fornecer ao desenvolvedor um conjunto de APIs para facilitar a implementação e abstrair  quaisquer complexidades desnecessárias na pilha subjacente. Aqui está um diagrama mostrando a arquitetura do nRF5 SDK for Mesh:

Figura 1: Arquitetura do nRF5 SDK for Mesh (fonte: Introdução à documentação do nRF5 SDK for Mesh)
Vamos examinar cada uma das camadas da arquitetura.
  • Modelos: como falamos nas postagens anteriores desta série, os modelos definem os comportamentos e mensagens específicos de um determinado aplicativo. Os modelos são semelhantes ao GATT no BLE, no sentido de que existem modelos padrão definidos pelo Bluetooth SIG, mas o desenvolvedor também tem a liberdade de definir e desenvolver seus próprios (geralmente para implementar um aplicativo ou funcionalidade personalizada que não é satisfeita por nenhum padrão). modelos).
  • Acesso: pense na camada de acesso como uma camada de multiplexação de modelo . É responsável por determinar quais mensagens de malha são destinadas a um modelo específico e encaminhá-lo para o modelo pretendido.
  • DSM (Device State Manager):  o DSM lida com a tarefa de armazenar as chaves e endereços de criptografia usados ​​pela pilha de malha. Para cada modelo configurado e atribuído a chaves e endereços de aplicativos, o DSM armazena esses valores no armazenamento persistente (para que possam ser recuperados após um ciclo de energia). Ele fornece identificadores para esses valores para permitir que os modelos os usem.
  • Núcleo: a camada Núcleo no nRF5 SDK for Mesh consiste em uma   camada de transporte e  rede .
    • Camada de transporte: essa camada é responsável por criptografar pacotes de malha com chaves de aplicativo (AppKeys) e dividi-los em pacotes de malha a serem transmitidos pelo ar. Ele também lida com a remontagem de segmentos de pacotes recebidos e a combinação deles em um formato que pode ser passado para a camada do Access.
    • Camada de rede: essa camada criptografa todos os segmentos de pacotes da camada de transporte com a  chave de rede (NetKey) e preenche os endereços de origem e destino antes de passá-los para a camada Portadora a ser enviada pelo ar. No lado de recebimento, descriptografa os pacotes, analisa os endereços de origem e destino para determinar se o pacote deve ser retransmitido para a pilha.
  • Provisionamento: o  provisionamento  é um requisito para qualquer rede em malha. Cada dispositivo precisa passar pelo processo de provisionamento antes de ingressar na rede. A pilha de malhas fornece duas maneiras de provisionar um dispositivo: diretamente pelo chamado PB-ADV (suporte de provisionamento de publicidade) ou pelo provisionamento remoto. O provisionamento PB-ADV pode acontecer apenas entre dois dispositivos que estão dentro do alcance um do outro. O provisionamento remoto permite que os dois dispositivos concluam o processo sem estarem no intervalo um do outro, com a ajuda dos outros dispositivos na rede mesh.
    Nota importante:  lembre-se de que o recurso de provisionamento remoto é específico do país nórdico e não pode ser usado com dispositivos de outros fornecedores.
  • DFU:  esta camada / módulo lida com o processo de atualização do firmware do dispositivo. Ele permite transferências simultâneas e autenticadas de firmware para todos os dispositivos na rede mesh sem afetar a operação do aplicativo. Isso é diferente e incompatível com o processo DFU usado no nRF5 SDK para dispositivos BLE.
    Nota importante:  lembre-se de que o recurso DFR de malha nRF5 também é específico do país nórdico e não pode ser usado com dispositivos de outros fornecedores.
  • Portador:  este nível / módulo é usado apenas internamente e não é acessível para a camada de aplicação. Ele lida com as operações de controlador de rádio de baixo nível necessárias para cumprir os horários e o formato de pacote do BLE.

Instalação e configuração do SDK

Existem algumas ferramentas necessárias que precisam ser instaladas antes da criação de um exemplo ou aplicativo de malha nRF5. Essas ferramentas estão resumidas na tabela a seguir:
Tabela 1: Lista de ferramentas necessárias para o nRF5 SDK for Mesh

Links para download

Além dessas ferramentas necessárias, há duas opções para o ambiente de construção : usando o CMake ou o SES (Segger Embedded Studio). Vamos nos concentrar na solução SES, pois é mais fácil e direto de usar.
Da documentação do Nordic:
O Python não é   necessário para criar a pilha de malha e exemplos, mas é necessário ao trabalhar com o DFU, o  Interactive PyACI , gerar projetos do SEGGER Embedded Studio e criar documentação. O nRF5 SDK for Mesh usa  Python 3 ;  no entanto , a   ferramenta nrfutil usada para transferências de DFU sobre serial requer o  Python 2.7 .
Para que a instalação funcione totalmente, siga as instruções descritas na página a seguir:

Compatibilidade de hardware

Os seguintes chipsets e kits de desenvolvimento são suportados pelo nRF5 SDK for Mesh:
nRF5 SDK para HW suportado por malha
Tabela 2: Lista de hardware suportado para nRF5 SDK for Mesh

Em nossos exemplos de implementação, usaremos uma mistura dos kits de desenvolvimento nRF52840 e nRF52832.

Exemplos de malha Bluetooth nRF52

Existem alguns exemplos fornecidos com o nRF5 SDK for Mesh. Cada um exigindo um número diferente de kits de desenvolvimento (ou dispositivos) e demonstrando diferentes conceitos e recursos no Bluetooth mesh. Alguns desses exemplos incluem:
  • Interruptor
  • Escurecimento experimental
  • Cliente de provisionamento remoto
  • Servidor de provisionamento remoto
  • Beaconing
  • e mais ...

Sumário

Neste post, abordamos alguns dos conceitos básicos do nRF5 SDK for Mesh. No próximo post da série, veremos os diferentes exemplos com mais profundidade, escolheremos um deles e começaremos a implementá-lo.
O melhor tutorial sobre malha Bluetooth (parte 5)






Na última postagem desta série sobre malha Bluetooth (encontrada aqui) , fornecemos uma visão geral de alto nível do nRF5 SDK para malha Bluetooth. Também listamos os diferentes exemplos fornecidos como parte do Nordic SDK. O mais completo desses exemplos é o exemplo de iluminação, e este é o que avançaremos na demonstração e explicação. Na postagem desta semana, examinaremos a construção e execução deste exemplo e a compreensão das diferentes partes dele. Nas próximas postagens, veremos os detalhes do código fonte de cada dispositivo.
Aqui está um diagrama mostrando a rede e os dispositivos que usaremos nela:
diagrama de rede nRF Mesh
Figura 1: diagrama de rede em malha nRF

Requisitos de hardware e software

Os diferentes dispositivos de hardware necessários neste exemplo incluem:
  • Duas placas nRF52 (usarei as placas de desenvolvimento nRF52840). Uma placa será programada com o servidor proxy e a outra com o cliente proxy . Usaremos nós proxy para permitir que o telefone celular os descubra e provisione (já que os SOs móveis não suportam a comunicação com dispositivos mesh não proxy).
  • Um telefone celular (iOS ou Android) executando o aplicativo móvel nRF Mesh.
  • Um PC para criar o código de exemplo, interagir com e programar as placas de desenvolvimento.
Os diferentes pacotes de software necessários para construir os exemplos são:
  • Segger Embedded Studio (SES) ( encontrado aqui ).
  • Nordic nRF5 SDK versão 15.0.0 ( encontrada aqui ).
  • Nordic nRF5 SDK for Mesh versão 2.2.0 ( encontrada aqui ).
  • Aplicativo nRF Mesh para iOS ou Android instalado em seu telefone celular ( encontrado aqui para iOS e aqui para Android ).
O nRF5 SDK for Mesh requer a criação do nRF5 SDK versão 15.0.0. As etapas necessárias para fazer isso são:
  • Certifique-se de baixar o nRF5 SDK for Mesh e o nRF5 SDK.
  • Coloque as pastas extraídas (dos arquivos ZIP) na mesma pasta. É assim que minha estrutura de pastas é:
    n── Projeto de malha nRF /
    │ ├── nRF5_SDK_15.0.0_a53641a /
    │ └── nrf5_SDK_for_Mesh_v2.2.0_src /
  • Por padrão, o Segger Embedded Studio (SES) selecionará o nRF5 SDK se ele for colocado ao lado do nRF5 Mesh SDK. No entanto, você pode colocá-lo em um local diferente e modificar a macro SDK_ROOT no SES para apontar para esse caminho diferente (seguindo as instruções aqui ).

Exemplo de malha de interruptor de luz

Descrição Geral da Operação

A operação básica deste exemplo é formar uma rede mesh Bluetooth que consiste em um smartphone (usado como provisionador) e duas placas de desenvolvimento nRF52: uma usada como interruptor de luz e a outra como lâmpada. O provedor (neste caso, smartphone) configura toda a rede:
  • Atribuir a cada dispositivo um endereço exclusivo.
  • Distribuir as chaves de rede e aplicativo necessárias e adequadas para cada dispositivo.
  • Configurando os modelos de malha para cada dispositivo.
O aplicativo móvel nRF Mesh (que usaremos como provisionador) nos oferece muita flexibilidade e controle sobre cada etapa do processo de provisionamento. Isso pode ser um pouco confuso e esmagador no começo, mas serve como uma ótima maneira de aprender sobre os diferentes conceitos e operações em uma rede mesh Bluetooth.

Executando o exemplo passo a passo

Antes de construir e exibir as placas de desenvolvimento com este exemplo pela primeira vez, precisaremos apagar o flash.

Apague as placas de desenvolvimento

Para fazer isso, siga estas etapas para cada uma das duas placas de desenvolvimento:
  • Primeiro, conecte apenas uma das placas de desenvolvimento ao seu computador através do cabo USB.
  • Abra o Segger Embedded Studio (SES). Se você ainda não fez o download e a configuração do SES, verifique primeiro o meu tutorial anterior: O tutorial completo de desenvolvimento de plataforma cruzada para nRF
  • Abra uma das soluções para o exemplo: ou o cliente proxy interruptor de luz ou servidor proxy interruptor de luz:
    └── nrf5_SDK_for_Mesh_v2.2.0_src /
    │ ├── exemplos
    │ ├── light_switch
    │ ├── proxy_client
    │ ├── light_switch_proxy_client_nrf52840_xxAA_s140_6_0_0. emProject    proxy
    ─── proxy_server │── light_switch_proxy_server_nrf52840_xxAA_s140_6_0_0.emProject
  • Navegue até o  item de menu Destino e escolha  Conectar J-Link:

    Figura 2: Conexão do J-Link no SES
  • Em seguida, navegue até o  menu Destino novamente e verifique se o J-Link está conectado agora. Você verá agora que as outras opções (como Redefinir, Fazer download, Apagar tudo e Fazer download) estão todas disponíveis (não estão mais acinzentadas). Selecione  Apagar tudo . Essa operação levará alguns segundos, mais ou menos um minuto, mas é necessária para garantir que a placa de desenvolvimento esteja limpa de qualquer versão anterior do SoftDevice e dos dados salvos na memória.

Figura 3: opção Apagar tudo no SES
  • Aguarde a conclusão da operação (geralmente quando a seguinte mensagem aparecer):

    Figura 4: Apagar tudo feito

Construindo e mostrando o exemplo

Quando terminar de apagar cada uma das placas de desenvolvimento, você estará pronto para criar o servidor proxy e os projetos do cliente proxy e atualizar cada um deles para uma placa de desenvolvimento.
Passos:
  • Verifique se você possui apenas uma placa de desenvolvimento conectada ao seu computador.
  • Abra um dos arquivos da solução SES para o cliente proxy do interruptor de luz ou o servidor proxy do interruptor de luz.
  • Crie e atualize o projeto. Você pode usar a  opção Compilar e depurar  no  menu Compilar para isso.
  • Depois de atualizar o quadro e iniciar o processo de depuração, você verá que o aplicativo pára em main () esperando que você continue a execução. Você também verá o seguinte na janela de saída do terminal de depuração:
    Light Switch Proxy Server:

    Figura 5: Saída de depuração de demonstração do servidor proxy

    Cliente Proxy do Light Switch:

    Figura 6: Saída de depuração de demonstração do Proxy Client
  • Nesse ponto, você pode simplesmente desligar a placa de desenvolvimento (ou desconectá-la) e passar a piscar a outra. A ativação da placa de desenvolvimento posteriormente executará o aplicativo, pois ele já foi atualizado e não será mais necessário executá-lo no computador.
  • Se você vir uma mensagem informando que o início da RAM pode ser ajustado para um endereço diferente, será necessário modificar as macros do projeto para corresponder aos valores sugeridos. Você pode fazer isso:
    • Clique com o botão direito do mouse no nome do projeto
    • Clicando nas opções de edição
    • No menu suspenso Configurações , escolha Comum
    • Selecionar  vinculador
    • Clique duas vezes em Macros de posicionamento de seção
    • Modificar RAM Iniciar para corresponder ao valor impresso na janela Debug Terminal
  • Certifique-se de que cada placa de desenvolvimento seja rotulada ou, pelo menos, reconhecida com a função em que foi exibida (Cliente / Switch ou Servidor / Light). Isso facilitará a identificação posterior ao provisionar e ao operar e testar a rede.
  • Depois de atualizar as placas de desenvolvimento com os exemplos de servidor e cliente, você estará pronto para executar o exemplo e configurar a rede mesh.

Configurando a rede (provisionamento)

Agora, estamos prontos para configurar nossa rede em malha e provisionar cada um dos servidores proxy de comutador de luz e dispositivos de cliente proxy.
  • Primeiro, verifique se o aplicativo nRF Mesh para iOS ou Android está instalado no seu smartphone
  • Inicie o aplicativo nRF Mesh
  • Clique em  Adicionar novo dispositivo
  • O aplicativo começará a procurar dispositivos não provisionados e beacon  na área circundante
  • Você verá os dispositivos nRF5x Mesh Light e nRF5x Mesh Switch aparecerem na lista
  • Clique em um deles na lista e, em seguida, clique em  Identificar
  • Aguarde o processo terminar e preencha as informações e clique em  Provisionar
  • Esse processo levará alguns segundos, mais ou menos um minuto (o progresso será mostrado no canto inferior direito da tela, indicando a porcentagem concluída)
  • Repita o processo de provisionamento para o outro dispositivo
Aqui está um vídeo mostrando o processo:



  • Depois de provisionar os dois dispositivos, você estará pronto para configurá-los.
  • Na  guia Rede , você verá a lista de dois dispositivos: nRF5x Mesh Switch e nRF5x Mesh Light.
  • Clique no Switch de malha nRF5x. Este é o dispositivo que queremos configurar para se comportar como cliente (um interruptor que controla outras lâmpadas na rede).
  • Clique em  Generic OnOff Client . O modelo GenericOnOff é um modelo definido por Bluetooth SIG que é o caso de uso de um interruptor liga / desliga básico (como um interruptor de luz).
  • Em seguida, queremos vincular o cliente a uma AppKey. Vamos escolher o primeiro da lista (AppKey 1). Depois de vinculado, você verá que está listado como  Índice de chave 0000.
  • Como este é um cliente, queremos que ele seja  publicado em um endereço. Então, vamos definir isso. Selecione Endereço de publicação e insira um endereço, se ainda não estiver definido ( digitei o CEEF no meu caso). Depois de inseri-lo, você pode clicar em  Aplicar publicação.
  • Se for bem-sucedido, você deverá vê-lo listado em  Endereço da publicação.
  • Agora, vamos configurar o servidor. Volte para a  guia Rede  e selecione o  dispositivo nRF5x Mesh Light  na lista.
  • Clique em  Generic OnOff Server . Selecione  AppKey Binding e escolha a primeira chave na lista (AppKey 1).
  • Em seguida, queremos definir o Endereço de assinatura,  pois esse dispositivo se comportará como um  servidor , o que significa que ele ouvirá e atuará nas mensagens e comandos enviados pelos  clientes.
  • Digite o mesmo endereço ( CEEF no meu caso). Agora você deve vê-lo listado em  Endereços de assinatura.
Aqui está uma gravação deste processo:



Testando a operação de rede

  • Agora, você está pronto para testar o funcionamento da rede.
  • Pressione o botão nº 1 na placa Cliente / Interruptor de luz.
  • Você deve ver que o LED nº 1 na outra placa (Servidor / Lâmpada) acende.
  • Pressione o botão nº 2  na placa Cliente / Interruptor de luz e ele deverá desligar o LED nº 1 na outra placa (servidor / lâmpada).

Sumário

Neste post, analisamos os conceitos básicos de construção, atualização e execução do exemplo de malha Light Switch nos kits de desenvolvimento nRF. Abordamos apenas o básico de como configurar e testar a rede. Como você provavelmente já deve ter notado, o aplicativo móvel nRF Mesh está cheio de opções e configurações, mas é sempre uma boa ideia começar com apenas um exemplo simples e depois expandir para os diferentes sinos e assobios quando tivermos uma rede básica configurada.
Nas postagens a seguir, começaremos a pesquisar o código fonte real para os diferentes tipos de dispositivos (nós de cliente e servidor), além de obter mais detalhes sobre o processo de provisionamento.





Agora que abordamos o básico da malha Bluetooth e também falamos sobre como executar um exemplo simples na plataforma nRF52, é hora de nos aprofundarmos no código fonte de cada tipo de dispositivo / nó envolvido em uma rede em malha.
Na publicação de hoje, abordaremos parte do código-fonte do exemplo que demonstramos na Parte 5 para entender melhor como implementar um exemplo de malha Bluetooth (e poder modificá-lo para satisfazer seus próprios requisitos).

Aplicação de demonstração

Descrição geral

Este aplicativo de demonstração implementa os modelos de malha Generic OnOff  Client e  Generic OnOff  Server  . Esses são os modelos de malha mais simples que existem no padrão e representam um simples estado Ativado ou Desativado.
O servidor mantém o estado, o acompanha e age com base em seu valor.
O cliente, por outro lado, envia as mensagens para definir ou obter o valor do estado.
Um valor de 0x00 representa o estado Desativado e um valor de 0x01 representa o estado Ativado .

Código fonte

O exemplo com o qual estamos trabalhando é fornecido pela Nordic Semiconductor no nRF5 SDK for Mesh. A localização do exemplo e o código-fonte são os seguintes:
└── nrf5_SDK_for_Mesh_v2.2.0_src /
│ ├── exemplos
│ ├── light_switch
│── proxy_client
│ ├── proxy_server
│ ├── provisioner

Tipos de nós usados

O exemplo que demonstramos na postagem da semana passada incluiu três tipos de nós:
  • Um nó do Proxy Client (o "Light Switch" implementado em uma placa de desenvolvimento nRF52840)
  • Um nó do servidor proxy (a "lâmpada" implementada em uma placa de desenvolvimento nRF52840)
  • Um nó Provisioner (um telefone celular ou outra placa de desenvolvimento nRF52)
Em uma postagem anterior dessa série, examinamos os diferentes tipos de nós na malha Bluetooth.
Dois desses nós eram nós de baixa potência (LPN) e nós amigos.
Esses dois nós ainda não foram implementados no Nordic nRF5 SDK for Mesh (a partir da versão 2.2.0). Esses nós são opcionais em uma implementação de rede mesh Bluetooth, portanto, não são obrigatórios e podem ser incluídos em uma versão futura do Mesh SDK.
Vamos examinar o código-fonte usado nos nós do cliente proxy e do servidor proxy para entender melhor a implementação da malha Bluetooth na plataforma nRF52.
Na próxima postagem, continuaremos cobrindo o nó do  provisionador .

Nó Cliente Proxy

Vamos examinar os principais elementos no código-fonte do  nó do cliente proxy .
Sempre que você estiver tentando entender o funcionamento interno de um aplicativo incorporado, a função main () (geralmente em main.c) é o melhor lugar para começar. Aqui está a função main ():
Você notará três chamadas de funções principais:
  • inicializar()
  • execução_start (início)
  • (vazio) sd_app_evt_wait ()
Vamos examinar cada um deles.
inicializar()
Esta é uma função estática (local) com o seguinte código-fonte:
  • provisioning_complete_cb ():
    • É chamado quando o processo de provisionamento é concluído com êxito.
    • Restaura os parâmetros de conexão.
    • Pisca os LEDs para indicar que o processo de provisionamento está completo.
  • app_generic_onoff_client_status_cb ():
    • Isso relata uma mensagem de status enviada ao cliente.
    • O status contém o  remetente (servidor) , o  valor do estado atual , o  valor do estado de destino e também o  tempo restante para que a operação seja executada posteriormente.
  • config_server_evt_cb ():
    • Relata quaisquer eventos destinados a serem processados ​​pelo  servidor . Isso inclui a  mensagem Redefinir nó que é enviada quando o dispositivo é removido da rede (não provisionado).
    • No caso de a  mensagem Redefinir Nó ser recebida, o servidor redefine a pilha de malha através da função local  node_reset ( )  :
  • button_event_handler ()
    • Esta função lida com 4 botões usados ​​por dois  clientes da seguinte maneira:
      • Os botões 1 e  2 enviam a mensagem Ativar e Desativar como Cliente 1, respectivamente.
      • Os botões 3 e 4 enviam a mensagem Ativar e Desativar como Cliente 2, respectivamente.
      • Os botões 1 e 2 demonstram o envio de uma mensagem "confiável" que requer que o destinatário confirme o recebimento da mensagem.
      • Os botões 3 e 4  demonstram o envio de uma mensagem não confirmada que não requer uma resposta do destinatário.
    • Ele também define os LEDs na placa de desenvolvimento local para o estado indicado (para dar feedback ao usuário de que uma mensagem de operação foi enviada ao servidor ). Por exemplo, pressionar o botão # 1 irá enviar o Na mensagem para o  servidor , mas também vai virar On LED # 1 para indicar ao usuário que a operação foi realizada.
  • rtt_input_handler ()
    • Permite ao usuário interagir e acionar o pressionamento de botão enviando comandos pelo terminal serial em vez de pressionar o botão físico.
  • models_init_cb ()
    • Esta função lida com a inicialização dos modelos apropriados para o aplicativo. Nesse caso, estamos inicializando dois  clientes genéricos OnOff [linha 12] .
    • Se você precisar implementar modelos adicionais, este seria o lugar para fazê-lo.
Aqui nós:

  • Habilite o módulo de registro, configure-o e exiba a primeira mensagem de registro  "----- Demonstração do cliente BLE Mesh Light Switch -----"  [Linhas 3-4] .
  • Ative o módulo do  timer , os LEDs  e os botões [Linhas 6-11].
  • Chame uma função SDK interna que habilite o  SoftDevice e o relatório de eventos para o nosso aplicativo [Linhas 12-13] .
  • Execute uma solução alternativa necessária para o S140 SoftDevice (que é para a placa de desenvolvimento nRF52840) [Linha 15] .
  • Defina as diferentes configurações para a pilha BLE no SoftDevice. Isso inclui o número de links ( periféricos e centrais configurados), o tamanho da MTU, o número de UUIDs específicos do fornecedor (para serviços e características), etc. A   variável ram_start é usada para retornar o local de início da RAM que será usado na próxima chamada de função [Linhas 18-21] .
  • Habilite a pilha BLE [Linhas 23-24] .
  • Configure o nome do dispositivo anunciado ( "nRF5x Mesh Switch" ) e diferentes parâmetros de conexão (incluindo intervalos mínimo e máximo de conexão preferidos, latência do escravo e tempo limite de supervisão da conexão) por meio de duas funções locais:  gap_params_init ( )  e conn_params_init ( )  [Linhas 26-27 ] .

execução_start (início)
Essa chamada de função pega um ponteiro de função (nesse caso, start ( )  ) e garante que as seções críticas sejam desativadas até que a execução seja concluída (para evitar interrupções durante a execução da função). Vamos dar uma olhada na função  start ( )  
Nesta função, nós:
  • Ative a funcionalidade RTT para permitir a interação com o aplicativo através do envio de comandos para a porta serial [Linha 3] .
  • Inicie a pilha de malhas. Esta operação envolve a geração de um UUID de dispositivo, a configuração da pilha e a atribuição das funções de retorno de chamada necessárias para lidar com os diferentes eventos de malha  [Linha 4] .
  • Configure e inicie a operação de sinalização que permite que o dispositivo seja provisionado (se não tiver sido provisionado) [Linhas 6-16] .
    Essa operação inclui sinalização através do portador de publicidade e do portador do GATT  (já que estamos executando um   nó proxy ).
  • Obtenha o UUID (exclusivo) deste dispositivo na pilha de malhas [Linha 18] .
  • Defina o status dos diferentes LEDs [Linha 21] .
  • Pisque os LEDs um certo número de vezes ( LED_BLINK_CNT_START  ) com um atraso de LED_BLINK_INTERVAL_MS  [Linha 22] .
(vazio) sd_app_evt_wait ()
Essa é uma função interna do SDK basicamente coloca nosso aplicativo em um estado ocioso até que quaisquer eventos sejam relatados pela pilha e precisem ser tratados pelo aplicativo.

Funções de retorno de chamada

O restante do código neste aplicativo está em funções de retorno de chamada que são chamadas sempre que um evento é relatado pela pilha e precisa ser tratado pelo aplicativo. Os mais importantes são:
  • provisioning_complete_cb ()
É chamado quando o processo de provisionamento é concluído com êxito.
  • Restaura os parâmetros de conexão.
  • Pisca os LEDs para indicar que o processo de provisionamento está completo.
  • app_generic_onoff_client_status_cb ()
    • Isso relata uma mensagem de status enviada ao cliente.
    • O status contém o  remetente (servidor) , o  valor do estado atual , o  valor do estado de destino e também o  tempo restante para que a operação seja executada posteriormente.
  • config_server_evt_cb ():
    • Relata quaisquer eventos destinados a serem processados ​​pelo  servidor . Isso inclui a  mensagem Redefinir nó que é enviada quando o dispositivo é removido da rede (não provisionado).
    • No caso de a  mensagem Redefinir Nó ser recebida, o servidor redefine a pilha de malha através da função local  node_reset ( )  :
  • button_event_handler ()
    • Esta função lida com 4 botões usados ​​por dois  clientes da seguinte maneira:
      • Os botões 1 e  2 enviam a mensagem Ativar e Desativar como Cliente 1, respectivamente.
      • Os botões 3 e 4 enviam a mensagem Ativar e Desativar como Cliente 2, respectivamente.
      • Os botões 1 e 2 demonstram o envio de uma mensagem "confiável" que requer que o destinatário confirme o recebimento da mensagem.
      • Os botões 3 e 4  demonstram o envio de uma mensagem não confirmada que não requer uma resposta do destinatário.
    • Ele também define os LEDs na placa de desenvolvimento local para o estado indicado (para dar feedback ao usuário de que uma mensagem de operação foi enviada ao servidor ). Por exemplo, pressionar o botão # 1 irá enviar o Na mensagem para o  servidor , mas também vai virar On LED # 1 para indicar ao usuário que a operação foi realizada.
  • rtt_input_handler ()
    • Permite ao usuário interagir e acionar o pressionamento de botão enviando comandos pelo terminal serial em vez de pressionar o botão físico.
  • models_init_cb ()
    • Esta função lida com a inicialização dos modelos apropriados para o aplicativo. Nesse caso, estamos inicializando dois  clientes genéricos OnOff [linha 12] .
    • Se você precisar implementar modelos adicionais, este seria o lugar para fazê-lo.

Nó do servidor proxy

O  código-fonte do Nó do Servidor Proxy é quase idêntico ao  código do Nó do Cliente Proxy,  com algumas exceções dignas de nota:
  • models_init_cb () 

    que chama app_model_init ( )  :
    • Aqui, o modelo inicializado é o modelo Generic OnOff Server em vez do modelo Generic OnOff Client .
  • button_event_handler () 
    • O botão nº 1 acende o LED nº 1 na placa de desenvolvimento local e, ao mesmo tempo, aciona uma mensagem de status enviada ao  Nó Cliente para notificá-lo da alteração de status.
    • O botão 3 é usado para redefinir o nó e "desprovisionar" a partir da rede.
  • A   função start ( ) não inclui piscar dos LEDs, como no código de exemplo do  Proxy Client Node .
  • A implementação de duas funções:
    • app_onoff_server_set_cb ( )   para definir o status do LED
    • app_onoff_server_get_cb ( )  para obter o status do LED

Sumário

Nesta postagem, abordamos o código fonte de dois nós na rede de malha:
  • Nó do cliente proxy
  • Nó do servidor proxy
Falamos sobre como o modelo Generic OnOff é inicializado e configurado para cada um dos nós de cliente e servidor.

Neste exemplo, que testamos na postagem anterior, usamos um telefone celular com o aplicativo nRF Mesh como provedor. No entanto, o nRF5 SDK for Mesh também fornece um exemplo de provisionador que é executado no kit de desenvolvimento nRF52. Na postagem da próxima semana, testaremos o dispositivo provisionador baseado em nRF e examinaremos o código-fonte desse nó.





No tutorial de hoje:
  • Vamos dar um passo atrás e falar um pouco sobre interoperabilidade e compatibilidade no Bluetooth mesh.
  • Em seguida, passaremos por uma demonstração da configuração de uma rede mesh que inclui uma mistura de dispositivos disponíveis no mercado.
  • Por fim, veremos o código-fonte passo a passo e as alterações necessárias para implementar a funcionalidade desta demonstração.

Compatibilidade e interoperabilidade

O poder de ter um padrão como a malha Bluetooth que um dispositivo certificado deve cumprir é:
  • A capacidade de adicionar dispositivos de diferentes fabricantes a qualquer rede mesh.
  • A capacidade na rede de dispositivos interagirem com outros que implementam uma funcionalidade comum de maneira quase uniforme.
Isso oferece aos fabricantes e consumidores grande flexibilidade em três aspectos principais:
  • Escolha dos tipos de dispositivos a serem usados ​​em uma rede mesh, incluindo os aplicativos de software que podem ser implementados em dispositivos como tablets e telefones celulares que interagem com a rede (por exemplo, dispositivos Provisioner).
  • Liberdade para os fabricantes fornecerem uma ampla variedade de dispositivos que oferecem diferentes funcionalidades.
  • Flexibilidade para o usuário final na configuração da rede de acordo com suas preferências.
O conceito de modelos , discutido na Parte 2 desta série de tutoriais ( encontrada aqui ), além dos endereços de grupo, ajuda a fornecer essa flexibilidade.

Dispositivos de malha Bluetooth para consumidores

Pesquisei no mercado dispositivos, especificamente lâmpadas, com certificação de malha Bluetooth. Encontrei a seguinte lista pública de dispositivos certificados para malha, mas 99% dos produtos listados são módulos ou chipsets.
Foi uma luta encontrar um produto de consumo real que qualquer pessoa possa comprar e usar imediatamente. Isso é compreensível ( eu acho ), já que o padrão é tão novo.
Vi a listagem da LEDVANCE, que é a empresa por trás da marca Sylvania . Entrei em contato com eles no Twitter, e eles foram capazes de me apontar na direção certa. Por fim, pousei nas lâmpadas Sylvania SMART + . Comprei alguns deles para começar a construir uma rede mesh Bluetooth em minha casa, mas também para ver como seria fácil / difícil criar uma rede a partir de vários dispositivos de diferentes empresas.

Uma rede de iluminação de malha Bluetooth em casa

A compatibilidade e a interoperabilidade entre dispositivos certificados são essenciais para o sucesso de qualquer padrão de conectividade. Minha experiência até agora com esse aspecto da malha Bluetooth foi ótima.
A seguir, é apresentado um diagrama de uma rede mesh Bluetooth simples que comecei a construir. Desde então, ampliei o número de dispositivos na rede e o testarei mais amplamente, principalmente quanto à confiabilidade e alcance .

Figura 1: Rede de iluminação de malha Bluetooth
A rede consiste no seguinte:
  • Um dispositivo provisionador iOS ou Android executando um aplicativo provisionador de malha Bluetooth genérico (como o aplicativo nRF Mesh da Nordic ou o aplicativo Bluetooth Mesh da Silicon Labs).
  • Duas lâmpadas prontas para venda com certificação Bluetooth da Sylvania:
  • Um kit de desenvolvimento nórdico nRF52840 (DK) como um interruptor de luz. A implementação do interruptor de luz será uma versão adaptada do exemplo fornecido pela Nordic no nRF5 SDK for Mesh (que testamos na Parte 5 ), mas com algumas funcionalidades adicionais:
    • Botão # 1: Vire na F1 . Também se transforma em LED # 1 sobre o kit de desenvolvimento.
    • Botão # 2: Vire em C1 . Também se transforma em LED # 2 sobre o kit de desenvolvimento.
    • Botão 3: Ligue F1 e C1 (como um grupo). Também transformar  em LEDs # 1 e # 2 no kit de desenvolvimento.
    • Botão 4: Desligue F1 e C1 (como um grupo). Desligue também  os LEDs 1 e 2 do kit de desenvolvimento.
Endereços de Nó
Figura 2: Atribuições de endereço de nó

Interruptor de luz de malha baseado em nRF52 (controle remoto)

Certifique-se de seguir as etapas de instalação e configuração da Parte 5 primeiro.
O aplicativo LightSwitch original fornecido nos exemplos de malha nRF Bluetooth suporta apenas dois clientes Generic OnOff. Em nosso exemplo, precisamos implementar três clientes :
  • Um cliente OnOff genérico para controlar F1.
  • Um cliente OnOff genérico para controlar C1.
  • Um cliente OnOff genérico para controlar o grupo (F1 + C1).
Vamos passar pelas alterações no código fonte para fazer isso.

Etapa 1: alterar o número de clientes (de 2 para 3)

O número de clientes é definido no arquivo de cabeçalho nrf5_SDK_for_Mesh_v2 . 2.0_src / examples / light_switch / include / light_switch_example_common . h  .
Altere para 3 (em vez de 2):

Etapa 2: Alterar o comportamento dos botões e LEDs integrados do kit de desenvolvimento

Todas as alterações que precisamos fazer estão na função static void button_event_handler ( uint32_t button_number ) .
  • Alterar o conjunto de estado pelos botão prensas para ser  on para os botões de 1,2, e 3.  Off para o botão 4.
  • Modifique para que o botão 2 envie uma mensagem como  cliente nº 2 (indexado em 1). Além disso, faça a alteração para ativar o LED 2 (indexado em 1).
  • Modifique para ter os botões 3 e 4 para enviar uma mensagem como cliente nº 3 (indexado em 2). Além disso, faça a alteração para definir o estado dos dois LEDs 1 e 2 (indexados em 0 e 1 respectivamente).

Passo a passo sobre provisionamento e configuração de rede

Vamos seguir as diferentes etapas para provisionar os nós e configurar a rede do zero.

Etapa 1: verifique se todos os dispositivos foram redefinidos e sem provisionamento

  • Para a placa de desenvolvimento nRF52, você pode fazer isso navegando até o  menu Destino no SES, escolhendo  Connect J-Link e depois  Apagar tudo . Depois de apagar a placa de desenvolvimento (que pode levar um ou dois minutos), você pode atualizá-la com o exemplo atualizado do Light Switch Proxy Client que modificamos na seção anterior.
  • Para as lâmpadas Sylvania, você pode fazer isso girando fora de energia e, em seguida, voltar em 5 vezes em uma fileira. Na última (quinta) vez em que você acender a luz, você verá um breve atraso (até 3 segundos), após o qual a luz piscará algumas vezes, indicando que agora está redefinida.

Etapa 2: use o aplicativo nRF Mesh iOS ou Android para procurar dispositivos para provisioná-los

  • Inicie o aplicativo nRF Mesh e vá para a  guia Scanner 

    Figura 3: Procurando dispositivos (todos os dispositivos não provisionados)

Etapa 3: provisionar os diferentes dispositivos

  • Clique em cada dispositivo e identifique-o:

    Figura 4: identificar o dispositivo

    Figura 5: Identificando o dispositivo
  • Provisione o dispositivo:

    Figura 6: Provisionar o dispositivo

    Figura 7: Processo de provisionamento em andamento
  •  Agora você deve ver a seguinte tela depois de provisionar a placa nRF52:

    Figura 8: kit de desenvolvimento nRF52 provisionado

  • Repita o processo para cada uma das lâmpadas. No final, você deve ver o seguinte:

    Figura 9: Todos os dispositivos provisionados

Etapa 4: configurar os clientes e servidores

Agora que temos todos os dispositivos provisionados, precisamos configurar os diferentes clientes e servidores.
  • Primeiro, configure o interruptor de luz (nRF52x Mesh Switch). Clique no dispositivo na  tela Rede :

    Figura 10: Vista principal do nRF5x Mesh Switch
  • Vamos configurar os  Clientes Genéricos OnOff da seguinte maneira:
    • Elemento 1:

      Figura 11: Cliente OnOff genérico nº 1
    • Elemento 2:

      Figura 12: Cliente OnOff genérico nº 2
    • Elemento 3:

      Figura 13: Cliente OnOff genérico nº 3
    • Depois de terminar, você verá o seguinte na visualização principal do nó do switch de malha nRF5x:

      Figura 14: Switch de malha nRF5x configurado
  • Vamos configurar os Generic OnOff Servers da seguinte maneira:
    • Configure o  SYLVANIA A19 FM da  seguinte maneira:

      Figura 15: Lâmpada Sylvania Filament Configuração genérica do OnOff Server
    • Configure o  SYLVANIA A19 CM da  seguinte maneira:

      Figura 16: Configuração genérica do OnOff Server da lâmpada colorida da Sylvania

Etapa 5: testar a rede de malha Bluetooth

Agora estamos prontos para iniciar o teste real da rede. Aqui está um vídeo mostrando o teste:

Tutorial em vídeo completo para provisionamento, configuração e teste

Se você quiser seguir as etapas de provisionamento, configuração e teste por meio de um vídeo, faça isso aqui:

Sumário

Nas postagens a seguir, faremos alguns testes extensivos com a rede mesh Bluetooth:
  • Adicionando mais luzes e outros dispositivos de malha.
  • Testar com o alcance da rede e como adicionar dispositivos e removê-los afeta o alcance.
EXECUTANDO REDE MESH NO NINA B112 E NINA B302

SDK's

NINA B112

No NINA B112 foi colocado o software light_switch_client. 

Para ter acesso às teclas (CHAVES) do EVK do NINA B112, você deve adicionar ao SDK  o CUSTOM_BOARD.

Ver subcapítulo em 2.2.1.2

Tive que alterar para poder compilar.
void hal_leds_init(void) { //for (uint32_t i = LED_START; i <= LED_STOP; ++i) // { // NRF_GPIO->PIN_CNF[i] = LED_PIN_CONFIG; // NRF_GPIO->OUTSET = 1UL << i; // } NRF_GPIO->PIN_CNF[LED_1] = LED_PIN_CONFIG; NRF_GPIO->PIN_CNF[LED_2] = LED_PIN_CONFIG; APP_ERROR_CHECK(app_timer_create(&m_blink_timer, APP_TIMER_MODE_REPEATED, led_timeout_handler)); } #endif /* SIMPLE_HAL_LEDS_ENABLED */










Programa foi compilado e transferido para o EVK e foi mostrado o DEVICE UID  (Debug)

Device UUID (raw): 72E4DAC5B64F1147A9F86E0B36C58EF1

Também já esta fazendo propaganda para entrar na rede MESH (provisioning)

Ble Scanner

NINA B302

 No NINA B302 foi colocado o light_switch_server, projeto do SDK MESH.



Seguindo o roteiro de 2.3.1.2

Também criei um CUSTOM_BOARD para atender o NINA B302, foi chamado de CUSTOM_BOARD_840

Compilando e executando obtivemos o ID
Device UUID (raw): F011E05E0C2A864D80C7FC3744B46FEC


Também já esta fazendo propaganda para entrar na rede MESH (provisioning)

Adafruit Scanner

No NINA B302, o led está definido em
#define ONOFF_SERVER_0_LED          (BSP_LED_0) no main.c e no CUSTOM_BOARD_840.H
#define BSP_LED_0 LED_1
#define LED_1 NRF_GPIO_PIN_MAP(0,13) // RED
OU SEJA, P0.13


TESTES
Para enviar o comando do Nó do NINA B112 (switch) para o NINA B302 (Lâmpada) foi utilizado o terminal RTT e então teclado 0 ou 1 para apagar ae acender a lâmpada via MESH!

static void rtt_input_handler(int key) { if (key >= '0' && key <= '3') { uint32_t button_number = key - '0'; button_event_handler(button_number); } }


suporte@smartcore.com.br

Referências:

 

Sobre a SMARTCORE

A SmartCore fornece módulos para comunicação wireless, biometria, conectividade, rastreamento e automação.
Nosso portifólio inclui modem 2G/3G/4G/NB-IoT/Cat.M, satelital, módulos WiFi, Bluetooth, GNSS / GPS, Sigfox, LoRa, leitor de cartão, leitor QR code, mecanismo de impressão, mini-board PC, antena, pigtail, LCD, bateria, repetidor GPS e sensores.
Mais detalhes em www.smartcore.com.br

 

Postado por às

Nenhum comentário:

Postar um comentário

Assinar: Postar comentários (Atom)