better esp 1ch lora gateway
1.0.0
Versão 6.2.0, dados: 29 de janeiro de 2020
Autor: M. Westenberg ([email protected])
Direitos autorais: M. Westenberg ([email protected])
Todos os direitos reservados. Este programa e os materiais que o acompanham são disponibilizados nos termos da licença do MIT que acompanha essa distribuição e está disponível em https://opensource.org/license/mit-license.php
Este programa é distribuído na esperança de que seja útil, mas sem garantia; sem a garantia implícita de comercialização ou aptidão para uma finalidade específica.
Mantido por Maarten Westenberg ([email protected])
Primeiro de tudo: leia este arquivo e documentação, ele deve conter a maioria das informações necessárias para continuar. Infelizmente, não tenho tempo para acompanhar todos os e-mails e, como a maioria das informações, incluindo pin-outs etc, etc.
Eu tenho mais de 10 mini painéis Wemos D1 em execução, alguns eu construí, cerca de 10 ou mais em Hallard, 3 em Comresult e 4 placas ESP32. Todos eles funcionam sem problemas neste código. Eu achei, no entanto, que boas juntas de solda e fiação fazem toda a diferença; portanto, se você receber redefinições/erros que não pode explicar, dê uma segunda olhada na sua fiação.
Este repositório contém uma implementação de prova de conceito de um gateway Lorawan de um único canal para o ESP8266. A versão inicial 5.2 também o ESP32 do TTGO (e outros) é suportado. O software implementa um gateway Lora padrão com as seguintes exceções e mudanças:
Este gateway Lora não é um gateway completo, mas implementa apenas um gateway de frequência de um canal/um. A quantidade mínima de frequências suportadas por um gateway completa é de 3, a maioria suporta 9 ou mais frequências. Esse software começou como uma prova de conceito para provar que um único chip RRFM95 de baixo custo que estava presente em quase todos os nó Lora da Europa poderia ser usado como uma alternativa barata aos portões completos muito mais caros que estavam usando o chip SX1301.
Como o software deste gateway será frequentemente usado durante a fase de desenvolvimento de um projeto ou em situações de demonstração, o software é flexível e pode ser facilmente configurado de acordo com os requisitos do ambiente ou do cliente. Existem duas maneiras de interagir com o software:
A documentação completa do gateway de canal único é encontrada no Things4u.github.io, veja o guia de hardware no capítulo Gateway.
O gateway de canal único foi testado em um gateway com o Wemos D1 Mini, usando um transceptor Hopef RFM95W. Os testes foram feitos na versão 868 do LORA e alguns testes em 433 MHz. Os nós Lora testados novamente este gateway são:
O código foi testado em pelo menos 8 placas de gateway separadas, ambos com base no Hallard e nas placas de comresultos. Ainda estou trabalhando no pin-out e funções do ESP32 (esperado em breve).
Recomenda -se compilar e iniciar o gateway de canal único com o mínimo de modificações possível. Isso significa que você deve usar as configurações padrão nos 2 arquivos de configuração o máximo possível e alterar apenas o SSID/senha para sua configuração Wi -Fi e os pinos do seu ESP8266 que você usa em loramodem.h. Esta seção descreve o mínimo de configuração necessária para obter um gateway de trabalho que pode ser configurado mais usando a página da Web.
Através do gerente da biblioteca:
Agora seu gateway deve estar em execução. Use a página da web para definir "Debug" como 1 e você poderá ver os pacotes entrando no monitor serial.
Existem duas maneiras de alterar a configuração do gateway de canal único:
Onde você tem uma escolha, a opção 2 é muito mais amigável e útil.
O arquivo Configgway.h contém as configurações de gateway configuráveis pelo usuário. Todos têm suas definições definidas através de declarações #Define. Em geral, a definição de um #Define como 1 permitirá a função e configurá -la como 0 o desativará.
Além disso, algumas configurações podem ser inicializadas definindo seu valor com um #Define, mas podem ser alteradas em tempo de execução na interface da web. Para algumas configurações, desativar a função com um #Define removerá a função do servidor da web também.
Nota sobre o uso da memória: o ESP8266 possui uma enorme quantidade de memória disponível para o espaço do programa e o sistema de arquivos SPIFFs. No entanto, a memória disponível para heap e variáveis é limitada a cerca de 80k bytes (para o ESP-32, isso é maior). O usuário é aconselhado a desativar as funções não usadas para economizar no uso da memória. Se o heap cair abaixo de 18 kbytes, algumas funções não podem se comportar conforme o esperado (em um caso extremo, o programa poderá travar).
O arquivo Confignode.h é usado para definir o ponto de acesso Wi-Fi e a estrutura dos sensores conhecidos no gateway de 1 canal. Definir os pontos de acesso WiFi conhecidos (SSID e senha) devem ser feitos no horário de compilação.
Quando o gateway não é usado apenas como gateway, mas também para fins de depuração, o usado pode especificar não apenas o nome do nó do sensor, mas também descriptografar para certos nós da mensagem.
O usuário pode determinar se o console USB é usado ou não para mensagens de saída. Ao definir _dusb como 0, toda a saída por serial está desativada (na verdade, as instruções seriais não estão incluídas no código).
#Define _dusb 1
Defina a classe de operação suportada pelo gateway. A classe A é suportada e contém a operação básica para sensores de bateria.
A classe B contém o modo de operação do farol/bateria. O gateway enviará um farol para os sensores conectados, o que lhes permite sincronizar o messagaging downlink.
O modo de operação da classe C (contínuo) contém suporte para dispositivos que provavelmente não são operados por bateria e ouvirão a rede o tempo todo. Como resultado, a latência desses dispositivos também é mais curta do que para os dispositivos de classe A. Os dispositivos Classe C não dependem da energia da bateria e estenderão as janelas de recebimento até a próxima janela de transmissão. De fato, apenas as transmissões farão com que o dispositivo aborte a escuta enquanto essa transmissão durar. Os dispositivos Classe C não podem fazer operação de classe B.
#Define _class "A"
Todos os dispositivos começarão como dispositivos de classe A e podem decidir "atualizar" para a classe B ou C. Além disso, o gateway pode ou não suportar a classe B, que é um superconjunto da classe A. Nota: Somente a classe A é suportada
Apoiamos duas configurações de pin-out prontas para uso: Hallard e Compesult. Se você usar um desses dois, basta definir o parâmetro como o valor certo. Se suas definições de pino forem diferentes, atualize o arquivo loramodem.h para refletir essas configurações. 1: Hallard 2: Comresult Pin Out
#define _pin_out 1
O seguinte parâmetro Shoudl será definido como 0 em circunstâncias normais. Ele permite que o sistema force a formatação do sistema de arquivos SPIFFs.
#define spiff_format 0
Defina o fator _spulding para o valor desejado SF7, SF8 - SF12. Observe que este valor está intimamente relacionado ao valor usado para _cad. Se _cad estiver ativado, o valor de _sPreading não será usado pelo gateway, pois possui todos os fatores de sading ativados.
#Define _SPreading SF9
Observe que a frequência padrão usada é 868,1 MHz, que pode ser alterada no arquivo Loramodem.h. O usuário é aconselhado a não alterar isso e usar apenas a frequência padrão de 868,1 MHz.
A detecção de atividade do canal (CAD) é uma função do chip Lora RFM95 para detectar mensagens de entrada (atividade). Essas mensagens recebidas podem chegar a qualquer um dos fatores de espalhamento bem conhecidos SF7-SF12. Ao ativar o CAD, o gateway pode receber mensagens de qualquer um dos fatores de espalhamento.
Na verdade, ele é usado na operação normal para dizer ao receptor que outro sinal já está usando o canal.
A funcionalidade CAD tem um (pouco) preço: o chip não poderá receber sinais muito fracos, pois a função CAD usará a configuração de registro RSSI do chip para determinar se recebeu ou não um sinal (ou apenas ruído). Como resultado, não são recebidos sinais muito fracos, o que significa que o alcance do gateway será reduzido no modo CAD.
#Define _CAD 1
A partir da versão 4.0.6, o gateway permite a atualização do ar se a configuração A_OTA estiver ligada. O software ar -air requer uma configuração de uma versão 4.0.6 sobre o USB no gateway, após o qual o software (padrão) está ativado para uso.
A primeira versão suporta apenas a função OTA usando o IDE que, na prática, significa que o IDE deve estar no mesmo segmento de rede que o gateway.
Nota: Você precisa usar o software Bonjour (Apple) em sua rede em algum lugar. Uma versão está disponível para a maioria das plataformas (enviada com o iTunes para Windows, por exemplo). O software Bonjour permite que o gateway use o MDNS para resolver o ID do gateway definido pelo OTA, após o qual as portas de download aparecem no IDE.
TODO: O software OTA ainda não foi testado em conjunto com o software Wifimanager.
#Define a_ota 1
Essa configuração permite o servidor da web. Embora o próprio servidor da web tenha muita memória, ajuda muito a configurar o tempo de execução do gatewayat e inspeciona seu comportamento. Ele também fornece estatísticas das últimas mensagens recebidas. O parâmetro A_Refresh define se o servidor da web deve renovar a cada x segundos.
#Define A_SERVER 1 // Defina apenas servidor da web local se este definir estiver definido
#define a_refresh 1 // O servidor da web está ativado para atualizar sim/não? (sim está ok) #define a_serverport 80 // Porta local da web servidor
#define a_maxbufsize 192 // deve ser maior que 128, mas pequeno o suficiente para funcionar
O parâmetro A_Refresh define se podemos ou não definir a configuração Atualizar sim/não no WebBrowser. A configuração no webbrowser é normalmente colocada "não" como padrão, mas podemos deixar a definição em "1" para ativar essa configuração no webbrowser.
Para que o gateway envie mensagens de downlink no fator de espalhamento predefinido e na frequência padrão, você deve definir o parâmetro _strict_1ch como 1. Observe que, quando não estiver definido como 1, o gateway responderá às solicitações de downlink com o conjunto de fatores de frequência e espalhamento pelo servidor de backend. E no momento, o TTN responde a mensagens de downlink para SF9-SF12 no intervalo de tempo RX2 e com a frequência 869.525MHz e no SF12 (de acordo com o padrão LORA ao enviar no slot de tempo RX2).
#Define _Stric_1ch 0
Você é aconselhado a não alterar a configuração padrão deste parâmetro.
Ao definir o OLED, você configura o sistema para trabalhar com painéis OLED sobre o I2C. Alguns painéis funcionam por SPI e I2C, onde I2C é Solwer. No entanto, como o SPI é usado para a comunicação do transceptor RFM95, você é desbotado com um desses, pois eles não funcionarão com este software. Em vez disso, escolha uma solução OLED que funcione sobre o I2C.
#Define OLED 1
Os seguintes valores são definidos para OLED:
Quando isso for definido (== 1), reuniremos as estatísticas de todas as mensagens e a produziremos para o sistema de arquivos SPIFFs. Garantimos que usamos vários arquivos com um número fixo de registros para estatísticas. O número de recreação nos diz quantos registros são permitidos em cada arquivo de estatísticas. Assim que o número de recreação for maior que o número de registros permitidos, abrimos um novo arquivo. Depois que o número de arquivos exceder a quantidade de arquivos de estatísticas, excluímos o arquivo antigo e abrimos um novo arquivo. Ao selecionar o botão "Log" na parte superior da tela da GUI, todos os arquivos de log são ouptu no dispositivo serial USB. Dessa forma, podemos examinar muito mais registros do que ajustar a tela da GUI ou a saída serial.
#Define stat_log 1
A definição dos pinos i2C SDA/SCL é feita no arquivo Configgway.h logo após o #Define of OLED. Padrão O ESP8266 usa os pinos D1 e D2 para as linhas I2C BUS SCL e SDA, mas elas podem ser alteradas pelo usuário. Normalmente, Thsi não é necessário. As funções OLED são encontradas no arquivo _loramodem.ino e podem ser adaptadas para mostrar outros campos. As funções são chamadas quando uma mensagem é recebida (!) E, portanto, potencialmente, isso aumentará a instabilidade do ESP, pois essas funções podem exigir mais tempo do que o esperado. Nesse caso, swithc off a função OLED ou construa em uma função no loop principal () que exibe no tempo do usuário (não interrompa).
O gateway permite conectar -se a 2 servidores ao mesmo tempo (como a maioria dos gateways Lora btw). Você precisa se conectar a pelo menos um roteador Lora padrão, caso use a rede de coisas (TTN) do que definir: definir:
#Define _ttnServer "Router.EU.THETHINGS.NETWORK"
#Define _ttnport 1700
Caso você configure seu próprio servidor, você pode especificar o seguinte usando seu próprio URL do roteador e sua própria porta:
#Define _thingServer "your_server.com" // URL do servidor do programa Lora Udp.js Server
#define _thingport 1701 // seu servidor UDP deve ouvir esta porta
Defina os parâmetros de identidade para o seu gateway:
#Define _Description "Esp-Gateway"
#define _email "[email protected]"
#Define _platform "Esp8266"
#Define _lat 52.00
#Define _lon 5.00
#Define _alt 0
É possível usar o gateway como um nó. Dessa forma, os valores de sensores locais/internos são relatados. Esta é uma função intensiva em CPU e memória como fazer uma mensagem de sensor envolve funções EAS e CMAC.
#Define GatewayNode 0
Mais abaixo no arquivo de configuração Confignode.h, é possível definir o endereço e outras informações do LORA do nó do gateway.
A maneira mais fácil de configurar o gateway no WiFi é usando a função Wifimanager. Esta função funciona fora da caixa. O Wifimanager colocará o gateway no modo AccessPoint para que você possa se conectar a ele como um WiFi AccessPoint.
#Define _WIFIMANAGER 0
Se o WiFi Manager estiver ativado, certifique -se de definir o nome do AccessPoint se o gateway estiver no modo AccessPoint e na senha.
#Define ap_name "Esp8266-Gway-Things4U"
#define ap_passwd "ttnautopw"
O nome do ponto de acesso padrão usado pelo gateway é "Esp8266 Gway" e sua senha é "ttnautopw". Após a ligação ao ponto de acesso ao seu telefone celular ou computador, vá para htp: //192.168.4.1 em um navegador e diga ao gateway para qual rede WiFi você deseja conectar e especificar a senha.
O gateway então redefinirá e se ligará à rede fornecida. Se tudo correr bem, agora você está definido e o ESP8266 se lembrará da rede à qual deve se conectar. NOTA: Desde que o ponto de acesso ao qual o gateway esteja preso esteja presente, o gateway não trabalhará mais com a lista WPA de pontos de acesso conhecidos. Se necessário, você pode excluir o ponto de acesso atual no servidor da web e o ciclo de energia do gateway para forçá -lo a ler a matriz WPA novamente.
#if gatewayNode == 1
#define _devaddr {0x26, 0x01, 0x15, 0x3d}
#define _appskey {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
#Define _nwksKey {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
#Define _Sensor_Interval 300
#endif
O servidor da web embutido pode ser usado para exibir informações de status e depuração. Além disso, o servidor da web permite que o usuário altere determinadas configurações em tempo de execução, como o nível de depuração ou ligue e desative a função CAD. Ele pode ser acessado com o seguinte URL: http: //: 80 Onde é o IP fornecido pelo roteador ao ESP8266 na inicialização. Provavelmente é algo como 192.168.1.xx O servidor da web mostra várias definições de configuração, além de fornecer funções para definir parâmetros.
Os seguintes parâmetros podem ser definidos usando o servidor da web.
O software depende de vários softwares, o Arduino IDE para o ESP8266 sendo o mais importante. Várias outras bibliotecas também são usadas por este programa, certifique -se de instalar essas bibliotecas com o IDE:
Por conveniência, as bibliotecas também são encontradas neste repositório do GitHub no diretório da biblioteca. Observe que eles não fazem parte do Gateway ESP 1Cannel e podem ter seu próprio licenciamento. No entanto, essas bibliotecas não fazem parte do software de gateway de canal único.
Consulte http://things4u.github.io na seção de hardware para obter instruções de construção e conexão.
As seguintes dependências são válidas para o gateway de canal único:
As seguintes coisas ainda estão na minha lista de desejos para fazer no gateway de canal único:
Os arquivos de origem do esboço do gateway neste repositório são disponibilizados sob a licença do MIT. As bibliotecas incluídas neste repositório estão incluídas apenas para conveniência e todas têm sua própria licença, e não fazem parte do código de gateway ESP 1CH.
