Sistema de monitorització meteorològica de l’IoT distribuït de manera intel·ligent mitjançant NodeMCU: 11 passos

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:10

És possible que tots sigueu conscients de l’estació meteorològica tradicional; però us heu preguntat mai com funciona realment? Atès que l'estació meteorològica tradicional és costosa i voluminosa, la densitat d'aquestes estacions per unitat de superfície és molt menor, cosa que contribueix a la inexactitud de les dades. T’explicaré com: suposem que una estació es troba al centre d’una ciutat i que és l’única estació que es troba en un radi de “metres”, es pot esbiaixar fàcilment si hi ha algun agent causant de la contaminació a les rodalies de l'estació que mostra tota la superfície de radi de "x" metres contaminada ja que aquesta única estació és responsable de determinar les dades meteorològiques de tota l'àrea.

Per superar aquest problema, cal augmentar la densitat dels mòduls, cosa que només és possible si els mòduls són més econòmics i tenen una petjada menor que l’actual.

Aquest és el motiu pel qual la meva solució proposada és la solució perfecta per a aquest problema, costa menys de 10 dòlars i també descansa fàcilment sobre el meu palmell.

Com funciona…

Hi ha 3 parts principals d’aquest projecte.

Part del dispositiu:

El dispositiu és un mòdul IoT que es mostra a la imatge que envia les dades meteorològiques al servidor cada interval de temps 'x'. Les dades inclouen les dades meteorològiques reals, la ubicació geogràfica del mòdul; és a dir, les seves coordenades, la seva adreça MAC; per identificar de manera única el dispositiu, la versió del firmware en què s’executa actualment. El costat del dispositiu comprèn N-mòduls distribuïts per l'àrea que aporten dades activament al servidor.

Al costat del servidor:

Com el seu nom indica, és el servidor centralitzat que gestiona diverses operacions com rebre les dades dels mòduls i emmagatzemar-les a la base de dades, actualitzar el mòdul amb el firmware més recent si s’executa en una versió anterior, enviar les dades meteorològiques a client a petició.

Client / usuari:

És l’usuari final qui sol·licita les dades meteorològiques al servidor. El client envia la ubicació actual i, en funció de la ubicació, el servidor calcula la distància entre el client i tots els mòduls i envia al client les dades meteorològiques del mòdul més proper, que es consideren exactes.

Subministraments

