תוכן עניינים:

מערכת ניטור מזג אוויר מבוזרת IoT חכמה באמצעות NodeMCU: 11 שלבים
מערכת ניטור מזג אוויר מבוזרת IoT חכמה באמצעות NodeMCU: 11 שלבים

וִידֵאוֹ: מערכת ניטור מזג אוויר מבוזרת IoT חכמה באמצעות NodeMCU: 11 שלבים

וִידֵאוֹ: מערכת ניטור מזג אוויר מבוזרת IoT חכמה באמצעות NodeMCU: 11 שלבים
וִידֵאוֹ: בידינו - התמודדות עם שינוי האקלים - פרופ' ורד בלאס 2024, יולי
Anonim
מערכת ניטור מזג אוויר מבוזרת IoT חכמה באמצעות NodeMCU
מערכת ניטור מזג אוויר מבוזרת IoT חכמה באמצעות NodeMCU

כולכם אולי מודעים לתחנת מזג האוויר המסורתית; אבל האם תהית אי פעם איך זה באמת עובד? מכיוון שתחנת מזג האוויר המסורתית יקרה ומגושמת, צפיפותן של תחנות אלה ליחידת שטח היא פחותה מאוד מה שתורם לחוסר הדיוק של הנתונים. אני אסביר לך איך: נניח שתחנה ממוקמת באמצע העיר וזו התחנה היחידה שנמצאת ברדיוס 'מטר' x ', ניתן להטיל אותה בקלות אם קיים גורם גורם לזיהום בסביבה של התחנה המציגה את כל שטח הרדיוס 'מטר' x 'כמזוהם שכן תחנה אחת אחראית לקבוע את נתוני מזג האוויר של כל האזור.

כדי להתגבר על בעיה זו, יש להגדיל את צפיפות המודולים, דבר אפשרי רק אם המודולים זולים יותר ותופסים טביעת רגל קטנה מהקיים.

זו הסיבה שהפתרון המוצע שלי הוא הפתרון המושלם לבעיה זו, הוא עולה פחות מ 10 $ וגם מונח בקלות על כף ידי.

איך זה עובד…

ישנם 3 חלקים עיקריים בפרויקט זה.

צד המכשיר:

ההתקן הוא מודול IoT המוצג בתמונה ששולח את נתוני מזג האוויר לשרת כל מרווח זמן 'x'. הנתונים כוללים את נתוני מזג האוויר בפועל, המיקום הגיאוגרפי של המודול; כלומר הקואורדינטות שלה, כתובת ה- MAC שלה; כדי לזהות את המכשיר באופן ייחודי, את גרסת הקושחה שבה הוא פועל כרגע. צד המכשיר כולל מודולי N המופצים ברחבי האזור התורמים נתונים לשרת באופן פעיל.

בצד השרת:

כפי שהשם מרמז, השרת הריכוזי הוא המטפל במספר פעולות כמו קבלת הנתונים מהמודולים ושמירתם במסד הנתונים, עדכון המודול עם הקושחה העדכנית ביותר אם הוא פועל בגרסה ישנה יותר, שליחת נתוני מזג האוויר אל לקוח על פי בקשה.

צד הלקוח/משתמש:

משתמש הקצה הוא זה שמבקש את נתוני מזג האוויר מהשרת. הלקוח שולח את המיקום הנוכחי ועל סמך המיקום, השרת מחשב את המרחק בין הלקוח לכל המודולים ושולח את נתוני מזג האוויר של המודול הקרוב ביותר ללקוח הנחשב למדויק.

אספקה

  • NodeMCU (ESP8266-12E)
  • DHT11 (חיישן לחות וטמפרטורה)
  • BMP180 (חיישן לחץ וטמפרטורה)
  • MQ-135 (חיישן אינדקס איכות אוויר)
  • כבל USB (להעלאת התוכנית)
  • ספק כוח 5 וולט
  • קבלים (אופציונלי: להציב במקביל לקו החשמל)
  • Arduino IDE (כדי לאתר באגים ולהעלות את התוכנית)
  • יישום POSTMAN (אופציונלי: ניפוי באגים של ה- API)
  • אתר אינטרנט (לאירוח שרת PHP ו- MySQL)

שלב 1: הלחמה של כל הרכיבים והעלאת התוכנית ל- NodeMCU

הלחם את כל הרכיבים והעלה את התוכנית ל- NodeMCU
הלחם את כל הרכיבים והעלה את התוכנית ל- NodeMCU
הלחם את כל הרכיבים והעלה את התוכנית ל- NodeMCU
הלחם את כל הרכיבים והעלה את התוכנית ל- NodeMCU

