IDC2018IOT: Meeting Room Snitcher: 6 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:24

PROBLEMET

Som vi vet har trenden med samarbeidsrom blitt akselerert de siste årene, sammen med den nyeste teknologien som definerer valget av det spesifikke samarbeidsområdet som passer for dine behov.

En av hovedfunksjonene som tilbys er delte møterom som tilbys medlemmene i samarbeidsområdet, som administreres av en (vanligvis) enkel kalenderplattform.

Et problem oppstår igjen når folk planlegger en tendens til å være dynamiske.

Man kan bestille et rom og tenke at han kanskje trenger det og ikke vil gå glipp av tidsluken.

Selv om man ikke ville bruke den tidsluken til slutt, vil han ikke gidde å varsle og avbryte den av hensyn til andre, ettersom det dessverre er menneskelig natur.

HVORDAN LØSER VI DET?

Ved å bruke IoT -teknologi - sjekke lyd og bevegelse i et bestemt møterom, sjekker vi hvert bestemte tidsintervall om et rom er booket og faktisk er okkupert eller ikke:

1. Hvis det ikke er bestilt, ikke gjør noe.

2. Hvis den er booket, sjekk om det er noen bevegelse eller lyd oppdaget;

Hvis det er det, ikke gjør noe.

Hvis ingenting ble oppdaget, send en advarsel (via e -post) til brukeren som bestilte rommet som spør om rommet fortsatt er i bruk. med mindre brukeren erklærer at han fortsatt bruker rommet, endres romstatusen til "Tilgjengelig".

* Her integrerte vi prosjektet vårt med Google Kalender for å generalisere det så mye som mulig.

Trinn 1: Nødvendig maskinvare og protokoller

1. Vi brukte NOSEMCU slik at vi kunne oppdatere ting dynamisk ved hjelp av WIFI -tilkoblingen.

2. Mikrofonsensor som vil "lese" støyen i rommet.

3. PIR -sensor som kontrollerer om det er bevegelse.

For programvare og serverbruk, foruten koden i Arduino, brukte vi Google Script og Zapier for å støtte systemet vårt online. Du kan se flyten i det lagt til bildet (og PDF).

Vi brukte Zapier til å koble til apper og automatisere arbeidsflytene våre (som IFTTT), og vi brukte Google Script for å hjelpe oss med å kommunisere med Google Kalender. Skriptet vi skrev produserer hendelsesskaperen sin e -post, slik at vi kunne sende den med Zapier og sjekke om brukeren ba om å få beholde rommet (ved å lagre litt informasjon i Google Regneark) før han sletter hendelsen.

Trinn 2: Koble mikrofonen og PIR -sensoren

Vi ønsket å sjekke gjennomsnittsverdiene mikrofonen legger inn på NODEMCU når folk snakker (tydelig, i hvert rom hadde forskjellige bakgrunnslyder). Vi testet og innså at det gjennomsnittlige støynivået i rommet vi jobbet i er et sted over 50.

PIR -sensoren gir bare høye eller lave verdier, så vi kontrollerte bare følsomhetsnivået som er mest nøyaktig for rommet vi sjekket. Denne guiden var ganske nyttig.

VÅRE TILKOBLINGER:

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

Trinn 3: Lag arbeidsflyten i Zapier

For å vite om rommet faktisk er tomt eller fortsatt er i bruk (og brukerne er for eksempel på pause), vil vi gjerne opprette en flyt som sikrer det, rett etter at NodeMCU avfyrte en Webhook til Zapier som varsler at rommet er tomt:

(1) TRIGGER - CATCH HOOKZapier fanger Webhook (som vil bli sendt av NODEMCU)

(2) ACTION - GETZapier sender en annen Webhook for å få hendelsesdata;> Den kaller (kjører) en GoogleScript - GetCurrentEmailEventID (forklaring i det følgende trinnet), for å få gjeldende hendelsesdata - hendelsesnavn, hendelses -ID, bruker -e -post.

(3) FILTER - KUN FORTSETT HVIS

Fortsett til neste trinn bare hvis det er en hendelse (enhver hendelse) som for øyeblikket skjer i kalenderen (ROM ER OPPSATT), ellers stopper det når rommet er ledig.

(4) HANDLING - GMAILZapier sender en e -post, via Gmail, til brukeren som bestilte rommet (fikk denne informasjonen i trinn 2)

