IDC2018IOT: اتاق جلسه Snitcher: 6 مرحله

2024 نویسنده: John Day | [email protected]. آخرین اصلاح شده: 2024-01-30 08:56

مشکل

همانطور که می دانیم ، طی چند سال گذشته روند فضاهای مشارکتی شتاب گرفته است ، همراه با فناوری روز که انتخاب فضای همکاری ویژه ای را متناسب با نیازهای شما مشخص می کند.

یکی از ویژگیهای اصلی ارائه شده ، اتاقهای جلسه مشترک است که به اعضای فضای همکاری ارائه می شود ، که توسط یک پلت فرم تقویم (معمولاً) ساده مدیریت می شود.

وقتی برنامه افراد پویا می شود ، مشکلی دوباره ایجاد می شود.

ممکن است یک نفر اتاق را رزرو کند و فکر کند ممکن است به آن نیاز داشته باشد و نمی خواهد زمان را از دست بدهد.

حتی اگر در نهایت کسی از این بازه زمانی استفاده نکند ، به خود زحمت نمی دهد که آن را به خاطر دیگران اطلاع داده و لغو کند ، زیرا متأسفانه این طبیعت انسانی است.

چگونه آن را حل می کنیم؟

با استفاده از فناوری اینترنت اشیا - بررسی صدا و حرکت در یک اتاق جلسات تعیین شده ، ما در هر بازه زمانی خاصی بررسی می کنیم که آیا یک اتاق رزرو شده و واقعاً اشغال شده است یا خیر:

1. اگر رزرو نشده است ، کاری نکنید.

2. اگر رزرو شده است ، بررسی کنید که آیا حرکت یا صدایی تشخیص داده شده است یا خیر.

اگر وجود دارد ، کاری نکنید.

اگر چیزی تشخیص داده نشد ، یک پیام هشداردهنده (از طریق ایمیل) به کاربر رزرو کننده اتاق ارسال کنید که می پرسد آیا هنوز از اتاق استفاده می شود. مگر اینکه کاربر اعلام کند هنوز از اتاق استفاده می کند ، وضعیت اتاق به "در دسترس" تغییر می کند.

* در اینجا ، ما پروژه خود را با تقویم Google ادغام کردیم تا آنجا که ممکن است تعمیم دهیم.

مرحله 1: سخت افزار و پروتکل های مورد نیاز

1. ما از NOSEMCU استفاده کردیم تا بتوانیم با استفاده از اتصال WIFI همه چیز را به صورت پویا به روز کنیم.

2. سنسور میکروفون که سر و صدای اتاق را "می خواند".

3. سنسور PIR که بررسی می کند آیا حرکتی وجود دارد یا خیر.

برای استفاده از نرم افزار و سرور ، علاوه بر کد موجود در آردوینو ، از Google Script و Zapier برای پشتیبانی آنلاین سیستم خود استفاده کردیم. می توانید جریان را در تصویر اضافه شده (و PDF) مشاهده کنید.

