Prozessverbesserungen durch IoT-Buttons

Eine dieser Lösungen ist beispielsweise der IoT-Button. Die mehr oder weniger kleinen Dinger, die in unzähligen Designs und Technologiespezifikationen vorkommen, sind Allrounder und bieten viele Anwendungsmöglichkeiten.

Welche Buttons gibt es denn?

Um eine Entscheidung für den richtigen Button treffen zu können, haben wir folgende Kategorien verwendet:

Kategorie	MyStrom Wifi Button 1	Seeed ReButton (Verwendet) 2	AWS IoT Button 3
Verbindungsart	Wifi	Wifi	Wifi
Dezentrale Verarbeitung Vendor Lock-In
Open Source

Verbindungsart

Gerade im Sinne der Verbindung gibt es schon die ersten Unterschiede. Grundsätzlich gibt es die WIFI-Buttons, die mittels einer WLAN-Verbindung entsprechend mit Ressourcen und Entitäten interagieren. Alternativen wären funk Formate wie ZigBee oder ähnliches.

Dezentrale Verarbeitung

Für uns im Speziellen war es wichtig, uns möglichst unabhängig von externen Systemen zu machen. Da die verschiedenen Buttons teilweise gebunden sind an entweder die Herstellersoftware oder einen bestimmten Cloudanbieter, muss hier eine Lösung verwendet werden, die sowohl umgezogen werden kann, als auch unter unserer vollen Kontrolle steht. Das heißt, die Software des Buttons muss einsehbar und anpassbar sein.

Open Source

Aufgrund des oben genannten Punktes wird ein Button benötigt, der Open Source ist, wodurch Firmware-Anpassungen möglich sind. Somit ist eine IT-Sicherheitsprüfung für interne Anwendungsfälle möglich und die Firmware kann auf die individuellen Anforderungen zugeschnitten werden.

Optimierungen

Wie auch andere Unternehmen sind wir immer bestrebt unsere internen Prozesse zu verbessern und uns auszuprobieren.

Die in Abbildung 1 aufgefassten Prinzipien sind uns dabei besonders wichtig, um einen geeigneten Prozess zu finden. Der neue Prozess sollte möglichst eigenständig funktionieren und nicht neue Abhängigkeiten schaffen. Er soll die vorhandenen Prozesse entkoppeln und ablösen. Auch ist eines der Kernziele, nicht mehr Arbeit zu schaffen, sondern alle Beteiligten zu entlasten.

Anwendungsfälle

Um veraltete Prozesse zu identifizieren, wurde zum Start des Evaluierungsprozesses eine Anforderungsanalyse durchgeführt. Die in der Abbildung 2 aufgeführten zwei Use Cases sind dabei herausgekommen und wurden entsprechend noch vertieft:

Postausgang

Da das Unternehmen doubleSlash auf drei im Süden Deutschlands platzierte Standorte aufgeteilt ist, haben wir eine interne Hauspost etabliert. Ziel ist es, durch interne Mitarbeiter, die gelegentlich aufgrund von Kundenbesuchen in den Standorten rotieren, unkritische Post entsprechend zu verteilen. Diese wurde aber oft vergessen und ggf. wurde unnötig in das Postfach geschaut. Dieser Prozess wurde durch den IoT-Button nun digitalisiert, wodurch jetzt bei einem Knopfdruck eine Benachrichtigung an die entsprechenden Personen versendet wird.

• Post wurde nach [Standort] mitgenommen
• Neue Post ist bereit nach [Standort] mitgenommen zu werden

Empfang

Der IoT-Button am Empfang stellt bei uns eine Art virtuelle Klingel dar. Unser neuer Standort in Friedrichshafen ist auch größentechnisch stark gewachsen und deshalb ist es nicht immer möglich den Empfang zu besetzen. Für diesen Fall haben wir den IoT-Button hier eingeführt, um den Empfang zu entlasten. So kann sich frei im Gebäude bewegt werden und falls Hilfe benötigt wird, wird eine entsprechende Benachrichtigung an die geforderten Personen gesendet.

• Es wird Hilfe am Empfang benötigt
• Bitte IT zum Empfang

Hier ein Beispiel, wie ein Anwendungsfall bei uns aussieht:

Architektur

