Sistema di monitoraggio meteo IoT intelligente distribuito utilizzando NodeMCU: 11 passaggi

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 09:59

Potreste essere tutti a conoscenza della tradizionale stazione meteorologica; ma vi siete mai chiesti come funziona effettivamente? Poiché la stazione meteorologica tradizionale è costosa e ingombrante, la densità di queste stazioni per unità di superficie è molto inferiore, il che contribuisce all'inesattezza dei dati. Ti spiego come: supponiamo che una stazione si trovi nel mezzo di una città e sia l'unica stazione che si trova nel raggio di "x" metri, può essere facilmente distorta se nelle vicinanze è presente un agente che causa l'inquinamento della stazione che mostra l'intera area di raggio 'x' metro come inquinata poiché quella singola stazione è responsabile della determinazione dei dati meteorologici dell'intera area.

Per ovviare a questo problema, è necessario aumentare la densità dei moduli, cosa possibile solo se i moduli sono più economici e occupano un ingombro ridotto rispetto a quello esistente.

Questo è il motivo per cui la mia soluzione proposta è la soluzione perfetta per questo problema, costa meno di $ 10 e si appoggia facilmente anche sul mio palmo.

Come funziona…

Ci sono 3 parti principali di questo progetto.

Lato dispositivo:

Il Dispositivo è un modulo IoT mostrato in figura che invia i dati meteo al server ogni 'x' intervallo di tempo. I dati includono i dati meteorologici effettivi, la posizione geografica del modulo; cioè le sue coordinate, il suo indirizzo MAC; per identificare in modo univoco il dispositivo, la versione del firmware su cui è attualmente in esecuzione. Il lato dispositivo comprende N-moduli distribuiti nell'area che contribuiscono attivamente ai dati al server.

Lato server:

Come suggerisce il nome, è il server centralizzato che gestisce diverse operazioni come ricevere i dati dai moduli e memorizzarli nel database, aggiornare il modulo con l'ultimo firmware se è in esecuzione su una versione precedente, inviare i dati meteo al cliente su richiesta.

Lato cliente/utente:

È l'utente finale che richiede i dati meteo dal server. Il client invia la posizione corrente e in base alla posizione, il server calcola la distanza tra il client e tutti i moduli e invia i dati meteorologici del modulo più vicino al client che è considerato accurato.

Forniture

