📚 Refactored IHK project documentation and setup scripts for better organization. 🖥️🧹

IHK_Projektdokumentation/DOKUMENTATION_BEREINIGUNG.md

@@ -1 +1,65 @@
- 
+# Dokumentation Bereinigung - Zusammenfassung
+
+## Durchgeführte Korrekturen
+
+### 1. Sprachstil und Formulierungen
+- Entfernung übertriebener Formulierungen ("kafkaeske Odyssee", "trotz Murphy's Law")
+- Vereinfachung komplexer Satzkonstruktionen
+- Reduzierung emotionaler Übertreibungen
+- Beibehaltung sachlicher, präziser Sprache
+
+### 2. Technische Korrekturen
+- IP-Adressen korrigiert: 192.168.0.100-106 (statt 151-156)
+- Raspberry Pi 5 von Anfang an (kein nachträglicher Wechsel vom Pi 4)
+- 128 GB Speicher korrekt erwähnt
+- Kein Touch-Display implementiert (Halluzination entfernt)
+
+### 3. Projektkontext
+- Torben Haack als Prototyp-Entwickler, sequenzielle Weiterentwicklung
+- Keine parallele Entwicklung (IHK-Compliance)
+- Backend-Entwicklung als Hauptaufgabe klar herausgestellt
+- Git-Verwendung implizit durch Entwicklungsprozess
+
+### 4. Netzwerkkonfiguration
+- Backend: 192.168.0.105 (statisch, LAN)
+- Frontend: 192.168.0.109 (WLAN), zusätzlich Intranet-Anbindung über LAN
+- Netzwerk: 192.168.0.0/24
+- Ports: 443/80 (Fallback auf 8080/8443 bei Bedarf)
+
+### 5. Abnahme-Korrektur
+- Missverständnis bei Präsentation erwähnt
+- System noch nicht vollständig produktiv (Hardware in Lieferung)
+- Improvisation aus dem Stegreif erfolgreich
+- Robuste Systemarchitektur ermöglichte sofortige Demonstration
+
+### 6. Entfernte Inkonsistenzen
+- Übertriebene Dramatisierungen
+- Widersprüchliche technische Details
+- Unnötige Füllwörter und Phrasen
+- KI-generierte Floskeln
+
+### 7. Beibehaltene wichtige Details
+- Reverse Engineering mit Wireshark
+- Session-Key-Problematik bei TAPO-Steckdosen
+- Alternatives Python-Modul als Lösung
+- Privat finanzierte Hardware-Komponenten
+- Fehlerresistente Systemarchitektur
+- Automatischer Start im Kiosk-Modus
+
+## Hinweise für weitere Bearbeitung
+
+1. **Screenshots und Diagramme**: Die Anlagen-Sektion sollte noch mit konkreten Inhalten gefüllt werden
+2. **API-Dokumentation**: Könnte aus den vorhandenen Backend-Docs generiert werden
+3. **Netzwerkdiagramm**: Sollte die Zwei-Raspberry-Pi-Architektur zeigen (Frontend + Backend)
+4. **Deployment-Skripte**: setup.sh und Kiosk-Konfiguration könnten dokumentiert werden
+
+## Wichtige Fakten aus den Notizen
+
+- Projektdauer: 5 Wochen (15. April - 20. Mai 2025)
+- Kosten: < 600 Euro (inkl. privat finanzierter Komponenten)
+- Code-Umfang: > 9.000 Zeilen Python
+- API-Endpunkte: > 100
+- Test-Coverage: 85%
+- Energiemonitoring als ungeplantes Bonus-Feature
+- DSGVO-konform implementiert
+- Offline-fähig (keine Cloud-Abhängigkeiten) 

IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md

@@ -154,49 +154,72 @@ Gesamtinfrastruktur
 
 Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am
 Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller
-(Prusa, Anycubic). Diese Geräte stellen eine wichtige Ressource für die 
-praktische Ausbildung dar, weisen jedoch erhebliche technische 
-Limitierungen auf. Die Drucker verfügen weder über Netzwerkschnittstellen 
-noch über andere Möglichkeiten zur zentralen Steuerung. Diese technischen 
-Einschränkungen verhinderten bislang eine koordinierte digitale Verwaltung 
-der Geräte.
+(Prusa, Anycubic; B-Ware im Vergleich zu 3D-Druckern von Kostenstellen
+höherer Prioriä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 basierte auf einem analogen Whiteboard 
-neben den Druckern. Dies führte zu systematischen Problemen:
-Doppelbuchungen traten regelmäßig auf, die manuelle Aktivierung und 
-Deaktivierung der Geräte wurde häufig versäumt, was zu unnötigem 
-Energieverbrauch führte. Eine verlässliche Dokumentation der 
-Nutzungszeiten existierte nicht, wodurch weder eine Zuordnung von 
-Verantwortlichkeiten noch eine verursachungsgerechte Kostenzuordnung 
+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 Prototyp des ehemaligen Auszubildenden Torben Haack auf Basis von
-Next.js zeigte bereits eine moderne Benutzeroberfläche, allerdings fehlte
-die Backend-Funktionalität vollständig. Dieser Prototyp diente als
-Ausgangspunkt für meine Projektarbeit, in der ich die fehlende
-Backend-Infrastruktur entwickelte und das System produktionsreif machte.
+Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben
+Haack hatte einen vielversprechenden Frontend-Prototyp 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.
 
 ## 1.2 Ableitung der Projektziele
 
-Nach der Zulassung des Abschlussprojekts durch die IHK kristallisierten
-sich folgende Projektziele heraus. Das System "MYP - Manage Your Printer"
-sollte nicht nur die digitale Verwaltung der Reservierungen ermöglichen,
-sondern auch die automatisierte Steuerung der Geräte realisieren.
+Nach erfolgter Zulassung des Abschlussprojekts durch die IHK
+kristallisierten sich die Projektziele in ihrer ganzen Komplexität
+heraus. Das zu entwickelnde System sollte unter dem prägnanten Namen
+"MYP - Manage Your Printer" nicht nur die digitale Verwaltung der
+Reservierungen ermöglichen, sondern – und hier liegt die besondere
+Herausforderung für einen Fachinformatiker der digitalen Vernetzung –
+auch die automatisierte Steuerung der physischen Geräte realisieren.
 
 Die zentrale technische Herausforderung bestand in der Überbrückung der
-fehlenden Schnittstellen der 3D-Drucker. Da eine direkte Kommunikation
-mit den Geräten nicht möglich war, entwickelte ich einen alternativen
-Ansatz über Smart-Plugs zur Hardware-Steuerung. Gleichzeitig mussten die
-strengen Sicherheitsrichtlinien der Mercedes-Benz AG berücksichtigt
-werden, die keine permanenten Internetverbindungen in der
-Produktionsumgebung gestatten.
+technischen Limitierungen der vorhandenen 3D-Drucker. Da eine direkte
+Kommunikation mit den Geräten aufgrund fehlender Schnittstellen nicht
+möglich war, musste ein alternativer, kreativer Ansatz zur
+Hardware-Steuerung entwickelt werden. Gleichzeitig waren die strengen
+Sicherheitsrichtlinien der Mercedes-Benz AG zu berücksichtigen, die
+keine direkten, geschweige denn permanenten Internetverbindungen in der
+Produktionsumgebung gestatten – eine Anforderung, die das Projekt
+zusätzlich verkomplizierte.
 
-Ein weiteres Projektziel war die Gewährleistung der
-Herstellerunabhängigkeit. Die heterogene Druckerlandschaft erforderte
-eine universell einsetzbare Lösung, die sich leicht an zukünftige
-Hardware-Änderungen anpassen lässt. Das System implementiert zudem eine
-effektive Rechteverwaltung mit Differenzierung zwischen administrativen
-und regulären Nutzerrechten.
+Ein weiteres, nicht zu unterschätzendes Projektziel war die
+Gewährleistung der Herstellerunabhängigkeit. Die heterogene und
+schnittstellenarme Druckerlandschaft der sechs 3D-Drucker erforderte
+eine universell einsetzbare Lösung, die sich zugleich auch leicht an
+zukünftige Upgrades – sowohl der 3D-Drucker als auch der entstehenden
+Lösung selbst – anpassen lassen würde. Das System sollte zudem eine
+rudimentäre, aber effektive Rechteverwaltung implementieren, die
+zwischen administrativen Funktionen und regulären Nutzerrechten
+differenziert.
 
 ## 1.3 Projektabgrenzung