Werkstattablauf

Geräteerkennung

Beim Start liest die Anwendung die verfügbaren DMI-Felder. Bevorzugt wird eine gültige System-UUID. Fehlt sie, wird eine gehashte Kombination aus Hersteller und Seriennummer verwendet. Platzhalter wie To be filled by O.E.M. sind ungültig. Falls der Linux-Benutzer einzelne DMI-Felder nicht lesen darf, müssen die Rechte auf dem Werkstattrechner passend eingerichtet werden.

Die Hardware-ID wird an POST /api/v1/devices/resolve/ gesendet. Der Server ordnet sie einem vorhandenen Gerät zu oder vergibt atomar eine neue Gerätenummer. UUID und Seriennummer können als Aliase dasselbe Gerät bezeichnen. Widersprüche werden zur manuellen Prüfung abgelehnt.

Automatische Erfassung

Für neue Geräte und Geräte in Eingang startet ein Kurzscan. Erfasst werden Hersteller, Modell, CPU, installierter RAM sowie Größe und Art aller Laufwerke. Die Daten werden revisionsgesichert über den Intake-Endpunkt geschrieben. Ein Gerät in einem späteren Prozessschritt wird durch den automatischen Scan nicht überschrieben.

Inspektion

Jeder Prüfschritt besitzt eine Aktion, eine verständliche Anleitung, ein sichtbares Ergebnis und eine Wiederholungsmöglichkeit. Verfügbare Schritte umfassen Display, Tastatur, Touchpad, WLAN, Lautsprecher, Mikrofon, Kamera, USB-Anschlüsse, Laden, Temperatur, Stabilität und SMART-Daten jedes internen Laufwerks.

Ergebnisse unterscheiden:

bestanden
Hardwarefehler
Test nicht verfügbar
Einrichtungsproblem
nicht geprüft
nicht vorhanden
Bestätigung erforderlich

Ein fehlendes Werkzeug oder eine fehlende Berechtigung wird niemals als Hardwaredefekt gewertet. Optionale Hardware muss ausdrücklich als nicht vorhanden bestätigt werden.

Beim Start einer Prüfung wird der Zustand Inspektion an den Server gesendet. Zwischenstände und der Abschluss verwenden unveränderliche Anforderungs-IDs, damit ein Verbindungsabbruch keine doppelten Einträge erzeugt. Ein Abschluss benötigt einen Technikernamen und vollständig bewertete Prüfschritte.

Unterbrechung und Offlinebetrieb

Der lokale Prüfstand wird atomar gespeichert. Nach einem Neustart öffnet die Anwendung die letzte unvollständige Prüfung mit Messwerten und Notizen. Noch nicht bestätigte Uploads liegen in outbox/inspections/; bestätigte Uploads werden nach outbox/sent/ verschoben. Beim nächsten Start werden gespeicherte Prüfungen erneut in die Warteschlange aufgenommen.

Reparaturen und Bericht

Eine Reparatur enthält Bauteil, Tätigkeit, Ersatzteil, Techniker und Zeitpunkt. Der vorherige Befund bleibt erhalten und der betroffene Test wird erneut geöffnet. Der HTML-Abschlussbericht enthält Spezifikationen, Laufwerks- und Akkuzustand, Messwerte, Mängel, Reparaturverlauf und technische Freigabe.

WLAN und Inventarverbindung

Das Werkstatt-WLAN wird erst nach erfolgreicher Verbindung gespeichert. Die Datei config/workshop-wifi.json ist nur für den Besitzer lesbar und kann in den Einstellungen ersetzt oder gelöscht werden. Das Passwort wird über die Standardeingabe an NetworkManager übergeben und erscheint nicht in Prozessargumenten.

Die Inventarverbindung benötigt:

{"url": "https://inventory.example.org"}

Der API-Schlüssel liegt separat in config/inventory-api-key. Für einen privaten HTTPS-Server kann config/inventory-server.crt die öffentliche CA enthalten. Zertifikats- und Hostnamenprüfung bleiben aktiv.

Abnahme eines neuen Builds

Vor dem Werkstatteinsatz sind mindestens diese Punkte auf echter Hardware zu prüfen:

Start der eigenständigen Datei in der vorgesehenen Linux-Umgebung
persistente Daten nach Neustart der Anwendung und des Rechners
automatische Wiederverbindung mit dem WLAN
richtige Gerätezuordnung und Dublettenwarnung
Intake-Synchronisation ohne Überschreiben späterer Zustände
Ein- und Ausgabegeräte sowie jedes Laufwerk
Offline-Warteschlange und Wiederholung nach Verbindungsabbruch
druckbarer Bericht

3.9 KiB Raw Blame History