IDC2018IOT: Vergaderruimte Snitcher - Ajarnpa

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:18

HET PROBLEEM

Zoals we weten, is de trend van co-working-ruimtes de afgelopen jaren in een stroomversnelling gekomen, samen met geavanceerde technologie die de keuze bepaalt van de specifieke co-working-ruimte die past bij uw behoeften.

Een van de belangrijkste functies die worden aangeboden, zijn gedeelde vergaderruimten die worden aangeboden aan de leden van de co-workingruimte, die worden beheerd door een (meestal) eenvoudig kalenderplatform.

Een probleem doet zich opnieuw voor omdat de planning van mensen vaak dynamisch is.

Men zou een kamer kunnen boeken met de gedachte dat hij die misschien nodig heeft en het tijdslot niet zou willen missen.

Zelfs als iemand dat tijdslot uiteindelijk niet zou gebruiken, zal hij niet de moeite nemen om het op de hoogte te stellen en het te annuleren in het belang van anderen, want dat is helaas de menselijke natuur.

HOE LOPEN WE HET OP?

Met behulp van IoT-technologie - het controleren van geluid en beweging in een aangewezen vergaderruimte, controleren we, elk bepaald tijdsinterval, of een ruimte is geboekt en daadwerkelijk bezet is of niet:

1. Als het niet is geboekt, niets doen.

2. Als het is geboekt, controleer dan of er beweging of geluid wordt gedetecteerd;

Als dat zo is, doe dan niets.

Als er niets is gedetecteerd, stuur dan een waarschuwingsbericht (via e-mail) naar de gebruiker die de kamer heeft geboekt met de vraag of de kamer nog in gebruik is. tenzij de gebruiker verklaart de kamer nog steeds te gebruiken, wordt de kamerstatus gewijzigd in "Beschikbaar".

* Hier hebben we ons project geïntegreerd met Google Agenda om het zo veel mogelijk te generaliseren.

Stap 1: Benodigde hardware en protocollen

1. We gebruikten NOSEMCU zodat we dingen dynamisch konden updaten via de WIFI-verbinding.

2. Microfoonsensor die het geluid in de kamer "leest".

3. PIR-sensor die controleert of er beweging is.

Voor software- en servergebruik hebben we, naast de code in Arduino, Google Script en Zapier gebruikt om ons systeem online te ondersteunen. U kunt de stroom zien in de toegevoegde afbeelding (en PDF).

We gebruikten Zapier om apps te verbinden en onze workflows te automatiseren (zoals IFTTT) en we gebruikten Google Script om ons te helpen communiceren met de Google Agenda. Het script dat we hebben geschreven, produceert de e-mail van de maker van het evenement, zodat we het Zapier kunnen sturen en controleren of de gebruiker heeft gevraagd om de ruimte vast te houden (door wat informatie op te slaan in Google Spreadsheets) voordat het evenement wordt verwijderd.

Stap 2: Sluit de microfoon en de PIR-sensor aan

We wilden de gemiddelde waarden controleren die de microfoon naar de NODEMCU stuurt wanneer mensen praten (duidelijk, in elke kamer hadden verschillende achtergrondgeluiden). We hebben wat tests gedaan en realiseerden ons dat het gemiddelde geluidsniveau in de kamer waarin we werkten ergens boven de 50 ligt.

De PIR-sensor geeft alleen HOGE of LAGE waarden, dus we hebben alleen het gevoeligheidsniveau gecontroleerd dat het meest overeenkomt met de kamer die we hebben gecontroleerd. Deze gids was behoorlijk nuttig.

ONZE VERBINDINGEN:

Microfoon - zoals in de fotoPIR-sensor: GND > GND, OUT > D7, VCC > VN (5V)

Stap 3: Creëer de workflow in Zapier

Om te weten of de ruimte daadwerkelijk leeg is of nog in gebruik is (en de gebruikers bijvoorbeeld pauze hebben), willen we een stroom creëren die ervoor zorgt dat dit direct nadat de NodeMCU een Webhook naar Zapier heeft gestuurd die aangeeft dat de kamer is leeg:

(1) TRIGGER - CATCH HOOKZapier vangt de webhook op (die wordt verzonden door de NODEMCU)

(2) ACTIE - GETZapier stuurt een andere webhook om de gebeurtenisgegevens op te halen;> Het roept een GoogleScript aan - GetCurrentEmailEventID (uitleg in de volgende stap), om de huidige gebeurtenisgegevens te krijgen - gebeurtenisnaam, gebeurtenis-ID, gebruikers-e-mail.

(3) FILTER - ALLEEN DOORGAAN ALS

Ga alleen door naar de volgende stap als er momenteel een evenement (een evenement) op de kalender plaatsvindt (KAMER IS BUSY), anders stopt het als de kamer leeg is.

(4) ACTIE - GMAILZapier stuurt een e-mail, via Gmail, naar de gebruiker die de kamer heeft geboekt (kreeg deze informatie in stap 2)

