Sistema de monitoramento de tempo IoT distribuído inteligente usando NodeMCU: 11 etapas

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:34

Todos vocês devem estar cientes da estação meteorológica tradicional; mas você já se perguntou como realmente funciona? Como a estação meteorológica tradicional é cara e volumosa, a densidade dessas estações por unidade de área é muito menor, o que contribui para a imprecisão dos dados. Vou explicar como: suponha que uma estação esteja localizada no meio de uma cidade e seja a única estação localizada em um raio de 'x' metros, ela pode ser facilmente influenciada se qualquer agente causador de poluição estiver presente nas proximidades da estação mostrando toda a área do raio de 'x' metros como poluída, uma vez que essa única estação é responsável por determinar os dados meteorológicos de toda a área.

Para contornar esse problema, a densidade dos módulos deve ser aumentada, o que só é possível se os módulos forem mais baratos e ocuparem menos espaço do que o existente.

Esta é a razão pela qual minha solução proposta é a solução perfeita para este problema. Custa menos de $ 10 e também repousa facilmente na minha palma.

Como funciona…

Existem 3 partes principais deste projeto.

Lado do dispositivo:

O dispositivo é um módulo IoT mostrado na imagem que envia os dados meteorológicos para o servidor a cada 'x' intervalo de tempo. Os dados incluem os dados meteorológicos reais, a localização geográfica do módulo; ou seja, suas coordenadas, seu endereço MAC; para identificar exclusivamente o dispositivo, a versão do firmware em que está sendo executado. O lado do dispositivo compreende N-módulos distribuídos pela área contribuindo ativamente com dados para o servidor.

Lado do servidor:

Como o nome sugere, é o servidor centralizado que lida com várias operações como receber os dados dos módulos e armazená-los no banco de dados, atualizar o módulo com o firmware mais recente se estiver rodando em uma versão mais antiga, enviar os dados meteorológicos para o cliente a pedido.

Cliente / lado do usuário:

É o usuário final que solicita os dados meteorológicos do servidor. O cliente envia a localização atual e com base na localização, o servidor calcula a distância entre o cliente e todos os módulos e envia ao cliente os dados meteorológicos do módulo mais próximo que é considerado preciso.

Suprimentos

• NodeMCU (ESP8266-12E)
• DHT11 (sensor de umidade e temperatura)
• BMP180 (sensor de pressão e temperatura)
• MQ-135 (sensor de índice de qualidade do ar)
• Cabo USB (para fazer upload do programa)
• Fonte de alimentação de 5 volts
• Capacitores (opcional: para ser colocado paralelo à linha de alimentação)
• Arduino IDE (para depurar e fazer upload do programa)
• Aplicativo POSTMAN (opcional: para depurar a API)
• Um site (para hospedar o servidor PHP e MySQL)

Etapa 1: Solde todos os componentes e carregue o programa para o NodeMCU

Solde todos os componentes para o NodeMCU conforme mostrado no diagrama de circuito em uma placa perf. Além disso, solde um capacitor em paralelo às linhas de energia, uma vez que a energia aumenta durante a transmissão e recepção de dados.

Uma vez feito o trabalho de solda, carregue o código fornecido no arquivo "code.c".

Observação: não se esqueça de substituir as credenciais por suas próprias credenciais. Coloque também o arquivo chamado "html_file.h" dentro da pasta de esboço do arduino. Todos os arquivos de cabeçalho usados neste projeto podem ser encontrados aqui

Características do código:

Ponto de acesso: Como é difícil programar todos os módulos com as credenciais em produção em massa, o módulo hospeda uma página da web em sua primeira inicialização para aceitar as credenciais do WiFi ao qual os módulos devem se conectar e armazena na EEPROM para uso posterior.

Depois que as credenciais são configuradas, o NodeMCU verifica a EEPROM em busca de credenciais e se conecta às credenciais WiFi presentes na EEPROM.

Depois de se conectar com sucesso ao WiFi, o NodeMCU começa a enviar os dados para o servidor a cada 'x' intervalo de tempo, os dados incluem dados meteorológicos, endereço MAC do módulo, versão do firmware, localização geográfica do dispositivo.

Atualização OTA: O módulo também verifica se há novas atualizações de firmware todos os dias em um horário específico especificado no código. Este recurso é útil porque não é possível para nenhum fabricante prosseguir e alterar o programa de um módulo individual caso haja alguma alteração a ser feita.

