IDC2018IOT: Снайпер за заседателна зала: 6 стъпки

2024 Автор: John Day | [email protected]. Последно модифициран: 2024-01-30 07:53

ПРОБЛЕМЪТ

Както знаем, тенденцията за пространства за съвместна работа се ускорява през последните няколко години, заедно с авангардна технология, определяща избора на конкретното пространство за съвместна работа, което отговаря на вашите нужди.

Една от основните предлагани функции са споделени заседателни зали, предлагани на членовете на пространството за съвместна работа, която се управлява от (обикновено) проста календарна платформа.

Проблем се появява отново, тъй като графикът на хората е динамичен.

Човек може да резервира стая, мислейки, че може да се нуждае от него и не би искал да пропусне времевия интервал.

Дори и човек да не използва този времеви интервал в крайна сметка, той няма да си направи труда да го уведоми и отмени заради другите, тъй като, за съжаление, това е човешката природа.

КАК СЕ РЕШАВАМЕ?

Използвайки IoT технологията - проверка на звука и движението в определена заседателна зала, ние проверяваме на всеки определен интервал от време дали една стая е резервирана и действително заета или не:

1. Ако не е резервиран, не правете нищо.

2. Ако е резервиран, проверете дали има открити движения или звук;

Ако има, не правете нищо.

Ако нищо не е открито, изпратете предупредително съобщение (по имейл) до потребителя, който е резервирал стаята, и пита дали стаята все още се използва. освен ако потребителят не декларира, че все още използва стаята, състоянието на стаята ще бъде променено на „Налично“.

* Тук интегрирахме нашия проект с Google Календар, за да го обобщим колкото е възможно повече.

Стъпка 1: Необходими са хардуер и протоколи

1. Използвахме NOSEMCU, за да можем динамично да актуализираме нещата, използвайки WIFI връзката.

2. Сензор за микрофон, който ще "чете" шума в стаята.

3. PIR сензор, който ще провери дали има някакво движение.

За използване на софтуер и сървър, освен кода в Arduino, използвахме Google Script и Zapier, за да поддържаме нашата система онлайн. Можете да видите потока в добавената картина (и PDF).

Използвахме Zapier за свързване на приложения и автоматизиране на нашите работни потоци (като IFTTT) и използвахме Google Script, за да ни помогнем да общуваме с Google Календар. Сценарият, който написахме, създава имейла на създателя на събитието, за да можем да го изпратим, хвърли Zapier и проверява дали потребителят е поискал да задържи стаята (като запази малко информация в Google Sheets), преди да изтрие събитието.

Стъпка 2: Свържете микрофона и PIR сензора

Искахме да проверим средните стойности, които микрофонът изпраща към NODEMCU, когато хората говорят (ясно, че във всяка стая имаше различни фонови шумове). Направихме някои тестове и разбрахме, че средното ниво на шум в стаята, в която работихме, е някъде над 50.

PIR сензорът дава само ВИСОКИ или НИСКИ стойности, така че проверихме само нивото на чувствителност, което е най -точно за стаята, която проверихме. Това ръководство беше доста полезно.

НАШИТЕ ВРЪЗКИ:

Микрофон - като на снимката PIR сензор: GND> GND, OUT> D7, VCC> VN (5V)

Стъпка 3: Създайте работния поток в Zapier

За да разберем дали стаята действително е празна или все още се използва (и потребителите са на почивка например), бихме искали да създадем поток, който да го гарантира, веднага след като NodeMCU задейства Webhook към Zapier, който уведомява, че стаята е празна:

(1) TRIGGER - COTCH HOOK Zapier улавя Webhook (това ще бъде изпратено от NODEMCU)

(2) ДЕЙСТВИЕ - GETZapier изпраща друг Webhook, за да получи данните за събитието;> Извиква (изпълнява) GoogleScript - GetCurrentEmailEventID (обяснение в следващата стъпка), за да получи данните за текущото събитие - име на събитие, идентификатор на събитие, имейл на потребителя.

(3) ФИЛТЪР - САМО ПРОДЪЛЖИ АКО

Продължете към следващата стъпка само ако в календара има събитие (всяко събитие) (ROOM IS BUSY), в противен случай спира, тъй като стаята е свободна.

(4) ДЕЙСТВИЕ - GMAILZapier изпраща имейл, чрез Gmail, до потребителя, който е резервирал стаята (получи тази информация в стъпка 2)

