IDC2018IOT: Meeting Room Snitcher: 6 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:45

PROBLEMET

Som vi vet har trenden med samarbetsutrymmen accelererat under de senaste åren, tillsammans med spetsteknik som definierar valet av det specifika samarbetsutrymmet som passar dina behov.

En av de viktigaste funktionerna som erbjuds är delade mötesrum som erbjuds medlemmarna i samarbetsutrymmet, som hanteras av en (vanligtvis) enkel kalenderplattform.

Ett problem uppstår när människor schemaläggs tenderar att vara dynamiska.

Man kan boka ett rum och tro att han kanske behöver det och inte vill missa tidsluckan.

Även om man inte skulle använda den här tidsluckan så småningom, kommer han inte att bry sig om att meddela och avbryta den för andras skull, tyvärr är det mänsklig natur.

HUR LÖSER VI DET?

Med hjälp av IoT -teknik - kontroll av ljud och rörelse i ett särskilt mötesrum, kontrollerar vi varje visst tidsintervall om ett rum är bokat och faktiskt upptaget eller inte:

1. Om det inte är bokat, gör ingenting.

2. Om det är bokat, kontrollera om det finns någon rörelse eller ljud.

Om det finns, gör ingenting.

Om ingenting upptäcktes, skicka ett varningsmeddelande (via e -post) till användaren som bokade rummet som frågar om rummet fortfarande används. såvida inte användaren förklarar att han fortfarande använder rummet ändras rumsstatusen till "Tillgänglig".

* Här integrerade vi vårt projekt med Google Kalender för att generalisera det så mycket som möjligt.

Steg 1: Hårdvara och protokoll behövs

1. Vi använde NOSEMCU så att vi kunde uppdatera saker dynamiskt med hjälp av WIFI -anslutningen.

2. Mikrofonsensor som "läser" bruset i rummet.

3. PIR -sensor som kontrollerar om det finns någon rörelse.

För programvara och serveranvändning, förutom koden i Arduino, använde vi Google Script och Zapier för att stödja vårt system online. Du kan se flödet i den tillagda bilden (och PDF).

Vi använde Zapier för att ansluta appar och automatisera våra arbetsflöden (som IFTTT) och vi använde Google Script för att hjälpa oss att kommunicera med Google Kalender. Skriptet vi skrev producerar händelseskaparens e -post så att vi kan skicka det med Zapier och kontrollera om användaren bad om att få behålla rummet (genom att spara lite information i Google Kalkylark) innan han tar bort händelsen.

Steg 2: Anslut mikrofonen och PIR -sensorn

Vi ville kontrollera de genomsnittliga värdena som mikrofonen postar till NODEMCU när människor pratar (klart, i varje rum hade olika bakgrundsljud). Vi gjorde några tester och insåg att den genomsnittliga ljudnivån är det rum vi arbetade i är någonstans över 50.

PIR -sensorn ger bara HIGH eller LOW -värden så vi kontrollerade bara den känslighetsnivå som är den mest exakta för rummet vi kontrollerade. Denna guide var ganska hjälpsam.

VÅRA ANSLUTNINGAR:

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

Steg 3: Skapa arbetsflödet i Zapier

För att veta om rummet faktiskt är tomt eller fortfarande används (och användarna är till exempel paus), skulle vi vilja skapa ett flöde som säkerställer det, direkt efter att NodeMCU avfyrar en Webhook till Zapier som meddelar att rummet är tomt:

(1) TRIGGER - CATCH HOOKZapier fångar Webhook (som kommer att skickas av NODEMCU)

(2) ACTION - GETZapier skickar en annan Webhook för att hämta händelsedata;> Den kallar (kör) ett GoogleScript - GetCurrentEmailEventID (förklaring i följande steg), för att hämta den aktuella händelsesdata - händelsens namn, händelse -ID, användarmail.

(3) FILTER - FORTSÄTT ENDAST OM

Fortsätt bara till nästa steg om det finns en händelse (någon händelse) som för närvarande händer i kalendern (RUM ÄR UPPTAGET), annars stannar det när rummet är ledigt.

(4) ÅTGÄRD - GMAILZapier skickar ett e -postmeddelande via Gmail till användaren som bokade rummet (fick denna information i steg 2)

