IDC2018IOT: Mødelokale Snitcher: 6 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:29

PROBLEMET

Som vi ved, har tendensen med samarbejdsrum accelereret i løbet af de sidste par år sammen med banebrydende teknologi, der definerer valget af det specifikke samarbejdsrum, der passer til dine behov.

En af de vigtigste funktioner, der tilbydes, er delte mødelokaler, der tilbydes medlemmerne af samarbejdsrummet, som administreres af en (normalt) enkel kalenderplatform.

Et problem opstår igen, når folk planlægger en tendens til at være dynamisk.

Man kan bestille et værelse og tro, at han måske har brug for det og ikke vil gå glip af tidsrummet.

Selvom man til sidst ikke ville bruge den tidslukke, gider han ikke meddele og annullere den af hensyn til andre, da det desværre er menneskelig natur.

HVORDAN LØSER VI DET?

Ved hjælp af IoT -teknologi - kontrol af lyd og bevægelse i et bestemt mødelokale kontrollerer vi hvert bestemte tidsinterval, om et værelse er reserveret og faktisk er optaget eller ej:

1. Hvis det ikke er reserveret, skal du ikke gøre noget.

2. Hvis det er reserveret, skal du kontrollere, om der er registreret bevægelse eller lyd;

Hvis der er noget, skal du ikke gøre noget.

Hvis der ikke blev fundet noget, skal du sende en advarselsmeddelelse (via e -mail) til den bruger, der reserverede lokalet, der spørger, om rummet stadig er i brug. medmindre brugeren erklærer, at han stadig bruger rummet, ændres værelsesstatus til "Tilgængelig".

* Her integrerede vi vores projekt med Google Kalender for at generalisere det så meget som muligt.

Trin 1: Hardware og protokoller påkrævet

1. Vi brugte NOSEMCU, så vi kunne opdatere tingene dynamisk ved hjælp af WIFI -forbindelsen.

2. Mikrofonsensor, der vil "læse" støj i rummet.

3. PIR -sensor, der kontrollerer, om der er bevægelse.

Til software og server brug, udover koden i Arduino, brugte vi Google Script og Zapier til at understøtte vores system online. Du kan se strømmen i det tilføjede billede (og PDF).

Vi brugte Zapier til at forbinde apps og automatisere vores arbejdsgange (f.eks. IFTTT), og vi brugte Google Script til at hjælpe os med at kommunikere med Google Kalender. Det script, vi skrev, producerer event -skabers e -mail, så vi kunne sende det med Zapier og kontrollere, om brugeren bad om at beholde rummet (ved at gemme nogle oplysninger i Google Sheets), før han slettede begivenheden.

Trin 2: Tilslut mikrofonen og PIR -sensoren

Vi ville kontrollere gennemsnitsværdierne, som mikrofonerne sender til NODEMCU, når folk taler (klart, i hvert rum havde forskellige baggrundslyde). Vi lavede nogle test og indså, at det gennemsnitlige støjniveau er det rum, vi arbejdede i, er et sted over 50.

PIR -sensoren giver kun HIGH eller LOW -værdier, så vi kontrollerede kun det følsomhedsniveau, der er det mest nøjagtige for det rum, vi kontrollerede. Denne guide var ret nyttig.

VORES FORBINDELSER:

Mikrofon - som på billedet PIR -sensor: GND> GND, OUT> D7, VCC> VN (5V)

Trin 3: Opret arbejdsgangen i Zapier

For at vide, om rummet rent faktisk er tomt eller stadig er i brug (og brugerne f.eks. Holder pause), vil vi gerne oprette et flow, der sikrer det, lige efter at NodeMCU har affyret en Webhook til Zapier, som giver besked om, at Værelset er tomt:

(1) TRIGGER - CATCH HOOKZapier fanger Webhook (der sendes af NODEMCU)

(2) HANDLING - GETZapier sender en anden Webhook for at hente hændelsesdata;> Den kalder (kører) en GoogleScript - GetCurrentEmailEventID (forklaring i det følgende trin) for at hente de aktuelle hændelsesdata - hændelsesnavn, hændelses -id, brugeremail.

(3) FILTER - KUN FORTSÆT HVIS

Fortsæt kun til det næste trin, hvis der i øjeblikket sker en begivenhed (enhver begivenhed) i kalenderen (VÆRELSE ER OPTAGET), ellers stopper den, da rummet er ledigt.

