LoRaWAN

Referência do driver LoRaWAN: o servidor de rede Basics Station embutido, certificados de gateway, os registros de sensor e de concentrador, e o endereçamento no payload.

O driver LoRaWAN transforma o Ganter Lab num pequeno servidor de rede LoRaWAN. O sentido da relação é invertido em comparação com a maioria dos drivers: a estação não alcança um sensor, o gateway conecta ao Ganter Lab, e os sensores entregam as leituras deles como uplinks por aquele gateway. O Ganter Lab embute um servidor de rede que fala o protocolo LoRa Basics Station da Semtech, então qualquer gateway com firmware Basics Station pode usar esta estação como LNS dele.

O servidor embutido inicia quando o primeiro dispositivo LoRaWAN habilitado é carregado no connector em execução, e não na inicialização da aplicação, e para quando o último é removido ou desabilitado: sem nenhum sensor e nenhum concentrador configurado, nada escuta na porta. Adicionar um o traz de volta, sem reiniciar a aplicação.

Cada dispositivo sob o driver é um de dois registros, escolhido no painel dele:

• Um sensor, identificado pelo DevEUI dele e admitido com a chave de aplicação dele. As tags dele decodificam o payload do uplink.
• Um concentrador de rádio (o gateway), identificado pelo Station EUI dele e registrado numa região de rádio escolhida de uma lista. Ele não carrega tags próprias.

Registre o concentrador além dos sensores. Um concentrador Basics Station pede a configuração de rádio dele assim que conecta e não repassa absolutamente nada até ser respondido, então uma estação que nunca viu o Station EUI dele deixa todo sensor atrás dele sem valor, enquanto a conexão em si parece saudável. A resposta é montada aqui a partir da região que você escolheu; não há texto de configuração para colar.

Servidor de rede e portas

A escuta é sempre TLS. Não existe definição que desligue a criptografia: uma escuta em HTTP simples é recusada em qualquer lugar, exceto no loopback, que é inalcançável da rede da planta e existe só para testes em processo.

Certificados

A admissão é por TLS mútuo: o servidor prova quem é com o certificado dele, e todo gateway precisa provar quem é com um certificado de cliente.

Certificado do servidor. Gerado automaticamente na primeira inicialização e guardado na pasta de dados da aplicação, em ua\pki\own\private:

• GanterLabOPCUAServer-with-san.pfx, a chave privada, criptografada sob uma senha aleatória que, por sua vez, é protegida por usuário do Windows (DPAPI), então o par de arquivos não abre para ninguém quando copiado para outro lugar.
• GanterLabOPCUAServer-with-san.pem, o certificado público. Este é o arquivo que você instala no gateway para que ele confie nesta estação.

O certificado é autoassinado e não expira. Você instala a metade pública dele em cada concentrador uma vez, à mão, então um certificado que vencesse derrubaria a rede de sensores inteira no aniversário dele, recusado no concentrador, onde esta estação não enxerga nada, e custaria uma visita a cada concentrador para voltar. Não há aviso de vencimento nem comando de renovação, porque não há o que renovar; a página do driver mostra a data que ele carrega como leitura.

Ele é escrito de novo só em dois casos, e os dois dizem isso no diário:

• O arquivo guardado não pode mais ser aberto, por exemplo porque foi escrito por outra conta do Windows.
• Ele foi emitido por uma versão anterior desta aplicação, que lhe dava 12 meses.

Nos dois casos a página do driver diz, uma vez, que todo concentrador precisa receber o novo GanterLabOPCUAServer-with-san.pem. Enquanto não receberem, eles não conseguem conectar.

Certificado de cliente do gateway. Todo gateway precisa apresentar um certificado de cliente durante o handshake TLS; um handshake sem ele é descartado antes de qualquer dado passar. O certificado precisa:

1. Formar uma cadeia válida nesta máquina Windows (erros de cadeia, como uma raiz não confiável, recusam a conexão, e o diário registra qual conferência falhou).
2. Carregar o Station EUI do gateway no nome comum do titular ou num nome alternativo de titular do tipo DNS. O identificador é lido como valor, então AABBCCDDEEFF0011, AA-BB-CC-DD-EE-FF-00-11 e AA:BB:CC:DD:EE:FF:00:11 nomeiam todos a mesma estação.
3. Nomear a mesma estação que a conexão de dados afirma ser: um certificado que nomeia um gateway diferente daquele do endereço da conexão é recusado.

Campos de conexão

Um dispositivo LoRaWAN não tem host nem porta próprios: um sensor é alcançado por qualquer concentrador que leve o tráfego de rádio dele, e um concentrador alcança esta estação. O painel mostra primeiro o seletor de registro e depois os campos de que aquele registro precisa.

Um identificador deixado vazio recai no nome higienizado do dispositivo, que quase nunca é um EUI válido, então preencha-o.

