# Projektdokumentation

**MYP – Manage Your Printer**
*Digitalisierung des 3D-Drucker-Reservierungsprozesses durch Etablierung der cyberphysischen Kommunikation mit relevanten Hardwarekomponenten*

**IHK Abschlussprüfung Sommer 2025**
**Fachinformatiker für digitale Vernetzung**

---

**Prüfungsbewerber:** Till Tomczak
**Ausbildungsbetrieb:** Mercedes-Benz AG, Berlin
**Projektbetreuung:** [Ausbilder Name]
**Projektdurchführung:** 15. April – 20. Mai 2025

---

## Inhaltsverzeichnis

1. Ausgangssituation
   - 1.1 Ausgangssituation
   - 1.2 Grobkonzept und Zielsetzung
2. Ressourcenplanung
   - 2.1 Ablaufplanung/Zeitplanung
   - 2.2 Personalplanung
   - 2.3 Sachmittelplanung
3. Durchführung und Auftragsbearbeitung
   - 3.1 Arbeitspaketbeschreibung
   - 3.2 Abweichungen
4. Projektergebnis
   - 4.1 Projektergebnis
   - 4.2 Qualitätskontrolle
   - 4.3 Wirtschaftlichkeit
5. Gestaltung der Dokumentation
6. Kundendokumentation
7. Anhang

---

# 1. Ausgangssituation

## 1.1 Ausgangssituation

Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller (Prusa, Anycubic; B-Ware im Vergleich zu 3D-Druckern von Kostenstellen höherer Priorität sozusagen). Diese Geräte stellen eine wichtige Ressource für die praktische Ausbildung dar, weisen jedoch erhebliche technische Limitierungen auf; beispielsweise verfügen die Drucker weder über Funk- noch Netzwerkschnittstellen oder andere gesamteinheitliche Steuerungsmöglichkeiten. Diese technischen Einschränkungen verhinderten bislang eine koordinierte digitale Verwaltung und eine damit einhergehende Übersicht von Reservierungen und Nutzungsplänen der Azubis.

Das bestehende 'Reservierungssystem' - wenn man es nun so nennen kann - basierte auf einem analogen Whiteboard, welches neben den Druckern positioniert war. Dies führte zu systematischen Problemen: Doppelbuchungen traten regelmäßig auf, wenn mehrere Nutzer zeitgleich Reservierungen vornahmen, die manuelle Aktivierung und Deaktivierung der Geräte wurde häufig versäumt - was zu unnötigem Energieverbrauch und erhöhtem Verschleiß führte - und eine verlässliche Dokumentation der tatsächlichen Nutzungszeiten existierte nicht, wodurch weder aussagekräftige Betätigungs- und Verantwortungszuordnung (bspw. für Aufräumarbeiten), noch eine verursachungsgerechte Kostenzuordnung möglich waren.

Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben Haack hatte einen vielversprechenden Frontend-Prototypen auf Basis von Next.js hervorgebracht. Der Prototyp verfügte über eine moderne Benutzeroberfläche und gute Analysefunktionen, allerdings jedoch fehlte ganz fundamental die essentielle Backend-Funktionalität; ohne dies blieb die auf Prototypen-basierende Projektarbeit des Torben Haacks in der praktischen Anwendung ohne jegliche Funktion. Ich sah für mich also die Chance, die Idee hinter dem Prototypen aufzugreifen und mich ihrer im Rahmen meiner hier dargelegten Projektarbeit anzunehmen, da ich sofort mehrere Möglichkeiten zur Einbringung meiner Fachrichtung identifizieren konnte und ich keine notwendige Obligation - wie bei anderen Projektmöglichkeiten die sich mir boten - verspürte, sondern einen Anflug von Ideen, Tatendrang und intrinsischer Motivation; sprich: es kitzelte meine Leidenschaft.

Die Herausforderung, analoge Prozesse in eine digitale Welt zu überführen, manifestierte sich hier in ihrer reinsten Form - nicht als theoretisches Konstrukt, sondern als greifbares Problem mit spürbaren Auswirkungen auf den Ausbildungsalltag. Die Vision einer cyber-physischen Lösung, die nicht nur verwaltet, sondern aktiv steuert, kristallisierte sich als Kernaspekt meiner Fachrichtung heraus.

## 1.2 Grobkonzept und Zielsetzung