• NodeMCU (ESP8266-12E)
• DHT11 (sensor d'humitat i temperatura)
• BMP180 (sensor de pressió i temperatura)
• MQ-135 (sensor d'índex de qualitat de l'aire)
• Cable USB (per carregar el programa)
• Alimentació de 5 volts
• Condensadors (opcional: es col·loquen paral·lels a la línia elèctrica)
• Arduino IDE (per depurar i penjar el programa)
• Aplicació POSTMAN (opcional: per depurar l'API)
• Un lloc web (per allotjar el servidor PHP i MySQL)

Pas 1: soldeu tots els components i pengeu el programa al NodeMCU

Soldeu tots els components al NodeMCU tal com es mostra al diagrama del circuit en una placa perf. A més, soldeu un condensador en paral·lel a les línies elèctriques, ja que la potència augmenta durant la transmissió i recepció de dades activament.

Un cop acabat el treball de soldadura, pengeu el codi proporcionat al fitxer "code.c".

Nota: no oblideu substituir les credencials per les vostres pròpies. Col·loqueu també el fitxer anomenat "html_file.h" dins de la carpeta d'esbossos arduino. Tots els fitxers de capçalera utilitzats en aquest projecte es poden trobar aquí

Característiques del codi:

Punt d'accés: atès que és difícil programar tots els mòduls amb les credencials en producció massiva, el mòdul allotja una pàgina web en el seu primer arrencada per acceptar les credencials del WiFi al qual els mòduls s'han de connectar i emmagatzema a l'EEPROM per a un ús posterior.

Un cop configurades les credencials, el NodeMCU comprova les credencials de l'EEPROM i es connecta a les credencials WiFi presents a l'EEPROM.

Després de connectar-se amb èxit a la xarxa WiFi, el NodeMCU comença a carregar les dades al servidor cada interval de temps 'x', les dades inclouen dades meteorològiques, adreça MAC del mòdul, versió del firmware, ubicació geogràfica del dispositiu.

Actualització OTA: el mòdul també comprova si hi ha actualització de firmware nova cada dia a una hora específica especificada al codi. Aquesta característica és útil ja que no és possible que cap fabricant pugui continuar i canviar el programa d'un mòdul individual en cas que hi hagi canvis.

Temporitzador del gos de vigilància: Atlast ha d’haver una manera de recuperar-se sense cap intervenció humana si s’enganxa o s’estavella. Això es pot aconseguir utilitzant el temporitzador Watchdog. La manera com funciona és: hi ha una subrutina d'interrupció que s'executa cada segon. La ISR augmenta el comptador cada vegada que s’executa i comprova si el comptador ha assolit el recompte màxim. Un cop el comptador assoleix el valor màxim, el mòdul es restableix suposant que s'ha bloquejat. En funcionament normal, el comptador sempre es restableix abans d’assolir el recompte màxim.

Pas 2: Configuració de l'SQL Server

La configuració de SQL Server també és molt senzilla. Simplement creeu una base de dades al servidor SQL i importeu la configuració important el fitxer anomenat "database_structure.txt". Podeu trobar el fitxer en aquest pas. Com que la instrucció no permet carregar fitxers ".sql", he canviat el nom del fitxer per ".txt".

Nota: canvieu el nom del fitxer de ".txt" a ".sql".

Pas 3: Configuració del servidor de fitxers

Configurar el servidor és molt fàcil si teniu un lloc web i s’allotja en línia. No seguiré tot el procediment de configuració i allotjament d'un lloc web, ja que està fora de l'abast d'aquest tutorial. Però podeu allotjar-lo al vostre propi ordinador com a localhost per provar el funcionament dels fitxers.

Com que l'Instruible no permet carregar fitxers PHP, he canviat el nom dels fitxers per ".txt".

Nota: canvieu el nom de l'extensió dels fitxers per ".php". Tampoc us oblideu de canviar les credencials del fitxer "config.php".

Només cal que pengeu els fitxers al servidor i ja podreu començar.

Us donaré una breu informació sobre els fitxers PHP.

db_config.php:

En aquest fitxer s’emmagatzemen totes les credencials necessàries per connectar-se al servidor SQL.

db_connect:

En aquest fitxer hi ha la classe necessària per a la connexió a la base de dades.

insert.php:

El NodeMCU crida aquest fitxer PHP per carregar les dades al servidor mitjançant el mètode GET. Aquest fitxer també és responsable d’emmagatzemar les mateixes dades al servidor SQL.

retrieve.php:

L’usuari / client crida a aquest PHP mitjançant el mètode GET. El servidor calcula la distància entre l'usuari i tots els mòduls. A continuació, les dades del mòdul més proper s’envien com a resposta al client en format JSON / XML, segons el client ho prefereixi.

update.php:

El mòdul crida aquest fitxer PHP cada dia a una hora específica per comprovar si el mòdul està executant la versió més recent del firmware. Simplement col·loqueu el fitxer ".bin" més recent al servidor de fitxers i especifiqueu el directori del fitxer a la variable del fitxer.

Si aquests primers fitxers semblen descoratjadors al principi, he inclòs la documentació de l’usuari al següent pas.

Pas 4: documentació de l'usuari

Introducció:

L’API Weather proporciona una interfície senzilla per sol·licitar les dades meteorològiques de les ubicacions de la superfície terrestre. Sol·liciteu la informació meteorològica per a un parell de latitud / longitud específic amb el format de sortida especificat. L'API retorna l'índex de temperatura, humitat, pressió i qualitat de l'aire registrat per última vegada pel mòdul més proper des de la ubicació sol·licitada.

Abans que comencis:

Aquest document està destinat a desenvolupadors de llocs web i mòbils que vulguin incloure informació meteorològica en una aplicació que s'està desenvolupant. Introdueix l’ús mitjançant l’API i material de referència sobre els paràmetres disponibles.

Sol·licituds de dades meteorològiques:

Les sol·licituds de l'API meteorològica es construeixen com una cadena d'URL. L'API retorna les dades meteorològiques d'un punt de la terra, especificades per un parell de latitud / longitud. Tingueu en compte que la precisió de les dades meteorològiques és directament proporcional a la densitat dels mòduls col·locats en una àrea.

Una sol·licitud de l'API Meteorològica adopta la forma següent:

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

Quan el format de sortida (format) pot ser qualsevol dels valors següents:

• JSON (recomanat), indica la sortida a JavaScript Object Notation (JSON); o bé
• XML, indica la sortida en XML, embolicada dins del node.

Paràmetres de sol·licitud:

Com és estàndard en tots els URL, els paràmetres es separen mitjançant el caràcter ampersand (&). A continuació es denota la llista de paràmetres i els seus possibles valors.

Paràmetres obligatoris:

• lat: Representa la latitud d’una ubicació a cercar. (per exemple, lat = 19.56875)
• lon: Representa la longitud d'una ubicació per cercar. (per exemple, lon = 72.97568)

Paràmetres opcionals:

format: especifica el format de sortida de resposta de les dades meteorològiques. Pot ser JSON o XML. El valor per defecte és JSON. (per exemple, format = json o format = xml)

Respostes meteorològiques:

Per a cada sol·licitud vàlida, el servei de zona horària retornarà una resposta en el format indicat a l'URL de sol·licitud. Cada resposta contindrà els elements següents:

• èxit: un valor que indica l'estat de la resposta.

  • 0: negatiu; indica que la sol·licitud s'ha format malament.
  • 1: afirmatiu; indica que la sol·licitud ha estat satisfactòria.
• missatge: una cadena que indica el motiu del malformat de la sol·licitud. Només disponible quan l'estat és negatiu.

• dades: una matriu amb múltiples paràmetres meteorològics.

  • temp: les dades de temperatura.
  • zumbit: dades de presència d'humitat.
  • pres: les dades de pressió absoluta.
  • aqi: l'índex actual de qualitat de l'aire.

Els exemples de resposta d'ambdós formats es poden veure a les imatges.

Pas 5: Configuració del mòdul

Es crea un punt d’accés i s’allotja una pàgina web en una adreça IP (per defecte: 192.168.4.1) per rebre les credencials del gestor / usuari del dispositiu en el primer moment d’arrencada o si el mòdul no troba les credencials ja emmagatzemades a EEPROM.

L’usuari ha d’introduir el SSID i la contrasenya a què vol que es connecti el mòdul. La latitud i la longitud s'omplen automàticament si permeteu que el navegador accedeixi a la ubicació.

Un cop introduïdes totes les dades, feu clic al botó "ENVIAR" i, a continuació, totes les credencials s'escriuran a la EEPROM del mòdul.

Aquest pas és molt crucial ja que, mentre es produeixen en massa els mòduls, no és factible programar tots els mòduls amb les seves dades d’ubicació exactes i les seves credencials WiFi. A més, no és recomanable codificar de manera dura les credencials del programa, ja que si necessitem traslladar el mòdul a alguna altra ubicació o volem canviar les credencials WiFi, haurem de reprogramar el mòdul. Per evitar aquesta molèstia, s’implementa la funció de configuració inicial.

Pas 6: ara és hora de contribuir amb dades al núvol

Després de completar tots els passos anteriors, és hora que permeti al mòdul carregar les dades al servidor. Comença a penjar-se automàticament un cop hàgiu desat les credencials.

Crida a "insert.php" com una trucada d'API amb la transmissió de tots els paràmetres a enviar en el mètode GET.

El fragment de codi següent mostra com es processen els paràmetres.

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.}

Així tots els mòduls comencen a carregar les dades.

Nota: Baixeu la freqüència de càrrega al codi si creieu que el servidor està sobrecarregat.

Pas 7: actualització per transmissió directa (OTA)

Després de configurar el mòdul i començar a carregar les dades, comprova si hi ha actualitzacions de firmware cada dia a l’hora específica esmentada al programa. Si en troba algun, descarrega i llança el fitxer binari. I si no ho fa, es continua la operació normal de càrrega de les dades.

Per comprovar si hi ha una nova actualització, el mòdul crida a "update.php" enviant l'adreça MAC a la capçalera de la sol·licitud. Aleshores, el servidor comprova si aquesta adreça MAC específica té alguna actualització nova, si és així, envia el fitxer binari del darrer firmware en resposta.

També comprova si hi ha totes les capçaleres necessàries per a l'autenticació bàsica del mòdul.

Pas 8: Com pot accedir l'usuari / client a les dades …

És bastant senzill accedir a les dades des del servidor. Només trucant a "retrieve.php", obtindrem les dades meteorològiques en resposta en format JSON. Després d’això, només es tracta d’analitzar les dades JSON per accedir als elements individuals. Similar és amb la resposta XML. L'usuari sempre pot especificar el format de resposta preferit amb el qual l'usuari és còmode de treballar. Si l'usuari no especifica el format, el format per defecte és JSON.

Es fa una sol·licitud de mostra mitjançant l'eina POSTMAN per comprovar el funcionament de l'API.

Un exemple d’anàlisi de la resposta JSON a javascript es mostra al fragment de codi següent.

var url = "https://example.com/retrieve.php?lat=19.044848&lon=72.8464373";funció httpGet (theUrl) {var xmlHttp = new XMLHttpRequest (); xmlHttp.open ("GET", theUrl, false); // fals per a la sol·licitud síncrona xmlHttp.send (nul); retorna 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 ("humitat"). innerHTML = Math.round (obj.data [0].hum) + "%"; document.getElementById ("pressió"). innerHTML = Math.round (obj.data [0].pres) + "mb";

El codi font de la pàgina HTML d'exemple que analitza la resposta JSON està disponible al final d'aquest pas.

Nota: canvieu l'extensió del fitxer a ".html".

Pas 9: limitacions d’aquest projecte

• El projecte utilitza GET per enviar les dades; tot i que no tracta de dades sensibles, es poden manipular fàcilment, ja que no té cap mecanisme per comprovar l'autenticitat de la font a part de comprovar les capçaleres, que es poden modificar fàcilment i fins i tot es pot falsificar un dispositiu normal per semblar un mòdul meteorològic.
• Atès que el mòdul només depèn i depèn d'altres punts d'accés (WIFI) per enviar les dades que en la majoria dels casos serien d'altres organitzacions. Si el punt d’accés no funciona, per algun motiu, el mòdul no seria capaç d’enviar dades.
• Tot i que el projecte està construït per augmentar la precisió del sistema existent, el sensor disponible al mercat és menys precís del que s’esperava, la qual cosa comporta un error en el seu propòsit principal.
• En planificar el projecte, tenia previst incloure un mode en què el servidor realitzés una mitjana del valor de les dades en funció de la ubicació per a la correcció d’errors. Però en implementar aquesta funció, em vaig adonar que necessitaven algunes API de tercers per traduir les coordenades a regions geogràfiques.

Pas 10: Millores addicionals que es poden fer en aquest projecte

• La precisió del mòdul es pot millorar encara més a mida dels sensors per al propòsit específic en lloc d’utilitzar el mòdul genèric disponible al mercat.
• El mòdul es pot modificar perquè funcioni encara més independentment mitjançant un xip especial que es comunica sense fils amb les torres cel·lulars per enviar les dades, millorant així la tolerància a fallades.
• El panell solar i el sistema de bateries es poden utilitzar conjuntament amb el mode de son profund de l'ESP, millorant així l'eficiència energètica i fent-lo més independent d'una font d'alimentació externa.
• POST es pot utilitzar per enviar dades amb algun mecanisme d'autenticació, com ara l'ús de codis cíclics per a cada transmissió de dades.
• En lloc de NodeMCU, que és una placa de prototipatge, podem utilitzar un microcontrolador personalitzat en producció massiva que no només redueix el cost, sinó que també fa un millor ús dels recursos del sistema.
• Juntament amb l'API de geolocalització de Google i connectant-se a qualsevol WIFI obert disponible, el mòdul pot funcionar sense configurar-lo; llest per transmetre dades de fàbrica sense necessitat de configuració.

Pas 11: poques paraules per al públic

Hola nois, m'adono que no és un tutorial per a principiants, ja que no he esmentat tots els detalls que cal cobrir. I, a més, aquest projecte és realment ampli per ser tractat en un instructable. Tot i això, vaig fer tot el possible per cobrir tots els aspectes importants del projecte. També sé que un vídeo que mostri el funcionament del projecte hauria estat realment fantàstic, però com que és el meu primer instructiu i, per ser sincer, aquesta és la meva primera publicació de res semblant, estava molt nerviós per estar davant d’un càmera.

Si necessiteu ajuda per fer aquest projecte o qualsevol cosa similar a aquest, contacteu amb mi a [email protected] o podeu deixar un comentari com sempre. Intentaré ajudar-los, al màxim de les meves possibilitats.

Gràcies!!