Watchdog Timer: Pelo menos deve haver uma maneira de se recuperar sem qualquer intervenção humana se ele travar ou travar. Isso pode ser feito usando o cronômetro do Watchdog. A maneira como isso funciona é: Existe uma sub-rotina de interrupção que é executada a cada segundo. O ISR incrementa o contador sempre que é executado e verifica se o contador atingiu a contagem máxima. Uma vez que o contador atinge o valor máximo, o módulo se reinicializa assumindo que ele travou. Em operação normal, o contador sempre é zerado antes de atingir a contagem máxima.

Etapa 2: Configurando o SQL Server

A configuração do SQL Server também é muito simples. Basta criar um banco de dados no servidor SQL e importar a configuração importando o arquivo denominado "database_structure.txt". Você pode encontrar o arquivo nesta etapa. Como as instruções não permitem o upload de arquivos ".sql", renomeei o arquivo para ".txt".

Nota: Renomeie o arquivo de ".txt" para ".sql".

Etapa 3: Configurando o Servidor de Arquivos

Configurar o servidor é realmente fácil se você possui um site e ele está hospedado online. Não vou passar por todo o procedimento de configuração e hospedagem de um site, pois está além do escopo deste tutorial. Mas você pode hospedá-lo em seu próprio PC como localhost para tentar o funcionamento dos arquivos.

Como o Instructable não permite o upload de arquivos PHP, renomeei os arquivos para ".txt".

Nota: Por favor, renomeie a extensão dos arquivos para ".php". Também não se esqueça de alterar as credenciais do arquivo "config.php".

Basta fazer o upload dos arquivos para o servidor e pronto.

Vou lhe dar uma breve informação sobre os arquivos PHP.

db_config.php:

Nesse arquivo, todas as credenciais necessárias para se conectar ao servidor SQL são armazenadas.

db_connect:

Neste arquivo, a classe necessária para conexão com o banco de dados está presente.

insert.php:

O NodeMCU chama este arquivo PHP para enviar os dados para o servidor usando o método GET. Este arquivo também é responsável por armazenar os mesmos dados no servidor SQL.

retrieve.php:

O usuário / cliente chama este PHP usando o método GET. O servidor calcula a distância entre o usuário e todos os módulos. Em seguida, os dados do módulo mais próximo são enviados como resposta ao cliente no formato JSON / XML de acordo com a preferência do cliente.

update.php:

Este arquivo PHP é chamado pelo módulo todos os dias em um horário específico para verificar se o módulo está executando a versão mais recente do firmware. Basta colocar o arquivo ".bin" mais recente no servidor de arquivos e especificar o diretório do arquivo na variável do arquivo.

Se esses muitos arquivos parecerem assustadores no início, incluí a documentação do usuário na próxima etapa.

Etapa 4: Documentação do usuário

Introdução:

A API do tempo fornece uma interface simples para solicitar os dados meteorológicos para locais na superfície da terra. Você solicita as informações meteorológicas para um par de latitude / longitude específico com o formato de saída especificado. O API retorna o índice de temperatura, umidade, pressão e qualidade do ar que foi registrado pela última vez pelo módulo mais próximo do local solicitado.

Antes de você começar:

Este documento se destina a desenvolvedores de sites e dispositivos móveis que desejam incluir informações sobre o clima em um aplicativo que está sendo desenvolvido. Ele apresenta o uso usando a API e material de referência sobre os parâmetros disponíveis.

Solicitações de dados meteorológicos:

As solicitações da API do tempo são construídas como uma string de URL. A API retorna dados meteorológicos para um ponto na Terra, especificados por um par de latitude / longitude. Observe que a precisão dos dados meteorológicos é diretamente proporcional à densidade dos módulos colocados em uma área.

Uma solicitação da API do tempo tem o seguinte formato:

example.com/retrieve.php?lat=25.96446&lon=53.9443&format=json

Onde o formato de saída (formato) pode ser um dos seguintes valores:

• JSON (recomendado), indica a saída em JavaScript Object Notation (JSON); ou
• XML, indica a saída em XML, envolvida no nó.

Parâmetros de solicitação:

Como é padrão em todos os URLs, os parâmetros são separados pelo caractere e comercial (&). A lista de parâmetros e seus valores possíveis são indicados a seguir.

