Dokumentation – Soft Skills und Technische Kompetenz (WiSe20/21 – SoSe2021)

Motivation/Problemstellung:

Die Projektgruppe hat sich zu Beginn der Ideenfindungsphase an Alltagssituationen erinnert, in denen der Einsatz einer Smart Home Lösung sinnvoll wäre. Ein Projektmitglied hat sich daran erinnert, dass vor kurzem im Kellerraum seiner Wohnung ein Fahrrad entwendet wurde. Da der Kellerraum von der Wohnung aus nicht einsehbar ist, kam die Idee auf, eine Art Bewegungsmelder zu installieren, der mittels Benachrichtigung auf ein Endgerät vor unbefugtem Zutritt warnt. Der Bewegungsmelder sollte sich „scharf“ stellen lassen, damit dieser nicht jederzeit Alarm schlägt. Ziel ist es also, mit der „Security Box“ Einbrecher und Diebe auf frischer Tat zu ertappen.

Github: https://github.com/romo9840/MFHL_Semesterprojekt_Security

Anforderungskatalog:

Notwendige technische Voraussetzungen:

ESP-8266 WEMOS D1 Mini als Mikrocontroller
Mobiles Endgerät
WiFi-Signal für Mikrocontroller und mobiles Endgerät
USB-Mini Stromversorgung
Sensoren:
- PIR Bewegungssensor (U1 HC-SR501)
Aktoren:
- 2 5mm-LEDs: rot und grün
- ESP-8266 Taster Aufsatz

Mögliche technische Voraussetzungen:

Widerstände 330 Ohm (soll)
Batterie Aufsatz (kann)
Batterie (kann)

Physische Voraussetzungen:

Design: kompakte Box & Deckel mit Löchern für Sensorik und Aktorik, sowie Stromversorgung
- Material: Kunststoff-Filament eines 3D-Druckers (PLA)
Kabel und Lötzubehör zum Verbauen der einzelnen Teile
Prototyp Platine (4,5cm x 3,5cm)

Eingesetzte Hilfssoftware:

Arduino IDE
Note RED
Autodesk Fusion 360

Software-Funktionsweise (Textuell erklärt):

Die „Security Box“ verfügt zwei LEDs, eine rote und eine grüne. Die grüne LED leuchtet, wenn die Box im Zustand „Home“ ist. Die rote LED leuchtet, wenn die Box im Zustand „Away“ ist. Im Nachtmodus leuchten keine der beiden LEDs. Sobald das Sicherheitssystem in den Zustand „Away“ wechselt, wird durch das Initialisieren eines zwei Minuten Timers eine Früherkennung unterbunden. Nach dem Ablauf des zweiminütigen Timers ist das Sicherheitssystem aktiv, nach dem Erkennen einer Bewegung wird eine entsprechende Nachricht via Discord oder E-Mail an den Benutzer verschickt. Im Zustand „Home“ bleibt das Sicherheitssystem inaktiv. Die Zustände werden durch das Betätigen des Buttons geregelt. Sobald der Button gedrückt wird, wechselt der Status der Box auf „Home“ oder „Away“. Entsprechend leuchtet auch die passende LED.

Projektplan und Verantwortlichkeiten

In Rahmen dieses Projektes wird ein Projektplan mit Meilensteinen erstellt und die Verantwortlichkeiten und Aufgaben werden in der Gruppe verteilt. In dem Projektplan werden Meilensteine definiert, welche wichtige Fertigstellungen von Arbeitspaketen markieren.

Auf dem Bild wird der Projektplan dargestellt. Die Kästchen mit blauer Umrandung sind Arbeitspakete, die mit schwarzer Umrandung Meilensteine. (Abbildung 1)

Projektkickoff ist der 05.07.21, bei dem die Limitierungen des Projektes bekanntgegeben werden. Daraufhin werden die Verantwortlichkeiten und Aufgaben in der Gruppe verteilt, für diesen Schritt wird ein Tag angesetzt. Verantwortlich für die Hardware ist die gesamte Gruppe, für die Software Leif Meyer und Hendrik Nessen, für die 3D-Modellierung Marvin Timmermann und Felix Büntemeier, welche ebenfalls für die Dokumentation verantwortlich sind.