הלחם את כל הרכיבים ל- NodeMCU כפי שמוצג בתרשים המעגלים על לוח perf. כמו כן, הלחם קבל במקביל לקווי החשמל מכיוון שהעוצמה עולה במהלך שידור וקבלה של נתונים באופן פעיל.

לאחר סיום עבודת ההלחמה, העלה את הקוד המופיע בקובץ "code.c".

הערה: אל תשכח להחליף את האישורים בתעודות משלך. הנח גם את הקובץ בשם "html_file.h" בתוך תיקיית הסקיצות של arduino. כל קובצי הכותרת המשמשים בפרויקט זה ניתן למצוא כאן

תכונות הקוד:

נקודת גישה: מכיוון שקשה לתכנת כל מודול עם האישורים בייצור המוני, המודול מארח בדף אתחול ראשון דף אינטרנט כדי לקבל את אישורי ה- WiFi שאליו המודולים צריכים להתחבר ומאחסנים ב- EEPROM לשימוש מאוחר יותר.

לאחר הגדרת האישורים, ה- NodeMCU בודק את אישורי EEPROM ומתחבר לאישורי ה- WiFi הקיימים ב- EEPROM.

לאחר חיבור מוצלח ל- WiFi, ה- NodeMCU מתחיל להעלות את הנתונים לשרת כל מרווח זמן 'x', הנתונים כוללים נתוני מזג אוויר, כתובת MAC של המודול, גרסת הקושחה, המיקום הגיאוגרפי של המכשיר.

עדכון OTA: המודול גם בודק אם קיימים עדכוני קושחה חדשים בכל יום בזמן מסוים שצוין בקוד. תכונה זו שימושית מכיוון שלא ניתן לאף יצרן להמשיך ולשנות את התוכנית של מודול בודד במקרה שיהיו שינויים כלשהם.

טיימר כלב השמירה: Atlast חייבת להיות דרך לשחזר את עצמה ללא התערבות אנושית אם היא נתקעת או מתרסקת. ניתן להשיג זאת באמצעות טיימר כלב השמירה. הדרך שבה זה עובד היא: יש שגרת משנה של Interrupt שעוברת כל שנייה. ה- ISR מגדיל את המונה בכל פעם שהוא מבצע ובודק אם המונה הגיע לספירה המקסימלית. ברגע שהמונה מגיע לערך המרבי, המודול מאפס את עצמו בהנחה שהוא התרסק. בפעולה רגילה, המונה תמיד מתאפס לפני שהוא מגיע לספירה המקסימלית.

שלב 2: הגדרת שרת SQL

הגדרת שרת SQL
הגדרת שרת SQL

ההתקנה של שרת SQL היא גם ממש פשוטה. פשוט צור מסד נתונים בשרת SQL וייבא את ההגדרה על ידי ייבוא הקובץ בשם "database_structure.txt". תוכל למצוא את הקובץ בשלב זה. מכיוון שההוראה אינה מאפשרת להעלות קבצי ".sql", שמתי את שם הקובץ ל- ".txt".

הערה: שנה את שם הקובץ מ- ".txt" ל- ".sql".

שלב 3: הגדרת שרת הקבצים

הגדרת השרת היא קלה מאוד אם אתה הבעלים של אתר אינטרנט והוא מתארח באופן מקוון. לא אעבור על כל ההליך של הקמת אתר אינטרנט ואירוחו מכיוון שהוא חורג מהיקף הדרכה זו. אבל אתה יכול לארח אותו במחשב האישי שלך בתור localhost כדי לנסות לעבוד על הקבצים.

מכיוון ש- Instructable אינו מאפשר להעלות קבצי PHP, שיניתי את שם הקבצים ל- ".txt".

הערה: אנא שנה את שם הסיומת של הקבצים ל- ".php". כמו כן אל תשכח לשנות את פרטי הכניסה של הקובץ "config.php".

פשוט העלה את הקבצים לשרת ואתה מוכן ללכת.

אני אתן לך מידע קצר על קבצי PHP.

db_config.php:

בקובץ זה, כל האישורים הנדרשים לחיבור לשרת SQL מאוחסנים.

db_connect:

בקובץ זה קיימת המחלקה הדרושה לחיבור מסד נתונים.

insert.php:

ה- NodeMCU קורא לקובץ PHP זה להעלאת הנתונים לשרת בשיטת GET. קובץ זה אחראי גם לאחסן את אותם נתונים בשרת SQL.

retrieve.php:

