Aus den Vielen Informationen des Blogs die interessanten für einen Vortrag herauszufinden, gestaltet sich anfänglich schwierig. Doch nach ein paar Versuchen und Absprachen innerhalb der Gruppe, steht die Auswahl schließlich fest. Dabei wird darauf geachtet, dass pro Folie ungefähr eine Minute Redezeit hergibt.

Als Layout der Präsentation wird zunächst ein schon Vorhandenes Layout einer Präsentation aus dem Wintersemester 2020/2021 verwendet.

Nachdem das Feedback zu den Folien der Präsentation eintrifft, werden die Inhalte in die Präsentationsvorlage der Carl von Ossietzky Universität Oldenburg übertragen. Das Feedback wird umgesetzt und die entsprechenden Folien werden angepasst oder auch gelöscht, falls diese nicht in den Vortrag passen.

Sobald die Änderungen vollzogen sind, wird die Präsentation im bereitgestellten Big Blue Button Raum durchgesprochen. Dabei werden die Folien zwischen den Gruppenmitgliedern aufgeteilt und beim Vortragen die Zeit gestoppt, um zu sichern, dass der Vortrag innerhalb der vorgegebenen Zeit von 10 Minuten gehalten wird.

Anschließend werden letzte Feinheiten geklärt, die noch geändert werden müssen und Informationen aufgezeigt, die beim Vortrag nicht fehlen sollen.

Um den Blog aufzusetzen, werden verschiedene Designs ausprobiert, um festzustellen, mit welchem am besten gearbeitet werden kann. Die Wahl fällt auf Twenty Thirteen von WordPress, da dieses Design intuitiv verändert werden kann. Zwar gibt es gegenüber anderen Designs das Problem, dass die Farbe des Menüs nicht verändert werden kann, aber um das zu umgehen wurde die Farbe in andere Seiten mit eingearbeitet. Der Anforderungskatalog wird zum Beispiel in einem ähnlichen Farbton gestaltet.

Das Aufteilen der Seiten und Unterseiten im Menü hat am Anfang zu Problemen geführt, da es noch sehr unübersichtlich war, wie die einzelnen Seiten alle auf der obersten Ebene darzustellen. Um sich einen Überblick zu schaffen, wird per OneNote eine Zeichnung erstellt, um die einzelnen Seiten passen zu Oberthemen zusammenzufassen.

Es wird sich dagegen entschieden, den Blog nur mit Blogeinträgen zu füllen. Stattdessen werden einige Seiten so bearbeitet, dass die Informationen direkt auf der jeweiligen Seite stehen.

Um den Zeitplan zu erstellen, wird erst eine Tabelle mit dem TablePress Tool von WordPress erstellt. Da diese nicht dem gewünschten Stil angepasst werden kann, wird die Tabelle per Tabellen Block hinzugefügt.

Nachdem alle wichtigen Dateien in die Repository gepusht wurden, fingen das schreiben der ReadMe an. Dies ist eine Anleitung zur Inbetriebnahme des Projekts, die beschreibt, welche Teile man braucht, welche Dinge installiert werden müssen und eine Beschreibung der genutzten Technologien, was in diesem Fall die Auflistung der genutzten C++ Librarys und deren Version war.

Als die Anleitung fertig geschrieben war, ging es an das Aufräumen der Repository. Dies bestand daraus, die ReadMe auf Fehler zu Überprüfen, bereits gepushte Dateien in sinnvolle Ordner zu packen und den Code auf vernünftige Kommentare zu prüfen. Außerdem war es gerade in diesem Fall wichtig den Code darauf zu überprüfen, ob noch private Daten, wie z.B. das Passwort des eigenen Netzwerkes im Code sind, da mit IoT Technologien gearbeitet wurde.

Nach der Erstellung der Repository auf Github, startete die erste Ideensammlung für die Strukturierung der readMe. Hierbei ging es hauptsächlich um eine grobe Aufteilung der Themen, aus welcher eine solche Datei meist aufgebaut ist. Die ersten Bausteine waren ein TOC oder auch Table of Contents was eine Art Inhaltsverzeichnis ist, eine generelle Beschreibung der Inbetriebnahme der Projekts, sowie einer Erklärung der genutzten Bibliotheken und da das ganze wie ein echtes Produkt behandelt werden sollte, eine Lizenz.