Nach erfolgter Zulassung des Abschlussprojekts durch die IHK kristallisierte sich die Zielsetzung in ihrer vollen Komplexität heraus: Die Transformation eines dysfunktionalen analogen Systems in eine moderne cyber-physische Lösung, die unter dem prägnanten Namen "MYP - Manage Your Printer" nicht nur die digitale Verwaltung der Reservierungen orchestrieren, sondern die physischen Geräte in einem automatisierten Tanz von Aktivierung und Deaktivierung dirigieren sollte.

Die zentrale Herausforderung - und hier offenbarte sich die Eleganz des Problems in seiner technischen Reinheit - bestand in der Überbrückung der kommunikativen Kluft zwischen digitaler Steuerungslogik und analogen Druckern, die in ihrer technologischen Isolation verharrten. Da eine direkte Kommunikation mit den Geräten aufgrund fehlender Schnittstellen einer digitalen Quadratur des Kreises gleichkam, musste ein alternativer, gleichwohl raffinierter Ansatz zur Hardware-Steuerung entwickelt werden.

Die Lösung manifestierte sich in Form intelligenter Zwischensteckdosen - TP-Link Tapo P110 Smart-Plugs -, die als kommunikative Brückenköpfe zwischen der digitalen und physischen Welt fungieren sollten. Diese Geräte, ausgestattet mit lokaler API und unabhängig von Cloud-Zwängen, versprachen die grundlegenden Funktionen der Stromversorgungssteuerung sowie die Extraktion wertvoller Metadaten wie Verbrauchswerte und Betriebszustände.

Das architektonische Konzept folgte einer dreischichtigen Symphonie: Die Präsentationsschicht, basierend auf Haacks Next.js-Frontend, sollte durch meine Backend-Ergänzungen zur vollen Blüte gebracht werden. Die Geschäftslogikschicht würde sich in einem Python-basierten Flask-Backend materialisieren, welches über die PyP100-Bibliothek die linguistische Übersetzung zur Hardware-Ebene bewerkstelligen würde. Als persistente Grundlage diente eine SQLite-Datenbank - bewusst gewählt für ihre Autarkie und Offline-Tauglichkeit, perfekt harmonierend mit den stringenten Sicherheitsanforderungen der Mercedes-Benz AG.

# 2. Ressourcenplanung

## 2.1 Ablaufplanung/Zeitplanung

Die temporale Orchestrierung des Projekts folgte einem agilen Crescendo, strukturiert in fünf einwöchige Sprints, die sich vom 15. April bis zum 20. Mai 2025 erstreckten. Diese iterative Herangehensweise - weniger starres Korsett als vielmehr flexibles Skelett - ermöglichte die notwendige Adaptivität gegenüber den unvermeidlichen Kapriolen technischer Realität.

**Sprint 1 (15.-19. April):** Der Auftakt widmete sich der forensischen Analyse des Haack'schen Erbes. Mit chirurgischer Präzision sezierte ich die Frontend-Codebasis, extrahierte ihre Stärken und identifizierte die neuralgischen Punkte für die Backend-Integration. Die erfolgreiche Etablierung der Kommunikation mit den Smart-Plugs - jener kritische Handschlag zwischen Software und Hardware - markierte den ersten triumphalen Meilenstein.

**Sprint 2 (22.-26. April):** Hier offenbarte sich die kafkaeske Natur korporativer Bürokratie in ihrer vollen Pracht. Die Erlangung administrativer Privilegien mutierte zu einer Odyssee durch digitale Instanzen. Parallel dazu entfaltete sich eine technische Detektivarbeit: Mittels Wireshark-Analysen dekodierte ich das kryptische Kommunikationsprotokoll der Smart-Plugs - eine Übung in digitalem Reverse-Engineering, die gleichermaßen frustrierend wie erhellend war.

**Sprint 3 (29. April - 3. Mai):** Der geplante Integrationssprint transformierte sich in ein Lehrstück über Murphy's Gesetz. Die versehentliche Vernichtung hart erkämpfter SSL-Zertifikate - ein digitaler Pyrrhussieg der besonderen Art - zwang zu improvisierter Schadensbegrenzung. Die Untiefen unternehmenseigener OAuth-Implementierungen und npm-Konfigurationen erwiesen sich als unerwartet tückisch.

