IDC2018IOT: Sala de reuniones Snitcher: 6 pasos

2024 Autor: John Day | [email protected]. Última modificación: 2024-01-30 08:43

EL PROBLEMA

Como sabemos, la tendencia de los espacios de coworking se ha ido acelerando en los últimos años, junto con la tecnología de vanguardia que define la elección del espacio de coworking específico que se adapta a sus necesidades.

Una de las principales características que se ofrecen son las salas de reuniones compartidas que se ofrecen a los miembros del espacio de coworking, que se gestiona mediante una plataforma de calendario (normalmente) sencilla.

Un problema vuelve a ocurrir ya que la programación de las personas tiende a ser dinámica.

Uno podría reservar una habitación pensando que podría necesitarla y no querría perderse el horario.

Incluso si uno no usa ese intervalo de tiempo eventualmente, no se molestará en notificarlo y cancelarlo por el bien de los demás, ya que, desafortunadamente, esa es la naturaleza humana.

¿COMO LO RESOLVEMOS?

Utilizando la tecnología de IoT, comprobando el sonido y el movimiento en una sala de reuniones designada, comprobamos, cada cierto intervalo de tiempo, si una sala está reservada y realmente ocupada o no:

1. Si no está reservado, no haga nada.

2. Si está reservado, verifique si hay algún movimiento o sonido detectado;

Si lo hay, no haga nada.

Si no se detectó nada, envíe un mensaje de advertencia (por correo electrónico) al usuario que reservó la habitación que pregunta si la habitación todavía está en uso. A menos que el usuario declare que todavía está usando la habitación, el estado de la habitación cambiará a "Disponible".

* Aquí, integramos nuestro proyecto con Google Calendar para generalizarlo tanto como sea posible.

Paso 1: hardware y protocolos necesarios

1. Usamos NOSEMCU para poder actualizar las cosas dinámicamente usando la conexión WIFI.

2. Sensor de micrófono que "leerá" el ruido en la habitación.

3. Sensor PIR que comprobará si hay algún movimiento.

Para el uso de software y servidor, además del código en Arduino, usamos Google Script y Zapier para respaldar nuestro sistema en línea. Puede ver el flujo en la imagen agregada (y PDF).

Usamos Zapier para conectar aplicaciones y automatizar nuestros flujos de trabajo (como IFTTT) y usamos Google Script para ayudarnos a comunicarnos con Google Calendar. El guión que escribimos está produciendo el correo electrónico del creador del evento para que podamos enviarlo a Zapier y verifica si el usuario pidió mantener la sala (guardando información en Google Sheets) antes de eliminar el evento.

Paso 2: conecte el micrófono y el sensor PIR

Queríamos verificar los valores promedio que el micrófono envía al NODEMCU cuando la gente está hablando (claramente, en cada habitación había diferentes ruidos de fondo). Hicimos algunas pruebas y nos dimos cuenta de que el nivel de ruido promedio en la habitación en la que trabajamos está por encima de 50.

El sensor PIR solo da valores ALTO o BAJO, por lo que solo verificamos el nivel de sensibilidad que es más preciso para la habitación que verificamos. Esta guía fue muy útil.

NUESTRAS CONEXIONES:

Micrófono - como en la imagen Sensor PIR: GND> GND, OUT> D7, VCC> VN (5V)

Paso 3: crea el flujo de trabajo en Zapier

Para saber si la sala está realmente vacía o todavía en uso (y los usuarios están en un descanso, por ejemplo), nos gustaría crear un flujo que lo asegure, justo después de que NodeMCU dispara un Webhook a Zapier que notifica que el la habitación está vacía:

(1) TRIGGER - CATCH HOOKZapier captura el Webhook (que será enviado por NODEMCU)

(2) ACCIÓN - GETZapier envía otro Webhook para obtener los datos del evento;> Llama (ejecuta) un GoogleScript - GetCurrentEmailEventID (explicación en el siguiente paso), para obtener los datos del evento actual - nombre del evento, ID del evento, correo electrónico del usuario.

(3) FILTRO - SÓLO CONTINÚE SI

Continúe con el siguiente paso solo si hay un evento (cualquier evento) que esté sucediendo actualmente en el calendario (LA HABITACIÓN ESTÁ OCUPADA); de lo contrario, se detiene porque la sala está vacía.

(4) ACCIÓN: GMAILZapier envía un correo electrónico, a través de Gmail, al usuario que reservó la habitación (obtuvo esta información en el paso 2)

(5) ACCIÓN - RETRASO PARA Deje que el usuario tenga tiempo para responder al correo electrónico.- Si el usuario hace clic en el enlace: llame (ejecute) GoogleScript - ApproveCurrentEvent (Por lo tanto, la sala se elimina de la lista 'Habitaciones para eliminar' y el la habitación todavía está marcada como ocupada.)

(6) ACCIÓN - OBTENER Después de 5 minutos, Zapier llama (ejecuta) GoogleScript - DeleteCurrentEvent- Si el usuario no hizo clic en el enlace

Comprueba si el ID de la habitación está en la lista 'Salas para eliminar'

simplemente elimina el evento.

Paso 4: Google Scripts

Como integramos todo el sistema, GoogleScripts fue la elección trivial de un IDE. Por lo tanto, usamos Bibliotecas de Google relevantes. Cambiaría según la plataforma de reserva de habitaciones.

(1) GetCurrentEmailEventID

Se ejecuta mediante una llamada de Webhook.

Usar un cierto desplazamiento para eliminar una posible cancelación errónea, obteniendo los datos del evento actual.

(2) ApproveCurrentEvent

Se ejecuta mediante un clic de usuario.

En caso de que un usuario apruebe que la sala todavía está en uso, elimina el ID del evento de las 'Salas para eliminar'. Usamos una hoja de Google, cualquier otra forma de lista podría ser relevante aquí.

(3) DeleteCurrentEvent

Se ejecuta mediante una llamada de Webhook.

Busca el ID del evento relevante en la lista (hoja de Google) y elimina ese evento del calendario.

Paso 5: conecta el flujo con el código Arduino

El código adjunto se conecta a los sensores que verificamos hace unos pasos al sistema en línea (calendario de Google en nuestro caso). Comprueba si la sala está ocupada y luego, si no lo está, envía una solicitud HTTP (un Webhook) que inicia la solicitud de eliminación de eventos en Zapier.

Paso 6: revisión, conclusiones y escalado futuro

El principal desafío al que nos enfrentamos es cubrir todos los casos extremos a la hora de decidir liberar una sala de reuniones. Luego tuvimos que crear una máquina de estado considerando todos los casos posibles, de modo que no ocurriera un error y la sala se configurara como disponible solo cuando debería.

Por ejemplo, si la sala está reservada para algún grupo que actualmente no está allí (que está en un descanso, por ejemplo), pero aún lo necesita, NODEMCU detectará que la sala está libre> PROBLEMA.

Luego, nuestra solución fue enviar un correo electrónico al usuario que reservó la habitación (lo cual no fue fácil de entender) con un mensaje que brinda la opción de mantener la habitación.

Si el usuario no respondió en un tiempo determinado (lo configuramos en 5 minutos, pero se puede cambiar fácilmente), eliminamos el evento del calendario (y liberamos la sala).

De esa manera, finalmente logramos manejar todos los escenarios posibles y crear un sistema de trabajo.

LIMITACIONES DE NUESTRO SISTEMA:

1. Los sensores utilizados deben ser muy precisos y sensibles.

2. El tamaño de la habitación está limitado al radio / rango del sensor.

3. Tendremos que confiar en la capacidad de respuesta del usuario.

4. Nuestro sistema está construido utilizando varias plataformas (calendario de Google, Gmail, Zapier, etc.) y tendrá que utilizar su servicio para funcionar.

5. La ampliación de este servicio para varias salas (en lugar de duplicar todo el sistema) requerirá un tratamiento adicional con la identificación de la sala.

6. El sistema es solo automático y no hay una opción manual para cancelar una reserva de habitación.

FUTUROS DESARROLLOS:

Definitivamente ampliaríamos el sistema de dos maneras:

1. Capacidad para trabajar con cualquier otra plataforma de calendario (por lo que cualquier empresa de espacios de coworking podría utilizarla).

2. Capacidad para manejar múltiples habitaciones, pisos y sitios.

Creemos que este tipo de escala tomará de 2 a 3 meses para generalizar, probar y agregar características de varias habitaciones (pisos, etc.).

Además, utilizando una cantidad ilimitada de dinero y recursos, usaríamos mejores sensores con un rango más amplio, además de personalizarlos para la habitación designada, considerando el rango, el radio, la cantidad de sensores, etc. Un paso que haría que la instalación de cada sistema fuera más larga. obviamente.