המשתמש/הלקוח מכנה PHP זה בשיטת GET. השרת מחשב את המרחק בין המשתמש לכל המודולים. לאחר מכן נתוני המודול הקרוב ביותר נשלחים כתגובה ללקוח בפורמט JSON/XML לפי העדפת הלקוח.

עדכון. PHP:

קובץ PHP זה נקרא על ידי המודול מדי יום בזמן מסוים כדי לבדוק אם המודול מריץ את הגירסה העדכנית ביותר של הקושחה. כל שעליך לעשות הוא למקם את קובץ ה- ".bin" האחרון בשרת הקבצים ולציין את ספריית הקובץ במשתנה של הקובץ.

אם קבצים רבים אלה נראים מרתיעים בהתחלה, כללתי את תיעוד המשתמש בשלב הבא.

שלב 4: תיעוד משתמשים

תיעוד משתמשים
תיעוד משתמשים
תיעוד משתמשים
תיעוד משתמשים

מבוא:

ה- API של מזג האוויר מספק ממשק פשוט לבקשת נתוני מזג האוויר למיקומים על פני כדור הארץ. אתה מבקש את מידע מזג האוויר עבור זוג קו רוחב/אורך ספציפי עם פורמט הפלט שצוין. ה- API מחזיר את הטמפרטורה, הלחות, הלחץ ומדד איכות האוויר שנרשם לאחרונה על ידי המודול הקרוב ביותר מהמיקום המבוקש.

לפני שאתה מתחיל:

מסמך זה מיועד למפתחי אתרים ומובייל שרוצים לכלול מידע על מזג האוויר ביישום המפותח. הוא מציג את השימוש באמצעות ה- API וחומר ההפניה על הפרמטרים הזמינים.

בקשות לנתוני מזג אוויר:

בקשות Weather API נבנות כמחרוזת כתובת URL. ה- API מחזיר נתוני מזג אוויר לנקודה על פני כדור הארץ, שצוין על ידי זוג קו אורך/קו אורך. שים לב שדיוק נתוני מזג האוויר הוא ביחס ישר לצפיפות המודולים המוצבים באזור.

בקשה ל- Weather API לובשת את הטופס הבא:

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

כאשר פורמט הפלט (פורמט) עשוי להיות אחד מהערכים הבאים:

  • JSON (מומלץ), מציין פלט בסימון אובייקט JavaScript (JSON); אוֹ
  • XML, מציין פלט ב- XML, עטוף בתוך הצומת.

בקשת פרמטרים:

כסטנדרט בכל כתובות האתרים, הפרמטרים מופרדים באמצעות תו אמפרסנד (&). רשימת הפרמטרים וערכיהם האפשריים מסומנים להלן.

פרמטרים נדרשים:

  • lat: ייצוג קו הרוחב של מיקום לחיפוש. (למשל lat = 19.56875)
  • lon: מייצג אורך של מיקום לחיפוש. (למשל lon = 72.97568)

פרמטרים אופציונליים:

format: מציין את פורמט פלט התגובה של נתוני מזג האוויר. זה יכול להיות JSON או XML. ברירת המחדל היא JSON. (למשל format = json או format = xml)

תגובות מזג אוויר:

עבור כל בקשה תקפה, שירות אזור הזמן יחזיר תגובה בפורמט המצוין בתוך כתובת האתר של הבקשה. כל תגובה תכלול את המרכיבים הבאים:

  • הצלחה: ערך המציין את סטטוס התגובה.

    • 0: שלילי; מציין כי הבקשה פגומה.
    • 1: חיובי; מציין שהבקשה הצליחה.
  • הודעה: מחרוזת המציינת את הסיבה לפגם הבקשה. זמין רק כאשר הסטטוס שלילי.
  • נתונים: מערך עם מספר פרמטרי מזג אוויר.

    • טמפ ': נתוני הטמפרטורה.
    • מזמזם: נתוני נוכחות הלחות.
    • pres: נתוני הלחץ המוחלט.
    • aqi: מדד איכות האוויר הנוכחי.

ניתן לראות בתגובה את תגובת הדוגמאות של שני הפורמטים.

שלב 5: הגדרת מודול

הגדרת מודול
הגדרת מודול
הגדרת מודול
הגדרת מודול

נקודת גישה נוצרת ודף אינטרנט מתארח בכתובת IP (ברירת מחדל: 192.168.4.1) כדי לקבל את האישורים ממנהל ההתקנים/המשתמש בעת האתחול הראשון או אם המודול אינו מוצא את האישורים שכבר מאוחסנים ב- EEPROM.

