📚 Improved IHK Projektdokumentation and logs for better clarity and organization.

IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md

@@ -168,28 +168,30 @@ neben den Druckern überhaupt so nennen möchte – führte zu systematischen
 Problemen. Doppelbuchungen waren an der Tagesordnung, die manuelle 
 Aktivierung und Deaktivierung der Geräte wurde regelmäßig vergessen (was 
 zu unnötigem Energieverbrauch und erhöhtem Verschleiß führte), und eine 
-verlässliche Dokumentation der tatsächlichen Nutzungszeiten? 
-Fehlanzeige. Weder Verantwortungszuordnung für Aufräumarbeiten noch 
+verlässliche Dokumentation der tatsächlichen Nutzungszeiten existierte 
+schlichtweg nicht. Weder Verantwortungszuordnung für Aufräumarbeiten noch 
 verursachungsgerechte Kostenzuordnung waren möglich.
 
 Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben
 Haack – Fachrichtung Daten- und Prozessanalyse – hatte einen
 vielversprechenden Frontend-Prototyp auf Basis von Next.js
 hervorgebracht. Der Prototyp verfügte über eine moderne
-Benutzeroberfläche mit umfangreichen Analysefunktionen. Nur fehlte
-dummerweise die komplette Backend-Funktionalität. Ohne Backend blieb 
+Benutzeroberfläche mit umfangreichen Analysefunktionen. Allerdings fehlte
+die essenzielle Backend-Funktionalität vollständig. Ohne Backend blieb 
 die Projektarbeit des Herrn Haack in der praktischen Anwendung 
 funktionslos. Ursprünglich war angedacht, API-Endpunkte zu 
 implementieren, welche die Daten- und Prozessanalyse seines Frontends 
 ermöglicht hätten – eine Aufgabe, die naturgemäß außerhalb meines 
 Fachgebiets der digitalen Vernetzung lag.
 
-Ich sah die Chance, die Idee aufzugreifen und im Rahmen meiner 
+Ich erkannte die Chance, die Idee aufzugreifen und im Rahmen meiner 
 Projektarbeit weiterzuentwickeln. Die Schnittstelle der Vernetzung zum 
-cyber-physischen System lag im Backend – genau mein Ding. Mehrere 
-Möglichkeiten zur Einbringung meiner Fachrichtung sprangen mir direkt 
-ins Auge. Keine lästige Pflichtaufgabe wie bei anderen Projektoptionen, 
-sondern echtes Interesse. Es kitzelte meine Leidenschaft.
+cyber-physischen System lag im Backend – exakt in meinem 
+Kompetenzbereich. Mehrere Möglichkeiten zur Einbringung meiner 
+Fachrichtung waren unmittelbar ersichtlich. Im Gegensatz zu anderen 
+verfügbaren Projektoptionen, die eher pflichtgemäßen Charakter hatten, 
+weckte dieses Vorhaben mein genuines fachliches Interesse und meine 
+intrinsische Motivation. Es kitzelte meine Leidenschaft.
 
 ## 1.2 Ableitung der Projektziele
 
@@ -300,8 +302,9 @@ Funktionsumfang und Benutzerfreundlichkeit.
 Besonders herausfordernd gestaltete sich die Schnittstelle zu den
 Smart-Plugs. Die ursprüngliche Annahme, dass sich die TAPO P110-Steckdosen
 von TP-Link problemlos integrieren lassen würden, erwies sich als
-naiv. Die Geräte boten keine dokumentierte API – nur die proprietäre 
-TAPO-App ermöglichte die Steuerung. Das war ein Problem.
+zu optimistisch. Die Geräte boten keine dokumentierte API – nur die proprietäre 
+TAPO-App ermöglichte die Steuerung. Dies stellte eine erhebliche technische 
+Herausforderung für die geplante Integration dar.
 
 ## 1.6 Analyse der IT-sicherheitsrelevante Bedingungen
 
@@ -529,24 +532,27 @@ kategorisch aus, was die Optionen erheblich einschränkte. Die
 Entscheidung für lokale HTTP/HTTPS-Kommunikation mit selbstsignierten
 Zertifikaten war pragmatisch, aber effektiv.
 