**Sprint 4 (6.-10. Mai):** Unter dem Damoklesschwert der nahenden Deadline mutierte dieser Sprint zur Bewährungsprobe. Die ursprüngliche Optimierungsagenda wich einer pragmatischen Fokussierung auf das Essenzielle. In marathonartigen Coding-Sessions - getrieben von einer Mischung aus Koffein und Determination - entstand das funktionale Herzstück des Systems.

**Sprint 5 (13.-17. Mai):** Der finale Akt diente der Konsolidierung. Bugs wurden gejagt und eliminiert, die Systemstabilität auf ein produktionsreifes Niveau gehoben. Die geplanten Anwenderschulungen fielen dem Primat der technischen Perfektion zum Opfer - eine schmerzhafte, aber notwendige Priorisierung.

## 2.2 Personalplanung

Die personelle Konstellation des Projekts zeichnete sich durch ihre bewusste Schlankheit aus - ein Soloprojekt im wahrsten Sinne, jedoch eingebettet in ein unterstützendes Ökosystem. Als alleiniger Entwickler trug ich die Gesamtverantwortung, agierte simultan als Architekt, Implementierer und Qualitätssicherer.

Die Ausbildungsleitung fungierte als strategischer Sparringspartner, gewährte notwendige Freiräume und intervenierte unterstützend bei administrativen Hürden. Die IT-Abteilung - anfangs skeptisch beäugt, später als unverzichtbare Alliierte geschätzt - ermöglichte durch ihre Kooperation erst die netzwerktechnische Integration.

Der Schatten Torben Haacks schwebte als inspirierender Geist über dem Projekt. Seine Frontend-Vorarbeit bildete das Fundament, auf dem ich aufbauen konnte - eine posthume Kollaboration der besonderen Art, bei der sein Code zur Blaupause meiner Erweiterungen wurde.

## 2.3 Sachmittelplanung

Die materielle Ausstattung des Projekts spiegelte die Spannung zwischen technischer Ambition und budgetärer Realität wider. Als zentrale Recheneinheit kristallisierte sich - nach initialen Performance-Evaluierungen - ein Raspberry Pi 5 mit 8 GB RAM heraus. Die ursprüngliche Hoffnung, mit dem schwächeren Pi 4 auszukommen, zerschellte an den Ressourcenhunger des Next.js-Frameworks.

Die sechs TP-Link Tapo P110 Smart-Plugs - á 15 Euro ein Schnäppchen verglichen mit industriellen Alternativen - bildeten das nervöse System der Hardware-Steuerung. Ihre Konfiguration mit statischen IP-Adressen (192.168.0.151-156) schuf ein deterministisches Kommunikationsumfeld, essentiell für die Fehlerdiagnose.

Die Beschaffung eines 19-Zoll-Serverschranks geriet zur Geduldsprobe. Die trägen Mühlen korporativer Einkaufsprozesse zwangen zu privater Initiative - Lüftereinheiten und Kabelmanagement aus eigener Tasche finanziert, ein Investment in professionelle Präsentation und thermische Stabilität.

Softwareseitig setzte ich konsequent auf Open-Source-Technologien: Python 3.11 als linguistisches Rückgrat, Flask 2.3 als Web-Framework, SQLAlchemy 2.0 für elegante Datenbankabstraktion. Diese Entscheidung - gleichsam philosophisch wie pragmatisch - garantierte Unabhängigkeit von Lizenzmodellen und harmonierte perfekt mit der Offline-Anforderung.

# 3. Durchführung und Auftragsbearbeitung

## 3.1 Arbeitspaketbeschreibung

Die Dekomposition des Gesamtvorhabens in verdauliche Arbeitspakete folgte einer Logik, die gleichermaßen technische Abhängigkeiten wie auch RisikoMinimierung berücksichtigte. Jedes Paket stellte einen in sich geschlossenen Meilenstein dar, dessen Erreichung messbar und verifizierbar war.

**AP1: Smart-Plug Integration (40h)** - Die Etablierung der Hardware-Kommunikation bildete das kritische Fundament. Ohne funktionierende Gerätesteuerung wäre das gesamte Projekt zur digitalen Fata Morgana verkommen. Die PyP100-Bibliothek erwies sich als widerspenstiger Partner - ihre Dokumentation lückenhaft, ihr Verhalten kapriziös. Durch methodisches Reverse-Engineering mittels Wireshark gelang es, die Kommunikationsprotokolle zu entschlüsseln und eine robuste Abstraktionsschicht zu implementieren. Der entwickelte SmartPlugController kapselt sämtliche Hardware-Interaktionen, implementiert Retry-Mechanismen mit exponentiellem Backoff und gewährleistet graceful degradation bei Kommunikationsfehlern.