המשתמש צריך להזין את ה- SSID והסיסמה שאליהם המשתמש רוצה שהמודול יתחבר. קו הרוחב והאורך מתמלאים אוטומטית אם אתה מאפשר לדפדפן לגשת למיקום.

לאחר הזנת כל הפרטים, לחץ על כפתור "שלח" ולאחר מכן כל האישורים כתובים ב- EEPROM של המודול.

שלב זה הוא קריטי מאוד מכיוון שבזמן ייצור המודולים ההמוני, לא ניתן לתכנת את כל המודולים עם נתוני המיקום המדויקים שלהם ותעודות ה- WiFi. כמו כן, לא מומלץ לקודד את אישורי התוכנית מכיוון שאם בכלל נצטרך להעביר את המודול למיקום אחר או לרצות לשנות את אישורי ה- WiFi, יהיה עלינו לתכנת מחדש את המודול. כדי להימנע מהטרחה הזו, פונקציית ההתקנה הראשונית מיושמת.

שלב 6: עכשיו הגיע הזמן לתרום נתונים לענן

עכשיו הגיע הזמן לתרום נתונים לענן
עכשיו הגיע הזמן לתרום נתונים לענן
עכשיו הגיע הזמן לתרום נתונים לענן
עכשיו הגיע הזמן לתרום נתונים לענן

לאחר השלמת כל השלבים הקודמים, הגיע הזמן לתת למודול להעלות את הנתונים לשרת. הוא מתחיל להעלות אוטומטית לאחר ששמרת את האישורים.

הוא מכנה את "insert.php" כקריאת API עם העברת כל הפרמטרים לשלוח בשיטת GET.

קטע הקוד להלן מראה כיצד מעבדים את הפרמטרים.