-Die Kommunikation mit den Smart-Plugs stellte die größte Herausforderung 
-dar. Die TAPO-Geräte boten keine dokumentierte Schnittstelle – nur die 
-proprietäre App konnte sie steuern. Also griff ich zu Wireshark und 
-analysierte den Netzwerkverkehr zwischen App und Steckdosen. Was ich 
-fand, war ernüchternd: verschlüsselte Kommunikation mit sich ständig 
-ändernden Session-Keys.
+Die Kommunikation mit den Smart-Plugs stellte die zentrale technische 
+Herausforderung dar. Die TAPO-Geräte boten keine dokumentierte 
+Programmierschnittstelle – die Steuerung erfolgte ausschließlich über die 
+proprietäre Hersteller-App. Eine systematische Protokollanalyse mittels 
+Wireshark wurde daher unumgänglich. Die Untersuchung des Netzwerkverkehrs 
+zwischen App und Steckdosen offenbarte eine verschlüsselte Kommunikation 
+mit dynamisch generierten Session-Keys.
 
-Mein erster Versuch mit einem vielversprechenden Python-Modul schlug 
-fehl – es funktionierte einfach nicht mit meinen Geräten. Der 
-Wireshark-Mitschnitt offenbarte immer dieselben verschlüsselten 
-Responses. Ohne Erfolg beim Simulieren einzelner Anfragen dämmerte 
-es mir: Die Anfragensequenz musste stimmen! Die Verbindung nutzte 
-temporäre Cookies und proprietäre Verschlüsselung.
+Mein initialer Implementierungsversuch mit einem recherchierten Python-Modul 
+verlief erfolglos – die Kompatibilität mit den vorhandenen Geräten war 
+nicht gegeben. Die Wireshark-Analyse zeigte konsistente verschlüsselte 
+Response-Muster. Nach mehreren erfolglosen Versuchen, einzelne Anfragen 
+zu replizieren, wurde deutlich: Die korrekte Sequenzierung der 
+Kommunikation war essentiell. Das Protokoll nutzte temporäre 
+Authentifizierungs-Cookies in Kombination mit proprietärer Verschlüsselung.
 
-Nach tagelangen Experimenten stieß ich auf PyP100 – ein alternatives 
-Python-Modul, versteckt in den Tiefen von GitHub. Dieses Modul löste 
-die Session-Key-Problematik elegant und ermöglichte endlich eine 
-stabile Integration.
+Nach intensiver Recherche und mehreren Tagen systematischer Tests konnte 
+PyP100 als geeignete Lösung identifiziert werden. Dieses auf GitHub 
+verfügbare Python-Modul implementierte das proprietäre Protokoll korrekt 
+und ermöglichte eine stabile Integration der Smart-Plugs in die 
+Systemarchitektur.
 
 ## 2.6 Planung der Prozess-/ und Systemschnittstellen
 
@@ -554,23 +560,25 @@ Die Schnittstellenplanung erforderte eine sorgfältige Balance zwischen
 Funktionalität und Sicherheit. Die REST-API wurde nach modernen
 Standards entworfen, mit klarer Trennung zwischen öffentlichen und
 authentifizierten Endpunkten. Über 100 Endpunkte wurden spezifiziert –
-eine Zahl, die zunächst übertrieben erschien, sich aber als notwendig
-erwies; jeder Endpunkt ein kleines Kunstwerk der Funktionalität.
+eine Anzahl, die zunächst umfangreich erschien, sich jedoch als 
+notwendig für die vollständige Funktionsabdeckung erwies. Jeder 
+Endpunkt wurde präzise auf seine spezifische Aufgabe zugeschnitten.
 
 Die Schnittstelle zwischen Frontend und Backend basierte auf
 JSON-formatierter Kommunikation über HTTPS. Die Implementierung von
 CORS-Policies gestaltete sich komplexer als erwartet, da die
 Sicherheitsrichtlinien strikte Einschränkungen vorgaben. Die Lösung –
 eine Whitelist-basierte CORS-Konfiguration – erfüllte die
-Sicherheitsanforderungen ohne die Funktionalität einzuschränken; ein
-Drahtseilakt zwischen Sicherheit und Usability.
+Sicherheitsanforderungen ohne die Funktionalität einzuschränken. Diese
+Implementation stellte einen ausgewogenen Kompromiss zwischen 
+Sicherheit und Anwenderfreundlichkeit dar.
 
 Besondere Aufmerksamkeit erforderte die Scheduler-Schnittstelle. Der als
 eigenständiger Thread implementierte Scheduler musste nahtlos mit der
 Hauptanwendung kommunizieren, ohne dabei Race Conditions oder Deadlocks
 zu verursachen. Die Verwendung von Thread-sicheren Queues und explizitem
-Locking löste diese Herausforderung – eine Lösung, die in ihrer
-Eleganz bestach.
+Locking löste diese Herausforderung mit einer technisch eleganten 
+Architektur.
 
 ## 2.7 Planung der IT-Sicherheitsmaßnahmen
 
@@ -609,23 +617,26 @@ iterativen, problemgetriebenen Herangehensweise.
 ### 3.1.1 Datenabfrage der Sensoren
 
 Die "Sensoren" in diesem Kontext waren die Smart-Plugs – eine
