Back2Work goes IoT – Technische Details zum Contact Tracer

Für das Szenario, dass die Auswertungen zeigen, dass zu viele Personen im Office arbeiten, wollten wir die Möglichkeit vorsehen, die Anwesenheit zu reservieren. Die Back2Work-App, die von Sycor schon vor einigen Wochen veröffentlicht wurde, bietet grundsätzlich die Möglichkeiten, die wir suchten. Die Anzahl der Mitarbeiter auf einem Geschäftstelefon war aber zu gering für einen flächendeckenden Rollout der Microsoft PowerApp. Daher haben wir die Back2Work-App um einen IoT-Sensor erweitert. Der RFID des vorhandenen Türöffner-Chips trägt eine einheitliche ID.

Durch das Scannen wird ein CheckIn auf der jeweiligen Etage durchgeführt. Ein Scannen auf einer anderen Etage führt automatisch ein CheckOut auf der Ursprungsetage und ein Checkin am neuen Ort durch. Ein erneutes Scannen in der Etage, in der man bereits eingecheckt ist, aktualisiert einen LastSeen Timestamp. Damit können wir bewusst auf einen CheckOut verzichten. Die User werden batch-basiert abends ausgecheckt.

Wir möchten im Folgenden aufzeigen, wie so ein einfaches IoT Setup aufgesetzt werden kann. Den notwendigen Quellcode stellen wir auf GitHub zur Verfügung. Dass dieses einfache Setup nicht unbedingt die Anforderungen an den Rollout auf einem großen Campus erfüllt, ist offensichtlich – Gerne unterstützen wir auch bei der Umsetzung von komplexeren Szenarien.

Der RFID-Scanner wird durch ein Olimex ESP32-Board mit angeschlossenem RFID-Leser umgesetzt. Eine LED zeigt den Status des Gerätes an, die Stromversorgung wird über PoE umgesetzt.

Auf dem Gerät wird auf das Scannen des Chips gewartet. Die ausgelesene eindeutige ID und die ID des Scanners (wir verwenden die MAC-Adresse als ID) werden per REST-Webservice-Aufruf an einen Microsoft PowerAutomate Job übergeben, der dann die eigentliche CheckIn-Logik abbildet.

Für den Scanner werden benötigt:

• Olimex ESP32-PoE-ISO
• RFID-Scanner (e.g. RFID Reader ID-12LA (125 kHz))
  • ggf. passendes Breakout Board (hier: SparkFun RFID Reader Breakout)
• RGB LED (hier: SparkFun COM-11120)
• Gehäuse (3D-Druck)

Die Hardware-Kosten pro Gerät liegen bei ungefähr 60€. Die Verkabelung ist wie folgt umgesetzt:

Wir setzen das ESP32-Arduino-Framework auf dem Olimex-Board ein. In der Firmware werden drei wesentliche Funktionalitäten umgesetzt. Nachdem die Netzwerkverbindung hergestellt wurde, wird auf Over-the-Air-Updates geprüft. Die LED und der RFID-Leser werden initialisiert und im Loop wird auf das Scannen eines RFID Chips gewartet. Das Scannen wird durch Signalisierung per LED bestätigt und eine JSON mit der ausgelesenen eindeutigen ID des Chips, der Mac Adresse des Boards und dem aktuellen Timestamp an die HTTP-Adresse des PowerAutomate Jobs gesendet.

Die 12 Bytes der eindeutigen ID werden mittels ESPSerial2.read() ausgelesen. Der Reader enkapsuliert die ID in 0x02 (Start of Text) und 0x03 (End of Text) und schließt mit 0x0D 0x0A ab (Carriage Return + Line Feed (\r\n)).

Der ESP32 verfügt über zwei Cores, daher wird die Standby-LED-Animation der Einfachheit halber als Task auf der zweiten Core ausgeführt.

Die Logik des CheckIns wird in folgendem PowerAutomate Flow abgebildet. Genau wie die PowerApp ist PowerAutomate ein LowCode Tool, mit dem es einfach möglich ist, auch ohne große Programmierkenntnisse die Prozesslogik anzupassen.

Es ist zu beachten, dass in der PowerAutomate-Version, die in Office365 enthalten ist, ein API-Limit von 2000 API Calls pro User pro Tag existiert. Wenn dieser Wert überschritten wird, muss eine separater PowerApps Plan erworben werden, oder der Code wird in eine LogicApp umgesetzt, die pro API-Aufruf über die Azure-Subskription abgerechnet wird.

Die Logik ist einfach aufzubauen und sieht im Überblick wie folgt aus:

Die App wird durch einen Webservice-Aufruf (URL wird beim ersten Speichern generiert) getriggert.

Die RFID ID wird über die SharePoint-Liste btw_token in eine Mailadresse umgesetzt. In der Liste btw_token wird das Mapping von eindeutiger Token ID zur Mailadresse des Users umgesetzt:

Die Mac-Adresse des Scanners wird über die SharePoint-Liste btw_space auf die SpaceId umgesetzt:

Die SharePoint-Liste btw_locationTrack wird abhängig von der Ausgangssituation aktualisiert. Es wird geprüft, ob ein aktiver CheckIn vorhanden ist. Ist das nicht der Fall, wird der User eingecheckt, indem ein Eintrag in die SharePoint-Liste btw_locationTrack erzeugt wird. Im Fall, dass der User bereits im gleichen „Space“ eingecheckt ist, wird nur der LastSeen Timestamp aktualisiert. Ist es ein neuer Ort, an dem der User sein Token scannt, wird ein Checkout (Setzen des Timestamps im Feld CheckOut) und ein neuer CheckIn mit der neuen SpaceID durchgeführt:

Es gibt einen weiteren einfachen Flow, der alle User auscheckt und die Datensätze, die älter als 60 Tage sind, löscht. Dieser Flow wird jeden Abend gestartet:

Optimalerweise existiert die Verknüpfung von eindeutigen IDs und E-Mail-Adresse schon in einem System, so dass man diese Daten einfach in die Liste btw_token übernehmen kann.

Wir haben das Setup für das Mapping so umgesetzt, dass es an zentraler Stelle einen Scanner und einen Thermo-Drucker gibt. Beim Scannen des RFID-Chips wird ein QR-Code und die eindeutige ID des Chips ausgedruckt. Der QR-Code führt zu einem ausgefüllten Google Forms-Formular, das der eingeloggte Nutzer bestätigt. Google Forms schreibt das Mapping in ein Google Sheet, das wiederum einen PowerAutomate Webservice aufruft um die Sharepoint-Liste zu aktualisieren. Hier ist sicherlich eine individuelle Lösung für jedes spezifische Setup zu finden.