Smart distribuert IoT værovervåkingssystem ved hjelp av NodeMCU: 11 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:20

Du er kanskje alle klar over den tradisjonelle værstasjonen; men har du noen gang lurt på hvordan det egentlig fungerer? Siden den tradisjonelle værstasjonen er kostbar og omfangsrik, er tettheten til disse stasjonene per arealenhet svært mindre, noe som bidrar til unøyaktigheten av dataene. Jeg skal forklare deg hvordan: Anta at en stasjon ligger midt i en by, og det er den eneste stasjonen som ligger i en radius på x meter, den kan lett være forutinntatt hvis det er forurensningsfremkallende middel i nærheten av stasjonen som viser hele x -meters radiusområdet som forurenset siden den ene stasjonen er ansvarlig for å bestemme værdataene for hele området.

For å overvinne dette problemet må tettheten til modulene økes, noe som bare er mulig hvis modulene er billigere og tar et mindre fotavtrykk enn det eksisterende.

Dette er grunnen til at den foreslåtte løsningen min er den perfekte løsningen for dette problemet. Den koster mindre enn $ 10 og hviler også lett på håndflaten min.

Hvordan det fungerer…

Det er 3 hoveddeler av dette prosjektet.

Enhetsside:

Enheten er en IoT -modul vist på bildet som sender værdataene til serveren hvert x -intervall. Dataene inkluderer de faktiske værdataene, modulens geografiske plassering; dvs. koordinatene, MAC -adressen; for å identifisere enheten på en unik måte, fastvareversjonen den kjører på. Enhetssiden består av N-moduler fordelt over området som aktivt bidrar med data til serveren.

Server-side:

Som navnet antyder, er det den sentraliserte serveren som håndterer flere operasjoner som å motta data fra modulene og lagre dem i databasen, oppdatere modulen med den nyeste fastvaren hvis den kjører på en eldre versjon, sende værdataene til klient på forespørsel.

Kunde/bruker side:

Det er sluttbrukeren som ber om værdata fra serveren. Klienten sender gjeldende plassering og basert på plasseringen beregner serveren avstanden mellom klienten og alle modulene og sender værdataene til den nærmeste modulen til klienten som anses som nøyaktig.

Rekvisita

• NodeMCU (ESP8266-12E)
• DHT11 (fuktighets- og temperatursensor)
• BMP180 (Trykk- og temperatursensor)
• MQ-135 (luftkvalitetsindekssensor)
• USB -kabel (for å laste opp programmet)
• 5 volt strømforsyning
• Kondensatorer (valgfritt: plasseres parallelt med kraftlinjen)
• Arduino IDE (For feilsøking og opplasting av programmet)
• POSTMAN -applikasjon (valgfritt: for å feilsøke API)
• Et nettsted (for å være vert for PHP- og MySQL -serveren)

Trinn 1: Lodd alle komponentene og last opp programmet til NodeMCU

Lodd alle komponentene til NodeMCU som vist i kretsdiagrammet på et perf -bord. Lodd også en kondensator parallelt med kraftledningene siden strømmen stiger under aktiv overføring og mottak av data.

Når loddearbeidet er fullført, laster du opp koden i filen "code.c".

Merk: Ikke glem å erstatte legitimasjonen med din egen legitimasjon. Plasser også filen med navnet "html_file.h" inne i arduino sketch -mappen. Alle topptekstfilene som brukes i dette prosjektet finner du her

Funksjoner i koden:

Tilgangspunkt: Siden det er vanskelig å programmere hver modul med legitimasjon i masseproduksjon, er modulen vert for en nettside på den første oppstarten for å godta legitimasjonen til WiFi -modulen som modulene må koble til og lagre i EEPROM for senere bruk.

Når legitimasjonen er konfigurert, sjekker NodeMCU EEPROM for legitimasjon og kobler seg til WiFi -legitimasjonen som er tilstede i EEPROM.

Etter vellykket tilkobling til WiFi begynner NodeMCU å laste opp dataene til serveren hvert x -intervall, dataene inkluderer værdata, modulens MAC -adresse, fastvareversjon, enhetens geografiske plassering.

OTA -oppdatering: Modulen ser også etter ny fastvareoppdatering hver dag på et bestemt tidspunkt spesifisert i koden. Denne funksjonen er nyttig siden det ikke er mulig for noen produsent å fortsette og endre programmet til en individuell modul i tilfelle det er noen endringer som må gjøres.