-euphemistische Bezeichnung für Geräte, die sich als erstaunlich
-widerspenstig erwiesen. Meine erste Hoffnung, ein bestehendes 
-Python-Modul zur Steuerung zu finden, zerschlug sich schnell. 
-Das gefundene Modul funktionierte schlicht nicht.
+euphemistische Bezeichnung für Geräte, die sich als technisch
+anspruchsvoll in der Integration erwiesen. Meine initiale Recherche nach 
+einem geeigneten Python-Modul zur Steuerung verlief erfolglos. Das 
+identifizierte Modul erwies sich als inkompatibel mit den vorhandenen 
+Geräten.
 
-Also Plan B: Wireshark. Ich schnitt den Netzwerkverkehr zwischen 
-TAPO-App und Smart-Plugs mit. Die Analyse offenbarte das komplexe
-Authentifizierungsprotokoll der TAPO-Geräte – verschlüsselte 
-Kommunikation mit Session-Tokens, die sich bei jeder Anmeldung 
-änderten. Die Verschlüsselung basierte auf einer Kombination aus 
-RSA und AES. Respektabel für Consumer-Hardware, aber auch verdammt 
-nervig für meine Zwecke.
+Daraufhin erfolgte eine Protokollanalyse mittels Wireshark. Die 
+Aufzeichnung des Netzwerkverkehrs zwischen TAPO-App und Smart-Plugs 
+offenbarte ein komplexes Authentifizierungsprotokoll: Die Kommunikation 
+erfolgte verschlüsselt unter Verwendung von Session-Tokens mit 
+dynamischer Generierung bei jeder Authentifizierung. Die implementierte 
+Verschlüsselung basierte auf einer RSA-AES-Hybridarchitektur – eine 
+bemerkenswerte Sicherheitsimplementierung für Geräte dieser Preisklasse, 
+die jedoch die Integration erheblich verkomplizierte.
 
-Nach tagelangen Experimenten stieß ich endlich auf PyP100 – ein 
-Python-Modul, das die lokale Kommunikation mit den TAPO-Geräten 
-tatsächlich beherrschte. Versteckt in den Tiefen von GitHub, löste 
-es die Session-Key-Problematik elegant. Endlich.
+Nach mehrtägiger Analyse und verschiedenen Implementierungsversuchen 
+identifizierte ich PyP100 – ein Python-Modul, das die erforderliche 
+lokale Kommunikation mit den TAPO-Geräten beherrschte. Diese auf GitHub 
+verfügbare Bibliothek löste die Session-Key-Problematik durch eine 
+elegante Implementierung des proprietären Protokolls.
 
 Die Implementierung der Datenabfrage erfolgte über eine
 selbstentwickelte Wrapper-Klasse, die die Komplexität der Kommunikation
@@ -653,8 +664,10 @@ bei Fehlern.
 Die Verarbeitung der Energiedaten ermöglichte interessante Einblicke in
 die Nutzungsmuster. Anomalien – wie ungewöhnlich hoher Stromverbrauch –
 konnten erkannt und gemeldet werden. Diese Funktion, ursprünglich nicht
-geplant, erwies sich als wertvolles Feature für die präventive Wartung;
-ein glücklicher Zufall, der zur Kernfunktionalität wurde.
+in der Projektspezifikation vorgesehen, entwickelte sich zu einem 
+wertvollen Feature für die präventive Wartung. Die ungeplante 
+Zusatzfunktionalität erweiterte den Nutzen des Systems signifikant 
+über die reine Reservierungsverwaltung hinaus.
 
 ## 3.2 Abweichung, Anpassung und Entscheidungen
 
@@ -773,8 +786,10 @@ geprüft.
 Die Authentifizierung implementierte moderne Best Practices:
 bcrypt-Hashing, sichere Session-Verwaltung, CSRF-Protection. Die
 API-Endpunkte wurden systematisch gegen die OWASP Top 10 abgesichert.
-Input-Validation erfolgte auf mehreren Ebenen – Client-seitig für UX,
-Server-seitig für Sicherheit; Vertrauen ist gut, Kontrolle ist besser.
+Input-Validation erfolgte auf mehreren Ebenen – Client-seitig für die 
+Benutzerfreundlichkeit, Server-seitig für die Sicherheit. Diese 
+mehrschichtige Validierung gewährleistete sowohl eine positive 
+Nutzererfahrung als auch robuste Sicherheit.
 
 Die Implementierung eines Rate-Limiters erschwerte
 Brute-Force-Angriffe. Nach fünf fehlgeschlagenen Login-Versuchen wurde