Parâmetros exigidos:

• lat: Representando a latitude de um local a ser pesquisado. (por exemplo, lat = 19,56875)
• lon: Representando a longitude de um local a ser pesquisado. (por exemplo, lon = 72,97568)

Parâmetros opcionais:

formato: especifica o formato de saída da resposta dos dados meteorológicos. Pode ser JSON ou XML. O padrão é JSON. (por exemplo, format = json ou format = xml)

Respostas meteorológicas:

Para cada solicitação válida, o serviço de fuso horário retornará uma resposta no formato indicado no URL da solicitação. Cada resposta conterá os seguintes elementos:

• sucesso: um valor que indica o status da resposta.

  • 0: Negativo; indica que a solicitação foi malformada.
  • 1: Afirmativo; indica que a solicitação foi bem-sucedida.
• mensagem: uma string que indica o motivo da malformidade da solicitação. Disponível apenas quando o status é negativo.

• data: uma matriz com vários parâmetros meteorológicos.

  • temp: os dados de temperatura.
  • hum: os dados de presença de umidade.
  • pres: os dados de pressão absoluta.
  • aqi: o índice de qualidade do ar atual.

Os exemplos de resposta de ambos os formatos podem ser vistos nas imagens.

Etapa 5: configuração do módulo

Um ponto de acesso é criado e uma página da web é hospedada em um endereço IP (Padrão: 192.168.4.1) para receber as credenciais do gerenciador de dispositivo / usuário na primeira inicialização ou se o módulo não encontrar as credenciais já armazenadas no EEPROM.

O usuário precisa inserir o SSID e a senha aos quais deseja que o módulo se conecte. A latitude e longitude são preenchidas automaticamente se você permitir que o navegador acesse o local.

Depois de inserir todos os dados, clique no botão "ENVIAR", e a seguir todas as credenciais serão gravadas na EEPROM do módulo.

Esta etapa é muito importante, pois durante a produção em massa dos módulos, não é viável programar todos os módulos com seus dados de localização exata e credenciais WiFi. Além disso, não é aconselhável codificar as credenciais no programa, pois se precisarmos realocar o módulo para algum outro local ou quisermos alterar as credenciais WiFi, precisaremos reprogramar o módulo. Para evitar esse aborrecimento, a função de configuração inicial é implementada.

Etapa 6: agora é hora de contribuir com dados para a nuvem

Depois que todas as etapas anteriores forem concluídas, agora é hora de permitir que o módulo carregue os dados para o servidor. O upload começa automaticamente assim que você salva as credenciais.

Ele chama o "insert.php" como uma chamada de API passando todos os parâmetros a serem enviados no método GET.

O trecho de código abaixo mostra como os parâmetros são processados.