(5) ACTIE - VERTRAGING VOORGeef de gebruiker de tijd om de e-mail te beantwoorden.- Als de gebruiker op de link klikt: bel (voer) de GoogleScript - ApproveCurrentEvent (vandaar dat de kamer wordt verwijderd uit de lijst 'Te verwijderen kamers') kamer is nog steeds gemarkeerd als bezet.)

(6) ACTIE - GET Na 5 minuten roept (voert) Zapier GoogleScript aan - DeleteCurrentEvent - Als de gebruiker niet op de link heeft geklikt

Controleert of de kamer-ID in de lijst 'Te verwijderen kamers' staat

het verwijdert gewoon de gebeurtenis.

Stap 4: Google Scripts

Omdat we het hele systeem integreerden, was GoogleScripts de triviale keuze van een IDE. Daarom gebruikten we relevante Google-bibliotheken. Zou veranderen volgens het Room Booking Platform.

(1) GetCurrentEmailEventID

Wordt uitgevoerd door een Webhook-oproep.

Een bepaalde offset gebruiken om mogelijke miss-cancelling te elimineren, de huidige gebeurtenisgegevens verkrijgen.

(2) Huidige gebeurtenis goedkeuren

Wordt uitgevoerd door een gebruikersklik.

In het geval van goedkeuring van een gebruiker dat de ruimte nog steeds in gebruik is, wordt de gebeurtenis-ID verwijderd uit de 'Te verwijderen ruimten'. We gebruikten een Google-blad, elke andere vorm van een lijst zou hier relevant kunnen zijn.

(3) Huidig evenement verwijderen

Wordt uitgevoerd door een Webhook-oproep.

Zoekt naar de relevante gebeurtenis-ID in de lijst (Google-blad) en verwijdert die gebeurtenis uit de kalender.

Stap 5: Verbind de stroom met de Arduino-code

De bijgevoegde code maakt verbinding met de sensoren die we een paar stappen geleden hebben gecontroleerd met het online systeem (in ons geval Google-agenda). Het controleert of de kamer bezet is en als dat niet het geval is, verzendt het een HTTP-verzoek (een webhook) dat het verzoek voor het verwijderen van gebeurtenissen op Zapier start.

Stap 6: Review, conclusies en toekomstige schaling

De belangrijkste uitdaging waarmee we te maken hadden, was om alle randgevallen te dekken bij de beslissing om een vergaderruimte vrij te maken. Vervolgens moesten we een toestandsmachine maken die rekening houdt met alle mogelijke gevallen, zodat er geen fout optreedt en de kamer alleen beschikbaar wordt gesteld als dat zou moeten.

Als de kamer bijvoorbeeld is geboekt voor een groep die er momenteel niet is (bijvoorbeeld in pauze), maar deze toch nodig heeft, zal NODEMCU detecteren dat de kamer vrij is > PROBLEEM.

Vervolgens was onze oplossing om de gebruiker die de kamer heeft geboekt (wat niet eenvoudig te achterhalen was) een bericht te e-mailen dat de mogelijkheid biedt om de kamer vast te houden.

Als de gebruiker niet binnen een bepaalde tijd heeft geantwoord (we hebben dit ingesteld op 5 minuten, maar dit kan eenvoudig worden gewijzigd), verwijderen we het evenement uit de kalender (en maken we de kamer vrij).

Op die manier zijn we er uiteindelijk in geslaagd om alle mogelijke scenario's aan te pakken en een werkend systeem te creëren.

ONZE SYSTEEMBEPERKINGEN:

1. De gebruikte sensoren moeten zeer nauwkeurig en gevoelig zijn.

2. De grootte van de ruimte is beperkt tot de straal/het bereik van de sensor.

3. We zullen moeten vertrouwen op het reactievermogen van de gebruiker.

4. Ons systeem is gebouwd met behulp van verschillende platforms (Google-agenda, Gmail, Zapier enz.) en zal hun service moeten gebruiken om te presteren.

5. Het schalen van deze service voor meerdere kamers (in plaats van het hele systeem te dupliceren) vereist een extra behandeling met kamer-ID.

6. Het systeem werkt alleen automatisch en er is geen handmatige optie om een kamerboeking te annuleren.

TOEKOMSTIGE ONTWIKKELINGEN:

We zouden het systeem zeker op twee manieren opschalen:

1. Mogelijkheid om met andere agendaplatforms te werken (zodat elk bedrijf in co-working spaces het zou kunnen gebruiken).

2. Mogelijkheid om meerdere kamers, verdiepingen en locaties te verwerken.

We zijn van mening dat dit soort schaal 2-3 maanden nodig heeft om te generaliseren, te testen en om meerdere kamers (verdiepingen enz.) toe te voegen.

Bovendien zouden we met een onbeperkte hoeveelheid geld en middelen betere sensoren met een groter bereik gebruiken, en ze aanpassen aan de aangewezen ruimte - rekening houdend met bereik, straal, aantal sensoren enz. Een stap die elk systeem langer zou installeren, blijkbaar.