A chave de aplicação é um segredo, e a estação a trata como tal. O painel a esconde atrás de pontos, com uma caixa Mostrar a senha que a revela enquanto você confere o que digitou; o banco de configuração a guarda protegida sob a conta do Windows que a digitou; e ela não aparece nem no diário nem no endereço que o driver lê, que carrega só o DevEUI. Abra a mesma configuração em outra conta do Windows e a chave não abre junto: o campo volta vazio, dizendo "Não pode ser lido nesta conta do Windows: ele só abre na máquina e na conta do Windows que o digitou. Digite de novo aqui.", e o sensor para de entrar na rede até você digitar a chave de novo. Uma configuração levada num backup mantém a chave, porque o backup é selado com a senha que você dá a ele.

O join é só OTAA: o sensor faz um join pelo ar através do concentrador, e o servidor de rede o responde usando a AppKey configurada. Uma requisição de join vinda de um DevEUI que nenhum dispositivo configurado carrega é recusada e registrada no diário. A ativação por personalização (ABP, chaves de sessão pré-provisionadas) não é suportada.

Desabilitar ou excluir um dispositivo o tira do servidor de rede na hora, sem esperar por um reinício: a chave dele sai do registro, a sessão que algum concentrador mantinha para ele é liberada, e o próximo join dele é recusado. Um registro que o servidor não aceita, um DevEUI, uma chave de aplicação, um Station EUI ou uma região digitados errado, deixa o dispositivo lendo como não conectado, e o diário nomeia o campo que foi recusado.

O que é enviado ao concentrador

Quando um concentrador registrado termina o handshake de versão, esta estação responde com a configuração de rádio da região dele: a faixa de frequência, as taxas de dados e quais delas são só de downlink, e o plano de canais padrão da região. Se o Station EUI não estiver registrado aqui, nada é enviado, e o diário diz qual estação perguntou e que ela não está registrada. Essa é a entrada a procurar quando um concentrador conecta e nenhum sensor atrás dele jamais reporta um valor.

Não há campos de intervalo de leitura. O LoRaWAN é baseado em push: o sensor decide quando faz uplink, o servidor guarda os payloads decodificados mais recentes por dispositivo, e os valores das tags se atualizam desse cache num ciclo fixo de um segundo.

Um sensor que ainda não fez uplink, portanto, não tem leitura, e não uma leitura que falhou. As tags ficam vazias, o dispositivo relata que nada foi observado, em vez de ficar offline, e nenhuma falha é registrada no diário: esperar o primeiro uplink é o protocolo funcionando. Um endereço que não resolve para nada num payload que o sensor de fato enviou é outra coisa, e é relatado como a falha de leitura que é.

Quando um sensor fica quieto

Como nada lê um sensor ciclicamente, o payload que ele enviou por último fica naquele cache até ele enviar outro. Deixado assim, um sensor cuja bateria acabou continuaria publicando o mesmo número como leitura boa enquanto a estação rodasse, alimentando gráficos, histórico e alarmes com um valor que deixou de ser verdade.

Todo sensor carrega, por isso, um tempo máximo sem transmissão, em segundos, no painel dele. O padrão é 3600 segundos, uma hora, que cobre com folga a cadência de dez a trinta minutos de um sensor comum; um sensor que reporta mais raramente eleva o próprio. Passado esse prazo:

• As tags dele param de carregar valor e publicam qualidade ruim, em vez de repetir o último uplink.
• O painel do dispositivo diz quando o sensor transmitiu pela última vez, para você ver há quanto tempo ele está quieto.

Deixar o campo em 0 desliga o vencimento naquele sensor: o último uplink dele continua lendo como bom por tempo indeterminado. Nada mais muda, e nenhum payload guardado é descartado.

Endereçamento da tag

Uma tag LoRaWAN endereça bytes dentro do payload decodificado do uplink. Não há endereço em texto livre; o cartão Origem oferece campos tipados em dois modos, trocados pela caixa de seleção Endereçar por canal/tipo Cayenne LPP:

A ordem das operações numa leitura é: pegar os bytes endereçados → aplicar a máscara de bits → inverter se o byte mais significativo vier primeiro → converter para o tipo de dado da tag → aplicar o multiplicador (tipos numéricos).

Exemplos, para um sensor cujo payload de 11 bytes carrega uma temperatura Int16 em big-endian no deslocamento 2:

• Modo de deslocamento: canal/deslocamento 2, comprimento de leitura 2, byte mais significativo primeiro ligado.
• Modo LPP, o mesmo sensor falando Cayenne LPP no canal 1 com tipo 103: marque a caixa LPP, canal 1, código de tipo 103, comprimento de leitura 2.

Tipos de dado suportados

Escritas e descoberta

Tags LoRaWAN são somente leitura: os valores vêm apenas dos uplinks do sensor, o campo de acesso não oferece escolha gravável, e o runtime recusa uma escrita em vez de fingir sucesso. Downlinks existem no protocolo como tráfego de rede (aceites de join, comandos MAC), nunca como escrita de valor de tag.

O driver não tem varredura de descoberta. Adicione o concentrador à mão, com o Station EUI e a região dele, e cada sensor à mão, com o DevEUI e a AppKey dele; o fluxo geral de adicionar um dispositivo está descrito na página Connector.