(5) HANDLING - FORSINKELSE FOR La brukeren tid til å svare på e -posten. - Hvis brukeren klikker på lenken: ring (kjør) GoogleScript - ApproveCurrentEvent (Derfor blir rommet fjernet fra listen 'Rom for å slette', og rommet er fortsatt merket som opptatt.)

(6) HANDLING - FÅ Etter 5 minutter ringer (kjører Zapier) GoogleScript - DeleteCurrentEvent- Hvis brukeren ikke klikket på lenken

Kontrollerer om rom -ID er i listen "Rom som skal slettes"

det bare fjerner hendelsen.

Trinn 4: Google Scripts

Da vi integrerte hele systemet, var GoogleScripts det trivielle valget av en IDE. Derfor brukte vi relevante Google Libraries. Ville endret seg i henhold til rombestillingsplattformen.

(1) GetCurrentEmailEventID

Kjøres av en Webhook -samtale.

Bruke en viss forskyvning for å eliminere mulig feil-kansellering, få gjeldende hendelsesdata.

(2) ApproveCurrentEvent

Kjøres av et brukerklikk.

I tilfelle en bruker godkjenner at rommet fortsatt er i bruk, sletter hendelses -ID -en ut av "Rom som skal slettes". Vi brukte et Google -ark. Enhver annen listeform kan være relevant her.

(3) DeleteCurrentEvent

Kjøres av en Webhook -samtale.

Søker etter den relevante hendelses -ID -en i listen (Google -ark) og sletter hendelsen fra kalenderen.

Trinn 5: Koble strømmen med Arduino -koden

Den vedlagte koden kobles til sensorene vi sjekket for noen få skritt siden til nettsystemet (Google -kalender i vårt tilfelle). Den sjekker om rommet er opptatt, og hvis det ikke er det, sender det en HTTP -forespørsel (en Webhook) som starter forespørselen om sletting av hendelser på Zapier.

Trinn 6: Gjennomgang, konklusjoner og fremtidig skalering

Hovedutfordringen vi måtte håndtere er å dekke alle kantsakene når vi bestemmer oss for å frigjøre et møterom. Vi måtte da opprette en statsmaskin som vurderer alle mulige tilfeller, slik at det ikke oppstår en feil og rommet blir angitt som tilgjengelig bare når det skal.

For eksempel, hvis rommet er bestilt for en gruppe som for øyeblikket ikke er der (for eksempel på pause), men fortsatt trenger det, vil NODEMCU oppdage at rommet er ledig> PROBLEM.

Deretter var løsningen vår å sende brukeren som bestilte rommet (som ikke var lett å finne ut) en e -postmelding som gir mulighet til å fortsette å holde rommet.

Hvis brukeren ikke svarte på en gitt tid (vi satte det til 5 minutter, men det kan enkelt endres), sletter vi hendelsen fra kalenderen (og frigjør rommet).

På den måten lyktes vi til slutt å håndtere alle mulige scenarier og lage et fungerende system.

VÅRE SYSTEMBEGRENSNINGER:

1. De brukte sensorene må være veldig nøyaktige og følsomme.

2. Romstørrelsen er begrenset til sensorens radius/rekkevidde.

3. Vi må stole på brukerens respons.

4. Systemet vårt er bygget med flere plattformer (Google -kalender, Gmail, Zapier etc.) og må bruke tjenesten deres for å utføre.

5. Skalering av denne tjenesten for flere rom (i stedet for duplisering av hele systemet) krever en ekstra håndtering med rom -ID.

6. Systemet er bare automatisk, og det er ikke et manuelt alternativ for å kansellere rombestilling.

FREMTIDIGE UTVIKLINGER:

Vi ville definitivt skalere opp systemet på to måter:

1. Evne til å jobbe med andre kalenderplattformer (slik at ethvert samarbeidende selskapsselskap kan bruke det).

2. Evne til å håndtere flere rom, gulv og steder.

Vi tror at denne typen skala vil ta 2-3 måneder å generalisere, teste og legge til flere rom (etasjer osv.).

I tillegg ville vi ved å bruke et ubegrenset beløp med penger og ressurser bruke bedre sensorer med et større område, sammen med å tilpasse dem til det angitte rommet - med tanke på rekkevidde, radius, mengde sensorer osv. Et trinn som ville få hvert system til å installere lenger, åpenbart.