Indholdsfortegnelse:

Smart Distributed IoT Weather Monitoring System Using NodeMCU: 11 trin
Smart Distributed IoT Weather Monitoring System Using NodeMCU: 11 trin

Video: Smart Distributed IoT Weather Monitoring System Using NodeMCU: 11 trin

Video: Smart Distributed IoT Weather Monitoring System Using NodeMCU: 11 trin
Video: IOT Weather Monitoring System @EGTECHNOLOGIES 2024, November
Anonim
Smart Distributed IoT Weather Monitoring System Using NodeMCU
Smart Distributed IoT Weather Monitoring System Using NodeMCU

I er måske alle klar over den traditionelle vejrstation; men har du nogensinde undret dig over, hvordan det rent faktisk fungerer? Da den traditionelle vejrstation er dyr og omfangsrig, er tætheden af disse stationer pr. Arealenhed meget mindre, hvilket bidrager til unøjagtigheden af dataene. Jeg forklarer dig hvordan: Antag, at en station er placeret midt i en by, og det er den eneste station, der er placeret i 'x' meters radius, det kan let være forudindtaget, hvis der er forureningsfremkaldende middel i nærheden af stationen, der viser hele 'x' meter radiusområdet som forurenet, da den enkelte station er ansvarlig for at bestemme vejrdata for hele området.

For at overvinde dette problem skal tætheden af modulerne øges, hvilket kun er muligt, hvis modulerne er billigere og tager et mindre fodaftryk end det eksisterende.

Dette er grunden til, at min foreslåede løsning er den perfekte løsning til dette problem. Det koster mindre end $ 10 og hviler også let på min håndflade.

Hvordan det virker…

Der er 3 hoveddele af dette projekt.

Enhedens side:

Enheden er et IoT -modul vist på billedet, der sender vejrdata til serveren hvert x -interval. Dataene inkluderer de faktiske vejrdata, modulets geografiske placering; dvs. dets koordinater, dens MAC -adresse; for entydigt at identificere enheden, den firmwareversion, den kører i øjeblikket. Enhedssiden omfatter N-moduler fordelt over området, der aktivt bidrager med data til serveren.

Server-side:

Som navnet antyder, er det den centraliserede server, der håndterer flere operationer, f.eks. Modtagelse af data fra modulerne og lagring af dem i databasen, opdatering af modulet med den nyeste firmware, hvis den kører på en ældre version, sender vejrdata til klient på forespørgsel.

Kunde-/brugerside:

Det er slutbrugeren, der anmoder om vejrdata fra serveren. Klienten sender den aktuelle placering og baseret på placeringen beregner serveren afstanden mellem klienten og alle modulerne og sender vejrdata for det nærmeste modul til klienten, hvilket anses for at være nøjagtigt.

Forbrugsvarer

  • NodeMCU (ESP8266-12E)
  • DHT11 (Fugtigheds- og temperatursensor)
  • BMP180 (Tryk- og temperatursensor)
  • MQ-135 (luftkvalitetsindekssensor)
  • USB -kabel (for at uploade programmet)
  • 5 volt strømforsyning
  • Kondensatorer (valgfrit: placeres parallelt med powerline)
  • Arduino IDE (Til fejlfinding og upload af programmet)
  • POSTMAN -applikation (valgfrit: til fejlretning af API)
  • Et websted (til at være vært for PHP- og MySQL -serveren)

Trin 1: Lodd alle komponenterne, og upload programmet til NodeMCU

Lod alle komponenterne og upload programmet til NodeMCU
Lod alle komponenterne og upload programmet til NodeMCU
Lod alle komponenterne og upload programmet til NodeMCU
Lod alle komponenterne og upload programmet til NodeMCU

Lod alle komponenterne til NodeMCU som vist i kredsløbsdiagrammet på et perf bord. Lod også en kondensator parallelt med kraftledningerne, da strømmen stiger under aktiv overførsel og modtagelse af data.

Når lodningsarbejdet er udført, skal du uploade koden i filen "code.c".

Bemærk: Glem ikke at udskifte legitimationsoplysningerne med dine egne legitimationsoplysninger. Placer også filen med navnet "html_file.h" inde i arduino sketch -mappen. Alle overskriftsfiler, der bruges i dette projekt, kan findes her

Kodens funktioner:

Adgangspunkt: Da det er svært at programmere hvert modul med legitimationsoplysninger i masseproduktion, er modulet vært for en webside på sin første opstart for at acceptere legitimationsoplysningerne for WiFi, som modulerne skal oprette forbindelse til og gemme i EEPROM til senere brug.

Når legitimationsoplysningerne er konfigureret, kontrollerer NodeMCU EEPROM for legitimationsoplysninger og opretter forbindelse til de WiFi -legitimationsoplysninger, der findes i EEPROM.

