Beim Wiederholungsbesuch die erste Frage des Kunden ("da ist doch nichts
dazugekommen, oder?") und die einzige, die ein einzelnes Protokoll nicht
beantworten kann. Das Werkzeug holt das juengste fruehere Protokoll desselben
Kunden vom Server und vergleicht die Geraetelisten.
KEINE Wiedererkennung ueber MAC: /proc/net/arp ist ab Android 10 gesperrt, im
ausgelieferten Protokoll ND2026-0015 hatten ALLE 68 Geraete keine MAC. Ein
MAC-Diff haette dort bei jedem Besuch "alles neu, alles verschwunden"
gemeldet - schlimmer als gar keine Aussage, weil es im Kundendokument nach
einem umgebauten Netz aussieht. Stattdessen eine Kaskade: MAC (falls
ausnahmsweise da), mDNS-Name, NetBIOS-Name, Hostname, IP+Portmuster. Jede
Zeile nennt, worueber sie zugeordnet wurde - "erkannt ueber IP und Portmuster"
ist eine schwaechere Aussage als "ueber Netzwerkname".
Im Emulator gegen echte Serverdaten geprueft. Dabei ein Fehler gefunden und
behoben: dieselbe Adresse stand gleichzeitig unter "neu" und "nicht mehr
erreichbar", weil sich nur das Portmuster geaendert hatte. Formal richtig, im
Kundendokument aber Unsinn - liest sich wie ein kaputtes Werkzeug. Solche
Faelle haben jetzt eine eigene Kategorie "Gleiche Adresse, andere offene
Ports", die sogar der interessantere Befund ist.
Bewertung bewusst ohne Rot: ein neues Geraet ist erst einmal eine Tatsache,
womoeglich hat der Techniker es selbst angeschlossen. Gelb nur, wenn etwas
fehlt oder die Zuordnung wackelt (ab 50 % schwache Zuordnung).
tools/pruefe-geraetediff.mjs: 20 Faelle, alle mit Geraeten OHNE MAC - so wie
sie beim Kunden ankommen. Der Browser-Mock gibt jedem Geraet eine MAC, dort
saehe auch ein naiver MAC-Diff perfekt aus.
Ausserdem: Server-Adresse wird jetzt geprueft. Eine http://-Adresse wird
abgewiesen, solange die App selbst ueber https laeuft - sie wuerde sonst stumm
scheitern ("Keine Verbindung zum Server", wahrer Grund nur im logcat). Ein
Debug-Build auf http://localhost darf HTTP dagegen, sonst waere der Testbau
unbenutzbar. tools/pruefe-serveradresse.mjs: 11 Faelle.
Neu in api.ts: getProtocol() laedt ein Protokoll samt Geraeten vom Server -
nur lesend, das fruehere Protokoll wird nie ueberschrieben.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die App ermittelt seit dem IP-Scanner-Umbau NetBIOS-/mDNS-Namen, offene Ports
und den Fundweg je Gerät, hat sie aber nie übertragen — im Kundenprotokoll
stand nur die IP, während der Techniker in der App "Drucker HP, Port 9100" sah.
Der Payload enthält jetzt netbiosName, mdnsName, mdnsServices, customName,
openPorts, foundVia und lastSeen. Die Gegenstelle (Dolibarr-Modul netdiag)
nimmt sie ab derselben Version entgegen; ältere Modulstände ignorieren die
zusätzlichen Schlüssel einfach.
Der Updater fragte die private Forgejo-Registry direkt ab -> 403/CORS ->
catch -> 'App ist aktuell'. Er hat NIE wirklich geprueft.
- updater.ts: geht jetzt ueber update.php (eigener, authentifizierter
Endpoint, CORS-frei). checkForUpdate() verschluckt Fehler NICHT mehr,
sondern wirft mit Klartext-Grund.
- Einstellungen: 'Auf Update pruefen' zeigt bei Fehler die echte Meldung
('Update-Pruefung fehlgeschlagen: <Grund>') statt falschem 'aktuell'.
- +layout: Start-Pruefung still (nur Banner bei Erfolg, kein Fehler-Toast).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Damit App-Fehler (Scan/Sync) ohne Kabel nachvollziehbar sind:
- debuglog.svelte.ts: faengt window.error, unhandledrejection und console.*
in einem Ringpuffer ab, gespiegelt in Preferences (ueberlebt Neustart)
- Auto-Upload zum neuen Endpoint applog.php (gedrosselt, best effort);
ToolDialog- und Sync-Fehler werden explizit mitgeloggt
- Seite Einstellungen -> Debug-Log: Eintraege ansehen, manuell senden, leeren
- initDebugLog() zuerst in +layout onMount, damit Startfehler erfasst werden
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