Watchdog Timer: Atlast det må være en måte å gjenopprette seg selv uten menneskelig inngrep hvis den blir sittende fast eller krasjer. Dette kan oppnås ved å bruke Watchdog -timeren. Måten dette fungerer på er: Det er en interrupt-rutine som går hvert sekund. ISR øker telleren hver gang den utfører og sjekker om telleren har nådd maksimumsantallet. Når telleren når maksimalverdi, tilbakestiller modulen seg selv forutsatt at den har krasjet. Ved normal drift blir telleren alltid tilbakestilt før den når maksimumsantallet.

Trinn 2: Konfigurering av SQL Server

Oppsett av SQL Server er også veldig enkelt. Bare opprett en database i SQL -serveren og importer innstillingen ved å importere filen som heter "database_structure.txt". Du finner filen i dette trinnet. Siden instruksjonene ikke tillater å laste opp ".sql" -filer, har jeg omdøpt filen til ".txt".

Merk: Gi filen nytt navn fra ".txt" til ".sql".

Trinn 3: Konfigurering av filserveren

Det er veldig enkelt å konfigurere serveren hvis du eier et nettsted, og det er vert på nettet. Jeg vil ikke gå gjennom hele prosedyren for å sette opp et nettsted og være vert for det siden det er utenfor omfanget av denne opplæringen. Men du kan være vert for den på din egen pc som localhost for å prøve å jobbe med filene.

Siden Instructable ikke tillater å laste opp PHP -filer, har jeg gitt filene nytt navn til ".txt".

Merk: Gi navn på filtypen til ".php". Ikke glem å endre legitimasjonen til "config.php" -filen.

Bare last opp filene til serveren, så er du i gang.

Jeg skal gi deg kort informasjon om PHP -filene.

db_config.php:

I denne filen lagres alle legitimasjonene som kreves for å koble til SQL -serveren.

db_connect:

I denne filen er klassen som trengs for databasetilkobling til stede.

insert.php:

NodeMCU kaller denne PHP -filen for opplasting av data til serveren ved hjelp av GET -metoden. Denne filen er også ansvarlig for å lagre de samme dataene til SQL -serveren.

retrieve.php:

Brukeren/klienten kaller denne PHP ved hjelp av GET -metoden. Serveren beregner avstanden mellom brukeren og alle modulene. Deretter sendes dataene til den nærmeste modulen som et svar til klienten i JSON/XML -format som foretrukket av klienten.

update.php:

Denne PHP -filen kalles av modulen hver dag på et bestemt tidspunkt for å kontrollere om modulen kjører den siste versjonen av fastvaren. Bare plasser den siste ".bin" -filen i filserveren og spesifiser katalogen til filen i variabelen til filen.

Hvis disse mange filene virker skremmende i begynnelsen, har jeg inkludert brukerdokumentasjonen i neste trinn.

Trinn 4: Brukerdokumentasjon

Introduksjon:

Weather API gir et enkelt grensesnitt for å be om værdata for steder på jordoverflaten. Du ber om værinformasjon for et spesifikt bredde-/lengdegradspar med utdataformatet angitt. API -en returnerer temperatur, fuktighet, trykk og luftkvalitetsindeks som sist ble registrert av den nærmeste modulen fra det forespurte stedet.

Før du begynner:

Dette dokumentet er beregnet for nettsted- og mobilutviklere som ønsker å inkludere værinformasjon om et program som er under utvikling. Den introduserer bruken ved hjelp av API og referansemateriale på de tilgjengelige parameterne.

Forespørsler om værdata:

Weather API -forespørsler er konstruert som en URL -streng. API -en returnerer værdata for et punkt på jorden, spesifisert av et breddegrad/lengdegrad -par. Vær oppmerksom på at nøyaktigheten av værdata er direkte proporsjonal med tettheten til modulene plassert i et område.

En Weather API -forespørsel har følgende form:

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

Hvor utdataformat (format) kan være en av følgende verdier:

• JSON (anbefalt), indikerer utdata i JavaScript Object Notation (JSON); eller
• XML, indikerer utdata i XML, pakket inn i noden.

Be om parametere:

Som standard i alle nettadresser, skilles parametrene ut med ampersand (&) -tegnet. Listen over parametere og deres mulige verdier er angitt nedenfor.