if (isset ($ _ GET ['temp']) && isset ($ _ GET ['hum']) && isset ($ _ GET ['pres']) && isset ($ _ GET ['aqi']) && isset ($ _ GET ['mac']) && isset ($ _ GET ['lat']) && isset ($ _ GET ['lon'])) 2. {3. // תוכנית ראשית 4.}

כאילו כל המודולים מתחילים להעלות את הנתונים.

הערה: הורד את תדירות ההעלאה בקוד אם אתה מרגיש שהשרת מקבל עומס יתר.

שלב 7: עדכון באוויר (OTA)

עדכון Over the Air (OTA)
עדכון Over the Air (OTA)

לאחר שהמודול מוגדר ומתחיל להעלות את הנתונים, הוא בודק אם קיימים עדכוני קושחה מדי יום בשעה מסוימת המוזכרת בתוכנית. אם הוא מוצא, הוא מוריד ומבהב את הקובץ הבינארי שבו. ואם לא, הפעולה הרגילה של העלאת הנתונים נמשכת.

כדי לבדוק אם קיים עדכון חדש, המודול מכנה את "update.php" על ידי שליחת כתובת ה- MAC בכותרת הבקשה שלו. לאחר מכן השרת בודק אם יש בכתובת ה- MAC הספציפית עדכון חדש כלשהו, אם כן, הוא שולח את הקובץ הבינארי של הקושחה האחרונה בתגובה.

הוא גם בודק את כל הכותרות הדרושות לצורך אימות בסיסי של המודול.

שלב 8: כיצד משתמש/לקוח יכולים לגשת לנתונים …

כיצד משתמש/לקוח יכול לגשת לנתונים …
כיצד משתמש/לקוח יכול לגשת לנתונים …
כיצד משתמש/לקוח יכול לגשת לנתונים …
כיצד משתמש/לקוח יכול לגשת לנתונים …
כיצד משתמש/לקוח יכול לגשת לנתונים …
כיצד משתמש/לקוח יכול לגשת לנתונים …

זה די פשוט לגשת לנתונים מהשרת. רק על ידי קריאת "retrieve.php", נקבל את נתוני מזג האוויר בתגובה בפורמט JSON. לאחר מכן, זה רק עניין של ניתוח נתוני JSON לגישה לרכיבים הבודדים. הדבר דומה לתגובת XML. המשתמש תמיד יכול לציין את פורמט התגובה המועדף שבו נוח למשתמש לעבוד איתו. אם המשתמש אינו מציין את הפורמט, תבנית ברירת המחדל היא JSON.

בקשה לדוגמא מתבצעת באמצעות כלי POSTMAN כדי לבדוק את פעולתו של ה- API.

דוגמה לניתוח תגובת JSON ב- javascript מוצגת בקטע הקוד למטה.

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 לבקשה סינכרונית xmlHttp.send (null); החזר xmlHttp.responseText; } var myVar = httpGet (url); var obj = JSON.parse (myVar); document.getElementById ("אקי"). innerHTML = obj.data [0].aqi; document.getElementById ("טמפרטורה"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("temp"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("לחות"). innerHTML = Math.round (obj.data [0].hum) + "%"; document.getElementById ("לחץ"). innerHTML = Math.round (obj.data [0].pres) + "mb";

קוד המקור של דף ה- HTML לדוגמא המנתח את תגובת JSON זמין בסוף שלב זה.

הערה: שנה את סיומת הקובץ ל- ".html".

שלב 9: מגבלות הפרויקט הזה

  • הפרויקט משתמש ב- GET לשליחת הנתונים; למרות שאינו עוסק בנתונים רגישים, ניתן לתמרן את הנתונים בקלות מכיוון שאין לו שום מנגנון לבדוק את מקוריותו של המקור מלבד בדיקת הכותרות, אותן ניתן לשנות בקלות ואף לזייף מכשיר רגיל. להיראות כמו מודול מזג אוויר.
  • מכיוון שהמודול מסתמך ותלוי בנקודת גישה אחרת (WIFI) בלבד ותשלח את הנתונים אשר ברוב המקרים יהיו של ארגונים אחרים. אם נקודת הגישה כלשהי פועלת מהשירות מסיבה כלשהי, המודול לא יוכל לשלוח נתונים.
  • למרות שהפרויקט בנוי בכדי להגדיל את הדיוק של המערכת הקיימת, החיישן הקיים בשוק פחות מדויק מהצפוי וכתוצאה מכך מוביל לכישלון מטרתו העיקרית.
  • בעת תכנון הפרויקט תכננתי לכלול מצב שבו השרת ממוצע את ערך הנתונים על סמך המיקום לתיקון שגיאות. אך עם יישום התכונה הזו הבנתי שהיא צריכה כמה ממשקי API של צד שלישי כדי לתרגם את הקואורדינטות לאזורים גיאוגרפיים.

שלב 10: שיפורים נוספים שניתן לבצע בפרויקט זה

  • ניתן לשפר עוד יותר את הדיוק של המודול על ידי התאמה מיוחדת של החיישנים למטרה הספציפית במקום להשתמש במודול הגנרי הקיים בשוק.
  • ניתן לשנות את המודול כך שיפעל עוד יותר באופן עצמאי באמצעות שבב מיוחד המתקשר באופן אלחוטי עם מגדלי Cell כדי לשלוח את הנתונים ובכך לשפר את סובלנות התקלות.
  • ניתן להשתמש בפאנל סולארי ובמערכת סוללות יחד עם מצב שינה עמוקה של ESP ובכך לשפר את יעילות החשמל ולהפוך אותו לעצמאי יותר מאספקת חשמל חיצונית.
  • ניתן להשתמש ב- POST לשליחת נתונים עם מנגנון אימות כלשהו כמו שימוש בקודים מחזוריים לכל שידור נתונים.
  • במקום NodeMCU, שהוא לוח אב טיפוס, אנו יכולים להשתמש במיקרו-בקר מותאם אישית בייצור המוני אשר לא רק מפחית את העלות אלא גם מנצל את משאבי המערכת בצורה הטובה ביותר.
  • בשילוב עם ממשק ה- API של מיקום גיאוגרפי של Google והתחברות לכל WIFI פתוח זמין, המודול יכול לעבוד אפילו בלי להגדיר אותו; מוכן להעביר נתונים מהמפעל ללא צורך בהתקנה כלשהי.

שלב 11: כמה מילים לקהל

כמה מילים לקהל
כמה מילים לקהל

היי חבר'ה, אני מבין שזו בכלל לא הדרכה ידידותית למתחילים מכיוון שלא ציינתי כל פרט שצריך להתייחס אליו. וגם הפרויקט הזה הוא עצום כדי להיות מכוסה במדריך. ובכל זאת, השתדלתי לכסות כל היבט חשוב של הפרויקט. אני גם יודע שסרטון שמציג את הפרוייקט של הפרויקט היה באמת נהדר אבל מכיוון שזהו ההוראה הראשון שלי ולמען האמת, זהו הפרסום הראשון שלי של משהו דומה לזה, הייתי די עצבני להיות מול מַצלֵמָה.

אם אתם זקוקים לעזרה בהכנת הפרויקט הזה או משהו דומה לזה, פנו אלי לכתובת [email protected] או שתוכלו להשאיר תגובה כתמיד. אנסה לעזור לכם כמיטב יכולתי.

תודה!!

מוּמלָץ: