IDC2018IOT: Снитчер для конференц-зала: 6 шагов

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

ЭТА ПРОБЛЕМА

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

Одна из основных предлагаемых функций - это общие конференц-залы, предлагаемые участникам коворкинга, которые управляются (обычно) простой календарной платформой.

Проблема повторяется, поскольку график людей имеет тенденцию быть динамичным.

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

Даже если кто-то в конечном итоге не воспользуется этим временным интервалом, он не потрудится уведомить и отменить его ради других, что, к сожалению, такова человеческая природа.

КАК МЫ РЕШАЕМ?

Используя технологию IoT - проверяя звук и движение в назначенном конференц-зале, мы проверяем через каждый определенный промежуток времени, забронирована ли комната и действительно ли она занята или нет:

1. Если он не забронирован, ничего не делайте.

2. Если это забронировано, проверьте, не обнаружено ли движение или звук;

Если есть, ничего не делайте.

Если ничего не обнаружено, отправьте предупреждающее сообщение (по электронной почте) пользователю, который забронировал номер, с вопросом, используется ли еще комната. если пользователь не заявит, что он все еще использует комнату, статус комнаты будет изменен на «Доступен».

* Здесь мы интегрировали наш проект с Google Calendar, чтобы максимально обобщить его.

Шаг 1. Необходимое оборудование и протоколы

1. Мы использовали NOSEMCU, чтобы можно было обновлять данные динамически, используя соединение WIFI.

2. Датчик микрофона, который «считывает» шум в комнате.

3. Датчик PIR, который проверяет, есть ли движение.

Для программного обеспечения и использования сервера, помимо кода в Arduino, мы использовали Google Script и Zapier для поддержки нашей системы в Интернете. Вы можете увидеть поток на добавленном изображении (и PDF).

Мы использовали Zapier для подключения приложений и автоматизации наших рабочих процессов (например, IFTTT), и мы использовали Google Script, чтобы помочь нам общаться с Календарем Google. Сценарий, который мы написали, создает электронную почту создателя события, чтобы мы могли отправить его с помощью Zapier и проверять, попросил ли пользователь удерживать комнату (путем сохранения некоторой информации в Google Таблицах) перед удалением события.

Шаг 2: Подключите микрофон и датчик PIR

Мы хотели проверить средние значения микрофонов, выводимых на NODEMCU, когда люди разговаривают (очевидно, в каждой комнате были разные фоновые шумы). Мы провели небольшое тестирование и поняли, что средний уровень шума в комнате, в которой мы работали, где-то выше 50.

Датчик PIR дает только ВЫСОКИЕ или НИЗКИЕ значения, поэтому мы проверили только тот уровень чувствительности, который является наиболее точным для проверяемой комнаты. Это руководство было очень полезным.

НАШИ ПОДКЛЮЧЕНИЯ:

Микрофон - как на картинке ИК-датчик: GND> GND, OUT> D7, VCC> VN (5V)

Шаг 3. Создайте рабочий процесс в Zapier

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

(1) TRIGGER - CATCH HOOK Zapier ловит Webhook (который будет отправлен NODEMCU)

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

(3) ФИЛЬТР - ПРОДОЛЖИТЬ ТОЛЬКО ЕСЛИ

Переходите к следующему шагу только в том случае, если в календаре в данный момент происходит событие (любое событие) (НОМЕР ЗАНЯТО), в противном случае он останавливается, поскольку комната свободна.

(4) ДЕЙСТВИЕ - GMAILZapier отправляет электронное письмо через Gmail пользователю, который забронировал номер (получил эту информацию на шаге 2).

(5) ДЕЙСТВИЕ - ЗАДЕРЖКА: Дайте пользователю время ответить на электронное письмо. - Если пользователь нажимает ссылку: вызовите (запустите) GoogleScript - ApproveCurrentEvent (Следовательно, комната удаляется из списка «Комнаты для удаления», а комната все еще помечена как занятая.)

(6) ДЕЙСТВИЕ - ПОЛУЧИТЬ Через 5 минут Zapier вызывает (запускает) GoogleScript - DeleteCurrentEvent - Если пользователь не щелкнул ссылку

Проверяет, есть ли ID комнаты в списке "Комнаты для удаления"

он просто убирает событие.

Шаг 4: скрипты Google

Поскольку мы интегрировали всю систему, GoogleScripts был тривиальным выбором в качестве IDE, поэтому мы использовали соответствующие библиотеки Google. Изменится в соответствии с платформой бронирования номеров.

(1) GetCurrentEmailEventID

Запускается по вызову Webhook.

Использование определенного смещения для исключения возможного пропуска отмены, получение данных о текущем событии.

(2) ApproveCurrentEvent

Запускается по щелчку пользователя.

В случае утверждения пользователем того, что комната все еще используется, удаляет идентификатор события из «Комнаты для удаления». Мы использовали лист Google, здесь может быть уместна любая другая форма списка.

(3) DeleteCurrentEvent

Запускается по вызову Webhook.

Выполняет поиск соответствующего идентификатора события в списке (лист Google) и удаляет это событие из календаря.

Шаг 5: соедините поток с кодом Arduino

Приложенный код подключает датчики, которые мы проверили несколько шагов назад, к онлайн-системе (в нашем случае календарь Google). Он проверяет, занята ли комната, а затем, если нет, отправляет HTTP-запрос (веб-перехватчик), который запускает запрос события удаления на Zapier.

Шаг 6: Обзор, выводы и будущее масштабирование

Основная задача, с которой нам пришлось столкнуться, - это охватить все крайние случаи при принятии решения об освобождении конференц-зала. Затем нам пришлось создать конечный автомат с учетом всех возможных случаев, чтобы ошибки не возникали, а комната была установлена как доступная только тогда, когда это необходимо.

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

Затем мы решили отправить по электронной почте пользователю, который забронировал номер (что было непросто понять), сообщение, в котором можно было оставить номер у себя.

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

Таким образом, нам в итоге удалось обработать все возможные сценарии и создать работающую систему.

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

1. Используемые датчики должны быть очень точными и чувствительными.

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

3. Придется полагаться на отзывчивость пользователей.

4. Наша система построена с использованием нескольких платформ (календарь Google, Gmail, Zapier и т. Д.), И для ее работы придется использовать их сервис.

5. Масштабирование этой услуги для нескольких комнат (вместо дублирования всей системы) потребует дополнительной обработки с идентификатором комнаты.

6. Система работает только автоматически, и нет возможности вручную отменить бронирование номера.

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

Мы определенно масштабируем систему двумя способами:

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

2. Возможность управлять несколькими комнатами, этажами и площадками.

Мы считаем, что такая шкала займет 2-3 месяца, чтобы обобщить, протестировать и добавить функцию нескольких комнат (этажей и т. Д.).

Кроме того, используя неограниченное количество денег и ресурсов, мы могли бы использовать более совершенные датчики с большим диапазоном, а также настраивать их для определенной комнаты - учитывая диапазон, радиус, количество датчиков и т. Д. Шаг, который увеличил бы время установки каждой системы, очевидно.