Nødvendige parametere:

• lat: Representerer en breddegrad for et sted å slå opp. (f.eks. lat = 19,56875)
• lon: Representerer en lengdegrad for et sted å slå opp. (f.eks. lon = 72.97568)

Valgfrie parametere:

format: Angir svarformatet for værdataene. Det kan være enten JSON eller XML. Standard er JSON. (f.eks. format = json eller format = xml)

Værsvar:

For hver gyldig forespørsel vil tidssonetjenesten returnere et svar i formatet angitt i forespørselens URL. Hvert svar vil inneholde følgende elementer:

• suksess: en verdi som indikerer statusen til svaret.

  • 0: Negativt; indikerer at forespørselen var feilformet.
  • 1: Bekreftende; indikerer at forespørselen var vellykket.
• melding: en streng som angir årsaken til misforholdet til forespørselen. Bare tilgjengelig når statusen er negativ.

• data: en matrise med flere værparametere.

  • temp: temperaturdataene.
  • hum: dataene for fuktighetsnærvær.
  • pres: dataene for absolutt trykk.
  • aqi: den nåværende luftkvalitetsindeksen.

Eksempelresponsen til begge formatene kan sees på bildene.

Trinn 5: Moduloppsett

Et tilgangspunkt opprettes, og en webside ligger på en IP-adresse (standard: 192.168.4.1) for å motta legitimasjonen fra enhetsbehandleren/brukeren ved første oppstart, eller hvis modulen ikke finner de allerede lagrede legitimasjonene i EEPROM.

Brukeren må angi SSID og passord som brukeren vil at modulen skal koble til. Bredde- og lengdegrad blir automatisk fylt hvis du lar nettleseren få tilgang til stedet.

Når alle detaljene er angitt, klikker du på "SEND" -knappen, og deretter skrives alle legitimasjonene i EEPROM -modulen.

Dette trinnet er svært avgjørende siden det ikke er mulig å programmere alle modulene med nøyaktige posisjonsdata og WiFi-legitimasjon mens det er masseproduserende moduler. Det er heller ikke tilrådelig å hardkode legitimasjonen i programmet, siden hvis vi i det hele tatt trenger å flytte modulen til et annet sted eller ønsker å endre WiFi-legitimasjonen, må vi omprogrammere modulen. For å unngå dette stresset, er den første oppsettfunksjonen implementert.

Trinn 6: Nå er det på tide å bidra med data til skyen

Etter at alle de foregående trinnene er fullført, er det nå på tide å la modulen laste opp dataene til serveren. Den starter automatisk opplastingen når du har lagret legitimasjonen.

Den kaller "insert.php" som et API -anrop med passering av alle parameterne for å sende i GET -metoden.

Kodestykket nedenfor viser hvordan parametrene behandles.

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

Som så begynner alle modulene å laste opp dataene.

Merk: Senk opplastingsfrekvensen i koden hvis du føler at serveren blir overbelastet.

Trinn 7: Over the Air (OTA) oppdatering

Etter at modulen er konfigurert og begynner å laste opp dataene, ser den etter fastvareoppdateringer hver dag på et bestemt tidspunkt som er nevnt i programmet. Hvis den finner noen, laster den ned og blinker den binære filen i den. Og hvis det ikke gjør det, fortsetter den normale driften av opplasting av data.

For å se etter en ny oppdatering, kaller modulen "update.php" ved å sende MAC -adressen i forespørselsoverskriften. Serveren sjekker deretter om den spesifikke MAC -adressen har en ny oppdatering, hvis ja, sender den den binære filen til den siste fastvaren som svar.

Den kontrollerer også alle nødvendige overskrifter som kreves for grunnleggende autentisering av modulen.

Trinn 8: Hvordan bruker/klient kan få tilgang til dataene …

Det er ganske enkelt å få tilgang til dataene fra serveren. Bare ved å kalle "retrieve.php", får vi værdataene som svar i JSON -format. Etter det er det bare å analysere JSON -dataene for å få tilgang til de enkelte elementene. Lignende er med XML -respons. Brukeren kan alltid angi ønsket svarformat der brukeren er komfortabel å jobbe med. Hvis brukeren ikke angir formatet, er standardformatet JSON.

Det blir laget en prøveforespørsel ved hjelp av POSTMAN -verktøyet for å kontrollere hvordan API -en fungerer.