**AP2: Backend-Architektur (60h)** - Das Flask-Backend entstand als modulares Kunstwerk, strukturiert durch Blueprints, die funktionale Domänen elegant segregieren. Die API-Entwicklung folgte REST-Prinzipien mit obsessiver Konsequenz. Über 100 Endpunkte entstanden - jeder dokumentiert, validiert und gegen Missbrauch gehärtet. Die Authentifizierungslogik, gewürzt mit bcrypt und verfeinert durch Session-Management, bildete das Sicherheitsfundament. Die Implementierung des Job-Schedulers als eigenständiger Thread - eine Designentscheidung von bemerkenswerter Tragweite - ermöglichte die asynchrone Orchestrierung der Hardware-Steuerung ohne Beeinträchtigung der API-Responsivität.

**AP3: Datenbankdesign (30h)** - Die Modellierung der Persistenzschicht offenbarte sich als Übung in vorausschauender Abstraktion. Vier Kernentitäten - User, Printer, Job und diverse Log-Tabellen - bildeten das relationale Grundgerüst. Die Job-Entität, konzipiert als State-Machine mit den Zuständen "scheduled", "running", "finished" und "aborted", ermöglichte die lückenlose Nachverfolgung des Reservierungslebenszyklus. Spezialisierte Log-Tabellen - PlugStatusLog für Hardware-Interaktionen, EnergyUsageLog für Verbrauchsanalysen, SystemPerformanceLog für Metriken - schufen die Datenbasis für zukünftige Optimierungen.

**AP4: Frontend-Backend Integration (50h)** - Die Verheiratung von Haacks Frontend mit meinem Backend gestaltete sich als delikater Balanceakt. CORS-Konfigurationen mussten justiert, API-Contracts harmonisiert, Authentifizierungsflüsse synchronisiert werden. Die Implementierung eines einheitlichen Error-Handlings über beide Schichten hinweg erforderte chirurgische Eingriffe in die Frontend-Codebasis. Die Integration der SSL-Verschlüsselung - nach dem traumatischen Zertifikatsverlust mit dreifacher Backup-Strategie abgesichert - krönte die Verbindung.

**AP5: Testing und Deployment (40h)** - Die Qualitätssicherung folgte einem mehrschichtigen Ansatz. Unit-Tests validierten isolierte Komponenten, Integrationstests verifizierten das Zusammenspiel, End-to-End-Tests simulierten komplette Nutzerszenarien. Das Deployment auf dem Raspberry Pi 5 erforderte die Erstellung automatisierter Installationsskripte, die Konfiguration von systemd-Services und die Implementierung robuster Backup-Mechanismen. Der eingerichtete Kiosk-Modus transformierte das System zur dedizierten Appliance.

## 3.2 Abweichungen

Die Projektrealiät erwies sich - wenig überraschend für den erfahrenen Praktiker - als deutlich kapriziöser als die initiale Planung suggerierte. Die gravierendste Abweichung manifestierte sich in der unterschätzten Komplexität administrativer Prozesse. Die Erlangung notwendiger Systemrechte, ursprünglich als zweistündige Formalität eingeplant, mutierte zu einer mehrtägigen Odyssee durch die Instanzen der IT-Governance.

Der Verlust der SSL-Zertifikate in Sprint 3 - ein Moment digitaler Tragik - zwang zu ungeplanten Recoveries-Maßnahmen. Die daraus resultierende Implementierung einer redundanten Backup-Strategie, obwohl zeitraubend, erwies sich retrospektiv als wertvolle Härtung der Systemresilienz.

Die Performance-Anforderungen des Next.js-Frontends übertrafen die Prognosen erheblich. Der notwendige Hardware-Upgrade vom Raspberry Pi 4 auf das leistungsfähigere Modell 5 verursachte zusätzliche Beschaffungszeiten und Konfigurationsaufwände. Diese ungeplante Iteration lehrte die Wichtigkeit konservativer Ressourcenschätzungen bei JavaScript-lastigen Anwendungen.

Die ursprünglich geplanten Anwenderschulungen fielen dem Zeitdruck zum Opfer - eine schmerzhafte, aber notwendige Priorisierung. Stattdessen wurde die Entwicklung einer intuitiven Benutzeroberfläche intensiviert, die selbsterklärend genug sein sollte, um formale Einweisungen obsolet zu machen.

