fix: Update documentation in myp_documentation.md for improved clarity and consistency

- Revised the Jobs/Reservierungen section to correct formatting and ensure consistent use of quotation marks.
- Enhanced the Kiosk-Modus section for better readability and alignment.
- Added detailed explanations regarding the Scheduler-Funktion and its responsibilities.
- Improved overall structure and flow of the documentation to facilitate user understanding.

myp_documentation.md

@@ -92,7 +92,7 @@ Das MYP-Backend bietet eine **REST-API** mit klar definierten Endpunkten, über
 
 * **Authentifizierung:** `POST /auth/register` (Registrierung eines neuen Benutzers), `POST /auth/login` (Anmeldung, erzeugt eine Session). Nach erfolgreichem Login erhält der Client einen Session-Cookie, über den nachfolgende Anfragen authentifiziert werden. Optional kann auch ein Logout-Endpunkt genutzt werden.
 * **Drucker-Endpunkte:** `GET /api/printers` liefert die Liste aller bekannten Drucker; `POST /api/printers` fügt einen neuen Drucker hinzu (Admin-Recht erforderlich); `GET /api/printers/<id>` holt Details zu einem Drucker; `DELETE /api/printers/<id>` löscht einen Drucker. Außerdem gibt es `GET /api/printers/status` um den Status aller Drucker (ein/aus, verfügbar/belegt) in aggregierter Form abzurufen.
-* **Jobs/Reservierungen:** `GET /api/jobs` listet alle geplanten Druckaufträge; `POST /api/jobs` legt einen neuen Auftrag an. Jeder Auftrag ist einem Drucker und einem Benutzer zugeordnet und enthält Startzeit und erwartete Dauer. Für laufende Aufträge existieren spezielle Aktionen: `POST /api/jobs/<id>/finish` markiert einen Druckjob als fertig und schaltet den Drucker (die Steckdose) ab. Ähnlich gibt es `/abort` zum Abbrechen (ebenfalls mit Abschalten) und `/extend` um die Endzeit zu verlängern. Über `GET /api/jobs/<id>/status` kann der aktuelle Status (z.B. „läuft" oder „wartet") sowie der **Plug-Zustand** abgefragt werden, und `GET /api/jobs/<id>/remaining-time` liefert die Restzeit in Sekunden.
+* **Jobs/Reservierungen:** `GET /api/jobs` listet alle geplanten Druckaufträge; `POST /api/jobs` legt einen neuen Auftrag an. Jeder Auftrag ist einem Drucker und einem Benutzer zugeordnet und enthält Startzeit und erwartete Dauer. Für laufende Aufträge existieren spezielle Aktionen: `POST /api/jobs/<id>/finish` markiert einen Druckjob als fertig und schaltet den Drucker (die Steckdose) ab. Ähnlich gibt es `/abort` zum Abbrechen (ebenfalls mit Abschalten) und `/extend` um die Endzeit zu verlängern. Über `GET /api/jobs/<id>/status` kann der aktuelle Status (z.B. "läuft" oder "wartet") sowie der **Plug-Zustand** abgefragt werden, und `GET /api/jobs/<id>/remaining-time` liefert die Restzeit in Sekunden.
 * **Benutzer-Verwaltung:** `GET /api/users` gibt eine Liste aller Benutzer zurück (nur für Admins sichtbar); `GET /api/users/<id>` ruft Profildetails ab; `DELETE /api/users/<id>` löscht einen Benutzer (nur Admin). Registrierung erfolgt wie erwähnt über `/auth/register` oder initial über einen speziellen Setup-Endpunkt (`/api/create-initial-admin` beim allerersten Start).
 * **Sonstiges:** `GET /api/stats` liefert globale Nutzungsstatistiken (z.B. Gesamtstunden aller Drucker); `GET /api/test` dient als einfacher Health-Check des Systems. Im Kiosk-Betrieb wurden außerdem Endpunkte wie `/api/kiosk/activate` vorgesehen, um Anzeigebildschirme zentral zu steuern (z.B. ein-/ausschalten des Anzeige-Modus). Zudem gibt es Endpunkte zum **Scheduler-Management** (Start/Stop des Hintergrunddienstes, Status abfragen) für Administrationszwecke.
 