(4) HANDLING - GMAILZapier sender en e -mail via Gmail til brugeren, der reserverede lokalet (fik disse oplysninger i trin 2)

(5) HANDLING - FORSINKELSE FORLAD brugeren tid til at svare på e -mailen. - Hvis brugeren klikker på linket: ring (kør) GoogleScript - ApproveCurrentEvent (Derfor fjernes rummet fra listen 'Værelser, der skal slettes', og Værelset er stadig markeret som besat.)

(6) ACTION - GET Efter 5 minutter kalder Zapier (kører) GoogleScript - DeleteCurrentEvent- Hvis brugeren ikke klikker på linket

Kontrollerer, om værelses -id'et er på listen 'Værelser, der skal slettes'

det fjerner bare begivenheden.

Trin 4: Google Scripts

Da vi integrerede hele systemet, var GoogleScripts det trivielle valg af en IDE, og derfor brugte vi relevante Google Libraries. Ville ændre sig i henhold til værelsesreservationsplatformen.

(1) GetCurrentEmailEventID

Kører via et Webhook -opkald.

Brug af en bestemt forskydning for at eliminere mulig fejl-annullering, få de aktuelle hændelsesdata.

(2) ApproveCurrentEvent

Køres med et brugerklik.

I tilfælde af en brugers godkendelse af, at rummet stadig er i brug, sletter hændelses -id'et fra 'Værelserne, der skal slettes'. Vi brugte et Google -ark, enhver anden form for en liste kan være relevant her.

(3) DeleteCurrentEvent

Kører via et Webhook -opkald.

Søger efter det relevante hændelses -id på listen (Google -ark) og sletter denne begivenhed fra kalenderen.

Trin 5: Tilslut flowet med Arduino -koden

Den vedhæftede kode forbinder de sensorer, vi kontrollerede for et par trin siden, til onlinesystemet (Google -kalender i vores tilfælde). Det kontrollerer, om rummet er optaget, og hvis det ikke er det, sender det en HTTP -anmodning (en Webhook), der starter anmodningen om sletning af begivenheder på Zapier.

Trin 6: Gennemgang, konklusioner og fremtidig skalering

Den største udfordring, vi var nødt til at håndtere, er at dække alle kantsager, når vi beslutter at frigøre et mødelokale. Vi måtte derefter oprette en statsmaskine i betragtning af alle mulige tilfælde, således at der ikke opstår en fejl, og rummet kun indstilles som tilgængeligt, når det skulle.

For eksempel, hvis rummet er reserveret til en gruppe, der i øjeblikket ikke er der (f.eks. Holder pause), men stadig har brug for det, registrerer NODEMCU, at rummet er gratis> PROBLEM.

Derefter var vores løsning at e -maile den bruger, der reserverede værelset (hvilket ikke var let at finde ud af) en meddelelse, der giver mulighed for at blive ved med at holde rummet.

Hvis brugeren ikke svarede på et givet tidspunkt (vi indstillede det til 5 minutter, men det kan let ændres), sletter vi begivenheden fra kalenderen (og frigør rummet).

På den måde lykkedes det til sidst at håndtere alle mulige scenarier og skabe et fungerende system.

VORES SYSTEMBEGRÆNSNINGER:

1. De brugte sensorer skal være meget præcise og følsomme.

2. Rumstørrelsen er begrænset til sensorens radius/rækkevidde.

3. Vi bliver nødt til at stole på brugerens lydhørhed.

4. Vores system er bygget ved hjælp af flere platforme (Google kalender, Gmail, Zapier osv.) Og skal bruge deres service til at udføre.

5. Skalering af denne service for flere rum (i stedet for kopiering af hele systemet) kræver en ekstra håndtering med rum -ID.

6. Systemet er kun automatisk, og der er ikke en manuel mulighed for at annullere en værelsesreservation.

FREMTIDIGE UDVIKLINGER:

Vi ville helt sikkert opskalere systemet på to måder:

1. Evne til at arbejde med andre kalenderplatforme (så enhver virksomhed i et samarbejdsrum kan bruge det).

2. Evne til at håndtere flere rum, gulve og steder.

Vi mener, at denne form for skala vil tage 2-3 måneder at generalisere, teste og tilføje flere rum (etager osv.).

Derudover ville vi bruge en ubegrænset mængde penge og ressourcer til at bruge bedre sensorer med et større område sammen med at tilpasse dem til det udpegede rum - i betragtning af rækkevidde, radius, mængde sensorer osv. Et trin, der ville få hvert system til at installere længere, naturligvis.