(5) ÅTGÄRD - FÖRDRÖJNING Låt användaren få tid att svara på e -postmeddelandet. - Om användaren klickar på länken: ring (kör) GoogleScript - ApproveCurrentEvent (Därför tas rummet bort från listan "Rum att radera" och rummet är fortfarande markerat som upptaget.)

(6) ÅTGÄRD - FÅ Efter 5 minuter ringer (körs) Zapier GoogleScript - DeleteCurrentEvent- Om användaren inte klickade på länken

Kontrollerar om rums -ID finns i listan "Rum att radera"

det tar bara bort händelsen.

Steg 4: Google Scripts

När vi integrerade hela systemet var GoogleScripts det triviala valet av en IDE. Därför använde vi relevanta Google -bibliotek. Skulle ändras enligt rumsbokningsplattformen.

(1) GetCurrentEmailEventID

Körs av ett Webhook -samtal.

Använda en viss förskjutning för att eliminera eventuell missavbokning, få aktuell händelsedata.

(2) ApproveCurrentEvent

Körs med ett användarklick.

I händelse av en användares godkännande av att rummet fortfarande används, raderas händelse -ID från "Rum att radera". Vi använde ett Google -blad, någon annan form av en lista kan vara relevant här.

(3) DeleteCurrentEvent

Körs av ett Webhook -samtal.

Söker efter relevant händelse -ID i listan (Google -blad) och raderar händelsen från kalendern.

Steg 5: Anslut flödet med Arduino -koden

Den bifogade koden ansluter till de sensorer vi kontrollerade för några steg sedan till onlinesystemet (Google -kalender i vårt fall). Det kontrollerar om rummet är upptaget och om det inte är det skickar det en HTTP -begäran (en Webhook) som startar borttagning av begäran om att ta bort på Zapier.

Steg 6: Granskning, slutsatser och framtida skalning

Den största utmaningen vi var tvungna att ta itu med är att täcka alla kantärenden när vi beslutar att frigöra ett mötesrum. Vi var sedan tvungna att skapa en tillståndsmaskin med tanke på alla möjliga fall, så att ett fel inte uppstår och rummet kommer att ställas in som tillgängligt endast när det borde.

Till exempel, om rummet är bokat för någon grupp som för närvarande inte finns där (till exempel paus), men fortfarande behöver det, kommer NODEMCU att upptäcka att rummet är ledigt> PROBLEM.

Sedan var vår lösning att mejla användaren som bokade rummet (vilket inte var enkelt att räkna ut) ett meddelande som ger möjlighet att fortsätta hålla rummet.

Om användaren inte svarade under en viss tid (vi ställde in det till 5 minuter, men det kan enkelt ändras), tar vi bort händelsen från kalendern (och frigör rummet).

På så sätt lyckades vi så småningom hantera alla möjliga scenarier och skapa ett fungerande system.

VÅRA SYSTEMBEGRÄNSNINGAR:

1. De använda sensorerna måste vara mycket exakta och känsliga.

2. Rumsstorleken är begränsad till sensorns radie/räckvidd.

3. Vi måste förlita oss på användarens lyhördhet.

4. Vårt system är byggt med flera plattformar (Google -kalender, Gmail, Zapier etc.) och måste använda deras tjänst för att prestera.

5. För att skala denna tjänst för flera rum (i stället för dubblering av hela systemet) krävs ytterligare hantering med rums -ID.

6. Systemet är bara automatiskt och det finns inget manuellt alternativ för att avboka en rumsbokning.

FRAMTIDA UTVECKLING:

Vi skulle definitivt skala upp systemet på två sätt:

1. Möjlighet att arbeta med andra kalenderplattformar (så att alla samarbetsföretag kan använda den).

2. Möjlighet att hantera flera rum, golv och platser.

Vi tror att denna typ av skala kommer att ta 2-3 månader att generalisera, testa och lägga till flera rum (golv etc.).

Dessutom, med en obegränsad mängd pengar och resurser skulle vi använda bättre sensorer med ett större intervall, tillsammans med att anpassa dem till det angivna rummet - med tanke på räckvidd, radie, mängd sensorer etc. Ett steg som skulle göra varje system längre att installera, självklart.