Efter en vellykket forbindelse til WiFi begynder NodeMCU at uploade dataene til serveren hvert 'x' interval, dataene inkluderer vejrdata, modulets MAC -adresse, firmwareversion, enhedens geografiske placering.

OTA -opdatering: Modulet søger også efter ny firmwareopdatering hver dag på et bestemt tidspunkt, der er angivet i koden. Denne funktion er nyttig, da det ikke er muligt for nogen producent at fortsætte og ændre programmet for et individuelt modul, hvis der er nogen ændringer, der skal foretages.

Watchdog Timer: Atlast der skal være en måde at gendanne sig selv uden nogen menneskelig indgriben, hvis den sætter sig fast eller går ned. Dette kan opnås ved hjælp af Watchdog -timeren. Sådan fungerer det: Der er en afbrydende underrutine, der kører hvert sekund. ISR øger tælleren hver gang den udfører og kontrollerer, om tælleren har nået det maksimale antal. Når tælleren når den maksimale værdi, nulstiller modulet sig selv, forudsat at det er gået ned. Ved normal drift nulstilles tælleren altid, før den når det maksimale antal.

Trin 2: Konfiguration af SQL Server

Konfiguration af SQL Server
Konfiguration af SQL Server

SQL Server -opsætningen er også virkelig enkel. Du skal bare oprette en database i SQL -server og importere indstillingen ved at importere filen med navnet "database_structure.txt". Du kan finde filen i dette trin. Da instruktionen ikke tillader at uploade ".sql" -filer, har jeg omdøbt filen til ".txt".

Bemærk: Omdøb filen fra ".txt" til ".sql".

Trin 3: Konfiguration af filserveren

Det er virkelig let at konfigurere serveren, hvis du ejer et websted, og det hostes online. Jeg vil ikke gennemgå hele proceduren med at oprette et websted og hoste det, da det ligger uden for denne vejledning. Men du kan hoste den på din egen pc som localhost for at prøve filernes funktion.

Da Instructable ikke tillader at uploade PHP -filer, har jeg omdøbt filerne til ".txt".

Bemærk: Omdøb filtypen til ".php". Husk også at ændre legitimationsoplysningerne for filen "config.php".

Upload bare filerne til serveren, og du er i gang.

Jeg giver dig korte oplysninger om PHP -filerne.

db_config.php:

I denne fil gemmes alle de legitimationsoplysninger, der kræves for at oprette forbindelse til SQL -serveren.

db_connect:

I denne fil er den klasse, der er nødvendig til databaseforbindelse, til stede.

insert.php:

NodeMCU kalder denne PHP -fil til upload af data til serveren ved hjælp af GET -metoden. Denne fil er også ansvarlig for at gemme de samme data til SQL -serveren.

retrieve.php:

Brugeren/klienten kalder denne PHP ved hjælp af GET -metoden. Serveren beregner afstanden mellem brugeren og alle modulerne. Derefter sendes dataene fra det nærmeste modul som et svar til klienten i JSON/XML -format som foretrukket af klienten.

update.php:

Denne PHP -fil kaldes af modulet hver dag på et bestemt tidspunkt for at kontrollere, om modulet kører den nyeste version af firmwaren. Placer bare den nyeste ".bin" -fil i filserveren og angiv filens bibliotek i filens variabel.

Hvis disse mange filer virker skræmmende i starten, har jeg inkluderet brugerdokumentationen i det næste trin.

Trin 4: Brugerdokumentation

Brugerdokumentation
Brugerdokumentation
Brugerdokumentation
Brugerdokumentation

Introduktion:

Weather API giver en enkel grænseflade til at anmode om vejrdata for placeringer på jordens overflade. Du anmoder om vejrinformationen for et specifikt bredde-/længdepar med det angivne outputformat. API'en returnerer temperatur, fugtighed, tryk og luftkvalitetsindeks, der sidst blev registreret af det nærmeste modul fra den ønskede placering.

Før du begynder:

Dette dokument er beregnet til websteds- og mobiludviklere, der ønsker at inkludere vejrinformation om en applikation, der er under udvikling. Det introducerer brugen ved hjælp af API og referencemateriale på de tilgængelige parametre.

Anmodninger om vejrdata:

Weather API -anmodninger er konstrueret som en URL -streng. API'en returnerer vejrdata for et punkt på jorden, angivet af et bredde-/længdepar. Bemærk, at vejrdataens nøjagtighed er direkte proportional med tætheden af modulerne placeret i et område.

En Weather API -anmodning har følgende form:

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

Hvor outputformat (format) kan være en af følgende værdier:

  • JSON (anbefales), angiver output i JavaScript Object Notation (JSON); eller
  • XML, angiver output i XML, pakket ind i noden.

Anmodningsparametre:

