IDC2018IOT: Meeting Room Snitcher - Gunook

2024 Autor: John Day | [email protected]. Zuletzt bearbeitet: 2024-01-30 07:20

DAS PROBLEM

Wie wir wissen, hat sich der Trend zu Coworking Spaces in den letzten Jahren beschleunigt, zusammen mit modernster Technologie, die die Wahl des spezifischen Coworking Spaces bestimmt, der Ihren Bedürfnissen entspricht.

Eine der Hauptfunktionen sind gemeinsame Besprechungsräume für die Co-Working-Space-Mitglieder, die über eine (normalerweise) einfache Kalenderplattform verwaltet werden.

Ein Problem tritt erneut auf, da der Zeitplan der Mitarbeiter dazu neigt, dynamisch zu sein.

Man könnte ein Zimmer buchen und denken, er könnte es brauchen und möchte das Zeitfenster nicht verpassen.

Selbst wenn man dieses Zeitfenster irgendwann nicht nutzen würde, wird er sich nicht die Mühe machen, es anderen zuliebe zu benachrichtigen und zu stornieren, denn das liegt leider in der Natur des Menschen.

WIE LÖSEN WIR ES?

Mit der IoT-Technologie - Überprüfung von Geräuschen und Bewegungen in einem bestimmten Besprechungsraum, überprüfen wir in jedem bestimmten Zeitintervall, ob ein Raum gebucht und tatsächlich belegt ist oder nicht:

1. Wenn es nicht gebucht ist, tun Sie nichts.

2. Wenn es gebucht ist, überprüfen Sie, ob Bewegungen oder Geräusche erkannt werden;

Wenn ja, tun Sie nichts.

Wenn nichts erkannt wurde, senden Sie eine Warnmeldung (per E-Mail) an den Benutzer, der das Zimmer gebucht hat, und fragen Sie, ob das Zimmer noch belegt ist. Sofern der Nutzer nicht erklärt, dass er den Raum weiterhin nutzt, wird der Raumstatus auf „Verfügbar“geändert.

* Hier haben wir unser Projekt mit Google Kalender integriert, um es so weit wie möglich zu verallgemeinern.

Schritt 1: Benötigte Hardware und Protokolle

1. Wir haben NOSEMCU verwendet, damit wir die Dinge dynamisch über die WIFI-Verbindung aktualisieren konnten.

2. Mikrofonsensor, der die Geräusche im Raum "liest".

3. PIR-Sensor, der überprüft, ob es eine Bewegung gibt.

Für die Software- und Servernutzung haben wir neben dem Code in Arduino Google Script und Zapier verwendet, um unser System online zu unterstützen. Sie können den Fluss im hinzugefügten Bild (und PDF) sehen.

Wir haben Zapier verwendet, um Apps zu verbinden und unsere Workflows (wie IFTTT) zu automatisieren, und wir haben Google Script verwendet, um uns bei der Kommunikation mit dem Google Kalender zu helfen. Das Skript, das wir geschrieben haben, erstellt die E-Mail des Erstellers der Veranstaltung, damit wir sie senden können, warf Zapier und prüft, ob der Benutzer gebeten hat, den Raum zu behalten (indem er einige Informationen in Google Tabellen speichert), bevor er die Veranstaltung löscht.

Schritt 2: Verbinden Sie das Mikrofon und den PIR-Sensor

Wir wollten die Durchschnittswerte überprüfen, die das Mikrofon beim Sprechen an die NODEMCU sendet (klar, in jedem Raum gab es andere Hintergrundgeräusche). Wir haben einige Tests durchgeführt und festgestellt, dass der durchschnittliche Geräuschpegel in dem Raum, in dem wir gearbeitet haben, irgendwo über 50 liegt.

Der PIR-Sensor gibt nur HIGH- oder LOW-Werte aus, daher haben wir nur die Empfindlichkeitsstufe überprüft, die für den von uns überprüften Raum am genauesten ist. Diese Anleitung war ziemlich hilfreich.

UNSERE VERBINDUNGEN:

Mikrofon - wie im picturePIR-Sensor: GND > GND, OUT > D7, VCC > VN (5V)

Schritt 3: Erstellen Sie den Workflow in Zapier

Um zu wissen, ob der Raum tatsächlich leer ist oder noch benutzt wird (und die Benutzer zum Beispiel eine Pause machen), möchten wir einen Flow erstellen, der dies sicherstellt, direkt nachdem die NodeMCU einen Webhook an Zapier feuert, der benachrichtigt, dass die Zimmer ist leer:

(1) TRIGGER - CATCH HOOKZapier fängt den Webhook (der von der NODEMCU gesendet wird)

(2) AKTION - GETZapier sendet einen weiteren Webhook, um die Ereignisdaten abzurufen;> Es ruft (läuft) ein GoogleScript - GetCurrentEmailEventID (Erklärung im folgenden Schritt) auf, um die aktuellen Ereignisdaten abzurufen - Ereignisname, Ereignis-ID, Benutzer-E-Mail.

(3) FILTER - NUR FORTFAHREN, WENN

Fahren Sie nur mit dem nächsten Schritt fort, wenn im Kalender gerade ein Ereignis (jedes Ereignis) stattfindet (ROOM IS BUSY), andernfalls wird das Zimmer abgebrochen, da das Zimmer frei ist.

(4) AKTION – GMAILZapier sendet über Gmail eine E-Mail an den Nutzer, der das Zimmer gebucht hat (diese Informationen wurden in Schritt 2 erhalten).