Zeitgleich wird sich mit der Ideenfindung befasst, welche ebenfalls ein Tag braucht bei der alle Gruppenmitglieder beteiligt sind. Nach diesen Meilensteinen wird die Hardware-Entwicklung starten sowie die Dokumentation. Für die Hardware-Entwicklung werden zehn Tage angesetzt, da sich erst ein Bild gemacht werden muss von der verfügbaren Hardware und dem darauffolgenden Zusammenbau. Für die Dokumentation wird ein Zeitraum bis Anfang September eingeplant, damit über die gesamte Projektdauer dokumentiert werden kann.

Die 3D-Modellierung kann, nachdem die Hardware fertiggestellt ist, beginnen, da die Maße der Hardware vorher unklar sind. Für diesen Schritt werden zwölf Tage eingeplant, damit die Modelle genau angepasst werden können. Zeitgleich wird mit der Software-Entwicklung begonnen, welche mit einem Monat eingeplant ist, damit alle Funktionen ausgiebig getestet werden können. Zeitgleich wird die Dokumentation mit den jeweiligen Inhalten aus den Arbeitspaketen gefüllt. Nachdem die Dokumentation fertiggestellt ist, wird mit der Erstellung der Präsentation begonnen, dafür werden vier Tage eingeplant.

Damit ein Risikomanagement in dem Projekt stattfinden kann, werden sechs Tage eingeplant. Falls ein Problem auftreten sollte, werden die darauffolgenden Aufgabenpakete entsprechend nach hinten verlagert. Zudem wird im gesamten Projekt für eventuelle Probleme oder Verzögerungen Zeit eingeplant, sodass Hardware, Software, 3D-Modell sowie die Dokumentation frühzeitig fertiggestellt werden können.

Der Projektplan wurde für das gesamte Projekt grundlegend eingehalten, bis auf die Fertigstellung der Dokumentation, welche sich um ein paar Tage nach hinten verlagert hat. Dies lag daran, dass zwei Gruppenmitglieder spontan für ein paar Tage nicht da waren.

Beschreibung der 3D-Modellierung

Nachdem die Hardware-Entwicklung fertiggestellt worden ist, konnte der Modellierungsprozess beginnen. Durch die fertige Hardware waren Maße gegeben, wie groß die „Security Box“ sein muss. Damit diese auch kompakt ist, sollte das Gehäuse für die Hardware so klein wie möglich sein. Zunächst wurde ein einfaches Gehäuse modelliert, bei dem der Deckel abnehmbar ist. Zusätzlich mussten Aussparungen eingefügt werden: Für die Stromversorgung, die LEDs, den Button und den Bewegungssensor. Diese wurden mit den Maßen der Hardware vorgenommen.

Auf dem Bild ist das erste Modell zu sehen:

Punkt 1 ist der Körper,
Punkt 2 die Aussparung für die Stromzufuhr,
Punkt 3 ist der Deckel,
Punkt 4 sind die Aussparungen für die LEDs,
Punkt 5 ist die Aussparung für den Button und
Punkt 6 ist die Aussparung für den Bewegungssensor.