Som standard i alle webadresser adskilles parametre ved hjælp af ampersand (&) -tegnet. Listen over parametre og deres mulige værdier er angivet nedenfor.

Påkrævede parametre:

  • lat: Repræsenterer en breddegrad for et sted, der skal søges op. (f.eks. lat = 19,56875)
  • lon: Repræsenterer en længdegrad for et sted at slå op. (f.eks. lon = 72.97568)

Valgfrie parametre:

format: Angiver svaroutputformatet for vejrdataene. Det kan enten være JSON eller XML. Standard er JSON. (f.eks. format = json eller format = xml)

Vejrsvar:

For hver gyldig anmodning returnerer tidszonetjenesten et svar i det format, der er angivet i anmodningswebadressen. Hvert svar vil indeholde følgende elementer:

  • succes: en værdi, der angiver svarets status.

    • 0: Negativ; angiver, at anmodningen var misdannet.
    • 1: Bekræftende; angiver, at anmodningen var vellykket.
  • meddelelse: en streng, der angiver årsagen til anmodningens misform. Kun tilgængelig, når status er negativ.
  • data: en matrix med flere vejrparametre.

    • temp: temperaturdata.
    • brummen: data om fugtighedstilstedeværelse.
    • pres: de absolutte trykdata.
    • aqi: det nuværende luftkvalitetsindeks.

Eksemplernes svar på begge formater kan ses på billederne.

Trin 5: Modulopsætning

Opsætning af modul
Opsætning af modul
Opsætning af modul
Opsætning af modul

Der oprettes et adgangspunkt, og en webside hostes på en IP-adresse (standard: 192.168.4.1) for at modtage legitimationsoplysninger fra enhedsadministratoren/brugeren ved den allerførste opstart, eller hvis modulet ikke finder de allerede gemte legitimationsoplysninger i EEPROM.

Brugeren skal indtaste SSID og adgangskode, som brugeren ønsker, at modulet skal oprette forbindelse til. Bredde- og længdegraden bliver automatisk udfyldt, hvis du tillader browseren at få adgang til placeringen.

Når alle detaljer er indtastet, skal du klikke på knappen "SEND", og derefter er alle legitimationsoplysninger skrevet i modulets EEPROM.

Dette trin er meget afgørende, da det ved masseproduktion af modulerne ikke er muligt at programmere alle modulerne med dens nøjagtige lokaliseringsdata og WiFi-legitimationsoplysninger. Det er heller ikke tilrådeligt at hard-kode legitimationsoplysningerne i programmet, da hvis vi overhovedet har brug for at flytte modulet til et andet sted eller ønsker at ændre WiFi-legitimationsoplysningerne, skal vi omprogrammere modulet. For at undgå dette besvær implementeres den første opsætningsfunktion.

Trin 6: Nu er det tid til at bidrage med data til skyen

Nu er det tid til at bidrage med data til skyen
Nu er det tid til at bidrage med data til skyen
Nu er det tid til at bidrage med data til skyen
Nu er det tid til at bidrage med data til skyen

Når alle de foregående trin er gennemført, er det nu tid til at lade modulet uploade dataene til serveren. Den starter automatisk med at uploade, når du har gemt legitimationsoplysningerne.

Det kalder "insert.php" som et API -opkald med passering af alle parametre, der skal sendes i GET -metoden.

Nedenstående kodestykke 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.}

Ligesom alle modulerne begynder at uploade dataene.

Bemærk: Sænk uploadfrekvensen i koden, hvis du føler, at serveren bliver overbelastet.

Trin 7: Over the Air (OTA) opdatering

Over the Air (OTA) opdatering
Over the Air (OTA) opdatering

Efter at modulet er konfigureret og begynder at uploade dataene, søger det efter firmwareopdateringer hver dag på et bestemt tidspunkt nævnt i programmet. Hvis den finder nogen, downloades og blinker den binære fil i den. Og hvis det ikke gør det, fortsættes den normale drift af upload af data.

For at kontrollere, om der er en ny opdatering, kalder modulet "update.php" ved at sende MAC -adressen i sin forespørgselsoverskrift. Serveren kontrollerer derefter, om den specifikke MAC -adresse har en ny opdatering, hvis ja, sender den den binære fil med den seneste firmware som svar.

Det kontrollerer også alle de nødvendige headere, der kræves til grundlæggende godkendelse af modulet.

Trin 8: Hvordan bruger/klient kan få adgang til dataene …

Hvordan bruger/klient kan få adgang til dataene …
Hvordan bruger/klient kan få adgang til dataene …
Hvordan bruger/klient kan få adgang til dataene …
Hvordan bruger/klient kan få adgang til dataene …
Hvordan bruger/klient kan få adgang til dataene …
Hvordan bruger/klient kan få adgang til dataene …