• NodoMCU (ESP8266-12E)
• DHT11 (Sensore di umidità e temperatura)
• BMP180 (Sensore di pressione e temperatura)
• MQ-135 (Sensore indice di qualità dell'aria)
• Cavo USB (per caricare il programma)
• Alimentazione 5 volt
• Condensatori (Opzionale: da posizionare parallelamente alla linea elettrica)
• Arduino IDE (per eseguire il debug e caricare il programma)
• Applicazione POSTMAN (opzionale: per eseguire il debug dell'API)
• Un sito web (per ospitare il server PHP e MySQL)

Passaggio 1: saldare tutti i componenti e caricare il programma sul NodeMCU

Saldare tutti i componenti al NodeMCU come mostrato nello schema elettrico su una scheda perf. Inoltre, saldare un condensatore in parallelo alle linee elettriche poiché l'alimentazione aumenta durante la trasmissione e la ricezione attiva dei dati.

Una volta terminato il lavoro di saldatura, caricare il codice fornito nel file "code.c".

Nota: non dimenticare di sostituire le credenziali con le tue credenziali. Posiziona anche il file denominato "html_file.h" all'interno della cartella sketch di arduino. Tutti i file di intestazione utilizzati in questo progetto possono essere trovati qui

Caratteristiche del codice:

Access Point: Poiché è difficile programmare ogni modulo con le credenziali nella produzione di massa, il modulo ospita una pagina Web al suo primo avvio per accettare le credenziali del WiFi a cui i moduli devono connettersi e memorizza nella EEPROM per un uso successivo.

Una volta configurate le credenziali, il NodeMCU controlla la EEPROM per le credenziali e si connette alle credenziali WiFi presenti nella EEPROM.

Dopo essersi connesso con successo al WiFi, il NodeMCU inizia a caricare i dati sul server ogni 'x' intervallo di tempo, i dati includono i dati meteo, l'indirizzo MAC del modulo, la versione del firmware, la posizione geografica del dispositivo.

Aggiornamento OTA: il modulo verifica anche la presenza di nuovi aggiornamenti del firmware ogni giorno a un'ora specifica specificata nel codice. Questa funzione è utile in quanto non è possibile per nessun produttore andare avanti e modificare il programma di un singolo modulo nel caso ci siano delle modifiche da apportare.

Watchdog Timer: Atlast ci deve essere un modo per riprendersi senza alcun intervento umano se si blocca o si blocca. Ciò può essere ottenuto utilizzando il timer Watchdog. Il modo in cui funziona è: c'è una subroutine di interruzione che viene eseguita ogni secondo. L'ISR incrementa il contatore ogni volta che viene eseguito e controlla se il contatore ha raggiunto il conteggio massimo. Una volta che il contatore raggiunge il valore massimo, il modulo si azzera supponendo che sia andato in crash. Durante il normale funzionamento, il contatore viene sempre azzerato prima di raggiungere il conteggio massimo.

Passaggio 2: configurazione di SQL Server

Anche l'installazione di SQL Server è molto semplice. Basta creare un database nel server SQL e importare l'impostazione importando il file denominato "database_structure.txt". Puoi trovare il file in questo passaggio. Poiché l'istruzione non consente di caricare file ".sql", ho rinominato il file in ".txt".

Nota: rinominare il file da ".txt" a ".sql".

Passaggio 3: configurazione del file server

La configurazione del server è davvero semplice se possiedi un sito web ed è ospitato online. Non esaminerò l'intera procedura di creazione di un sito Web e di ospitarlo poiché va oltre lo scopo di questo tutorial. Ma puoi ospitarlo nel tuo pc come localhost per provare il funzionamento dei file.

Poiché Instructable non consente di caricare file PHP, ho rinominato i file in ".txt".

Nota: rinominare l'estensione dei file in ".php". Inoltre, non dimenticare di modificare le credenziali del file "config.php".

Basta caricare i file sul server e sei a posto.

Ti darò brevi informazioni sui file PHP.

db_config.php:

In questo file sono memorizzate tutte le credenziali necessarie per connettersi al server SQL.

db_connect:

In questo file è presente la classe necessaria per la connessione al database.

inserisci.php:

Il NodeMCU chiama questo file PHP per caricare i dati sul server utilizzando il metodo GET. Questo file è anche responsabile dell'archiviazione degli stessi dati sul server SQL.

recupera.php:

L'Utente/Client chiama questo PHP usando il metodo GET. Il server calcola la distanza tra l'utente e tutti i moduli. Quindi i dati del modulo più vicino vengono inviati come risposta al client in formato JSON/XML come preferito dal client.

update.php:

Questo file PHP viene chiamato dal modulo ogni giorno a un'ora specifica per verificare se il modulo esegue l'ultima versione del firmware. Basta inserire l'ultimo file ".bin" nel file server e specificare la directory del file nella variabile del file.

Se all'inizio questi molti file sembrano scoraggianti, ho incluso la documentazione per l'utente nel passaggio successivo.

Passaggio 4: documentazione per l'utente

Introduzione:

L'API Weather fornisce una semplice interfaccia per richiedere i dati meteorologici per le località sulla superficie della terra. Si richiedono le informazioni meteo per una specifica coppia latitudine/longitudine con il formato di output specificato. L'API restituisce la temperatura, l'umidità, la pressione e l'indice di qualità dell'aria che è stato registrato l'ultima volta dal modulo più vicino dalla posizione richiesta.

Prima di iniziare:

Questo documento è destinato agli sviluppatori di siti Web e dispositivi mobili che desiderano includere informazioni meteorologiche su un'applicazione in fase di sviluppo. Introduce l'utilizzo tramite API e materiale di riferimento sui parametri disponibili.

Richieste di dati meteorologici:

Le richieste dell'API meteo sono costruite come una stringa URL. L'API restituisce i dati meteorologici per un punto sulla terra, specificato da una coppia latitudine/longitudine. Si noti che l'accuratezza dei dati meteorologici è direttamente proporzionale alla densità dei moduli posizionati in un'area.

Una richiesta all'API Weather ha il seguente formato:

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

Dove il formato di output (formato) può essere uno dei seguenti valori:

• JSON (consigliato), indica l'output in JavaScript Object Notation (JSON); o
• XML, indica l'output in XML, racchiuso all'interno del nodo.

Parametri di richiesta:

Come è standard in tutti gli URL, i parametri sono separati utilizzando il carattere e commerciale (&). Di seguito è riportato l'elenco dei parametri e dei loro possibili valori.

Parametri richiesti:

• lat: Rappresenta la latitudine di una posizione da cercare. (es. lat=19.56875)
• lon: Rappresenta la longitudine di una posizione da cercare. (es. lon=72.97568)

Parametri opzionali:

format: specifica il formato di output della risposta dei dati meteo. Può essere JSON o XML. L'impostazione predefinita è JSON. (es. formato=json o formato=xml)

Risposte meteo:

Per ogni richiesta valida, il servizio del fuso orario restituirà una risposta nel formato indicato nell'URL della richiesta. Ogni risposta conterrà i seguenti elementi:

• success: un valore che indica lo stato della risposta.

  • 0: negativo; indica che la richiesta non era valida.
  • 1: affermativo; indica che la richiesta è andata a buon fine.
• messaggio: una stringa che indica il motivo della non conformità della richiesta. Disponibile solo quando lo stato è negativo.

• data: un array con più parametri meteorologici.

  • temp: i dati della temperatura.
  • ronzio: i dati di presenza di umidità.
  • pres: i dati di pressione assoluta.
  • aqi: l'attuale indice di qualità dell'aria.

La risposta di esempio di entrambi i formati può essere vista nelle immagini.

Passaggio 5: configurazione del modulo

Viene creato un Access-point e viene ospitata una pagina web su un indirizzo IP (Default:192.168.4.1) per ricevere le credenziali dal gestore/utente del dispositivo al primo avvio o se il modulo non trova le credenziali già memorizzate nel EEPROM.

L'utente deve inserire l'SSID e la password a cui l'utente desidera che il modulo si connetta. La latitudine e la longitudine vengono compilate automaticamente se si consente al browser di accedere alla posizione.

Una volta inseriti tutti i dettagli, cliccare sul pulsante "INVIA", quindi tutte le credenziali vengono scritte nella EEPROM del modulo.

Questo passaggio è molto cruciale poiché durante la produzione di massa dei moduli, non è possibile programmare tutti i moduli con i dati di posizione esatti e le credenziali WiFi. Inoltre, non è consigliabile codificare le credenziali nel programma poiché se è necessario spostare il modulo in un'altra posizione o si desidera modificare le credenziali WiFi, sarà necessario riprogrammare il modulo. Per evitare questo problema, viene implementata la funzione di configurazione iniziale.

Passaggio 6: ora è il momento di fornire dati al cloud

Dopo che tutti i passaggi precedenti sono stati completati, ora è il momento di consentire al modulo di caricare i dati sul server. Il caricamento inizia automaticamente una volta salvate le credenziali.

Chiama "insert.php" come una chiamata API con il passaggio di tutti i parametri da inviare nel metodo GET.

Il frammento di codice seguente mostra come vengono elaborati i parametri.

if (isset($_GET['temp']) && isset($_GET['hum']) && isset($_GET['pres']) && isset($_GET['aqi']) && isset($_GET ['mac']) && isset($_GET['lat']) && isset($_GET['lon '])) 2. { 3. // programma principale 4. }

In questo modo tutti i moduli iniziano a caricare i dati.

Nota: Riduci la frequenza di caricamento nel codice se ritieni che il server sia sovraccarico.

Passaggio 7: aggiornamento via etere (OTA)

Dopo che il modulo è stato configurato e ha iniziato a caricare i dati, controlla gli aggiornamenti del firmware ogni giorno a un'ora specifica indicata nel programma. Se ne trova, scarica e fa lampeggiare il file binario al suo interno. E in caso contrario, la normale operazione di caricamento dei dati continua.

Per verificare la presenza di un nuovo aggiornamento, il modulo chiama "update.php" inviando l'indirizzo MAC nell'intestazione della richiesta. Il server quindi verifica se quell'indirizzo MAC specifico ha un nuovo aggiornamento, in caso affermativo, invia in risposta il file binario dell'ultimo firmware.

Inoltre, controlla tutte le intestazioni necessarie richieste per l'autenticazione di base del modulo.

Passaggio 8: come l'utente/cliente può accedere ai dati…

È abbastanza semplice accedere ai dati dal server. Semplicemente chiamando "recupera.php", otterremo i dati meteo in risposta in formato JSON. Dopodiché, si tratta solo di analizzare i dati JSON per accedere ai singoli elementi. Simile è con la risposta XML. L'utente può sempre specificare il formato di risposta preferito con cui l'utente è a suo agio a lavorare. Se l'utente non specifica il formato, il formato predefinito è JSON.

Viene effettuata una richiesta di esempio utilizzando lo strumento POSTMAN per verificare il funzionamento dell'API.

Un esempio di analisi della risposta JSON in javascript è mostrato nel frammento di codice di seguito.

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); // false per la richiesta sincrona 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("temperature").innerHTML = Math.round(obj.data[0].temp) + "°C"; document.getElementById("temp").innerHTML = Math.round(obj.data[0].temp) + "°C"; document.getElementById("umidità").innerHTML = Math.round(obj.data[0].hum) + "%"; document.getElementById("pressione").innerHTML = Math.round(obj.data[0].pres) + "mb";

Il codice sorgente della pagina HTML di esempio che analizza la risposta JSON è disponibile alla fine di questo passaggio.

Nota: modificare l'estensione del file in ".html".

Passaggio 9: limiti di questo progetto

• Il progetto utilizza GET per inviare i dati; anche se non si tratta di dati sensibili, i dati possono essere facilmente manipolati poiché non ha alcun meccanismo per verificare l'autenticità della fonte a parte il controllo delle intestazioni, che possono essere facilmente modificate e anche un normale dispositivo può essere falsificato per sembrare un modulo meteo.
• Poiché il modulo si basa esclusivamente e dipende da altri punti di accesso (WIFI) per inviare i dati che nella maggior parte dei casi sarebbero di altre organizzazioni. Se per qualche motivo il punto di accesso non fosse in servizio, il modulo non sarebbe in grado di inviare dati.
• Anche se il progetto è costruito per aumentare la precisione del sistema esistente, il sensore disponibile sul mercato è meno accurato del previsto, il che di conseguenza porta a fallire il suo scopo principale.
• Durante la pianificazione del progetto, ho pianificato di includere una modalità in cui il server calcola la media del valore dei dati in base alla posizione per la correzione degli errori. Ma dopo aver implementato questa funzione, mi sono reso conto che erano necessarie alcune API di terze parti per tradurre le coordinate in regioni geografiche.

Passaggio 10: ulteriori miglioramenti che possono essere apportati a questo progetto

• La precisione del modulo può essere ulteriormente migliorata adattando appositamente i sensori per lo scopo specifico invece di utilizzare il modulo generico disponibile sul mercato.
• Il modulo può essere modificato per funzionare in modo ancora più indipendente utilizzando uno speciale chip che comunica in modalità wireless con Cell-tower per inviare i dati migliorando così la tolleranza ai guasti.
• Il pannello solare e il sistema di batterie possono essere utilizzati in combinazione con la modalità deep-sleep dell'ESP migliorando così l'efficienza energetica e rendendolo più indipendente da un'alimentazione esterna.
• Il POST può essere utilizzato per inviare dati con un meccanismo di autenticazione come l'utilizzo di codici ciclici per ogni trasmissione di dati.
• Invece di NodeMCU, che è una scheda di prototipazione, possiamo utilizzare un microcontrollore personalizzato nella produzione di massa che non solo riduce i costi ma fa anche il miglior uso delle risorse di sistema.
• In combinazione con l'API di geolocalizzazione di Google e collegandosi a qualsiasi WIFI aperto disponibile, il modulo può funzionare senza nemmeno configurarlo; pronto a trasmettere i dati fuori dalla fabbrica senza bisogno di alcuna configurazione.

Passaggio 11: poche parole per il pubblico

Ehi ragazzi, mi rendo conto che questo non è affatto un tutorial adatto ai principianti poiché non ho menzionato ogni singolo dettaglio che deve essere coperto. E anche questo progetto è davvero vasto da coprire in un Instructable. Tuttavia, ho fatto del mio meglio per coprire ogni aspetto importante del progetto. So anche che un video che mostrasse il funzionamento del progetto sarebbe stato davvero fantastico, ma poiché questo è il mio primo istruttore e, ad essere onesti, questa è la mia prima pubblicazione di qualcosa di simile, ero piuttosto nervoso per essere di fronte a un telecamera.

Se avete bisogno di aiuto per realizzare questo progetto o qualcosa di simile, contattatemi a [email protected] o potete lasciare un commento come sempre. Cercherò di aiutarvi ragazzi al meglio delle mie capacità.

Grazie!!