if (isset ($ _ GET ['temp']) && isset ($ _ GET ['hum']) && isset ($ _ GET ['pres']) && isset ($ _ GET ['aqi']) && isset ($ _ GET ['mac']) && isset ($ _ GET ['lat']) && isset ($ _ GET ['lon'])) 2. {3. // programa principal 4.}

Assim, todos os módulos começam a enviar os dados.

Nota: Reduza a frequência de upload no código se achar que o servidor está ficando sobrecarregado.

Etapa 7: Atualização Over the Air (OTA)

Depois que o módulo está totalmente configurado e começa a carregar os dados, ele verifica se há atualizações de firmware todos os dias em um horário específico mencionado no programa. Se encontrar algum, ele baixa e atualiza o arquivo binário nele. E se isso não acontecer, a operação normal de upload dos dados continua.

Para verificar se há uma nova atualização, o módulo chama o "update.php" enviando o endereço MAC em seu cabeçalho de solicitação. O servidor então verifica se aquele endereço MAC específico tem alguma nova atualização; em caso afirmativo, ele envia o arquivo binário do firmware mais recente em resposta.

Ele também verifica todos os cabeçalhos necessários para autenticação básica do módulo.

Etapa 8: Como o usuário / cliente pode acessar os dados …

É muito simples acessar os dados do servidor. Apenas chamando o "retrieve.php", obteremos os dados meteorológicos em resposta no formato JSON. Depois disso, é apenas uma questão de analisar os dados JSON para acessar os elementos individuais. Semelhante é a resposta XML. O usuário sempre pode especificar o formato de resposta preferido com o qual se sinta confortável para trabalhar. Se o usuário não especificar o formato, o formato padrão é JSON.

Uma solicitação de amostra é feita usando a ferramenta POSTMAN para verificar o funcionamento da API.

Um exemplo de análise de resposta JSON em javascript é mostrado no trecho de código abaixo.

var url = "https://example.com/retrieve.php?lat=19.044848&lon=72.8464373";function httpGet (theUrl) {var xmlHttp = new XMLHttpRequest (); xmlHttp.open ("GET", theUrl, false); // falso para solicitação síncrona xmlHttp.send (null); return xmlHttp.responseText; } var myVar = httpGet (url); var obj = JSON.parse (myVar); document.getElementById ("aqi"). innerHTML = obj.data [0].aqi; document.getElementById ("temperatura"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("temp"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("umidade"). innerHTML = Math.round (obj.data [0].hum) + "%"; document.getElementById ("pressão"). innerHTML = Math.round (obj.data [0].pres) + "mb";

O código-fonte da página HTML de exemplo que analisa a resposta JSON está disponível no final desta etapa.

Nota: Altere a extensão do arquivo para ".html".

Etapa 9: Limitações deste projeto

• O projeto usa GET para enviar os dados; mesmo não lidando com dados sensíveis, os dados podem ser facilmente manipulados, pois não possui nenhum mecanismo para verificar a autenticidade da fonte além da verificação dos cabeçalhos, que podem ser facilmente modificados e até mesmo um dispositivo normal pode ser falsificado para parecer um módulo meteorológico.
• Uma vez que o módulo depende unicamente e depende de outro ponto de acesso (WIFI) para enviar os dados que na maioria dos casos seriam de outras organizações. Se o ponto de acesso estiver inoperante por algum motivo, o módulo não será capaz de enviar dados.
• Mesmo que o projeto seja construído para aumentar a precisão do sistema existente, o sensor disponível no mercado é menos preciso do que o esperado, o que leva ao fracasso de seu objetivo principal.
• Durante o planejamento do projeto, planejei incluir um modo no qual o servidor calcula a média do valor dos dados com base na localização para correção de erros. Mas ao implementar esse recurso, percebi que eram necessárias algumas APIs de terceiros para traduzir as coordenadas para regiões geográficas.

Etapa 10: Outras melhorias que podem ser feitas neste projeto

• A precisão do módulo pode ser ainda mais aprimorada, adaptando especialmente os sensores para o propósito específico, em vez de usar o módulo genérico que está disponível no mercado.
• O módulo pode ser modificado para funcionar de forma ainda mais independente, usando um chip especial que se comunica sem fio com as torres de celular para enviar os dados, melhorando assim a tolerância a falhas.
• O painel solar e o sistema de bateria podem ser usados em conjunto com o modo de hibernação do ESP, melhorando assim a eficiência de energia e tornando-o mais independente de uma fonte de alimentação externa.
• O POST pode ser usado para enviar dados com algum mecanismo de autenticação, como o uso de códigos cíclicos para cada transmissão de dados.
• Em vez de NodeMCU, que é uma placa de prototipagem, podemos usar um microcontrolador personalizado na produção em massa que não apenas reduz o custo, mas também faz o melhor uso dos recursos do sistema.
• Em conjunto com a API de geolocalização do Google e conectando-se a qualquer WIFI aberto disponível, o módulo pode funcionar sem mesmo configurá-lo; pronto para transmitir dados de fábrica sem necessidade de configuração alguma.

Etapa 11: Algumas palavras para o público

Ei pessoal, eu percebi que este não é um tutorial para iniciantes, pois não mencionei todos os detalhes que precisam ser cobertos. E também este projeto é muito vasto para ser abordado em um Instructable. Mesmo assim, tentei o meu melhor para cobrir todos os aspectos importantes do projeto. Eu também sei que um vídeo mostrando o funcionamento do projeto teria sido ótimo, mas como este é meu primeiro instrutível e para ser honesto, esta é minha primeira publicação de algo semelhante a isso, eu estava muito nervoso por estar na frente de um Câmera.

Se vocês precisarem de ajuda para fazer este projeto ou algo semelhante a este, basta entrar em contato comigo em [email protected] ou você pode deixar um comentário como sempre. Vou tentar ajudar vocês da melhor maneira possível.

Obrigado!!