Det er ret ligetil at få adgang til dataene fra serveren. Bare ved at kalde "retrieve.php" får vi vejrdata som svar i JSON -format. Derefter er det bare at analysere JSON -dataene for at få adgang til de enkelte elementer. Lignende er med XML -svar. Brugeren kan altid angive det foretrukne svarformat, hvor brugeren er behagelig at arbejde med. Hvis brugeren ikke angiver formatet, er standardformatet JSON.

En prøveforespørgsel fremsættes ved hjælp af POSTMAN -værktøj til at kontrollere, hvordan API'en fungerer.

Et eksempel på analyse af JSON -svar i javascript er vist i kodestykket herunder.

var url = "https://example.com/retrieve.php?lat=19.044848&lon=72.8464373"; funktion httpGet (theUrl) {var xmlHttp = ny XMLHttpRequest (); xmlHttp.open ("GET", theUrl, false); // falsk for synkron anmodning 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 ("temperatur"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("temp"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("fugtighed"). innerHTML = Math.round (obj.data [0].hum) + "%"; document.getElementById ("tryk"). innerHTML = Math.round (obj.data [0].pres) + "mb";

Kildekoden for den eksempel -HTML -side, der analyserer JSON -svaret, er tilgængelig i slutningen af dette trin.

Bemærk: Skift filtypen til ".html".

Trin 9: Begrænsninger af dette projekt

  • Projektet bruger GET til at sende dataene; selvom de ikke omhandler følsomme data, kan dataene let manipuleres, da de ikke har nogen mekanisme til at kontrollere kildens ægthed bortset fra at kontrollere overskrifterne, som let kan ændres og endda en normal enhed kan forfalskes at virke som et vejrmodul.
  • Da modulet udelukkende er afhængigt og afhængig af andet adgangspunkt (WIFI) til at sende de data, som i de fleste tilfælde ville være fra andre organisationer. Hvis overhovedet adgangspunktet er ude af drift af en eller anden grund, ville modulet ikke kunne sende data.
  • Selvom projektet er bygget for at øge nøjagtigheden af det eksisterende system, er den tilgængelige sensor på markedet mindre præcis end forventet, hvilket resulterer i, at dens hovedformål ikke lykkes.
  • Mens jeg planlagde projektet, planlagde jeg at inkludere en tilstand, hvor serveren gennemsnitlige dataværdien baseret på placering til fejlkorrektion. Men da jeg implementerede denne funktion, indså jeg, at det havde brug for nogle tredjeparts API'er for at oversætte koordinaterne til geografiske områder.

Trin 10: Yderligere forbedringer, der kan foretages i dette projekt

  • Modulets nøjagtighed kan forbedres yderligere ved specielt at skræddersy sensorerne til det specifikke formål i stedet for at bruge det generiske modul, der er tilgængeligt på markedet.
  • Modulet kan ændres til at fungere endnu mere uafhængigt ved hjælp af en speciel chip, der trådløst kommunikerer med Cell-towers for at sende dataene og dermed forbedre fejltolerancen.
  • Solcellepanel og batterisystem kan bruges i forbindelse med ESP's dyb dvaletilstand og forbedrer dermed energieffektiviteten og gør den mere uafhængig af en ekstern strømforsyning.
  • POST kan bruges til at sende data med en vis godkendelsesmekanisme, f.eks. Ved hjælp af cykliske koder til hver transmission af data.
  • I stedet for NodeMCU, som er et prototypebord, kan vi bruge en brugerdefineret mikrokontroller i masseproduktion, som ikke kun reducerer omkostningerne, men også udnytter systemressourcerne bedst.
  • I forbindelse med Googles geolokaliserings -API og forbindelse til enhver tilgængelig åben WIFI kan modulet fungere uden selv at konfigurere det; klar til at overføre data fra fabrikken uden nogen form for opsætning.

Trin 11: Et par ord til publikum

Et par ord til publikum
Et par ord til publikum

Hej fyre, jeg indser, at dette slet ikke er en begyndervenlig vejledning, da jeg ikke har nævnt hver eneste detalje, der skal dækkes. Og også dette projekt er virkelig stort for at blive dækket af en instruerbar. Alligevel forsøgte jeg mit bedste at dække alle vigtige aspekter af projektet. Jeg ved også, at en video, der viser, hvordan projektet fungerer, ville have været virkelig fantastisk, men da dette er min første instruerbare og for at være ærlig, er dette min første udgivelse af noget lignende dette, jeg var ret nervøs for at stå foran en kamera.

Hvis du har brug for hjælp til at lave dette projekt eller noget lignende, skal du bare kontakte mig på [email protected], eller du kan slippe en kommentar som altid. Jeg vil prøve at hjælpe jer bedst muligt.

Tak skal du have!!

Anbefalede: