IDC2018IOT: Sala de reunions Snitcher: 6 passos

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:15

EL PROBLEMA

Com sabem, la tendència dels espais de treball compartit s’ha anat accelerant durant els darrers anys, juntament amb una tecnologia d’avantguarda que defineix l’elecció de l’espai específic de treball compartit que s’adapti a les vostres necessitats.

Una de les principals característiques que s’ofereixen són les sales de reunions compartides que s’ofereixen als membres de l’espai de treball compartit, que són gestionades per una plataforma de calendari (normalment) senzilla.

Es repeteix un problema ja que l’horari de les persones sol ser dinàmic.

Es pot reservar una habitació pensant que podria necessitar-la i no voldria perdre’s la franja horària.

Fins i tot si finalment no s’utilitzaria aquesta franja horària, no es molestarà en notificar-la i cancel·lar-la per altres, ja que, malauradament, això és naturalesa humana.

COM HO SOLUCIONEM?

Mitjançant la tecnologia IoT: comprovació del so i el moviment en una sala de reunions designada, comprovem, cada cert interval de temps, si hi ha una sala reservada i realment ocupada o no:

1. Si no està reservat, no feu res.

2. Si es reserva, comproveu si hi ha moviment o so detectat;

Si n'hi ha, no feu res.

Si no s'ha detectat res, envieu un missatge d'advertència (per correu electrònic) a l'usuari que ha reservat l'habitació i us pregunti si l'habitació encara està en ús. tret que l'usuari declari que encara utilitza la sala, l'estat de la sala es canviarà a "Disponible".

* Aquí hem integrat el nostre projecte amb Google Calendar per tal de generalitzar-lo al màxim.

Pas 1: Calen maquinari i protocols

1. Hem utilitzat NOSEMCU per poder actualitzar les coses dinàmicament mitjançant la connexió WIFI.

2. Sensor de micròfon que permetrà "llegir" el soroll de l'habitació.

3. Sensor PIR que comprovarà si hi ha algun moviment.

Per a l'ús de programari i servidor, a més del codi d'Arduino, hem utilitzat Google Script i Zapier per donar suport al nostre sistema en línia. Podeu veure el flux a la imatge afegida (i PDF).

Hem utilitzat Zapier per connectar aplicacions i automatitzar els nostres fluxos de treball (com IFTTT) i hem utilitzat Google Script per ajudar-nos a comunicar-nos amb Google Calendar. El guió que hem escrit està produint el correu electrònic del creador de l'esdeveniment per poder enviar-lo a Zapier i comprovar si l'usuari demanava mantenir la sala (desant informació a Fulls de càlcul de Google) abans de suprimir l'esdeveniment.

Pas 2: connecteu el micròfon i el sensor PIR

Volíem comprovar els valors mitjans dels missatges del micròfon al NODEMCU quan la gent parla (clarament, a cada habitació hi havia diferents sorolls de fons). Vam fer algunes proves i ens vam adonar que el nivell mitjà de soroll és que l’habitació on hem treballat és superior a 50.

El sensor PIR només proporciona valors ALT o BAIX, de manera que només hem comprovat el nivell de sensibilitat que és el més precís de l’habitació que hem comprovat. Aquesta guia va ser força útil.

LES NOSTRES CONNEXIONS:

Micròfon: com a la imatge Sensor PIR: GND> GND, OUT> D7, VCC> VN (5V)

Pas 3: creeu el flux de treball a Zapier

Per saber si l’habitació està realment buida o encara està en ús (i els usuaris estan en un descans, per exemple), ens agradaria crear un flux que l’asseguri, just després que el NodeMCU llanci un Webhook a Zapier que notifiqui que l'habitació està buida:

(1) TRIGGER - CATCH HOOKZapier atrapa el Webhook (que serà enviat pel NODEMCU)

(2) ACCIÓ: GETZapier envia un altre Webhook per obtenir les dades de l'esdeveniment;> Crida (executa) un GoogleScript - GetCurrentEmailEventID (explicació al pas següent) per obtenir les dades de l'esdeveniment actual: nom de l'esdeveniment, identificador de l'esdeveniment, correu electrònic de l'usuari.

(3) FILTRE: CONTINUEU NOMÉS SI

Continueu al pas següent només si hi ha un esdeveniment (qualsevol esdeveniment) que s'està produint actualment al calendari (L'HABITACIÓ ESTÀ OCUPADA); en cas contrari, s'aturarà perquè la sala estigui lliure.

(4) ACCIÓ: GMAILZapier envia un correu electrònic a través de Gmail a l'usuari que ha reservat l'habitació (ha obtingut aquesta informació al pas 2)

(5) ACCIÓ - RETARDAR Permetre a l’usuari el temps necessari per respondre al correu electrònic. Si l’usuari fa clic a l’enllaç: truqueu (executeu) el GoogleScript - ApproveCurrentEvent la sala encara es marca com a ocupada.)

(6) ACCIÓ: GET Després de 5 minuts, Zapier crida (executa) GoogleScript - DeleteCurrentEvent- Si l'usuari no ha fet clic a l'enllaç

Comprova si l'identificador d'habitació es troba a la llista "Sales a suprimir"

només elimina l'esdeveniment.

Pas 4: Google Scripts

A mesura que integràvem tot el sistema, GoogleScripts era l’elecció trivial d’un IDE. Per tant, hem utilitzat biblioteques rellevants de Google. Canviaria segons la plataforma de reserves d'habitacions.

(1) GetCurrentEmailEventID

S’executa mitjançant una trucada Webhook.

Utilitzant un cert desplaçament per tal d’eliminar la possible cancel·lació errònia, obtenint les dades actuals de l’esdeveniment.

(2) ApproveCurrentEvent

S'executa mitjançant un clic d'usuari.

En cas que l’usuari aprovi que la sala encara està en ús, elimineu l’identificador de l’esdeveniment de la secció “Sales a suprimir”. Hem utilitzat un full de Google, qualsevol altra forma de llista podria ser rellevant aquí.

(3) DeleteCurrentEvent

Funciona amb una trucada Webhook.

Cerca l'identificador d'esdeveniment rellevant a la llista (full de Google) i suprimeix l'esdeveniment del calendari.

Pas 5: connecteu el flux amb el codi Arduino

El codi adjunt es connecta als sistemes que vam comprovar fa uns passos al sistema en línia (calendari de Google en el nostre cas). Comprova si la sala està ocupada i, si no, envia una sol·licitud HTTP (un Webhook) que inicia la supressió de la sol·licitud d'esdeveniments a Zapier.

Pas 6: revisió, conclusions i escala futura

El principal repte que vam haver d’afrontar és cobrir tots els casos avantatjosos a l’hora de decidir alliberar una sala de reunions. Aleshores vam haver de crear una màquina d’estats tenint en compte tots els casos possibles, de manera que no es produís cap error i l’habitació es configurés com a disponible només quan hauria de ser-ho.

Per exemple, si la sala està reservada per a un grup que actualment no hi és (que està en un descans, per exemple), però que encara la necessita, NODEMCU detectarà que l'habitació és lliure> PROBLEMA.

Llavors, la nostra solució era enviar un missatge de correu electrònic a l’usuari que va reservar l’habitació (cosa que no era senzill d’entendre), que ofereix l’opció de mantenir la sala.

Si l'usuari no va respondre en un temps determinat (el vam establir a 5 minuts, però es pot canviar fàcilment), suprimim l'esdeveniment del calendari (i alliberem la sala).

D’aquesta manera, finalment vam aconseguir gestionar tots els escenaris possibles i crear un sistema de treball.

LES NOSTRES LIMITACIONS DEL SISTEMA:

1. Els sensors utilitzats han de ser molt precisos i sensibles.

2. La mida de l'habitació es limita al radi / abast del sensor.

3. Haurem de confiar en la capacitat de resposta de l'usuari.

4. El nostre sistema està construït mitjançant diverses plataformes (Google Calendar, Gmail, Zapier, etc.) i haurà d’utilitzar el seu servei per funcionar.

5. Escalar aquest servei per a diverses habitacions (en lloc de duplicar tot el sistema) requerirà un tractament addicional amb l'identificador d'habitació.

6. El sistema només és automàtic i no hi ha cap opció manual per cancel·lar la reserva d'una habitació.

DESENVOLUPAMENTS FUTURS:

Definitivament ampliaríem el sistema de dues maneres:

1. Capacitat per treballar amb qualsevol altra plataforma de calendari (de manera que qualsevol empresa d’espais de col·laboració en pugui fer servir).

2. Capacitat per manejar diverses habitacions, pisos i llocs.

Creiem que aquest tipus d’escala trigarà entre 2-3 mesos a generalitzar-se, provar i afegir la funció de diverses habitacions (pisos, etc.).

A més, utilitzant una quantitat il·limitada de diners i recursos, faríem servir millors sensors amb un abast més gran, juntament amb personalitzar-los a la sala designada, tenint en compte l'abast, el radi, la quantitat de sensors, etc. òbviament.