(5) AKTION - VERZÖGERUNG Lassen Sie dem Benutzer Zeit, auf die E-Mail zu antworten. - Wenn der Benutzer auf den Link klickt: Rufen Sie das GoogleScript auf (führen Sie es aus). Zimmer ist noch als belegt markiert.)

(6) AKTION - GET Nach 5 Minuten ruft Zapier auf (läuft) GoogleScript - DeleteCurrentEvent - Wenn der Benutzer nicht auf den Link geklickt hat

Prüft, ob die Raum-ID in der Liste 'Zu löschende Räume' enthalten ist

es entfernt nur das Ereignis.

Schritt 4: Google-Skripte

Da wir das gesamte System integriert haben, war GoogleScripts die triviale Wahl einer IDE. Daher haben wir entsprechende Google-Bibliotheken verwendet. Würde sich gemäß der Zimmerbuchungsplattform ändern.

(1) AktuelleEmailEventID abrufen

Wird über einen Webhook-Aufruf ausgeführt.

Verwenden eines bestimmten Offsets, um eine mögliche Fehllöschung zu eliminieren, um die aktuellen Ereignisdaten zu erhalten.

(2) Aktuelles Ereignis genehmigen

Wird durch einen Benutzerklick ausgeführt.

Im Falle der Zustimmung eines Benutzers, dass der Raum noch verwendet wird, löscht die Ereignis-ID aus den 'Räumen zum Löschen'. Wir haben ein Google-Sheet verwendet, jede andere Form einer Liste könnte hier relevant sein.

(3) Aktuelles Ereignis löschen

Wird über einen Webhook-Aufruf ausgeführt.

Sucht in der Liste (Google-Tabelle) nach der entsprechenden Veranstaltungs-ID und löscht diese Veranstaltung aus dem Kalender.

Schritt 5: Verbinden Sie den Fluss mit dem Arduino-Code

Der angehängte Code verbindet sich mit den Sensoren, die wir vor einigen Schritten überprüft haben, mit dem Online-System (in unserem Fall Google-Kalender). Es prüft, ob der Raum besetzt ist, und wenn dies nicht der Fall ist, sendet es eine HTTP-Anfrage (einen Webhook), die die Löschereignisanfrage auf Zapier startet.

Schritt 6: Überprüfung, Schlussfolgerungen und zukünftige Skalierung

Die größte Herausforderung, der wir uns stellen mussten, bestand darin, bei der Entscheidung, einen Besprechungsraum freizugeben, alle Randfälle abzudecken. Wir mussten dann eine Zustandsmaschine erstellen, die jeden möglichen Fall berücksichtigt, sodass kein Fehler auftritt und der Raum nur dann als verfügbar gesetzt wird, wenn er sollte.

Wenn der Raum beispielsweise für eine Gruppe gebucht ist, die gerade nicht da ist (z. B. in einer Pause), aber dennoch benötigt, erkennt NODEMCU, dass der Raum frei ist > PROBLEM.

Dann bestand unsere Lösung darin, dem Benutzer, der den Raum gebucht hatte (was nicht einfach war, eine Nachricht zu senden), eine Nachricht zu senden, die die Möglichkeit bietet, den Raum weiter zu halten.

Wenn der Benutzer in einer bestimmten Zeit nicht geantwortet hat (wir haben es auf 5 Minuten festgelegt, aber es kann leicht geändert werden), löschen wir das Ereignis aus dem Kalender (und geben den Raum frei).

Auf diese Weise ist es uns schließlich gelungen, alle möglichen Szenarien zu bewältigen und ein funktionierendes System zu schaffen.

UNSERE SYSTEMEINSCHRÄNKUNGEN:

1. Die verwendeten Sensoren müssen sehr genau und empfindlich sein.

2. Die Raumgröße ist auf den Radius/die Reichweite des Sensors begrenzt.

3. Wir müssen uns auf die Reaktionsfähigkeit des Benutzers verlassen.

4. Unser System basiert auf mehreren Plattformen (Google Kalender, Gmail, Zapier usw.) und muss deren Dienste nutzen.

5. Die Skalierung dieses Dienstes für mehrere Räume (anstatt das gesamte System zu duplizieren) erfordert eine zusätzliche Handhabung mit der Raum-ID.

6. Das System funktioniert nur automatisch und es gibt keine manuelle Möglichkeit, eine Zimmerbuchung zu stornieren.

ZUKÜNFTIGE ENTWICKLUNGEN:

Wir würden das System auf jeden Fall auf zwei Arten skalieren:

1. Fähigkeit, mit anderen Kalenderplattformen zu arbeiten (damit kann jedes Co-Working-Space-Unternehmen sie verwenden).

2. Fähigkeit, mehrere Räume, Etagen und Standorte zu handhaben.

Wir glauben, dass diese Art von Skala 2-3 Monate dauern wird, um die Funktionen für mehrere Räume (Etagen usw.) zu generalisieren, zu testen und hinzuzufügen.

Darüber hinaus würden wir mit unbegrenztem Geld und unbegrenzten Ressourcen bessere Sensoren mit größerer Reichweite verwenden und sie an den vorgesehenen Raum anpassen – unter Berücksichtigung von Reichweite, Radius, Anzahl der Sensoren usw. Ein Schritt, der die Installation jedes Systems länger machen würde, offensichtlich.