Wie in Abbildung 4 zu sehen, ist die von uns verwendete Architektur grundlegend in die AWS-Cloud und unser internes doubleSlash Netzwerk gegliedert. Wir haben uns hier für die Cloud entschieden, da wir somit die Belegung des Buttons während des Betriebs frei neu vergeben können. Dadurch kann der Button einmal mit der Firmware bespielt werden und kann dann so im Betrieb bleiben, ohne dass wir Anpassungen vornehmen müssen.
Der Button ist dabei rein dafür verantwortlich, eine UUID an die AWS-Umgebung zu versenden. Pro Click-UseCase eine.

Das API-Gateway bildet in diesem Prozess den Eintrittspunkt in die Programmlogik. Es ermöglicht uns mehrere Sicherheitsmechanismen, wie die API-Absicherung und Request-Limitierung, aber leitet die Anfrage an unsere Serverless-Function weiter. Diese wird über den Service AWS-Lambda bereitgestellt. Sie mapped die bereitgestellte UUID auf die hinterlegten Daten und versendet dann eine Benachrichtigung an den hinterlegten Teams-Channel. Teams stellt dafür WebHooks zur Verfügung, die frei eingebunden werden können.

Probleme

Im Verlaufe der Exploration haben wir jeden der gelisteten Buttons evaluiert. Und gerade in der Benutzung in größeren Unternehmensstrukturen kommen die Buttons schnell an Grenzen. Dies kann von simplen IT-Sicherheitsrestriktionen bis hin zu tieferliegenden Netzwerk Blockaden reichen. Hier eine kleine Beschreibung von den drei größten Problemen, die uns begegnet sind:

Firewall Restriktionen

Gerade bei IT-Firmen sind die Firewalls sehr restriktiv konfiguriert, um Risiken auf Angriffe zu vermeiden. Dies hat aber auch zur Folge, dass bestimmte Anfragen nach außen blockiert sein könnten. Vor allem bei Buttons, deren Firmware man nicht einsehen kann, kann das die Problem-Identifizierung erschweren, oder gar gänzlich behindern.

Festgefahrene Software

Da der ReButton OpenSource ist, hat er es uns ermöglicht, die Software nach unseren Anforderungen adaptieren zu können. Die anderen beiden Lösungen bieten zwar einen schnellen Einstieg, aber forcieren das Festsetzen auf einen externen Dienstleister wie IFTTT oder eine Cloud. Vor allem beim Strom WiFi Button hat sich das Problem gezeigt, dass keine HTTPS Kommunikation möglich ist und somit IFTTT verwendet werden muss.

Vendor Lock-In

Da eine generelle Anforderung an unsere Projekte und Produkte die Wartbarkeit ist, spielt gerade der Vendor Lock-Ins auch eine größere Rolle. Dieser muss bei der Wahl des Buttons in Betracht gezogen werden. Viele Anbieter forcieren den Nutzer dazu, entweder die eigene Cloud nutzen zu müssen oder eine spezielle eigene Software zu verwenden (bspw. IFTTT). Das erschwert unter anderem die Wartung, da ggf. der Support für externe Services in Zukunft eingestellt wird. Hier ist die volle Kontrolle über den Ort der Code-Ausführung und die Unabhängigkeit zu externen Dienstleistern für unsere Zwecke unabdingbar.

Fazit

Prozessänderungen sind fließende Anpassungen, an die die entsprechenden Personen herangeführt werden müssen. Gerade bei sehr eingefahrenen Prozessen.
Dabei muss darauf geachtet werden, dass gerade in der Startphase regelmäßig Aufmerksamkeit auf die Änderung gebracht wird und sich somit die Änderungen bei den Beteiligten festigen.
Die Exploration war sehr erfolgreich und wir haben nun an mehreren Stellen den IoT-Button erproben und einsetzen können. Auch Mehrwert in internen Prozessen ist bereits durch das Nutzungsverhalten und Feedback der Entlasteten erkennbar.

[1] MyStrom, 3 2 2023. [Online]. Available: https://mystrom.com/de/wifi-button/ ^

[2] S. Studio, 3 2 2023. [Online]. Available: https://www.seeedstudio.com/ReButton-p-2930.html ^

[3] A. W. Services, 3 2 2023. [Online]. Available: https://aws.amazon.com/iotbutton/ ^