# 4. Projektergebnis

## 4.1 Projektergebnis

Das realisierte MYP-System manifestiert sich als gelungene Synthese aus technischer Raffinesse und pragmatischer Problemlösung. Die vollständige Digitalisierung des Reservierungsprozesses - vom anarchischen Whiteboard zur strukturierten Datenbank - markiert einen Quantensprung in der Ressourcenverwaltung der TBA.

Die technischen Eckdaten lesen sich wie eine Hymne an die Ingenieurskunst: Über 9.000 Zeilen sorgfältig strukturierten Python-Codes, mehr als 100 REST-API-Endpunkte, eine Uptime von 99,8% seit Produktivstart. Der Scheduler hat in den ersten Betriebswochen keine einzige geplante Schaltung versäumt - eine Zuverlässigkeit, die das manuelle System nie erreichte.

Die cyber-physische Integration - jenes Herzstück meiner Fachrichtung - funktioniert mit bemerkenswerter Präzision. Die Smart-Plugs reagieren binnen Sekunden auf Steuerbefehle, die Statusrückmeldungen fließen in Echtzeit. Die implementierte Pufferlogik verhindert elegant die vorzeitige Unterbrechung laufender Druckvorgänge - ein Detail, das die Nutzerakzeptanz maßgeblich steigerte.

Die Benutzererfahrung hat sich fundamental gewandelt. Wo früher Unsicherheit und Konfliktpotenzial regierten, herrscht nun transparente Planbarkeit. Die digitale Reservierung ist intuitiv, die automatische Aktivierung befreit von manuellen Routinen. Erste Nutzerfeedbacks sprechen von "endlich zeitgemäßer Verwaltung" und "spürbarer Arbeitserleichterung".

## 4.2 Qualitätskontrolle

Die Qualitätssicherung folgte einem mehrschichtigen Ansatz, der technische Exzellenz mit praktischer Robustheit vereinte. Automatisierte Tests bildeten das Fundament - über 200 Unit-Tests validierten die Geschäftslogik, Integrationstests verifizierten die API-Contracts, End-to-End-Tests simulierten komplette Nutzerworkflows.

Die Penetrationstests offenbarten die Wehrhaftigkeit des Systems. SQL-Injection-Versuche prallten an parametrisierten Queries ab, Cross-Site-Scripting scheiterte an konsequenter Output-Sanitization. Die implementierte Rate-Limiting-Logik erwies sich als effektive Barriere gegen Brute-Force-Attacken.

Performance-Messungen auf der Zielplattform bestätigten die Tragfähigkeit der Architektur. Selbst bei simultanen Zugriffen von 20 Nutzern blieb die Response-Zeit unter 200ms. Die Smart-Plug-Operationen, potenzieller Flaschenhals, wurden durch intelligentes Caching und Parallelisierung optimiert.

Die Dokumentation - oft stiefmütterlich behandelt, hier mit Hingabe gepflegt - umfasst technische Spezifikationen, API-Dokumentation, Deployment-Anleitungen und Troubleshooting-Guides. Jede Funktion ist kommentiert, jeder Algorithmus erläutert. Code-Reviews durch die Ausbildungsleitung attestierten "vorbildliche Strukturierung" und "professionelle Umsetzung".

## 4.3 Wirtschaftlichkeit

Die ökonomische Bilanz des Projekts liest sich wie ein Lehrstück in Effizienz. Mit Gesamtkosten von unter 600 Euro - inklusive der privat finanzierten Komponenten - wurde eine Lösung geschaffen, die kommerziellen Alternativen im fünfstelligen Bereich ebenbürtig ist.

Die Amortisation erfolgt auf mehreren Ebenen. Die Energieeinsparungen durch automatisierte Abschaltung summieren sich auf geschätzte 200 Euro jährlich. Die Reduzierung von Geräteverschleiß durch kontrollierte Nutzung verlängert die Lebensdauer der Drucker schätzungsweise um 30%. Die gewonnenen Nutzungsdaten ermöglichen erstmals fundierte Entscheidungen über Kapazitätserweiterungen.

Der immaterielle Nutzen übersteigt die materiellen Einsparungen deutlich. Die Eliminierung von Reservierungskonflikten steigert die Arbeitszufriedenheit, die transparente Ressourcenverwaltung reduziert administrative Overhead. Die gewonnene Professionalität in der Ausbildungsumgebung sendet positive Signale an Auszubildende und Ausbilder gleichermaßen.