Danach ging an die ersten Versuche mit dem MQ135 Sensor. Hierfür wurde ein simpler Test-Code geschrieben. Jedoch hat der Sensor unpassende Werte geliefert. Selbst nach der Kalibrierung und testen, wo der Sensor hoher Rauchkonzentration ausgesetzt wurde, lieferte dieser keinen richtigen Werte. Da die Fehlerquelle bis zuletzt nicht gefunden werden konnte, wurde der MQ135 Sensor aus dem Projekt gestrichen.

In der KW 36 wurde mit der Programmierung begonnen. Der Test des Luftqualitätssensors war erfolgreich. Somit wurde der Sensor zum Einbrennen an die frische Luft gelegt und danach wurde dann der Code vom Testprogramm mit einem MQTT Beispielprogramm vereint. In NodeRED wurde mit mqtt in und debug geprüft ob und welche Werte angekommen sind. Bei der Programmierung des OLED Shields war ein erster Test mit einem Testprogramm nicht erfolgreich, da die zusätzlichen Bibliotheken in der falschen Version installiert wurden. Das Problem ließ sich schnell beheben und der Fehler war ebenfalls schnell gefunden. Die beiden Mikrocontroller haben mit den Programmen genau das gemacht was sie sollten und auch beim Testen (anatmen) wurden die Werte schnell passend aktualisiert.

In der KW 34 und 35 wurden die ersten 3D Drucke abgeholt und überdacht. Zudem wurde angefangen die Hardware zu löten. Dabei ist aufgefallen, dass unser anfänglicher Plan vom Formfaktor der Hardware nicht mehr passt. Es wurde sich entschieden alles kompakter und vor allem modular zu löten. Falls also der Sensor kaputt geht, soll dieser austauschbar sein, genauso wie der Mikrocontroller. Dadurch, dass alles austauschbar war hatten wir ein Stecksystem, welches die Komponenten übereinander und nicht mehr nebeneinander angeordnet hat. Anfangs gab es ein zwei Schwierigkeiten beim Löten, da das Lötzinn nicht so schön geschmolzen ist wie gewollt, das konnten wir mit Hitzeeinstellungen am Lötkolben beheben. Danach lief alles sehr gut. Routine war wieder schnell vorhanden. Zudem haben wir noch einen zusätzlichen Sensor bekommen, welcher die Luftqualität besser darstellen kann, als der ursprüngliche MQ-135. Der neue Sensor misst den CO2 Gehalt und den TVOC-Wert. (TVOC, total volatile organic compounds)

Nachdem die Hülle für den MQ-135 Sensor in der Gruppe designt und gedruckt wurde, ging es an die Fertigstellung der Hardware. Dabei hat sich herausgestellt, dass der Einsatz von zwei Sensoren (MQ-135 Sensor und CCS811 Sensor) sinnvoller ist und diese kompakter als gedacht gelötet werden können.
Also mussten jetzt zwei neue Modelle entworfen und gedruckt werde.
Bei dem Entwurf wurde auf den Klickverschluss der Hülle des Raspberry Pis zurückgegriffen und eine einfache Box mit individuellen Öffnungen erstellt.
Für die Anzeige der Luftqualität war ein Display vorgesehen, welches öfters in den Hintergrund gerückt war. Nachdem die Hardware dafür fertiggestellt wurde, wurde nach dem Prinzip der anderen Modelle ebenfalls eine Box für das OLED-Shield erstellt.

Da die Drucke nicht optimal gepasst haben, wurde ein Modell neu gedruckt und die anderen mit einem Feinbohrer bearbeitet (siehe Abb. 1).

Nach dem Treffen im Makerspace am 23.07 zur Besprechung der Projetplanung und der Erstellung eines Anforderungskatalogs, ging es mit der Dokumentation los.

Der Anforderungskatalog und geplante Meilensteine wurden sauber in ein Worddokument kopiert.
Für die Motivation wurden eigene Gedanken niedergeschrieben und mit Argumenten aus eigener Recherche unterstützt.
Nachdem in der Gruppe erste Überlegungen zum Risikomanagement besprochen wurden, wurden dieser weiter ausgereift und ebenfalls dokumentiert.
Zusätzlich wurde für die bessere Übersicht eine Excel Tabelle als Zeitplan erstellt.
In dieser sollen Termine für gemeinsame Treffen und selbst gesetzte Fristen festgehalten werden.
Da der Makerspace bereits am 03.09 schließt, wurde der 31.08 als Frist für die Fertigstellung der Hardware und des 3D-Drucks gewählt. Die Software möglichst am 06.09 fertig sein, damit bei möglichen Problemen noch 10 Tage bis zur Vorstellung des Projekts bleiben, um diese zu beheben.