A Helium network é uma rede LoRaWAN descentralizada que utiliza uma estrutura de blockchain de modo que cada gateway atue como um validador e minerador de pacotes transacionados, essa estrutura garante um maior crescimento da rede com alta segurança.
1 O que é Helium network?
Basicamente, a Helium Network é uma rede sem fio descentralizada, código-aberto, que utiliza tecnologias LoRaWAN e 5G – este último está disponível apenas nos EUA.
A Helium Network possui toda a exponencialidade de crescimento e colaboração de pessoas, semelhante à The Things Network (TTN), porém com um modelo econômico próprio baseado em criptoativos. Isso permite um forte engajamento de empresas e comunidade, garantindo um alto nível de serviço e confiabilidade.
Sua base é a tecnologia Blockchain, em que cada gateway valida informações entre si, reforçando a segurança e cobertura da rede. A Helium é a maior rede de LoRaWAN do mundo e tem o seu maior destaque no USA e na Europa onde a população aderiu bastante a essa tecnologia que inclusive esse mesmo efeito se repete na TTN.
No Brasil o cenário da Helium ainda é modesto se comparado com outros países, mas vem crescendo de forma avassaladora e ganhando cada vez mais cobertura e o Rio de Janeiro é o estado que lidera a cobertura e em números de gateways ativos, pelo menos até o momento (18/07/2023).
O Rio de Janeiro e a segunda cidade mais populosa do Brasil e a primeira cidade no Brazil em cobertura. Na fase inicial do projeto investidores adquiriram vários gateways e espalharam no estado a fim de surfar no alto valor do token em meados de 2021.
Antes mesmo de considerar investir em um gateway, é importante compreender o funcionamento essencial da rede. Se sua intenção é especular, é importante ressaltar que o projeto da Helium não se encaixa nessa proposta. Este não é um artigo para você.
2 Como funciona a Helium Network?
Resumidamente a Helium Network Helium é uma rede wireless descentralizada que oferece conectividade LoraWan e 5G onde a Helium Foundation garante a governança descentralizada e todo o resto é feito por empresas parceiras e toda a comunidade.
2.1 Pilares do ecossistema Helium
Existem inúmeros pilares dentro do ecossistema da Helium e como cada um faz sua parte a rede em si se torna muito dinâmica, por isso algumas coisas poderão mudar ao decorrer do tempo, mas de qualquer forma os principais pilares são:
2.1.1 Fabricantes de Hardware:
Todo gateway da rede Helium é fabricado por empresas parceiras como a Seeed, é basicamente como se fosse um gateway LoRaWAN que montamos com o da Radioenge, porém com uma camada de blockchain e autorizado pela Helium Fundation.
2.1.2 Parceiros de Hardware e Integração:
Empresas como a Seeed por exemplo, também consegue atuar dentro da criação e formulação de dispositivos para aplicação.
2.1.2.1 Operadores de Hotspots:
Cada operador fornecerá uma cobertura e em troca será recompensado através do Token IOT que pode ser trocado (redeemed) pelo Helium Network Token (HNT), token de governança da rede.
No que tange à recompensas, cada operador de gateway Helium pode ser recompensado através de dois métodos dentro da própria rede: um é provendo conectividade à dispositivos LoRaWan e a outra é pela prova de cobertura (PoC).
2.1.2.1.1 Recompensa por dispositivos conectados na rede
Dispositivos consomem DC (Data Credits) para se conectarem dentro da rede através de LNS (LoRaWan Network Server) Helium, todo Gateway é recompensado quando o dispositivo comunica-se com ele, recebendo uma fração do token IOT.
2.1.2.1.2 Recompensa por prova de cobertura
Outro método que talvez seja a principal fonte em alguns caso é justamente a prova de cobertura, que nada mais é do que um método em que a rede se testa para validar se de fato um determinado gateway está aonde se diz está.
Esse método é bastante interessante e útil, porém iremos abordar esse conceito de funcionamento em outro tópico mais a frente.
2.1.2.2 Desenvolvedores de Aplicativos e Dispositivos IoT:
Algumas empresas ficam dedicadas a montarem uma aplicação do inicio ao fim e já fornecer diretamente para o usuário final sem que ele se preocupe com outras etapas.
Um exemplo disso é uma empresa montar um dispositivo de sensor de umidade relativa do ar, configurar para a rede Helium, configurar para aplicação e entregar tudo pronto para quem precisa desse tipo de informação.
2.1.2.3 Parceiros de Aplicativos e Serviços:
Os parceiros de aplicação e serviços são responsáveis por fornecer um dashboard que se conecta com a Helium network e obtém os dados dos “end devices”, levando até o usuário final de uma forma mais lúdica. Um grande exemplo disso é a própria TagoIO, levando até o usuário final de uma forma mais intuitiva e amigável
2.1.2.4 Provedores
Os provedores são a principal frente da Helium, pois são eles que faz a união de todos os outros pilares para que tudo chegue de forma eficiente ao usuário. Existem vários provedores autorizados pela Helium e aqui no Brasil e America Latina temos a BrDot.
2.1.2.5 Desenvolvedores e Comunidade:
Nesse pilar é aonde estamos, desenvolvendo bibliotecas e tutoriais para facilitar ainda mais o processo de desenvolvimento de dispositivos IoT com LoRaWAN.
2.1.2.6 Usuários Finais:
Por fim temos os usuários finais que são os responsáveis por puxar todo o ecossistema, pois são eles que precisam necessariamente da aplicação em si. No entanto, cada pilar anterior consegue monetizar individualmente sem depender necessariamente dos usuários finais.
2.2 Tokens da rede Helium
A Helium tem um total de três Tokens dentro da rede onde cada um tem uma aplicação especifica e é extremamente importante entender isso para evitar confusões.
2.2.1 Data Credits (DC)
O Data Credits é como o próprio nome já fala, são créditos para transferência de dados e ele é cotado encima do dólar. Onde cada 1 DC podemos transferir de 0 a 24 bytes e custará 0.00001 USD, isso para LoRaWAN, para 5G é 0.50 USD para cada 1GB.
Porém esse valor não quer dizer que de fato o usuário final vai pagar isso, pois esse valor é para os provedores e existe um custo de manutenção de servidores, infraestrutura e lucro envolvidos. Mas mesmo assim o custo para o usuário final fica 3x mais barato do que o método tradicional, isso se referindo a nível Brasil.
2.2.2 Helium Network Token (HNT)
Os tokens HNT são utilizados para acessar a conectividade sem fio da rede Helium, uma vez que esses tokens podem ser convertidos em DC (Créditos de Dados). Além disso, os tokens HNT também respaldam outros tokens de governança dentro do ecossistema Helium, como MOBILE e IOT.
Porém dentro da HNT temos dois “sub tokens” que são usados para identificar a origem da receita e também separar o mercado, o que aumenta o aproveitamento do mercado da cripto, no final são convertidos em HNT. Esses “sub tokens” são o IoT (LoRaWAN) e mobile (5G), em termos de funcionamento é tudo igual a estrutura do HNT, porém segmentado.
3 O que é blockchain?
Descentralização é uma estrutura que de fato da autonomia e liberdade ao povo quanto maior for a centralização de qualquer coisa principalmente recursos básicos como energia e comunicação, maior será o poder de controle sobre a nação, seja ela por pessoas internas de um país ou externas.
Blockchain não quer dizer sempre criptomoedas, claro que é um grande pilar do blockchain, mas não quer dizer que essa tecnologia sirva apenas para isso.
Basicamente fazendo uma analogia, o bloackchain é o mesmo processo de uma indústria, onde cada operário monta uma parte de um produto e outros operários validam para ver se está tudo certo com o que foi feito anteriormente, por fim é empacotado e enviado para algum lugar.
Esse é o blockchain, porém ao invés de todo processamento estar em um único ponto, ele é dividido com diversos dispositivos que são chamados de “nós” ou mais comumente conhecidos como “mineradores” por conta das criptos e tokens.
Os nós são chamados de mineradores justamente por recompensar pessoas que detém de um hardware dedicado para realizar esses cálculos complexos que uma rede dessas necessitam, por isso o blockchain tem como pilar as criptomoedas.
4 Gateway da Helium, o grande segredo da rede
Um dos principais segredos da rede Helium está justamente no gateway de modo que além de fornecer conectividade LoRaWAN, também roda algoritmo de blockchain a fim de validar e integrar todos os gateways.
Mas o mais legal de tudo isso é que a Helium não produz nenhum gateway em si, ela basicamente montou a estrutura da rede e toda lógica de funcionamento e disponibilizou a documentação para fazer a integração com a rede caso alguma empresa queira virar parceira.
O gateway LoRaWAN em si não é nada muito diferente do que montamos com o hardware da Radioenge e inclusive utiliza a mesma estrutura de código, até o Raspberry Pi é utilizado veja só esse gateway da SenseCAP:
4.1 Estrutura de funcionamento interno
Como dito a estrutura de funcionamento interno é muito similar ao que montamos com o da Radioenge, a diferença é que pós camada de Packet Forwarder temos a camada de blockchain (hostspot cliente) e por fim o LNS (LoRaWAN Network Server).
Durante o processo de implementação dos gateways os softwares responsáveis pelo processamento do blockchain necessitavam de 8GB de RAM, mas ao logo do tempo o pessoal da Helium fundation foi otimizando o código ao ponto de conseguir rodar com 2GB de RAM o que diminuiu consideravelmente o preço de aquisição desses gateways.
4.1.1 Diferenças do Hardaware do LoRa
Nesses gateways utilizados pela Helium em especial os produzidos pela SenseCAP que é uma marca da Seeed, existem alguns pontos bastante interessantes se compararmos com o diagrama de blocos padrão de qualquer gateway LoRaWAN.
O que vemos de novo é a presença de mais três chips e um deles é LoRa, mas é o mesmo presente no módulo da Radioenge para end device. Esse chip da liberdade ao Raspberry pi atuar como P2P o que simplifica muito alguns processo, afinal nem tudo precisa ser LoRaWAN.
Talvez esse chip possa ser acessado em paralelo ao LoRaWAN, mas acessa-lo de forma simultânea não faz muito sentido, pois para receber pacote e enviar diretamente com ele será necessário definir as mesmas configurações dos dois lados da comunicação.
Tudo isso leva a crer que de fato ele seja exclusivamente para aplicações de P2P e não há nenhuma relação de uso para os gateways Helium da SenseCAP e na versão SPI do módulo WM1302 ele não está presente.
Por outro lado o microcontrolador SMT32L412 e o sensor de temperatura I2C estão presentes em ambas as versões, o sensor de temperatura é algo realmente bastante interessante para analisarmos a temperatura da placa, mesmo embora não tenha notado a placa esquentando igual como o SX1301.
O microcontrolador dentro desse módulo não tem função alguma a não ser abstrair duas comunicações em uma só, mas mesmo assim a Seeed disponibiliza as outras interfaces para caso queria ser acessadas de forma direta sem intermediários.
De todos esses chips o mais relevante é a troca do SX1301 para o SX1302 que trouxe mudanças significativas em termos operacionais.
4.2 Comparativo do SX1302 em relação ao SX1301
Basicamente o SX1302 é a grosso modo, um aprimoramento do SX1301 onde as principais diferenças está associado a performance, consumindo menos energia que o anterior e tendo maior range de temperatura de operação.
Na imagem a baixo da para ver que o consumo de energia da transmissão caiu aproximadamente 59% e o de recebimento de pacotes caiu 7,5x menos do que o normal. Além disso a tolerância da temperatura negativa aumentou em -35ºC e a temperatura positiva aumentou em 30ºC.
Esse comparativo é baseado no módulo LoRaWAN da Seeed e o da Radioenge, possa ser que tenha uma coisa ou outra diferente internamento no hardware da Seeed, mas ainda assim nos da uma visualização sobre a diferença entre eles.
Essas melhorias foram fundamentais para a expansão do LoRaWAN no mundo inteiro, por conta da alta tolerância a variação de temperatura.
5 Boas práticas para garantir uma boa cobertura de rádio
Por mais o preço tenha caído consideravelmente ao ponto de compensar ainda mais o investimento, é necessário entender o posicionamento do gateway é um fator determinístico para uma boa cobertura.
Também é importante destacar que para ter uma boa visada, é extremamente importante evitar barreiras como arvores e prédios e quanto mais alto melhor, é claro que nem todo mundo terá o melhor cenário possível e é por isso inclusive que algumas pessoas que focam na rentabilidade acabam se frustrando também.
Mas mesmo assim existem inúmeros pontos em que se pode melhorar para ter a melhor cobertura de acordo com sua realidade.
5.1 Melhores locais para por o gateway dentro de casa
Cada gateway é projetado para uma aplicação e por isso é interessante consultar o manual de cada fabricante, no caso da SenseCAP os gateways são feitos para ficarem dentro de casa, pois não tem proteção suficiente para aguentar os intemperes de um ambiente externo.
E nem todo mundo tem como por um gateway em um ambiente externo, por isso é recomendado que o gateway fique posicionado em um local que seja favorável ao sinal de rádio, como por exemplo as janelas.
5.2 Melhor lugar para por na área externa
Existem vários pontos na área externa em que se pode por um gateway, mas sempre prefira por encima do telhado ou outra estrutura que seja mais alta, mas é bom sempre também tomar cuidado para evitar da antena ser o ponto mais alto para não atuar como “para raio” e se tiver “para raio” coloque a antena abaixo dele.
De qualquer forma antes de por em ambiente externo no “ponto mais alto” sempre estude bem e se possível contrate um profissional qualificado para esse tipo de operação para evitar acidentes durante e pós instalação.
Esse gateway SenseCAP da imagem abaixo foi instalado em um hospital em Brasilia pelo Gabriel Marques lá da Brdot e nitidamente podemos ver que não há nenhuma barreira física na faixa visual do gateway, nem mesmo olhando para o horizonte e é exatamente essa perspectiva que é necessária para instalar qualquer gateway em ambiente externo.
Como os gateways se validam entre si, é possível visualizar a intensidade do sinal LoRaWAN em cada ponto e até obter o alcance de cada gateway, a imagem abaixo se trata do mesmo da imagem acima e é possível notar a mesma perspectiva da foto acima, porém em sinal de rádio.
6 Alcance dos Gateways
Muitas pessoas relatam que não conseguiram ou não consegue um bom alcance com o LoRa e existem infinitos fatores que podem prejudicar no alcance, principalmente se for configurado de modo inadequado.
Mas se for bem posicionado em uma altura adequada e a topografia for favorável esse tipo de cenário abaixo acaba de fato ocorrendo, um único gateway conseguindo se comunicar com todos os outros em Brasília.
O mais interessante de tudo isso é que qualquer pessoa pode simplesmente entrar neste site e consultar a distância de comunicação com base na imagem acima, veja só que belezinha, 28.81km de comunicação LoRaWAN.
Repetindo, esse caso é um caso bem atípico, mas de qualquer forma podemos ver as comunicações recentes desse mesmo gateway e ter uma base das distâncias que são alcançadas e você poderá confirmar neste link.
Esses gateways que foram usados como exemplo, são gateways de cunho público e por isso temos acesso a algumas informações sobre eles, mas também temos como por eles de forma privada, podendo ter a própria rede exclusiva.
A forma que foi demonstrado o alcance neste tópico é a melhor maneira de se analisar o real alcance de cada gateway, pois ele tem atualizações constantes do status de atividade. Porém também existe também o falso alcance que pode ser criado de forma não intencional ou proposital.
6.1 Falso Alcance
Esse falso alcance da uma impressão que o gateway consegue se comunicar com outro gateway em uma distância absurda e pincipalmente com um RSSI extremamente baixo para uma distância tão longa.
Porém se compararmos essa imagem com a primeira imagem do tópico anterior, conseguirmos perceber que o espalhamento de cobertura é completamente diferente da segunda imagem para a primeira.
Na imagem acima o gateway que está no Rio de Janeiro se comunica com apenas um único gateway em São Paulo o que difere muito da primeira imagem onde tem um espalhamento da cobertura que mesmo tão distante consegue se conectar com vários outros gateways ao redor do mais distante.
Para ter uma confiabilidade maior, basta analisarmos o RSSI que quanto maior for (mais próximo do zero) melhor será o sinal e visse versa, nesse caso um RSSI de -9db para uma distância de 344,4km é completamente surreal.
Particularmente acabei me deixando levar por uma imagem em um momento de euforia e simplesmente não analisei os dados de forma mais criteriososa e acabei criando uma postagem lá no meu Linkedin mostrando esse longo alcance, mas logo em seguida de ter entendido que de fato errei acabei apagando o post para não continuar circulando uma informação que não é coerente.
6.1.1 Então um LoRaWAN não chega a essa distância?
Depende de cada caso, porém de qualquer forma é bom analisarmos de maneira criteriosa esse tipo de informação e dentro da própria rede Helium é possível avaliarmos cada gateway individualmente e tirar as próprias conclusões.
Mas é sempre bom analisar as comunicações mais recentes para de fato ter um parâmetro de análise mais coerente, além disso a própria rede tem mecanismos de validação de veracidade para garantir a integridade da rede.
7 Processo de validação do gateway na rede
A precisão da posição de cada gateway é algo extremamente importante na rede, pois isso ajuda a criar um mapa de cobertura mais eficiente para os usuários, além também de possibilitar uma maior precisão em dispositivos de rastreamento via LoRaWAN.
Para validar se de fato um gateway está mesmo no lugar onde se diz está, ele é simplesmente desafiado pela rede através de um método chamado prova de cobertura onde o próprio hotspot manda um sinal de broadcasting e todos os gateways ao redor dele vai simplesmente testemunhar se de fato ele está presente lá.
Através desse link é possível verificar quais são os gateways que conseguiu testemunhar o broadcasting transmitido e também quantos ele conseguiu testemunhar.
7.1 Método de validação do gateway através da comunidade e punição
Esses é uma das formas de confirmar se de fato um determinado gateway é realmente válido, mas há também outra forma em que a comunidade consegue fazer votações tanto de forma positiva como de forma negativa através do crowdspot.
Caso algum gateway seja considerado inválido decorrente de algum critério da Helium ele entrará na denylist e consequentemente será desconsiderado na rede, deixando de receber HNT. Quando algum estiver na denylist é possível ver a informação no canto inferior direito através desse link.
7.2 Como ingressar Helium Network?
Para de fato fazer parte como um usuário da rede você pode providenciar e manter sua próprio servidor LNS ou encontrar um provedor no ecossistema da Helium, nesse caso para a America Latina temos a BrDot.
Uma das vantagens de entrar em contato com a Brdot é que a depender da solução que você queria oferecer, eles já poderão ter algum case pronto, pois eles tem contato continuo com diversos polos tecnológicos de LoRaWAN em todo o mundo.
Além disso, eles já facilitam bastante o processo de adesão a rede tanto é que não precisei configurar gateway nem muito menos os dispositivos do console, apenas foi necessário aceitar o convite de acesso ao console, ligar o gateway e cadastrar um end device.
8 Ingressando na Rede Helium
Por mais que a Brdot facilite o processo para entrar na rede ainda assim é necessário abordarmos alguns pontos para deixar tudo ainda mais nítido.
8.1 Sobre o gateway M1 da SenseCAP e seu comportamento
Caso você não tenha cobertura Helium na sua região, então será necessário adquirir um gateway — é possível fazer uma solicitação de comodato à própria Brdot, como eles não vendem os gateways propriamente. No meu caso, o gateway já veio configurado então só é necessário ligar e conectar no cabo Ethernet.
Antes mesmo de ligar, certifique-se que a antena está bem conectada para evitar problemas, uma antena desconectada e equipamento ligado pode ocasionar na queima em todo o circuito de front end do LoRaWAN, por isso o tornará incapaz de comunicação.
O gateway do vídeo abaixo está sem a carcaça dele para demonstrar melhor a estrutura interna e seu funcionamento, mas no próprio vídeo é possível notar que assim que o gateway é inicializado sem o cabo ehternet ele começa a ficar piscando o LED azul até que a conexão seja estabelecida.
Feito isso o seu gateway está pronto para uso, agora só basta ir para o console e fazer algumas configurações para começar a mexer na rede.
9 Helium Network console
O console em si é extremamente intuitivo e fácil de mexer, sem muito mistério, tem algumas funções a mais e outras a menos, mas no geral é bastante simples.
9.1 Cadastrando dispositivos
O cadastramento dos dispositivos é bastantes simples e da também para importar diretamente da The Things Network ou de um arquivo .csv. Ao cadastrar o dispositivo é importante também selecionar uma opção “Padrão” que está dentro do prâmetro “profile”.
O único ponto negativo é que até o momento do teste v2.2.42 do console Brdot Helium não disponibilizava a opção de autenticação ABP, apenas OTAA. Contudo, a Brdot me informou possuir um LNS Chirpstack configurado para Helium que atende a dispositivos ABP.
9.1.1 Dispositivos compatíveis e configuração para conexão
A rede funciona muito bem com qualquer dispositivo LoRaWAN, em especial os módulos da Radioenge e da Smart modular. A configuração que é necessária para se comunicar com a Helium é a mesma da The Things Network e Chirpstack, ou seja, uma configuração padrão.
9.2 Se conectando na rede
Fazer a conexão com a rede Helium é bastante simples, porém é necessário ter DC para que as comunicações não sejam bloqueadas. Além disso também é necessário entender que não importa se o “end device” envia 1 ou 24 bytes, sempre o consumo será 1 DC então tente aproveitar ao máximo cada comunicação.
9.2.1 Testando a rede Helium com Arduino IDE e Helium console
Existe uma forma bem simples com quase nenhuma complexidade para testarmos se de fato tudo está funcionando como o esperado, mas isso só confirma o funcionamento do dispositivo até a camada do console.
O método vai funcionar para qualquer end device se os critérios de comunicação forem atendidos, em outras palavras é se conseguir comunicar com a TTN ou CS consegue também com a Helium. Porém neste post vamos mostrar apenas como funciona com os dois principais fabricantes de módulos LoRaWAN no Brasil que é a Radioenge e a Smart Modular.
9.2.1.1 Módulo LoRaWAN da Radioenge e Helium Network
Os módulos da Radioenge já foi amplamente explorados aqui no site, tanto os módulos LoRaWAN como também gateway e até LoRa Mesh, então caso tenha alguma dúvida de como funciona esse módulo é recomendado fazer leitura.
9.2.1.1.1 Diagrama do módulo da Radioenge e ESP32
Para usarmos o módulo da Radioenge é necessário ter um conversor USB serial para fazer os comandos, porém o uso de um microcontrolador como o ESP32 por exemplo, acaba possibilitando uma automatização do processo de configuração e comunicação com a rede.
Vale salientar que o uso do LED e o resistor não é necessário para essa aplicação, usa se quiser, é apenas um feedback visual de que o conjunto estar funcionando.
9.2.1.1.2 Código para módulo da Radioenge
O código é extremamente simples e enxuto e já faz todo o de configuração do módulo para a Helium network sem precisar fazer o processo manualmente, porém para que o código funcione é necessário baixar a nossa biblioteca em nosso Github.
#include "LoRaWAN_Radioenge.h"
LoRaWAN_Radioenge LoRa(&Serial2);
void setup() {
Serial.begin(9600);
Serial2.begin(9600);
LoRa.begin(true);
LoRa.printParameters();
if(LoRa.JoinNetwork(OTAA, TTN, true, !true))
LoRa.SendString("elcereza.com", 1);
LoRa.pinMode(2, OUTPUT);
}
void loop() {
LoRa.digitalWrite(2, 1);
delay(5000);
LoRa.digitalWrite(2, 0);
delay(5000);
}
9.2.1.2 Módulo LoRaWAN da Smart modular e Helium Network
Diferentemente do da Radioenge, esse módulo ainda não foi explorado aqui no site, mas concidentemente durante os estudos da rede tive a oportunidade de receber dois devkit’s do meu amigo João Victor da JVTech que utiliza um ESP32S3 ou ESP32C3 e o módulo da Smart.
Mesmo embora sejam módulos diferentes, há muitas semelhanças em comparação ao funcionamento em modo geral, então o estudo de um vai servir para o estudo do outro.
9.2.1.2.1 Código para devkit da JVTech
Para fazer o código funcionar no ESP32C3 ou no ESP32S3 é necessário seguir o guia de configuração desses microcontroladores para o Arduino IDE, em seguida é necessário baixar a biblioteca para o módulo da Smart Modular, em caso de dúvidas é bom consultar a documentação do devkit.
#include <SoftwareSerial.h>
#include <RoboCore_SMW_SX1262M0.h>
#define LORA_RX 7
#define LORA_TX 6
SoftwareSerial LoRaSerial(LORA_RX, LORA_TX);
SMW_SX1262M0 lorawan(LoRaSerial);
CommandResponse response;
void setup() {
Serial.begin(9600);
LoRaSerial.begin(9600);
Serial.println(F("--- DevKit ESP32-C3 LoRa Simple Join ---"));
// Efetua o reset(reboot) do módulo LoRaWAN
response = lorawan.reset();
if (response == CommandResponse::OK) {
} else {
Serial.println(F("Error on reset the module"));
}
delay(1000);
// Efetua a leitura do Device EUI do módulo
char deveui[16];
response = lorawan.get_DevEUI(deveui);
if (response == CommandResponse::OK) {
Serial.print(F("DevEUI: "));
Serial.write(deveui, 16);
Serial.println();
} else {
Serial.println(F("Error getting the Device EUI"));
}
// Efetua a leitura da AppKey do módulo
char appKey[32];
response = lorawan.get_AppKey(appKey);
if (response == CommandResponse::OK) {
Serial.print(F("AppKey: "));
Serial.write(appKey, 32);
Serial.println();
} else {
Serial.println(F("Error getting the AppKey"));
}
char appeui[16];
response = lorawan.get_AppEUI(appeui);
if (response == CommandResponse::OK) {
Serial.print(F("AppEUI: "));
Serial.write(appeui, 16);
Serial.println();
} else {
Serial.println(F("Error getting the Appeui"));
}
// Define o modo de autenticação na rede LoRaWAN como OTAA
response = lorawan.set_JoinMode(SMW_SX1262M0_JOIN_MODE_OTAA);
if (response == CommandResponse::OK) {
Serial.println(F("Mode set to OTAA"));
} else {
Serial.println(F("Error setting the join mode"));
}
// Salva as configurações setadas acima na memória do módulo
response = lorawan.save();
if (response == CommandResponse::OK) {
Serial.println(F("Settings saved"));
} else {
Serial.println(F("Error on saving"));
}
// Efetua uma tentativa de JOIN na rede LoRaWAN
Serial.println(F("Joining the network"));
}
void loop() {
if (lorawan.isConnected()) {
static bool init = true;
if(init){
init = false;
Serial.println(F("Joined"));
delay(1000);
lorawan.sendT(1, "elcereza.com");
}
}
else
lorawan.join();
delay(1000);
}
9.2.1.3 Conectando na rede e fazendo uplink
No console da Helium podemos comprovar se realmente a comunicação foi realizada com sucesso através de duas formas, a primeira é analisando o status do dispositivo e o tamanho do payload recebido, dessa forma é possível saber se de fato o que foi enviado é o que foi recebido.
Porém há outra forma que é até mais eficiente onde conseguirmos analisar tudo que foi recebido e até parâmetros relacionadas ao LoRa em si, esse método consiste da análise do log de eventos que pode ser facilmente baixado dentro do evento de cada dispositivo.
Quando algum dispositivo envia um uplink toda a mensagem fica dentro também do log de eventos e essa mensagem pode ser vista no parâmetro do JSON chamado de payload, esse parâmetro trabalha com base64 e por isso não é possível ler de forma explicita sem antes converter base64 para texto.
No vídeo a baixo é possível ver todo esse processo de comunicação com os dois módulos de exemplo e também a confirmação de que de fato o pacote foi recebido.
9.2.1.3.1 Módulo da Radioenge e Helium Network
9.2.1.3.2 Devkit JVTech e Helium Network
9.3 Flows, montagem da aplicação
O flows é uma função bem diferente se comparado com a TTN ou ChirpStack, mas é lá que vamos direcionar a cadeia de funcionamento da aplicação, onde cada dispositivo vai apontar para uma função ‘e’ ou ‘ou’ a uma integração e cada dispositivo pode apontar para mais de uma aplicação.
9.3.1 Função de decodificação dos payload’s
A função nada mais é do que um código em JavaScript que vai realizar um processo de decodificação do payload e a interligação da função no flows é entre o dispositivo e a integração. Nas funções temos três decodificadores já padronizados, porém também é possível criar o próprio código de decodificação.
9.3.2 Integração do LNS com a aplicação
Por fim temos a ultima etapa da rede LoRaWAN que é a aplicação. A aplicação basicamente é onde o usuário vai conseguir analisar os dados lidos pelo end device e até mandar comandos em alguns casos, porém para que a aplicação funcione é necessário fazer com ela se conecte.
A integração faz o papel de conectar o LNS com a aplicação e dentro de Helium temos inúmeros integradores já presentes no mercado como por exemplo a TagoIO, mas também é possível fazer sua integração do zero através do protocolo HTTP ou MQTT.