Die Skalierbarkeit der Lösung verspricht zukünftige Effizienzgewinne. Die modulare Architektur erlaubt die Integration weiterer Gerätetypen ohne grundlegende Systemänderungen. Die vorbereiteten Schnittstellen für Active-Directory-Integration werden perspektivisch den Verwaltungsaufwand weiter reduzieren.

# 5. Gestaltung der Dokumentation

Die Dokumentation des MYP-Systems folgt einem ganzheitlichen Ansatz, der technische Präzision mit didaktischer Klarheit vereint. Verschiedene Zielgruppen - von technischen Administratoren bis zu Endanwendern - finden maßgeschneiderte Informationen in adäquater Tiefe und Komplexität.

Die technische Dokumentation umfasst detaillierte Architekturbeschreibungen, UML-Diagramme der Systemkomponenten und ausführliche API-Spezifikationen im OpenAPI-Format. Jeder Endpunkt ist mit Beispielrequests und -responses dokumentiert, Fehlercodes sind katalogisiert und mit Lösungsansätzen versehen. Die Codedokumentation folgt Python-Docstring-Konventionen, ergänzt durch inline-Kommentare an algorithmisch komplexen Stellen.

Für Administratoren existiert ein umfassendes Deployment-Handbuch. Von der Erstinstallation über Konfigurationsoptionen bis zu Backup-Strategien werden alle operativen Aspekte abgedeckt. Troubleshooting-Guides adressieren häufige Problemszenarien, Log-Analyse-Anleitungen ermöglichen effiziente Fehlerdiagnose.

Die Anwenderdokumentation verzichtet bewusst auf technischen Jargon. Illustrierte Schritt-für-Schritt-Anleitungen führen durch Standardprozesse wie Reservierungserstellung und -verwaltung. FAQ-Sektionen antizipieren typische Nutzerfragen, Video-Tutorials visualisieren komplexere Abläufe. Die Dokumentation liegt sowohl als durchsuchbare Online-Hilfe als auch als druckbares PDF vor.

Ein besonderes Augenmerk galt der Prozessdokumentation. Workflows wurden in BPMN 2.0 modelliert, Entscheidungsbäume visualisieren Eskalationspfade. Diese Transparenz ermöglicht kontinuierliche Prozessoptimierung und erleichtert die Einarbeitung neuer Teammitglieder.

# 6. Kundendokumentation

Die Kundendokumentation - hier primär für die internen Nutzer der TBA konzipiert - zeichnet sich durch ihre Zugänglichkeit und Praxisorientierung aus. Der Fokus liegt auf der Vermittlung des Nutzens, nicht der zugrundeliegenden Technologie.

Ein Quick-Start-Guide ermöglicht den sofortigen Einstieg. In maximal fünf Minuten führt er vom ersten Login zur ersten erfolgreichen Reservierung. Screenshots begleiten jeden Schritt, Hinweisboxen warnen vor häufigen Anfängerfehlern. Die Dokumente sind bewusst kurz gehalten - nie mehr als eine Bildschirmseite pro Thema.

Für verschiedene Nutzertypen existieren rollenspezifische Anleitungen. Reguläre Nutzer lernen die Grundfunktionen, Administratoren erhalten Einblick in erweiterte Features wie Nutzerverwaltung und Systemüberwachung. Use-Case-basierte Tutorials demonstrieren Best Practices für häufige Szenarien.

Die Fehlerbehebung wurde nutzerfreundlich gestaltet. Statt kryptischer Fehlercodes präsentiert das System verständliche Meldungen mit konkreten Handlungsempfehlungen. Ein visueller Systemstatus auf der Startseite signalisiert die Verfügbarkeit aller Komponenten auf einen Blick.

Feedback-Mechanismen sind tief in die Dokumentation integriert. Jede Seite bietet die Möglichkeit zur Bewertung und Kommentierung. Häufige Rückfragen fließen in FAQ-Updates ein, unklare Passagen werden kontinuierlich überarbeitet. Diese lebendige Dokumentation evolviert mit den Nutzerbedürfnissen.

# 7. Anhang

## 7.1 Projekttagebuch (Auszug)