ما از Zapier برای اتصال برنامه ها و خودکارکردن گردش کار خود (مانند IFTTT) استفاده کردیم و از Google Script برای کمک به ارتباط با تقویم Google استفاده کردیم. اسکریپتی که ما نوشتیم ایمیل سازنده رویداد را تولید می کند ، بنابراین می توانیم آن را به Zapier ارسال کنیم و بررسی کنیم که آیا کاربر قبل از حذف رویداد (با ذخیره برخی اطلاعات در 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 زاپیر Webhook را می گیرد (که توسط NODEMCU ارسال می شود)

(2) ACTION - GETZapier یک Webhook دیگر برای دریافت داده های رویداد ارسال می کند ؛> با GoogleScript تماس می گیرد (اجرا می شود) - GetCurrentEmailEventID (توضیح در مرحله زیر) ، برای دریافت اطلاعات رویداد فعلی - نام رویداد ، شناسه رویداد ، ایمیل کاربر.

(3) فیلتر - در صورت ادامه فقط

در صورتی که رویدادی (هر رویدادی) در حال حاضر در تقویم اتفاق می افتد (ROOM IS BUSY) به مرحله بعدی ادامه دهید ، در غیر این صورت ، با خالی بودن اتاق متوقف می شود.

(4) ACTION - GMAILZapier یک ایمیل از طریق Gmail به کاربر رزرو کننده اتاق ارسال می کند (این اطلاعات را در مرحله 2 دریافت کرد)

(5) ACTION - DELAY FORLL به کاربر اجازه دهید تا به ایمیل پاسخ دهد. - اگر کاربر روی پیوند کلیک کرد: با GoogleScript تماس بگیرید (اجرا کنید) - ApproveCurrentEvent (بنابراین اتاق از لیست "Rooms to delete" حذف می شود ، و اتاق هنوز به عنوان اشغال شده علامت گذاری شده است.)

(6) ACTION - GET بعد از 5 دقیقه ، Zapier با GoogleScript تماس می گیرد (اجرا می شود) - DeleteCurrentEvent- اگر کاربر روی پیوند کلیک نکرده باشد

بررسی می کند که آیا شناسه اتاق در لیست "اتاق هایی برای حذف" وجود دارد

فقط رویداد را حذف می کند.

مرحله 4: اسکریپت های Google

همانطور که ما کل سیستم را ادغام کردیم ، GoogleScripts انتخاب بی اهمیت IDE بود ، بنابراین ، ما از کتابخانه های Google مربوطه استفاده کردیم. با توجه به بستر رزرو اتاق تغییر می کند.

(1) GetCurrentEmailEventID

توسط تماس Webhook اجرا می شود.

استفاده از یک جبران معین به منظور حذف احتمالی لغو ، بدست آوردن داده های رویداد جاری.

(2) ApproveCurrentEvent

با کلیک کاربر اجرا می شود.

در صورت تأیید کاربر مبنی بر اینکه اتاق هنوز در حال استفاده است ، شناسه رویداد را از "اتاقهای حذف" حذف می کند. ما از یک صفحه Google استفاده کردیم ، هر شکل دیگری از لیست می تواند در اینجا مرتبط باشد.

(3) DeleteCurrentEvent

توسط تماس Webhook اجرا می شود.

جستجوی شناسه رویداد مربوطه در لیست (برگه Google) و حذف آن رویداد از تقویم.

مرحله 5: جریان را با کد آردوینو وصل کنید

کد پیوست شده به حسگرهایی که چند مرحله قبل بررسی کرده ایم به سیستم آنلاین متصل می شود (در مورد ما تقویم Google). این بررسی می کند که آیا اتاق مشغول است و سپس اگر نه ، یک درخواست HTTP (Webhook) ارسال می کند که درخواست حذف رویداد را در Zapier شروع می کند.

مرحله 6: مرور ، نتیجه گیری و مقیاس بندی آینده

اصلی ترین چالشی که ما باید با آن کنار بیاییم این است که هنگام تصمیم گیری برای آزادسازی اتاق جلسات ، تمام موارد حاشیه ای را پوشش دهیم. سپس ما مجبور شدیم با توجه به هر مورد احتمالی ، یک ماشین حالت ایجاد کنیم ، به گونه ای که خطایی رخ ندهد و اتاق فقط در مواقع لازم تنظیم شود.

به عنوان مثال ، اگر اتاق برای گروهی رزرو شده باشد که در حال حاضر آنجا نیستند (برای مثال در تعطیلات) ، اما هنوز به آن نیاز دارند ، NODEMCU تشخیص می دهد که اتاق رایگان است> PROBLEM.

سپس ، راه حل ما این بود که به کاربری که اتاق را رزرو کرده بود (که تشخیص آن ساده نبود) ایمیل ارسال کنیم که این امکان را برای نگه داشتن اتاق فراهم می کند.

اگر کاربر در زمان معینی پاسخ نداد (ما آن را 5 دقیقه تنظیم کردیم ، اما می توان آن را به راحتی تغییر داد) ، ما رویداد را از تقویم حذف می کنیم (و اتاق را آزاد می کنیم).

به این ترتیب ، ما در نهایت موفق شدیم همه سناریوهای ممکن را مدیریت کرده و یک سیستم کار ایجاد کنیم.

محدودیت های سیستم ما:

1. سنسورهای مورد استفاده باید بسیار دقیق و حساس باشند.

2. اندازه اتاق محدود به شعاع/محدوده سنسور است.

3. ما باید به پاسخگویی کاربر تکیه کنیم.

4. سیستم ما با استفاده از چندین پلتفرم (تقویم Google ، Gmail ، Zapier و غیره) ساخته شده است و باید از خدمات آنها برای اجرا استفاده کند.

5. مقیاس بندی این سرویس برای اتاق های متعدد (به جای تکراری شدن کل سیستم) نیاز به دستکاری اضافی با شناسه اتاق دارد.

6. سیستم فقط اتوماتیک است و گزینه ای برای لغو رزرو اتاق وجود ندارد.

توسعه های آینده:

ما قطعاً سیستم را به دو طریق مقیاس بندی می کنیم:

1. توانایی کار با سایر سیستم عامل های تقویم (بنابراین هر شرکت فضایی که می تواند از آن استفاده کند می تواند از آن استفاده کند).

2. توانایی اداره چندین اتاق ، طبقه و سایت.

ما معتقدیم که این نوع مقیاس 2-3 ماه طول می کشد تا ویژگی ها را تعمیم ، آزمایش و اضافه کنید.

علاوه بر این ، با استفاده از مقدار نامحدودی از پول و منابع ، از سنسورهای بهتر با دامنه بزرگتر ، به همراه سفارشی سازی آنها در اتاق تعیین شده - با در نظر گرفتن محدوده ، شعاع ، مقدار سنسورها و غیره استفاده می کنیم. گامی که نصب هر سیستم را طولانی تر کند ، به طور مشخص.