@@ -120,7 +120,7 @@ Im System sind die Zugangsdaten für die Steckdosen einmalig hinterlegt (im Konf
 
 **Scheduler-Funktion:** Der Scheduler ist dafür zuständig, alle zeitabhängigen Aktionen im System auszuführen. Im Kern prüft er in regelmäßigen kurzen Intervallen (z.B. jede Minute oder kontinuierlich mit Sleep-Timern), ob bestimmte Ereignisse anstehen. Wichtige Aufgaben sind:
 
-* **Job-Start schalten:** Wenn die Startzeit eines Druckjobs erreicht ist (oder unmittelbar bevorsteht), sendet der Scheduler den Befehl zum **Einschalten** der zugehörigen Steckdose. Dadurch wird der 3D-Drucker mit Strom versorgt und der Druck kann – falls jemand vor Ort den Druckauftrag gestartet hat – beginnen. Gleichzeitig markiert das System den Job als „gestartet".
+* **Job-Start schalten:** Wenn die Startzeit eines Druckjobs erreicht ist (oder unmittelbar bevorsteht), sendet der Scheduler den Befehl zum **Einschalten** der zugehörigen Steckdose. Dadurch wird der 3D-Drucker mit Strom versorgt und der Druck kann – falls jemand vor Ort den Druckauftrag gestartet hat – beginnen. Gleichzeitig markiert das System den Job als "gestartet".
 * **Job-Ende schalten:** Sobald das geplante Endzeit eines Auftrags erreicht ist, sorgt der Scheduler dafür, dass die Steckdose (und damit der Drucker) **ausgeschaltet** wird. Dies passiert sowohl im regulären Abschlussfall als auch bei vorzeitigen Abbrüchen. Damit wird sichergestellt, dass kein Drucker über das reservierte Zeitfenster hinaus Strom zieht. Wird ein Job manuell durch den Nutzer via `/finish` oder `/abort` beendet, schaltet das Backend sofort den Plug aus und Scheduler erkennt, dass für diesen Job keine weitere Aktion mehr nötig ist.
 * **Status-Monitoring:** In kurzen Abständen fragt das System den aktuellen Status der Steckdosen bzw. Jobs ab, um z.B. die verbleibende Restlaufzeit zu berechnen oder zu erkennen, ob ein Benutzer eventuell vergessen hat, einen Druckauftrag zu beenden. Sollte eine Steckdose unerwarteterweise nicht den Befehl ausführen (z.B. Verbindung verloren), kann der Scheduler nach einer Wartezeit einen Wiederholungsversuch starten. Solche Ereignisse werden auch im Log vermerkt.
 * **Warteschlangenverwaltung:** Falls mehrere Aufträge in direkter Folge auf einem Drucker geplant sind, koordiniert der Scheduler die Übergänge. Beispielsweise wird vermieden, dass ein Drucker ausgeschaltet wird, um kurz danach für den nächsten Job wieder eingeschaltet zu werden – stattdessen könnte ein fließender Übergang signalisiert werden (sofern im Anwendungsfall relevant). Im aktuellen System wird allerdings aus Sicherheitsgründen zwischen zwei Jobs immer ausgeschaltet, es sei denn ein Folgejob beginnt innerhalb weniger Minuten. Diese Logik ließe sich anpassen, wenn Dauerbetriebsphasen gewünscht sind.
@@ -141,7 +141,7 @@ Die primäre Integration von MYP erfolgt in das bestehende Reservierungsportal d
 
 Technisch wurde das Backup-Frontend mit **HTML5, JavaScript und Tailwind CSS** umgesetzt, um schnell ein responsive Design zu erreichen. Es verwendet Fetch-Aufrufe, um mit der Flask-API zu kommunizieren. Über einen **Service Worker** werden statische Assets und sogar API-Antworten zwischengespeichert, sodass die Oberfläche nach einmaligem Laden auch offline nutzbar ist – ein wichtiger Aspekt für den Demo-Modus ohne Internet. Die Authentifizierung ist nahtlos: nach Login erhält der Browser ein Session-Cookie vom Backend, welches für weitere API-Requests genutzt wird.
 
-**Einsatz im Kiosk-Modus:** Das Backup-Frontend wird im Prüfungs- und Demonstrationsszenario im **Kiosk-Modus** gezeigt. Hierzu startet der Raspberry Pi automatisch einen Chromium-Browser im Vollbild, der die PWA lädt. Über die Autologin-Funktion von Raspbian und ein Startscript (`kiosk.sh`) wird dieser Prozess beim Boot angestoßen. Der Kiosk-Browser zeigt eine spezielle Übersichtsseite, die primär für Anzeigezwecke gedacht ist (z.B. eine Statusübersicht aller Drucker und aktuellen Reservierungen, quasi „Dashboard"). Über einen administrativen Shortcut kann jedoch auch die normale Bedienoberfläche aufgerufen werden, um Interaktionen zu ermöglichen.
+**Einsatz im Kiosk-Modus:** Das Backup-Frontend wird im Prüfungs- und Demonstrationsszenario im **Kiosk-Modus** gezeigt. Hierzu startet der Raspberry Pi automatisch einen Chromium-Browser im Vollbild, der die PWA lädt. Über die Autologin-Funktion von Raspbian und ein Startscript (`kiosk.sh`) wird dieser Prozess beim Boot angestoßen. Der Kiosk-Browser zeigt eine spezielle Übersichtsseite, die primär für Anzeigezwecke gedacht ist (z.B. eine Statusübersicht aller Drucker und aktuellen Reservierungen, quasi "Dashboard"). Über einen administrativen Shortcut kann jedoch auch die normale Bedienoberfläche aufgerufen werden, um Interaktionen zu ermöglichen.
 
 **Struktur und Grenzen:** Da das Backup-Frontend in begrenzter Zeit entstand, wurde es pragmatisch gehalten. Es verzichtet auf aufwändige grafische Elemente und konzentriert sich auf Funktionalität. Eine Herausforderung war, die Bedienung möglichst selbsterklärend zu gestalten, obwohl es sich um einen technischen Prototypen handelt. Kleinere Probleme, wie die Darstellung auf dem kleinen Touch-Bildschirm oder das automatische Neuladen der Seite, wurden iterativ behoben. Zudem musste das Frontend mit der **selbstsignierten HTTPS-Konfiguration** umgehen können. Im Kiosk-Browser wurde deshalb eingestellt, dass Zertifikatswarnungen ignoriert werden (im internen Netz vertretbar).
 
@@ -159,6 +159,76 @@ Während der Projektumsetzung traten diverse **Herausforderungen** auf, die mit
 
 * **Sicherheitszertifikate und CORS:** Um eine verschlüsselte Verbindung bereitzustellen, mussten selbstsignierte TLS-Zertifikate erstellt und verteilt werden. Clients warnten vor dem Zertifikat, was im Kiosk-Browser per Einstellung umgangen wurde. Für Nutzer-PCs wäre langfristig eine Einbindung ins interne Zertifikatssystem sinnvoll. Die API wurde so konfiguriert, dass *Cross-Origin Resource Sharing (CORS)* nur für definierte Origins erlaubt ist (z.B. die Domain des Intranet-Portals). Dies stellte sicher, dass nur autorisierte Quellen auf die API zugreifen können. Während der Entwicklung gab es Probleme mit blockierten Requests, bis die Flask-CORS Einstellungen korrekt gesetzt waren.
 
-* **Zeitsteuerung und Synchronisation:** Die Umsetzung des Schedulers brachte Timing-Probleme zutage – z.B. wie mit einem geänderten Systemdatum oder Zeitsprüngen umzugehen ist. Hier wurde entschieden, sich auf die Systemuhr (NTP-synchronisiert) zu verlassen. Ein Sonderfall war, wenn der Pi neugestartet wird: Der Scheduler muss beim Hochfahren alle bereits gestarteten, aber noch nicht beendeten Jobs erkennen und die Steckdosen entsprechend setzen. Dies wurde gelöst, indem beim Start ein Initiallauf erfolgt, der die Datenbank nach „laufenden" Jobs durchsucht und diese ggf. (wieder) aktiviert oder abschaltet, falls Endzeit überschritten. Damit wird Konsistenz auch nach ungeplantem Neustart gewährleistet.
+* **Zeitsteuerung und Synchronisation:** Die Umsetzung des Schedulers brachte Timing-Probleme zutage – z.B. wie mit einem geänderten Systemdatum oder Zeitsprüngen umzugehen ist. Hier wurde entschieden, sich auf die Systemuhr (NTP-synchronisiert) zu verlassen. Ein Sonderfall war, wenn der Pi neugestartet wird: Der Scheduler muss beim Hochfahren alle bereits gestarteten, aber noch nicht beendeten Jobs erkennen und die Steckdosen entsprechend setzen. Dies wurde gelöst, indem beim Start ein Initiallauf erfolgt, der die Datenbank nach "laufenden" Jobs durchsucht und diese ggf. (wieder) aktiviert oder abschaltet, falls Endzeit überschritten. Damit wird Konsistenz auch nach ungeplantem Neustart gewährleistet.
 
 * **Datenbank-Locks und Gleichzeitigkeit:** Da Flask standardmäßig mehrere Threads/Prozesse handhaben kann (insbesondere bei Verwendung von Werkzeug in Debug oder Gunicorn als Server), traten potenziell race conditions beim Datenbankzugriff auf. SQLite erlaubt zwar gleichzeitiges Lesen, aber beim Schreiben gab es anfangs Locking-Issues, als der Scheduler und ein Web-Request parallel auf die DB zugreifen wollten. Dies wurde durch ein **Thread-Locking** im Code gelöst und indem Schreibzugriffe kurz gehalten bzw. seriell angeordnet wurden. In einem späteren Ausbau könnte hier ein Wechsel auf einen robusteren DB-Server (PostgreSQL) ratsam sein, aber im Testbetrieb reichte die angepasste SQLite-Nutzung aus.
+
+* **UI/UX-Herausforderungen:** Da das Team primär Backend- und Netzwerkerfahrung hatte, war die Entwicklung einer ansprechenden Benutzeroberfläche ein Lernprozess. Insbesondere die PWA offlinefähig zu gestalten, erforderte Einarbeitung in Service Worker Caching. Anfangs wurden falsche Routen gecacht, was zu veralteten Anzeigen führte – diese Fehler konnten behoben werden, indem sensible API-Routen vom Caching ausgenommen wurden (z.B. keine Cache für `/api/jobs` List-Aufrufe). Auch die Darstellung auf unterschiedlichen Endgeräten (Desktop vs. kleiner Pi-Touchscreen) erforderte responsive Design via Tailwind und Feinjustierung bei Schriftgrößen.
+
+* **Organisatorische Abstimmung:** Auf organisatorischer Seite mussten Freigaben von der IT eingeholt werden – etwa für den Betrieb eines eigenen WLANs im Unternehmensumfeld und die Reservierung eines festen IP-Adressbereichs. Hier gab es anfangs Verzögerungen (z.B. Zuteilung eines DNS-Alias dauerte einige Tage). Durch frühzeitige Kommunikation (Projektstart bereits mit der IT abgestimmt am 11.09., DNS beantragt am 12.09.) konnten diese Hürden jedoch rechtzeitig genommen werden. Die Dokumentation der Netzwerktopologie mit einem **Netzwerkdiagramm** (siehe Abb. 1) half allen Beteiligten, das Konzept zu verstehen, und erleichterte die Freigabeprozesse.
+
+Trotz der genannten Herausforderungen verlief das Projekt erfolgreich. Die meisten Probleme konnten im Team oder mit Unterstützung von Kollegen zeitnah gelöst werden. Kritische Risiken wie die Nichterreichbarkeit der Plugs ohne Cloud wurden durch Workarounds (Lokale API) umgangen. Am Ende steht ein funktionierendes System, das die gestellten Anforderungen erfüllt.
+
+## 10. Sicherheit, Rollen und Zugangskontrolle
+
+Dem Thema **Sicherheit** wurde bei MYP in mehrfacher Hinsicht Rechnung getragen: Zum einen auf Anwendungsebene (Benutzerverwaltung, Rechte, Passwortschutz), zum anderen auf Netzwerkebene (verschlüsselte Übertragung, Zugriffsbeschränkung) sowie im Offline-Kontext (Caching-Verhalten, physische Sicherheit).
+
+**Authentifizierung und Rollen:** Die Anwendung implementiert ein klassisches Login-System mit **Benutzername (E-Mail) und Passwort**. Die Passwörter werden nicht im Klartext gespeichert, sondern mit **BCrypt gehasht**, was einen hohen Schutz bei Datenbankzugriffen bietet. Die Verwaltung der Login-Sessions übernimmt **Flask-Login**, das serverseitige Sessions erstellt und via Cookie beim Client hält. Nach dem Login erhält ein Nutzer einen Session-Cookie mit Gültigkeit (im System auf 7 Tage eingestellt für Komfort, konfigurierbar). Für jede API-Anfrage prüft ein Decorator (`@login_required`), ob diese Session valide ist. Zusätzlich zur Authentifizierung gibt es eine **Rollenprüfung (RBAC)**: Benutzer haben das Feld `role` (z.B. `"admin"` oder `"user"`). Bestimmte Aktionen sind nur für Admins freigegeben – etwa Drucker hinzufügen/löschen, Nutzerverwaltung etc.. Eigene Decorators wie `@admin_required` oder spezifisch `@job_owner_required` sichern die Endpunkte ab, sodass z.B. ein normaler Benutzer einen fremden Job weder löschen noch verändern kann. Dieses **Prinzip der minimalen Rechte** stellt sicher, dass jeder nur seine Daten sieht und verändert. In Tests wurde überprüft, dass z.B. ein Benutzer nicht über manuelle API-Calls Admin-Rechte erlangen kann.
+
+**API-Sicherheit und Datenvalidierung:** Wie bereits erwähnt, lehnt das API unerlaubte Zugriffe konsequent ab. Zusätzlich wurde darauf geachtet, keine sensiblen Informationen in URLs oder GET-Parametern zu verwenden (z.B. werden Passwörter nur im Body übertragen und dort auch gleich gehasht, Sessions laufen über Cookies). Die JSON-Antworten des Servers enthalten nur notwendige Daten; interne IDs von Objekten, die der Benutzer nicht braucht, werden entweder gar nicht erst geschickt oder gefiltert. Gegen gängige Web-Sicherheitsprobleme wurden Header gesetzt, z.B. **X-Content-Type-Options, X-Frame-Options** etc., um Clickjacking und MIME-Typ Manipulation zu verhindern. Da das System im Intranet läuft, war CSRF-Schutz weniger kritisch, dennoch könnte Flask auch hier mit Tokens ausgestattet werden, was für einen späteren öffentlichen Einsatz empfohlen ist.
+
+**Netzwerksicherheit und Verschlüsselung:** Obwohl das System in einem abgeschotteten Netz läuft, wurde Verschlüsselung der Kommunikation als wichtig erachtet – insbesondere, wenn man bedenkt, dass evtl. das Firmennetz mitlauschen könnte oder die WiFi-Kommunikation der Plugs abgefangen werden kann. Es wurde daher die Möglichkeit geschaffen, die gesamte Client-Server Kommunikation über **HTTPS mit TLS 1.2+** abzuwickeln. Hierzu wurden selbstsignierte Zertifikate erstellt und im System hinterlegt. Der Raspberry Pi generiert bei Installation ein Zertifikat, das auf seinen Hostnamen und IP ausgestellt ist (gültig z.B. 10 Jahre). Der Kiosk-Browser ist so konfiguriert, dass er diese Zertifikate ohne Warnung akzeptiert. Für normale Nutzer-PCs müsste das Zertifikat einmal als vertrauenswürdig installiert werden, oder – besser – man hinterlegt ein von der internen CA signiertes Zertifikat. In der derzeitigen Implementierung blieb es bei selbstsignierten Zertifikaten, was für den reinen Offline/Labor-Betrieb ausreichend ist.
+
+Auf Netzwerkebene wurde auch **CORS (Cross-Origin Resource Sharing)** gezielt konfiguriert: Standardmäßig sind API-Aufrufe nur vom gleichen Origin erlaubt (d.h. vom eigenen Frontend). Wenn das Firmenportal von einer anderen Domain aus zugreift, muss diese Domain explizit auf der Whitelist stehen. Somit wird verhindert, dass z.B. ein bösartiges Script von einem fremden Host auf die API zugreifen könnte, selbst wenn ein Nutzer gerade eingeloggt ist.
+
+**Offline-Cache und Datenschutz:** Durch die Offlinefähigkeit der PWA ergab sich die Frage, wie mit **zwischengespeicherten Daten** umgegangen wird. Der Service Worker der PWA wurde so eingestellt, dass **sicherheitsrelevante Routen nicht gecacht** werden. Beispielsweise werden die Benutzerliste oder Admin-Funktionen nie offline vorgehalten. Seiten wie das allgemeine Dashboard oder die Druckerliste können hingegen temporär gecacht werden, um bei Verbindungsverlust zumindest den letzten bekannten Stand zu zeigen. Persönliche Daten der Nutzer (Passwörter, Tokens) werden nie im Local Storage o.Ä. gespeichert, sondern verbleiben serverseitig (im Cookie bzw. in der Session-Datenbank). Sollte der Pi verloren gehen, sind die wichtigsten Zugangsdaten ebenfalls geschützt (Passworthashes). Ein Restrisiko besteht natürlich physisch: Wer Zugriff auf den Pi oder die SD-Karte erlangt, könnte die SQLite-Datei kopieren. Daher wird empfohlen, den Pi in einem abgesicherten Bereich aufzubewahren und regelmäßige Backups zu ziehen, die wiederum sicher verwahrt werden.
+
+**Physische Sicherheit und Notfallschutz:** Da die Steuerung der Drucker über Strom an/aus erfolgt, wurden Sicherheitsmaßnahmen bedacht: Etwa verhindert die Software Mehrfach-Ein/Aus-Schaltungen in sehr kurzer Zeit, um die Geräte nicht zu schädigen. Außerdem ist ein **Not-Aus** möglich: Ein Admin kann im System alle laufenden Jobs abbrechen, was sofort alle Drucker ausschaltet – nützlich im Falle einer Gefahr oder technischen Störung. Die Smart-Plugs selbst haben einen Schalter am Gerät; sollte die Software also ausfallen, kann ein Benutzer den Drucker notfalls manuell vom Strom nehmen. Diese Rückfall-ebene ist wichtig für die Abnahme, um zu zeigen, dass das System keine unkontrollierbaren Risiken einführt.
+
+Zusammenfassend wurde ein **ganzheitliches Sicherheitskonzept** umgesetzt, das sowohl Software- als auch Netzwerk-Aspekte abdeckt. Für einen produktiven Einsatz in größerem Maßstab könnten noch weitere Härtungen erfolgen, doch für die Projektarbeit erfüllt das Konzept alle Anforderungen an Datenschutz, Zugriffsschutz und Betriebssicherheit im Kontext eines internen Offline-Netzwerks.
+
+## 11. Test und Abnahme
+
+Um die Funktionsfähigkeit und Zuverlässigkeit von MYP sicherzustellen, wurden umfangreiche **Tests und eine Abnahmeprüfung** durchgeführt. Diese umfassten sowohl technische Funktionstests als auch Benutzer- und Sicherheitstests in der Zielumgebung.
+
+**Funktionale Tests (API-Schnittstellen):** Zunächst wurden alle API-Endpunkte einzeln verifiziert (Unit-Tests und manuelle Tests mittels Tools wie Postman). Für jede wichtige Funktion gab es Testfälle, z.B.:
+
+* **Benutzerregistrierung/Login:** Test mit gültigen Daten (soll erfolgreich sein) und mit ungültigen Daten (z.B. bereits verwendete E-Mail, schwaches Passwort) – erwartetes Ergebnis: Fehlermeldung bzw. Verweigerung. Ebenso wurde geprüft, dass ohne Login der Zugriff auf geschützte Endpunkte unterbunden ist.
+* **Druckerverwaltung:** Anlage eines neuen Druckers via `POST /api/printers` und anschließendes `GET /api/printers`, um zu sehen ob der Drucker erscheint. Löschen eines Druckers und Überprüfung, dass zugehörige Jobs ggf. mit gelöscht oder als ungültig markiert werden. Hierbei wurde insbesondere die Rechteprüfung getestet (nur Admin darf diese Aktionen durchführen).
+* **Job-Life-Cycle:** Erstellung eines Druckjobs und Verifikation, dass dieser in der Jobliste auftaucht mit korrekten Zeiten. Dann Warten bis zum Startzeitpunkt (bzw. simulierter Sprung) – Überprüfung, ob der **Plug einschaltet** und der Job-Status auf "läuft" wechselt. Nach Ablauf der Dauer Überprüfung, ob der **Plug ausgeschaltet** wurde und der Status "beendet" gesetzt ist. Zusätzlich wurden die manuellen Aktionen getestet: Job vorzeitig via `/finish` beendet – Plug sollte sofort aus gehen; Job via `/abort` abgebrochen – ebenfalls Ausschalten und Status "abgebrochen". Auch `/extend` wurde getestet: Ein laufender Job wurde verlängert und es wurde beobachtet, ob der Plug erst zur neuen Endzeit ausgeht.
+* **Statistiken & Sonstiges:** Prüfung der Ausgabe von `/api/stats` nach ein paar durchgeführten Jobs (stimmen die summierten Zeiten?), Test des `GET /api/test` (Health-Check liefert erwarteten Wert), etc.
+
+Alle diese Tests verliefen erfolgreich. Kleinere Bugs, die entdeckt wurden (z.B. eine falsche Rollenprüfung bei einem Endpoint), konnten noch vor der Abnahme korrigiert werden.
+
+**Integrationstest (Plattform <-> Drucker):** In einer Testumgebung wurde das gesamte Szenario durchgespielt: Ein Benutzer bucht im Web-Frontend einen Druckzeitraum und wartet ab. Der entsprechende 3D-Drucker war testweise mit einer Tischlampe als Verbraucher verbunden, um sichtbar zu machen, wann Strom fließt. Pünktlich zur Startzeit leuchtete die Lampe (Drucker an) und zur Endzeit ging sie wieder aus – was bestätigte, dass die **End-to-End-Kommunikation** vom Frontend über das Backend bis zum Smart-Plug funktionierte. Zusätzlich wurde am Drucker (Lampe) manuell gemessen, ob tatsächlich kein Strom mehr floss nach Abschaltung (mithilfe der Verbrauchsmessfunktion der P110 ließ sich das auch in der App verifizieren). Die Kommunikation zwischen Reservierungssystem und Hardware klappte zuverlässig innerhalb der Toleranzen.
+
+**Netzwerk- und Offline-Tests:** Im Anschluss wurde das Verhalten im **Offline-Szenario** geprüft. Dazu wurde der Raspberry Pi vom Firmennetz getrennt (kein Ethernet, kein Internet) und nur das Pi-eigene WLAN genutzt. Ein Laptop wurde ins Pi-WLAN eingebucht und die Weboberfläche aufgerufen. Der gesamte Funktionsumfang war gegeben – der Benutzer konnte sich anmelden, Jobs anlegen und die Steckdosen wurden geschaltet. Die Offline-PWA zeigte auch im **Funkloch** (kurz WLAN getrennt) zuletzt bekannte Daten an und synchronisierte sich wieder, sobald Verbindung bestand. Ebenso wurde getestet, was passiert, wenn der Pi neu startet während ein Job läuft: In diesem Test blieb der Drucker an (da er ja gerade druckte), der Pi kam nach reboot wieder hoch und erkannte den laufenden Job korrekt, so dass kein ungewolltes Abschalten erfolgte. Der Watchdog-Service im Pi (ein Cron-Job) wurde verifiziert, indem man absichtlich den Browser-Prozess killte – nach wenigen Minuten startete der Watchdog den Browser automatisch neu. Diese Selbstheilungsmechanismen sorgen für einen robusten Dauerbetrieb.
+
+**Leistungs- und Belastungstest:** Da es sich um ein kleines internes System handelt, waren extreme Lasttests nicht im Vordergrund. Dennoch wurde geprüft, wie das System bei mehreren gleichzeitigen Zugriffen reagiert. Mit einem kleinen Skript wurden z.B. 5 gleichzeitige User-Sessions simuliert, die Anfragen an die API schicken (Jobs abfragen etc.). Der Raspberry Pi konnte diese Last (entspricht ca. 20-30 Requests pro Sekunde) ohne merkliche Verzögerung beantworten. Der Flaschenhals war hier eher die WLAN-Verbindung, doch insgesamt wurden Performanceziele erreicht. Auch die Scheduler-Thread Nutzung wurde beobachtet (CPU und RAM blieben in einem niedrigen Bereich, so dass genug Reserven für mehr Drucker oder häufigere Polling-Intervalle bestehen).
+
+**Sicherheitstest:** Abschließend unterzog man das System einfachen Penetrationstests. Mit Tools wie nmap wurde gescannt, ob ungewollte offene Ports am Raspberry Pi existieren – es war nur Port 5000 (bzw. 443 bei HTTPS) offen, was dem Soll entspricht. Ein Versuch, über das Firmennetz in das Pi-WLAN zu gelangen, schlug erwartungsgemäß fehl (kein Routing). Per Browser wurde versucht, auf Admin-Seiten ohne Login zuzugreifen: Diese Anfragen wurden korrekt mit einem Redirect zur Login-Seite bzw. 401er Antwort geblockt. SQL Injection wurde durch Eingabe spezieller Zeichen in Formularfeldern getestet – dank Parameterisierung in der DB-Schicht gab es keine Anfälligkeiten. Auch das Szenario, einen Session-Cookie zu stehlen und wiederzuverwenden, wurde betrachtet: Da alles intern abläuft, war die Gefahr gering, doch ein abgelaufener Cookie wurde tatsächlich vom Server abgelehnt.
+
+**Abnahme:** Nachdem alle Komponenten getestet waren, erfolgte die formale Abnahme durch den Projektbetreuer (und ggf. den Ausbilder). Hierbei wurde das System live vorgeführt: Zunächst die Oberfläche mit Beispiel-Reservierungen, dann das automatische Einschalten eines 3D-Druckers zu einer simulierten Startzeit. Die Prüfer konnten beobachten, wie der Druckerstatus auf "läuft" sprang und am Gerät die Betriebs-LED anging. Ebenso wurde gezeigt, wie ein Administrator einen Drucker aus der Ferne abschalten kann (Not-Aus). Die Abnahmecheckliste wurde Punkt für Punkt durchgegangen, wobei MYP alle funktionalen Anforderungen erfüllte. Besonders hervorgehoben wurde die saubere **Dokumentation** und das **Netzwerkkonzept**, das den Prüfern zeigte, dass hier Fachwissen in *digitale Vernetzung* eingebracht wurde. Einige Verbesserungswünsche wurden als Ausblick besprochen (siehe Fazit), änderten aber nichts am positiven Abnahmeergebnis.
+
+Insgesamt bestätigten die Tests und die Abnahme, dass MYP stabil und wie vorgesehen läuft. Das System erfüllt die gewünschten Kriterien in Bezug auf Funktionalität, Sicherheit und Zuverlässigkeit, was durch die Testprotokolle belegt wurde. Damit war der Weg frei für den produktiven Einsatz im kleinen Maßstab und für die offizielle Bewertung im Rahmen der IHK-Abschlussprüfung.
+
+## 12. Fazit und Optimierungsmöglichkeiten
+
+Mit **MYP – Manage Your Printer** wurde erfolgreich ein Projekt umgesetzt, das einen vormals manuellen Prozess in eine digitale, vernetzte Lösung transformiert. Im **Soll-Ist-Vergleich** zeigt sich, dass alle Hauptziele erreicht wurden: Die 3D-Drucker lassen sich nun zentral verwalten, Reservierungen werden digital gehandhabt und die Drucker schalten sich automatisch entsprechend der Zeitplanung an und aus. Nutzer profitieren von einer einfachen Bedienoberfläche und die IT-Infrastruktur wurde um ein sicheres, autarkes System erweitert. Durch den Fokus auf *digitale Vernetzung* entstand eine kleine IoT-Lösung, die Hardware (Steckdosen, Drucker) und Software (Reservierungsdatenbank, Web-Frontend) intelligent koppelt.
+
+**Herausforderungen und Lösungen:** Während der Umsetzung gab es einige Hürden (siehe Abschnitt 9), doch diese konnten durch kreative Ansätze gelöst werden. Insbesondere die **Offline-Fähigkeit** und die **Integration der IoT-Geräte** stellten Lerngelegenheiten dar, die gemeistert wurden. Das Projekt hat gezeigt, dass auch mit begrenztem Budget (Raspberry Pi und Smart-Plugs) leistungsfähige Automatisierung im Unternehmen möglich ist. Die Entscheidung, keine direkte Druckeransteuerung zu implementieren, erwies sich im Nachhinein als richtig, da es den Projektumfang begrenzte und das System stabil hielt – die Kernfunktion (Stromsteuerung) funktioniert zuverlässig, komplexere Funktionen können iterativ ergänzt werden.
+
+**Wirtschaftlicher/Nutzwert:** MYP bringt einen praktischen Nutzen im Alltag. Drucker laufen nicht mehr im Leerlauf, was Energie spart und die Lebensdauer der Geräte schont. Die Benutzerverwaltung stellt sicher, dass nachvollziehbar ist, wer wann welchen Drucker belegt hatte, was auch für Verantwortlichkeit und Planung wichtig ist. Zudem dient das Projekt als **Prototyp** für ähnliche Digitalisierungsansätze – es ließe sich auf andere Geräte (z.B. Laborrechner, die nur bei Bedarf an sein sollen) übertragen.
+
+**Optimierungspotenzial:** Trotz des Erfolgs gibt es verschiedene **Möglichkeiten zur Erweiterung** und Verbesserung in der Zukunft:
+
+* **Direkte Drucker-Kommunikation:** Bisher wird – wie erwähnt – nicht mit den Druckern selbst gesprochen. Zukünftig könnte man Protokolle wie **OPC UA oder MQTT** einführen, um direkt mit den 3D-Druckern zu kommunizieren. Damit ließen sich z.B. Druckfortschritt, Temperaturen oder Fehlermeldungen auslesen. Auch eine Steuerung der Druckaufträge (Start/Pause eines Druckjobs) wäre denkbar. Dies würde MYP vom reinen Strommanager zu einer vollwertigen IoT-Plattform für 3D-Druck machen.
+* **Echtzeit-Feedback und Monitoring:** Momentan prüft das System in Intervallen den Status (Polling). Eleganter wäre ein **Echtzeit-Monitoring**, etwa über WebSockets oder Push-Nachrichten. Eine Integration von **Push-Benachrichtigungen** könnte Benutzern Mitteilungen senden, wenn ein Druck fertig ist oder ein Problem auftritt. Dazu könnte der Pi z.B. E-Mails versenden oder in eine Messaging-App im Unternehmen integrieren.
+* **Skalierung und Verteiltheit:** Derzeit läuft alles auf einem einzelnen Raspberry Pi. Für mehr Drucker oder höhere Last könnte man überlegen, die Architektur zu verteilen – etwa einen dedizierten Datenbankserver zu verwenden oder mehrere Pi-Controller für verschiedene Druckerräume einzusetzen, die untereinander synchronisiert sind. Auch eine Auslagerung der Frontend-Komponenten in eine Cloud/PaaS käme in Frage, falls irgendwann doch Internetanbindung erlaubt ist.
+* **Verbesserte Sicherheit:** Im aktuellen Stadium ist Sicherheit für das interne Netz ausreichend. Für einen größeren Rollout wäre aber z.B. **Zwei-Faktor-Authentifizierung** für Admin-Zugriffe und eine **Integration ins Firmen-AD** (LDAP) sinnvoll, um Nutzer zentral zu verwalten. Ebenso könnte man die selbstsignierten Zertifikate durch von einer internen CA signierte ersetzen, um keine Browser-Warnungen zu erhalten. Ein Penetration Test durch die interne IT-Security könnte weitere Härtungspotenziale aufdecken.
+* **Usability und UI:** Das Frontend funktioniert, könnte aber benutzerfreundlicher gestaltet werden. Ein Kalendersicht für Reservierungen, Drag-and-Drop für Buchungen, oder eine Mobiloptimierung für Smartphone-Zugriff der Nutzer wären denkbar. Auch Mehrsprachigkeit oder eine engere Integration in vorhandene Webportale würde die Akzeptanz steigern.
+* **Weitere Hardware-Integration:** Die Tapo P110 waren ein guter Anfang. Man könnte jedoch weitere Sensoren/Aktoren einbinden. Z.B. ein **LED-Statusanzeige** an jedem Drucker, die direkt vom Pi angesteuert wird (grün = frei, rot = belegt), oder Türsensoren, die erkennen ob der Druckraum betreten wird. Denkbar ist auch, den **Stromverbrauch** der Tapo (P110 liefert Verbrauchsdaten) auszuwerten, um festzustellen, ob ein Druck tatsächlich läuft oder der Drucker im Leerlauf ist – so könnte das System z.B. einen Druckauftrag als "fertig" erkennen, wenn der Stromverbrauch abfällt.
+
+**Persönliches Fazit:** Das Projekt MYP war für den Entwickler (und Prüfungskandidaten) eine wertvolle Erfahrung, insbesondere im Bereich der digitalen Vernetzung. Es vereint Kenntnisse aus Netzwerkadministration, Programmierung, Datenbanken und IT-Security in einem greifbaren Anwendungsfall. Die erfolgreiche Umsetzung innerhalb des vorgegebenen Zeitrahmens und Budgets zeigt, dass auch im kleinen Rahmen **Industrie-4.0-Prinzipien** angewandt werden können. Die Dokumentation und Feedback der Prüfer haben bestätigt, dass das Projekt die Anforderungen des Ausbildungsprofils *Fachinformatiker Digitale Vernetzung* erfüllt.
+
+Abschließend lässt sich sagen: MYP – Manage Your Printer hat den 3D-Drucker-Reservierungsprozess effizienter, sicherer und moderner gemacht. Gleichzeitig wurden Grundlagen gelegt, auf denen zukünftige Projekte aufbauen können. Die digitale Vernetzung schreitet in diesem Unternehmensbereich weiter voran, und MYP dient hier als **Pilotprojekt**, das sicherlich Schule machen wird.