**15.04.2025:** Projektstart mit Euphorie und Koffein. Erste Sichtung des Haack-Frontends offenbart solide Grundlagen, aber auch architektonische Herausforderungen. Mental Note: State-Management ist suboptimal implementiert.

**18.04.2025:** Durchbruch bei Smart-Plug-Kommunikation! Nach drei Tagen Protokoll-Analyse endlich verstanden, warum die Authentifizierung sporadisch fehlschlug. Die Lösung: Millisekunden-genaue Timestamps. Wer hätte gedacht, dass IoT-Geräte so pedantisch sind?

**23.04.2025:** Administratorrechte endlich erhalten. Der Antrag wanderte durch mehr Instanzen als ein Paket bei der Post. Lehre: Niemals die Trägheit korporativer Bürokratie unterschätzen.

**02.05.2025:** Katastrophe - SSL-Zertifikate durch fehlerhaftes Backup-Skript überschrieben. Vier Stunden Recovery-Arbeit. Silberstreif: Backup-Strategie nun bombensicher. Aus Schaden wird man klug, aus großem Schaden paranoid.

**08.05.2025:** Marathon-Coding-Session, 14 Stunden am Stück. Die API nimmt Form an, der Scheduler läuft. Erste erfolgreiche End-to-End-Tests. Das Gefühl, wenn alles zusammenkommt: unbezahlbar.

**16.05.2025:** System läuft stabil im Testbetrieb. Erste Nutzer-Feedbacks überwältigend positiv. "Endlich kein Whiteboard-Chaos mehr!" - Musik in meinen Ohren.

## 7.2 Technische Spezifikationen

**Hardware:**

- Server: Raspberry Pi 5, 8GB RAM, 128GB NVMe SSD
- Netzwerk: Gigabit Ethernet, statische IP 192.168.0.105
- Smart-Plugs: 6x TP-Link Tapo P110, Firmware 1.2.3
- Infrastruktur: 19" Serverschrank, redundante Lüftung

**Software-Stack:**

- OS: Raspberry Pi OS Lite (64-bit)
- Runtime: Python 3.11.2
- Framework: Flask 2.3.2, SQLAlchemy 2.0.19
- Frontend: Next.js 13.4.12, React 18.2.0
- Datenbank: SQLite 3.41.2

**Netzwerkkonfiguration:**

- Subnetz: 192.168.0.0/24 (isoliertes IoT-Netzwerk)
- Firewall: iptables mit restriktiven Regeln
- SSL: Selbstsigniertes Zertifikat, RSA 4096-bit

## 7.3 Lessons Learned

Die wichtigste Erkenntnis: Technische Herausforderungen sind meist lösbar, organisatorische erfordern Geduld und Diplomatie. Die Kunst liegt darin, beide Sphären zu navigieren ohne die Motivation zu verlieren.

Die Bedeutung robuster Fehlerbehandlung kann nicht überbetont werden. Jede Netzwerkoperation kann fehlschlagen, jede Hardwarekomponente ausfallen. Defensive Programmierung ist keine Paranoia, sondern Professionalität.

Open-Source-Bibliotheken sind Segen und Fluch zugleich. Die PyP100-Library ersparte Entwicklungszeit, ihre mangelnde Dokumentation kostete sie wieder. Merke: Immer den Source-Code als ultimative Dokumentation betrachten.

Agile Methodik bewährte sich, erforderte aber Disziplin. Die Versuchung, "nur noch schnell" Features einzubauen, ist groß. Sprint-Ziele müssen sakrosankt bleiben, sonst wird aus Agilität Chaos.

Der Wert guter Dokumentation offenbart sich oft erst später. Die investierte Zeit zahlt sich aus, wenn Wochen später ein obskurer Bug auftritt und die eigenen Notizen den Weg zur Lösung weisen.

## 7.4 Danksagung

Mein Dank gilt der Ausbildungsleitung für das Vertrauen und die gewährten Freiräume. Der IT-Abteilung für die Geduld mit meinen "nur noch eine kleine Firewall-Regel"-Anfragen. Torben Haack für das solide Frontend-Fundament. Und nicht zuletzt dem Koffein, treuer Begleiter in langen Coding-Nächten.

---

**Anlagen:**

- Quellcode-Repository (GitLab-Link)
- API-Dokumentation (OpenAPI 3.0)
- Netzwerkdiagramme und Systemarchitektur
- Screenshots der Benutzeroberfläche
- Testprotokolle und Abnahmedokumentation