(5) ДЕЙСТВИЕ - ЗАБАВЯНЕ ЗА Оставете на потребителя време да отговори на имейла. - Ако потребителят кликне върху връзката: обадете се (стартирайте) GoogleScript - ApproveCurrentEvent (Следователно стаята се премахва от списъка „Стаи за изтриване“и стаята все още е маркирана като заета.)

(6) ДЕЙСТВИЕ - ВЗЕМЕТЕ След 5 минути Zapier извиква (изпълнява) GoogleScript - DeleteCurrentEvent- Ако потребителят не е щракнал върху връзката

Проверява дали идентификационният номер на стаята е в списъка „Стаи за изтриване“

просто премахва събитието.

Стъпка 4: Google Scripts

Тъй като интегрирахме цялата система, GoogleScripts беше тривиалният избор на IDE. По този начин използвахме съответните библиотеки на Google. Ще се промени според Платформата за резервация на стаи.

(1) GetCurrentEmailEventID

Изпълнява се чрез повикване чрез Webhook.

Използване на определен офсет, за да се елиминира евентуалното пропускане, получаване на данните за текущото събитие.

(2) ApproveCurrentEvent

Работи с кликване на потребител.

В случай на одобрение от потребителя, че стаята все още се използва, изтрива идентификатора на събитието от „Стаите за изтриване“. Използвахме лист на Google, всяка друга форма на списък може да бъде от значение тук.

(3) DeleteCurrentEvent

Изпълнява се чрез повикване чрез Webhook.

Търси съответния идентификационен номер на събитието в списъка (лист на Google) и изтрива това събитие от календара.

Стъпка 5: Свържете потока с кода на Arduino

Прикаченият код се свързва със сензорите, които проверихме преди няколко стъпки, към онлайн системата (Google календар в нашия случай). Той проверява дали стаята е заета и след това, ако не е, изпраща HTTP заявка (Webhook), която стартира заявката за изтриване на събитие в Zapier.

Стъпка 6: Преглед, заключения и мащабиране на бъдещето

Основното предизвикателство, с което трябваше да се справим, е да покрием всички крайни случаи, когато решаваме да освободим заседателна зала. След това трябваше да създадем машина за състоянието, обмисляща всеки възможен случай, така че да не възникне грешка и стаята да бъде настроена като налична само когато трябва.

Например, ако стаята е резервирана за група, която в момента не е там (която е на почивка, например), но все още се нуждае от нея, NODEMCU ще открие, че стаята е свободна> ПРОБЛЕМ.

След това нашето решение беше да изпратим имейл на потребителя, който е резервирал стаята (което не беше лесно да се разбере), съобщение, което предоставя възможност да продължи да държи стаята.

Ако потребителят не е отговорил за определен период от време (зададохме го на 5 минути, но може лесно да се промени), изтриваме събитието от календара (и освобождаваме стаята).

По този начин в крайна сметка успяхме да се справим с всички възможни сценарии и да създадем работеща система.

НАШИТЕ ОГРАНИЧЕНИЯ НА СИСТЕМАТА:

1. Използваните сензори трябва да бъдат много точни и чувствителни.

2. Размерът на стаята е ограничен до радиуса/диапазона на сензора.

3. Ще трябва да разчитаме на отзивчивостта на потребителите.

4. Нашата система е изградена с помощта на няколко платформи (Google календар, Gmail, Zapier и т.н.) и ще трябва да използва тяхната услуга за изпълнение.

5. Мащабирането на тази услуга за множество стаи (вместо дублиране на цялата система) ще изисква допълнителна обработка с ID на стаята.

6. Системата е само автоматична и няма ръчна опция за отмяна на резервация за стая.

БЪДЕЩИ РАЗВИТИЯ:

Определено бихме разширили системата по два начина:

1. Възможност за работа с всякакви други календарни платформи (така че всяка компания за съвместни работни пространства да може да го използва).

2. Възможност за работа с множество стаи, етажи и обекти.

Вярваме, че този мащаб ще отнеме 2-3 месеца за обобщаване, тестване и добавяне на множество функции (етажи и т.н.).

Освен това, използвайки неограничено количество пари и ресурси, бихме използвали по -добри сензори с по -голям обхват, заедно с персонализирането им в определеното помещение - като се има предвид обхват, радиус, количество сензори и т.н. очевидно.