Et eksempel på analyse av JSON -respons i javascript er vist i kodebiten nedenfor.

var url = "https://example.com/retrieve.php?lat=19.044848&lon=72.8464373";funksjon httpGet (theUrl) {var xmlHttp = ny XMLHttpRequest (); xmlHttp.open ("GET", theUrl, false); // false for synkron forespørsel xmlHttp.send (null); returner xmlHttp.responseText; } var myVar = httpGet (url); var obj = JSON.parse (myVar); document.getElementById ("aqi"). innerHTML = obj.data [0].aqi; document.getElementById ("temperatur"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("temp"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("fuktighet"). innerHTML = Math.round (obj.data [0].hum) + "%"; document.getElementById ("press"). innerHTML = Math.round (obj.data [0].pres) + "mb";

Kildekoden til HTML -eksemplet på siden som analyserer JSON -svaret er tilgjengelig på slutten av dette trinnet.

Merk: Endre filtypen til ".html".

Trinn 9: Begrensninger for dette prosjektet

• Prosjektet bruker GET til å sende dataene; selv om det ikke omhandler sensitive data, kan dataene enkelt manipuleres siden de ikke har noen mekanisme for å kontrollere ektheten til kilden bortsett fra å kontrollere overskriftene, som enkelt kan endres og til og med en normal enhet kan forfalskes å virke som en værmodul.
• Siden modulen utelukkende er avhengig og avhengig av andre tilgangspunkt (WIFI) for å sende dataene som i de fleste tilfeller ville være fra andre organisasjoner. Hvis tilgangspunktet i det hele tatt er nede på tjenesten av en eller annen grunn, vil ikke modulen kunne sende data.
• Selv om prosjektet er bygget for å øke nøyaktigheten til det eksisterende systemet, er sensoren tilgjengelig på markedet mindre nøyaktig enn forventet, noe som resulterer i at hovedformålet ikke lykkes.
• Mens jeg planla prosjektet, planla jeg å inkludere en modus der serveren gjennomsnittlig dataverdien basert på plassering for feilkorrigering. Men da jeg implementerte denne funksjonen, innså jeg at det trengte noen tredjeparts API-er for å oversette koordinatene til geografiske regioner.

Trinn 10: Ytterligere forbedringer som kan gjøres i dette prosjektet

• Nøyaktigheten til modulen kan forbedres ytterligere ved å skreddersy sensorene spesielt for det spesifikke formålet i stedet for å bruke den generiske modulen som er tilgjengelig på markedet.
• Modulen kan modifiseres til å fungere enda mer uavhengig ved å bruke en spesiell chip som trådløst kommuniserer med Cell-towers for å sende dataene og dermed forbedre feiltoleransen.
• Solcellepanel og batterisystem kan brukes i forbindelse med dyp-dvalemodus for ESP og forbedrer dermed energieffektiviteten og gjør den mer uavhengig av en ekstern strømforsyning.
• POST kan brukes til å sende data med en eller annen autentiseringsmekanisme som å bruke sykliske koder for hver overføring av data.
• I stedet for NodeMCU, som er et prototypebrett, kan vi bruke en tilpasset mikrokontroller i masseproduksjon som ikke bare reduserer kostnadene, men også utnytter systemressursene best.
• I forbindelse med Googles geografiske lokaliserings -API og tilkobling til tilgjengelig WIFI, kan modulen fungere uten å konfigurere den. klar til å overføre data fra fabrikken uten noe oppsett nødvendig.

Trinn 11: Noen få ord for publikum

Hei folkens, jeg skjønner at dette ikke er en nybegynnervennlig opplæring i det hele tatt, siden jeg ikke har nevnt hver eneste detalj som må dekkes. Og også dette prosjektet er virkelig stort for å bli dekket av en Instructable. Likevel prøvde jeg mitt beste for å dekke alle viktige aspekter av prosjektet. Jeg vet også at en video som viser hvordan prosjektet fungerer ville ha vært veldig bra, men siden dette er min første instruerbare og for å være ærlig, er dette min første publikasjon av noe som ligner på dette, jeg var ganske nervøs for å stå foran en kamera.

Hvis du trenger hjelp til å lage dette prosjektet eller noe lignende, kan du bare kontakte meg på [email protected], eller du kan legge igjen en kommentar som alltid. Jeg skal prøve å hjelpe dere så godt jeg kan.

Takk skal du ha!!