In diesem letzten Teil unserer laufenden IoT-Blogserie werden wir eine erweiterte Pipeline besprechen, die wir hier im SnapLogic-Hauptquartier installiert haben (wie im letzten Beitrag versprochen). Aus Platzgründen können wir nicht alle Details der Funktionsweise zeigen, aber wir werden die wichtigsten Punkte in diesem und dem nächsten Beitrag behandeln.
Vielleicht haben Sie in Ihrer beruflichen Laufbahn schon einmal an einer Besprechung teilgenommen, bei der es zu Überstunden gekommen ist. (Vielleicht sind Sie gerade jetzt in einer). Wahrscheinlich haben Sie sich gewünscht, dass die Besprechung beendet wird. Nun, das Internet der Dinge ist hier, um Ihren Wunsch zu erfüllen.
Wir werden eine Pipeline erstellen, um ein Signal für die Beendigung des Treffens im Konferenzraum zu aktivieren, den Luminescent Evanescent Apparatus for Voiding Engagements.
Die Pipeline fragt die FreeBusy-API von Google Calendar ab, um herauszufinden, wann Besprechungen für einen bestimmten Konferenzraum enden sollten; die Pipeline verarbeitet diese Informationen dann in einer Variable "time-until-finished" und berechnet einen eindeutigen Hash für die Besprechung. Wenn für eine Besprechung noch 5 Minuten oder weniger verbleiben, erlaubt der Filter die Weitergabe dieser Information an den Endpunkt. Dabei kann es sich um ein POST an den Mikrocontroller oder, um allgemeiner zu sein, um ein Push an einen allgemeinen Warteschlangenmechanismus (z. B. RabbitMQ) handeln. Der letztgenannte Ansatz ähnelt der zusätzlichen Abstraktionsschicht, die ein IoT-Hub-Dienst bieten würde. In diesem Fall würden wir in unserem Dokument auch die ID des Konferenzraums angeben, an den die Nachricht gehen soll.
Wir verwenden einen Photon von particle.io als Mikrocontroller. Photons sind (größtenteils) Arduino-kompatibel, verfügen aber über umfangreiche native Cloud-Funktionen. Insbesondere können wir Funktionen in der Firmware als REST-Endpunkte bereitstellen. Das bedeutet, dass wir die Firmware (in einer Untermenge von C++) schreiben können, die Dinge in der realen Welt auslöst, und wir können diese Funktionalität dann mit einem einfachen POST aufrufen.
Wir lassen diese Pipeline als geplante Aufgabe einmal pro Minute laufen. Dies ist der Grund für die Berechnung des Hashwerts - wir können mehrere Nachrichten an Photon (oder den Broker) über dasselbe Treffen weiterleiten, aber das Gerät weiß, dass es Nachrichten ignoriert, deren Hashwert mit dem der vorherigen Nachricht übereinstimmt. Dies ist ein Entwurfsmuster, das Sie vielleicht nützlich finden - es kann einfacher sein, den Zustand eines Endpunkts zu verfolgen als in einer Pipeline. (Jede Minute auszuführen und nach einem Delta unter fünf Minuten zu suchen, bedeutet, dass wir die Nachricht "Besprechung ist vorbei" voraussichtlich fünfmal generieren werden, im Extremfall vielleicht sogar sechsmal).
Der schwierigste Aspekt dieser Pipeline ist die korrekte GET-Anforderung an Google Calendar. Sie müssen sicherstellen, dass Sie die richtigen Berechtigungen für das verwendete Google-Konto haben und die richtigen Parameter in der GET-Anfrage und in der Autorisierung übergeben. Das Endergebnis wird in etwa so aussehen:
Wir wandeln die Ausgabe der FreeBusy-API in "Delta-Zeiten" um - die Differenz zwischen der aktuellen Zeit und der Endzeit der Besprechung. Schließlich erzeugen wir einen "Hash" - eigentlich nur eine Verschlüsselungsoperation - für die Endzeit der Besprechung. Die Zeit bis zum Ende der Besprechung und der Hash werden durch den Filter an den Endpunkt weitergeleitet, wenn die Besprechung in weniger als fünf Minuten endet. Dies sind die einzigen beiden Daten, die unser Mikrocontroller von uns benötigt.
Der nächste Beitrag wird sich mit dem IoT-Gerät und seiner Software befassen. Schauen Sie sich in der Zwischenzeit den Rest der IoT-Blogserie an, oder kontaktieren Sie uns , um eine Demo zu erhalten.
