zur Übersicht

Anonyme Nutzungsstatistiken mittels RFID-Reader

Lesedauer ca. 3 Minuten
23.01.2024

Aufgrund diverser Kundenprojekte mit IoT-Umgebungen verfügen wir über einschlägige Erfahrung und Expertise in der Entwicklung eigener Hardwarekomponenten. Bereits in einem unserer früheren Blogbeiträge (HR-Dashboard) haben wir darüber berichtet, wie unsere Xperten ihre Kompetenzen dafür einsetzen, um unsere internen Prozesse auf ein neues Level zu heben.

Aktuell befassen sich unsere Xperten mit dem Ein- und Auschecken für das kostenlose Mittagsbuffet im Büro. Dieses wird zweimal die Woche im Rahmen unseres Work & Enjoy-Programms angeboten und sorgt nicht nur für eine unterhaltsame Zeit, sondern auch einen guten Teamzusammenhalt. Dabei entsteht ein geldwerter Vorteil, der zur Steuerpflicht führt. Um die Leistung korrekt zu versteuern, wurde bisher eine Liste ausgelegt, auf der Mitarbeitende die Inanspruchnahme an dem jeweiligen Tag vermerken.

Auch wenn diese Liste die naheliegendste und einfachste Wahl zu sein scheint, zieht sie doch einige Nachteile mit sich:

  • Datenschutzbedenken
  • Übermäßige Datenerfassung
  • Aufwendige Auswertung
  • Entspricht nicht dem Anspruch eines modernen IT-Unternehmens

Wie kann dieser Prozess nun durch das Know-how unserer Xperten vereinfacht und verbessert werden?

Digitale Lösung

Um unseren eigenen Anforderungen gerecht zu werden, haben wir uns schließlich für den digitalen Weg entschieden. Damit sollte vor allem der Aufwand in der Erfassung sowie der Weiterverarbeitung reduziert werden. Schnell fiel die Entscheidung auf eine Lösung in Kombination mit unserem Türöffnungschip, den alle Mitarbeitenden der IT Sonix besitzen und täglich nutzen. Dieser bietet die Möglichkeit, mit einem RFID-Reader ausgelesen zu werden und die erfassten Daten anschließend anonymisiert in einer Webanwendung zu speichern sowie auszuwerten.

Entwicklungsboard

Das Auslesen des Türchips erfolgt über einen ESP8266-Chip, der mit einem RFID-Reader verbunden ist. Dabei setzen wir auf das bewährte Entwicklungsboard D1 Mini. Vor allem Verfügbarkeit und Preis waren für diese Entscheidung ausschlaggebend. Außerdem besitzt dieses IoT-Modul bereits einen USB-Anschluss und auch die nötigen I/O-Ports sind leicht zugänglich. Um die gewünschten Hardwareanforderungen für unseren Anwendungsfall bestmöglich zu erfüllen, haben wir ein eigenes Gehäuse per 3-D-Drucker erstellt und daraufhin die Hardware adäquat platziert. Eine externe Powerbank sorgt via USB für die Stromversorgung.

Zur einfachen Nutzung haben wir mittels Web Installer die Firmware „Tasmota“ auf dem D1-Board installiert. So konnten wir ohne Programmieraufwand den 125KHz-RFID-Leser vom Typ RDM6300 verwenden, der ganz unkompliziert an die I/O- und Strom-Pins des D1 gelötet wurde. Über die Weboberfläche von Tasmota muss jetzt nur noch der richtige Pin ausgewählt werden und schon wird die ID jedes vorgehaltenen Türchips ausgelesen. Da deren IDs indirekte personenbezogene Daten darstellen, werden diese mit dem bcrypt-Verfahren sowie einem zufälligen Salt gehasht und damit anonymisiert.

Warum AWS?

Aus den folgenden Gründen haben wir uns für die Verwendung von AWS als Cloud-Infrastruktur entschieden:

  • Vertriebliche Aspekte durch vermehrte Kundenanfragen
  • Wissensaufbau bei den beteiligten Xperten
  • Einfache Anbindung aus Tasmota möglich
  • Serverless MQTT Broker durch AWS IoT ohne Konfigurationsaufwand

Bedingt durch unsere Erfahrung mit IoT-Anwendungen haben wir die Entscheidung getroffen, den Großteil der benötigten Infrastruktur (Messaging, Persistenz) Serverless vorzuhalten. Dieses Vorgehen ist nicht nur gängige Praxis, sondern bietet auch erhebliche Kostenvorteile.

Umsetzung in AWS

Tasmota erstellt eine Nachricht mit der Identifikationsnummer des Türchips inkl. Datum und Uhrzeit. Diese wird an AWS IoT verschickt und anschließend durch eine IoT Event Rule an AWS SQS (Simple Queue Service) weitergeleitet. Da AWS IoT prinzipiell ohne Persistenz arbeitet, SQS jedoch die Daten für vier Tage vorhält, handelt es sich hierbei um eine angemessene Lösung. So kann ein Datenverlust bei einem kurzfristigen Ausfall des Backend-Services vermieden werden.

Der Service wurde mit Spring Boot erstellt, konsumiert die Nachrichten, die auf dem SQS Topic abgelegt werden und speichert die Daten in einer NoSQL-Datenbank (DynamoDB). Dabei muss sichergestellt werden, dass Events nicht mehrfach verarbeitet werden. Halten Mitarbeitende wiederholt ihren Türchip an den Reader, ist das der Fall. Automatisch wird täglich eine E-Mail mit der Anzahl der Events an unsere Buchhaltung verschickt. Die Daten werden zusätzlich durch eine REST-Schnittstelle angeboten.

Entwicklungsperspektive

Für die spätere Umsetzungsphase ist u. a. geplant, auch die Anzahl der noch verfügbaren Sitzplätze basierend auf den Check-in-Events abfragen zu können. Über eine intuitiv zu bedienende Webanwendung soll dieser Vorgang für alle Mitarbeitenden möglich sein. Darüber hinaus ist auch eine anonymisierte Feedbackfunktion inkl. Auswertung in Planung.