Zunächst wurde nur der Deckel gedruckt, da der Bewegungssensor, die LEDs und der Button durch die Aussparungen passen müssen. Es stellte sich heraus, dass die Aussparungen nicht passend waren, sodass das Modell überarbeitet werden musste. Hierfür wurde eine Skizze vom Bewegungssensor für Autodesk Fusion 360 benutzt (https://www.thingiverse.com/thing:1673521), welche die genauen Abmessungen des Bauteils hatte.

Zusätzlich wurde diese Skizze erweitert, sodass die LEDs und der Button genau passen. Damit der Deckel auf dem Körper fest ist, wurden vier Eckpfeiler eingefügt, sodass diese genau in die Ecken des Körpers passen. Bei dem Körper wurde die Aussparung für die Stromversorgung ein wenig nach links verschoben und zudem eckig modelliert.

Auf dem Bild ist das fertige Modell zu sehen:

Punkt 1 ist der Körper,
Punkt 2 die Aussparung für die Stromzufuhr,
Punkt 3 ist der Deckel,
Punkt 4 ist die Aussparung für die LEDs,
Punkt 5 ist die Aussparung für den Button und
Punkt 6 ist die Aussparung für den Bewegungssensor sowie die Haltevorrichtung für diesen.

Die Abmessungen der Modelle sind sind im folgenden Abbildungen 4 und 5 zu erkennen.

Dieses Modell wurde im „Makerspace“ gedruckt.

Hardware-Entwicklung

Im Folgenden wird beschrieben, wie mit den im „Makerspace“ ausgesuchten Hardware-Bauteilen ein funktionierender Schaltplan entwickelt und dieser Schritt für Schritt kompakt zusammengelötet wurde:

Hier sind erneut die verwendeten Bauteile:

ESP8266 Lolin Wemos D1 Mini
ESP8266 Taster Aufsatz
Zwei 5mm LEDS (Rot und Grün)
Ein Bewegungssensor (U1 HC-SR501)
330 Ohm Widerstand
Prototyp Platine (4.5cm x 3.5cm)

Zu Beginn hieß es, sich Gedanken über die Verkabelung der einzelnen Bauteile zu machen, da nur so eine logische Verlötung der einzelnen Pins am Mikrocontroller mit den Pins der Bauteile möglich ist. Der abgebildete Schaltplan ohne Widerstand (Abbildung 6) stellt dar, wie das aktuelle Projekt verlötet ist.

Schaltplan ohne Widerstand (Abbildung 6)

Die darauffolgende Abbildung stellt denselben Schaltplan mit Widerstand (Abbildung 7) dar. Dieser wird zwar empfohlen, wurde Anfangs allerdings nicht genutzt, da die 5V-LEDs auch ohne einen passenden Widerstand mit einer angelegten Spannung von 5V funktionieren. Wegen eines defekten Pins am Mikrocontroller wurde diese aber doch letztendlich verwendet. Der Grund für den defekten Pin lag wahrscheinlich nicht am fehlenden Widerstand.

Zum Verlöten wurde zuerst der ESP-8266 auf der Platine platziert, sodass Platz für die LEDs auf der rechten Seite (von oben gesehen) geschaffen wurde. Mittels des Stecksystems kann der Taster Aufsatz auf den ESP-8266 gesteckt werden. Die LEDs wurden neben ihren Pins (D2 für Grün und D4 für Rot) mittels der Anode mit deren untersten Kante auf Höhe der Platine des Taster-Aufsatzes platziert. Die Kathode der beiden LEDs wurde auf Höhe von Pin D4 gesteckt (falls ein Widerstand eingebaut wird, müsste dies angepasst werden).

ESP-8266, der Taster Aufsatz und die Steckhalterung für den Bewegungssensor von oben (Abbildung 8)

Zu Beginn wurden nur die ersten Bauteile verlötet: Der ESP-8266, der Taster Aufsatz und die Steckhalterung für den Bewegungssensor (Abbildungen 8 & 9). Es wurde auf folgendes geachtet:

Nur 5V, GND und D3 wurden beim Taster Aufsatz verlötet.
5V, GND und D1-D4 wurden bei dem ESP-8266 verlötet.
Lötstellen sind am ESP-8266 mit Stecksystem trotzdem zu verlöten, auch wenn das Stecksystem dabei nicht mehr bündig schließt.
Bauteile wurden nur an den nötigen Stellen sowie den Eckpunkten verlötet, um möglichst viel Halt mit möglichst wenig Aufwand zu gewährleisten.

Im weiteren Verlauf des Projektes wurden die LEDs sowie die Verkabelung des Bewegungssensors verlötet. Davor war noch nicht klar, ob LEDs mit oder ohne Widerstand verlötet werden sollten, es wurde entschieden, ohne Widerstand zu verlöten. Es wurde hier auch auf folgendes geachtet:

Die LEDs wurden mittels einer Brücke/Leitung an GND verlötet.
Die LEDs wurden direkt zu ihrem zugehörigen Pin verlötet.

ESP-8266, der Taster Aufsatz und die Steckhalterung für den Bewegungssensor von unten (Abbildung 9)

Von der Steckhalterung aus wurde wie im folgenden Bild (Abbildung 10) die Verkabelung von 5V, GND und OUT/D1 verlötet. Dabei wurde aufgepasst, dass die Kabel über möglichst direkte, aber saubere Wege verfügen.

Löten des Bewegungssensors (Abbildung 10)

Am 15.09 wurde die Hardware erneut umgelötet um mehrere Probleme zu lösen. Es wurde, wie in Abbildung 11 dargestellt, ein Widerstand (330 Ohm) rechts verlötet und die rote LED wurde auf Pin D6 verlötet (mittels eines roten Kabels). In Abbildung 12 erkennt man den Widerstand und LEDs von der Seite.

Probleme bei der Hardware-Entwicklung

Da schrittweise vorgegangen wurde, gab es immer nur kleinere Probleme, die aber immer innerhalb eines Tages gelöst wurden. Größtenteils war die Ursache, dass die Lötstellen nicht sauber waren. Folgende Probleme wurden gelöst:

Der Button Shield funktionierte nicht wie erwartet, da die Lötstellen zwischen dem ESP-8266 und dem Taster Aufsatz nicht funktionstüchtig waren. Es entstand ein Wackelkontakt der durch erneutes Löten gelöst wurde.

Die Rote LED wurde auf den Pin D4 gelötet. Das Problem ließ sich erst bei der Programmierung bemerken. Die eingebaute interne LED vom ESP-8266 lässt sich auch mit D4 ansteuern. So gab es einen Konflikt mit der Software, da immer nur eine der beiden LEDs willkürlich leuchtete.

Der Pin D4 wurde gegen Ende des Projektes aus noch unbekannten Grund defekt. Die rote LED hat nach dem Zusammenbau der Komponenten nicht mehr funktioniert. Die LED musste von D4 auf D6 umgelötet werden. Dies hat auch das Problem mit der internen LED gelöst.

Beschreibung der Systemarchitektur und der Softwareentwicklung

Im folgendem Absatz wird Abbildung 13 erläutert. Das Sicherheitssystem stellt Anfangs, bei Inbetriebnahme eine Verbindung zu einem spezifizierten Netzwerk her. Dies ist notwendig, um eine Kommunikation zwischen den Systemen zu gewährleisten. Erkennt das Sicherheitssystem eine Bewegung, wird eine entsprechende Meldung via MQTT über das Internet übermittelt. Die Daten werden von einem Broker (Mosquitto) empfangen und an einen Node-RED Server weitergeleitet.

Die empfangenen Daten werden mittels Node-RED als Email-, sowie Discord-Nachricht verarbeitet und weitergeleitet. Die verarbeitete Meldung erscheint schließlich auf den jeweiligen Endgeräten.

Arduino Setup

In den folgenden Abbildungen 15-18 werden die verwendeten Parameter dargestellt. Die Parameter in Abbildung 17 sind für den Benutzer anzupassen sodass das System sich mit dem Internet verbinden kann.

Bibliotheken und globale Parameter – werden nicht angepasst (Abbildung 15)

Bei Start des Sicherheitssystems wird beginnend das „NETWORK SETUP“ des Programms ausgeführt. In dieser Phase werden Verbindungen zum Netzwerk, zum MQTT-Broker sowie zum Node-RED Client hergestellt und aufrechterhalten. Der Nutzer muss hier Wifi und MQTT Parameter anpassen.

Netzwerk und MQTT Parameter – diese werden vom Nutzer angepasst (Abbildung 17)

Die von Spivey entwickelte Button-Class (Abbildung 18)/Logik (Abbildung 19) (https://www.hackster.io/Spivey/wemos-d1-mini-esp8266-smart-iot-button-with-messagebird-dbef7e) ermöglichte eine flexible Programmierung des Tasters. Im Setup wird die folgende Klasse erstellt. Dabei sind Parameter für den Pin des Tasters, die zwei Dauerangaben, „short“ und „long“, und ein Zähler für die Dauer eines Drucks initialisiert. Zudem wird auch der vorherige, sowie der aktuelle Zustand des Tasters (HIGH oder LOW) initialisiert. Nach der Implementierung der Klasse wird eine Variable vom Typ Button dieser Klasse initialisiert.

Ein wichtiger Hinweis zur optimalen Umsetzung des Buttons ist, dass der Taster „active-low“ ist. Dies bedeutet das der Taster, falls gedrückt, ein LOW Signal ausgibt.

Loop-Methode

Nachdem alle Verbindungen erfolgreich hergestellt werden konnten, beginnt die „Loop-Methode“ des Programms. In diesem Teil des Programms wird die von Spivey entwickelte Button-Logik des Sicherheitssystems umgesetzt. Diese Button Logik wurde wie in Abbildung 19 abgeändert.

Die von Spivey entwickelte Button-Logik nutzt Zustände und Timer, um zwischen kurzen und langen Tastendrücken zu unterscheiden. Dies ist für die spezifische Funktionalität des Sicherheitssystems notwendig. Erkennt das System einen kurzen Knopfdruck, wechselt das System abhängig vom vorherigen Zustand in den „Home“- oder den „Away“-Zustand. Registriert das System einen langen Knopfdruck, wird der Nachtmodus des Sicherheitssystems aktiviert. Die LED-Leuchten werden deaktiviert und der aktuelle Zustand bleibt bestehen. Die Implementierung hierfür ist in Abbildung 20 zu erkennen.

Das eingeschaltete System befindet sich im Ausgangszustand „Home“. In diesem Zustand wird lediglich die grüne LED-Leuchte aktiviert. Es werden in diesem Zustand keine Bewegungsdaten erfasst und ausgewertet. Implementierung in Abbildung 21.

Nachdem das System in den „Away“ -Zustand gelangt, erlischt die grüne LED-Leuchte und die rote LED wird aktiviert. Mithilfe eines im Setup definierten Zählers „counter“, kann zwischen Zuständen vor und nach der Timerlogik separiert werden. Dabei wird bei erstmaligem Eintritt in den „Away“-Zustand durch den vordefinierten Zähler das Sicherheitszeit von zwei Minuten gestartet (counter = 0 auf counter = 1). Nachdem der Timer abgelaufen ist, gelangt man durch das Inkrementieren des Zählers in den Folgezustand, welcher die Bewegungssensorik aktiviert (counter = 2). Diese musst erstmal den aktuellen Wert des Sensors annehmen (counter = 3), weil sonst direkt eine Bewegung gemeldet wird. Die Bewegungssensorik ist jetzt bereit, Bewegungen zu erkennen.

Erkennt das Sicherheitssystem eine Bewegung, wird eine entsprechende Meldung an den MQTT-Broker übermittelt. Der Zähler wird erneut inkrementiert (counter = 4) um weitere Nachrichten zu verhindern. Falls der Bewegungssensor wieder keine Bewegung erkennt, wird der Zähler wieder zurückgesetzt und das Programm gelangt wieder in den Zustand, welcher für die Bewegungserkennung verantwortlich ist. So kann eine Überwachung mit erneute Einhaltung des Sicherheitszeit gewährleistet werden. Erneute Einhaltung der Sicherheitszeit hilft dabei große Mengen an Nachrichten zu verhindern. Die Implementierung des Away Zustandes ist in Abbildung 22 zu erkennen.

Node Red

Die Datenübertragung wird über einen mit Node-RED eingerichteten Server abgewickelt. Innerhalb des Programms wird ein vordefiniertes Topic („MFHLSensor“) genutzt, um eine Kommunikation über den MQTT Broker zu ermöglichen. Bei eintretender Bewegungserkennung wird mit der „publishString“ Methode eine Kommunikation zwischen den Schnittstellen eingeleitet. Nachdem die Daten an Node-RED übermittelt worden sind, muss eine Weiterleitung an die entsprechenden Endgeräte stattfinden.

In der folgenden Abbildung (Abbildung 23) wird der verwendete Flow dargestellt. Es wird eine Test Methode berücksichtigt um die Funktionen der verbundenen Email und Discord Nodes zu überprüfen. Ein Funktions-node (Abbildung 24) formatiert die Nachricht sodass der Topic der Email “Security System Noticed Intrusion” lautet, sowie eine Datum mit aktuelle Zeitangabe der Nachricht hinzugefügt werden.

Über das Netzwerk-Node „mqtt-in“ kann durch das Festlegen eines vorspezifizierten Servers, sowie Topics ein Dateninput verarbeitet werden. Dabei werden die Nodes „discord“ und „email“ zur Weiterleitung einer Push-Benachrichtigung genutzt.

Um eine Push-Benachrichtung an eine E-Mail Adresse weiterzuleiten, muss das „email“ Node (Abbildung 25) lediglich mit Server, Port und den ID-Daten des Nutzers synchronisiert werden.

Um eine Push-Benachrichtigung via Discord-Bot durchzuführen, muss eine Applikation, sowie ein Discord-Bot initialisiert werden. Über das Developer-Portal von Discord kann eine entsprechende Applikation erstellt werden, welche das Verwenden eines Discord-Bots ermöglicht.

Um einen Discord-Bot zu erstellen, erstellt man eine Applikation, sowie Bot auf der “Discord Developer” Homepage unter folgendem Link: https://discord.com/developers/applications. Um den Bot einzusetzen, wird er über den Reiter “OAuth2” einem bestehenden Server zugewiesen. Auch die Attribute und Berechtigungen des Bots werden in diesem Bereich ausgewählt. Hierbei werden SCOPES:={bot} und BOT PERMISSIONS:={Send Messages} ausgewählt (Abbildung 26).

Scope und Permissions Einstellungen (Abbildung 26)

Die freigelegte URL unter dem “SCOPES” Bereich führt nun über die Eingabe in die Adressleiste des Browsers zu einer Sicherheitsbenachrichtigung. Durch Bestätigen der Benachrichtigung ist der Discord-Bot einsatzbereit und das Setup des Bots abgeschlossen.

Der erstellte Discord-Bot wird mit einem gegebenen Token (Abbildung 27) sowie die Channel-ID des gewünschten Discord Channels, über Node-RED initialisiert. So kann eine Kommunikation zwischen den Systemen stattfinden und eine Meldung an die Endgeräte weitergeleitet werden.

Probleme bei der Software-Entwicklung:

Bei der Realisierung der Software kam es vereinzelt zu kleineren Problematiken oder Schwierigkeiten. Jedoch führten keine dieser Probleme zu weitereilenden Maßnahmen oder Planänderungen. Die Umsetzung des Softwareentwurfs konnte planmäßig und im vorher festgelegtem Zeitrahmen ablaufen und beendet werden.

Das Realisieren eines Sicherheitstimers stellte anfangs eine zu bewältigende Hürde dar. Ziel war es, nach Aktivierung des “Away”-Zustands einen zweiminütigen Zeitpuffer vor Einschaltung des Bewegungssensors zu realisieren. Beginnend wurde mit der “delay”-Methode versucht, diese Funktionalität zu erreichen. Jedoch führte das Ausführen der “delay”-Methode zu einem Stillstand aller Programmabschnitte. Es war so nicht mehr möglich zwischen den Zuständen zu wechseln, oder den Nachtmodus zu aktivieren. Um dieses Problem zu lösen, wurde eine Timerlogik erstellt, welche mit Festlegung der Systemzeit eine optimale Zeiterfassung ermöglicht.
Ein weitere Schwierigkeit befand sich in der Umsetzung einer umfangreichen Funktionalität mit nur einem gegebenen Button. Da nur ein Button verwendet wird, konnte die Umschaltung zwischen den Zuständen mit Hilfe von booleschen Werten realisiert werden. Weitere Funktionalitäten, wie das Einschalten eines Nachtmodus, waren jedoch kaum umsetzbar und sehr bedienerunfreundlich. Um einem Button weitere Funktionalität hinzuzufügen, verwendeten wir die Button-Logik von Spivey. Es war so möglich, zwischen kurzen und langen Knopfdrücken zu separieren und so umfangreichere Funktionalitäten zu gewährleisten.
Schließlich stellte sich auch das Initialisieren einer Push-Benachrichtigung als kleinere Herausforderung heraus. Nachdem die “publish”-Methode, welche eine Nachricht an den MQTT-Broker verschicken sollte, wiederholt zu Fehlermeldungen führte, wurde ein Verbindungsproblem als Fehlerquelle vermutet. Es stellte sich jedoch heraus, dass der MQTT-Broker lediglich mit “Char-Arrays” operieren kann. Der Fehler lag an der Verwendung eines falschen Datentyps. Um dieses Problem zu lösen, wurde eine “publishString”-Methode entworfen, um eine parametrisierte Nachricht in ein “Char-Array” umzuwandeln und zu verschicken (Abbildung 28).

Inbetriebnahme

Video Demo zur Inbetriebnahme

Fazit, Lessons Learned und mögliche Verbesserungen

Das Semesterprojekt im Rahmen der Veranstaltung „Soft Skills und technische Kompetenz “ zum Thema „DIY – Smart Home“ verlief in der Gruppe größtenteils reibungslos. Im Rahmen der Ideenfindung und der Rollenverteilung war schnell eine gemeinsame Projektidee gefunden und die Kompetenzen der Gruppenmitglieder haben sehr gut zusammengepasst. Jedes Gruppenmitglied konnte seine Stärken in das Projekt bestenfalls einbringen. Im Verlauf des Projektes wurden regelmäßig Meetings in den eingeteilten Zweierteams und in der ganzen Gruppe durchgeführt, sodass schnell auf Probleme reagiert werden konnte und alle Gruppenmitglieder auf dem neuesten Stand waren. Viele Probleme gab es während des Projektes nicht, wenn welche vorgefallen sind, wurden diese innerhalb kurzer Zeit gelöst oder ein Workaround geschaffen. Als Beispiel ist hier das Lötproblem am D4-Pin zu nennen, welches durch das Umlöten auf D6 gelöst wurde. Die interne LED wird nicht mehr angesprochen und der D4 PIN wurde umgangen.
Die Projektgruppe konnte die geplanten Arbeitspakete zeitlich alle einhalten, lediglich die Projektdokumentation wurde am Ende des Projektes um zwei Tage verschoben, da hier zwei Projektmitglieder nicht zur Verfügung standen. Der eingeplante Zeitpuffer für Risikomanagement hat der Projektgruppe aber weiterhin einen Puffer gewährt, sodass die fertige Projektdokumentation noch mehrfach korrekturgelesen werden konnte.

Aus dem Projekt zieht die Gruppe, dass eine gute Organisation zu Beginn des Projektes ein sehr wichtiger Faktor für ein gelungenes Projekt ist. Von allen Projektmitgliedern wurde das Projektziel akzeptiert und in der geplanten Zeit umgesetzt. Alle gewünschten Funktionalitäten konnten umgesetzt werden.

Für das nächste Projekt nimmt die Projektgruppe mit, dass schwierig zu reproduzierende Ergebnisse (bspw. der Zusammenbau der Hardware mit Löten) mit mehr Vorsicht angegangen werden. Die Schaltung hätte mit Software getestet werden müssen, dann wäre der Fauxpas mit der internen LED früher aufgefallen. Da wir die Hardware jeweils nur 1x zur Verfügung hatten, konnte die Schaltung nicht wieder auseinander gelötet werden. Das Risiko wäre zu groß gewesen, dass Teile zerstört werden.

Im Großen und Ganzen blickt die Projektgruppe auf ein von Vorne bis Hinten gelungenes Projekt zurück.