IDC2018IOT: חדר ישיבות סנצ'ר: 6 שלבים

2024 מְחַבֵּר: John Day | [email protected]. שונה לאחרונה: 2024-01-30 09:16

הבעיה

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

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

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

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

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

כיצד נפתור זאת?

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

1. אם הוא לא הוזמן, אל תעשה דבר.

2. אם הוא הוזמן, בדוק אם זוהתה תנועה או צליל כלשהו;

אם יש, אל תעשה דבר.

אם לא זוהה דבר, שלח הודעת אזהרה (באמצעות דוא"ל) למשתמש שהזמין את החדר ושואל אם החדר עדיין בשימוש. אלא אם כן המשתמש יצהיר שהוא עדיין משתמש בחדר, מצב החדר ישתנה ל"זמין ".

* כאן שילבנו את הפרויקט שלנו ביומן Google על מנת להכלילו ככל האפשר.

שלב 1: דרושה חומרה ופרוטוקולים

1. השתמשנו ב- NOSEMCU כדי שנוכל לעדכן את הדברים באופן דינמי באמצעות חיבור WIFI.

2. חיישן מיקרופון ש"קריא "את הרעש בחדר.

3. חיישן PIR שיבדוק אם יש תנועה כלשהי.

לשימוש בתוכנה ובשרת, מלבד הקוד בארדואינו, השתמשנו ב- Google Script וב- Zapier כדי לתמוך במערכת שלנו באופן מקוון. אתה יכול לראות את הזרימה בתמונה הנוספת (וב- PDF).

השתמשנו ב- Zapier כדי לחבר אפליקציות ולאוטומטי את תהליכי העבודה שלנו (כמו IFTTT) והשתמשנו ב- Google Script כדי לעזור לנו לתקשר עם לוח השנה של Google. התסריט שכתבנו מייצר את הדוא ל של יוצר האירוע כדי שנוכל לשלוח אותו זורק ולבדוק אם המשתמש ביקש להחזיק את החדר (על ידי שמירת מידע כלשהו ב- Google Sheets) לפני מחיקת האירוע.

שלב 2: חבר את המיקרופון ואת חיישן ה- PIR

רצינו לבדוק את הערכים הממוצעים שהמיקרופון מפרסם ב- NODEMCU כאשר אנשים מדברים (ברור שבכל חדר היו רעשי רקע שונים). עשינו כמה בדיקות והבנו שרמת הרעש הממוצעת היא החדר שעבדנו בו הוא איפשהו מעל 50.

חיישן PIR נותן רק ערכי HIGH או LOW ולכן בדקנו רק את רמת הרגישות שהכי מדויקת לחדר שבדקנו. המדריך הזה היה די מועיל.

החיבורים שלנו:

מיקרופון - כמו בתמונה חיישן PIR: GND> GND, OUT> D7, VCC> VN (5V)

שלב 3: צור את זרימת העבודה ב- Zapier

על מנת לדעת אם החדר אכן ריק או עדיין בשימוש (והמשתמשים בהפסקה למשל), נרצה ליצור זרימה המבטיחה זאת, מיד לאחר שה- NodeMCU ירה Webhook ל- Zapier שיודיע כי החדר ריק:

(1) TRIGGER - CATCH HOOK זאפייר תופס את ווהוק (שיישלח על ידי ה- NODEMCU)

(2) ACTION - GETZapier שולח וובוק אחר כדי לקבל את נתוני האירוע;> הוא קורא (מריץ) GoogleScript - GetCurrentEmailEventID (הסבר בשלב הבא), כדי לקבל את נתוני האירוע הנוכחי - שם אירוע, מזהה אירוע, דוא"ל משתמש.

(3) מסנן - המשך רק אם

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

(4) פעולה - GMAILZapier שולח דואר אלקטרוני, באמצעות Gmail, למשתמש שהזמין את החדר (קיבל מידע זה בשלב 2)

(5) פעולה - עיכוב לפני תן למשתמש זמן להשיב להודעת הדוא ל. - אם המשתמש לוחץ על הקישור: התקשר (הפעל) ל- GoogleScript - ApproveCurrentEvent (מכאן שהחדר יוסר מרשימת 'חדרים למחיקה', והרשימה החדר עדיין מסומן כתפוס.)

(6) פעולה - קבל לאחר 5 דקות, זאפייר מתקשר (מריץ) GoogleScript - DeleteCurrentEvent- אם המשתמש לא לחץ על הקישור

בודק אם מזהה החדר נמצא ברשימה 'חדרים למחוק'

זה פשוט מסיר את האירוע.

שלב 4: סקריפטים של Google

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

(1) GetCurrentEmailEventID

מופעל באמצעות שיחת Webhook.

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

(2) ApproveCurrentEvent

פועל בלחיצת משתמש.

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

(3) DeleteCurrentEvent

מופעל באמצעות שיחת Webhook.

מחפש את מזהה האירוע הרלוונטי ברשימה (דף Google) ומוחק את האירוע הזה מהלוח השנה.

שלב 5: חבר את הזרימה באמצעות קוד הארדואינו

הקוד המצורף מתחבר לחיישנים שבדקנו לפני כמה צעדים למערכת המקוונת (לוח השנה של גוגל במקרה שלנו). הוא בודק אם החדר עמוס ואז אם אין, הוא שולח בקשת HTTP (Webhook) המפעילה את בקשת האירוע המחיקה ב- Zapier.

שלב 6: סקירה, מסקנות וקנה מידה עתידי

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

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

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

אם המשתמש לא השיב בזמן נתון (הגדרנו אותו ל -5 דקות, אך ניתן לשנות אותו בקלות), אנו מוחקים את האירוע מהיומן (ומשחררים את החדר).

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

הגבלות המערכת שלנו:

1. החיישנים המשומשים חייבים להיות מדויקים ורגישים מאוד.

2. גודל החדר מוגבל לרדיוס/טווח החיישן.

3. נצטרך להסתמך על היענות המשתמש.

4. המערכת שלנו בנויה באמצעות מספר פלטפורמות (לוח שנה של גוגל, ג'ימייל, זאפייר וכו ') ותצטרך להשתמש בשירותם לביצוע.

5. הגדלת שירות זה למספר חדרים (במקום שכפול כל המערכת) תדרוש טיפול נוסף עם מזהה החדר.

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

פיתוחים עתידיים:

בהחלט היינו מגדילים את המערכת בשתי דרכים:

1. יכולת עבודה עם כל פלטפורמות לוח שנה אחרות (כך שכל חברת חללי עבודה משותפים תוכל להשתמש בה).

2. יכולת טיפול במספר חדרים, קומות ואתרים.

אנו מאמינים כי סוג זה של סולם ייקח 2-3 חודשים להכללה, בדיקה והוספת מספר חדרים (קומות וכו ').

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