Ein Befund davon ist ein Fehler aus Phase 4/5, den erst die Bestandsprüfung zutage gebracht hat: - MeasurementResult konnte nur Skalare und Textlisten. Die WLAN-Kanalmessung besteht aber aus verschachtelten Objekten (eigenesNetz, netze, empfehlung24GHz) — auf dem Handy stand dort "[object Object]", während dieselbe Messung in Dolibarr als saubere Tabelle aussah. Jetzt: "Eigenes Netz: FRITZ!Box 7590 SM · Kanal 6 · 2.4 GHz · -50 dBm · sehr gut". Weiter: - Ampel mit Form UND Zeichen statt nur Farbe (AmpelBadge.svelte): Kreis ✓, Dreieck !, Quadrat ✕, Raute ?. Rot-Grün-Sehschwäche betrifft rund 9 % der Männer, und im Sonnenlicht sind gesättigte Farben auf dem Handy ohnehin kaum zu unterscheiden. Ersetzt drei duplizierte Farbpunkt-Stellen. - Zeitstempel je Messung — bei mehreren Läufen desselben Werkzeugs war sonst nicht erkennbar, welche von wann ist. - messfelder.ts: deutsche Bezeichnungen mit Einheiten, Gegenstück zu netdiagKundenfelder() im Modul. Aus "verlustProzent: 0 · minMs: 4.4" wird "Paketverlust: 0 % · Kürzeste Antwortzeit: 4.4 ms". Bewusst KEINE Whitelist wie im Kundendokument — die App ist die Technikeransicht, unbekannte Schlüssel werden lesbar gemacht statt ausgeblendet. - Werkzeug-Klarnamen auch in der App: Messungen aus eigenen Routen (WLAN-Kanalanalyse, Monitor, IP-Test) haben keine Registry-ID, dort stand die rohe ID "wifikanal". - Fehler-Toasts bleiben 12 s statt 3 s stehen, erscheinen unten im Daumenbereich statt oben am Notch und lassen sich zum Schließen antippen. Sie weichen einer festen Aktionsleiste aus, statt den "Abschließen"-Knopf zu verdecken. - Kontrast: Messwerte von text-zinc-500 (3,67:1, unter WCAG-Minimum) auf text-zinc-400 (6,91:1), 11 -> 12 px, Zahlen mit tabular-nums. - setKeepAwake (nativ, FLAG_KEEP_SCREEN_ON): Bildschirm bleibt an, solange eine Messung läuft. Der WakeLock aus Phase 1 hält nur die CPU wach — das Display ging trotzdem aus, und man musste beim Zusehen ständig antippen. Im Emulator geprüft: WLAN-Kanalmessung wird vollständig lesbar dargestellt (Kennzahlen, Kanalempfehlung, Hinweise, Netzliste), Ampel als Kreis mit Haken, Zeitstempel, Klarname. |
||
|---|---|---|
| .forgejo/workflows | ||
| android | ||
| native-plugin | ||
| src | ||
| tools | ||
| .gitignore | ||
| capacitor.config.ts | ||
| package.json | ||
| README.md | ||
| svelte.config.js | ||
| tsconfig.json | ||
| vite.config.ts | ||
NetDiag — Diagnose-App (Android)
Mobile Netzwerk-Diagnose-App. Erfasst vor Ort beim Kunden (Handy am WLAN oder
USB-C→RJ45-Adapter) Geräte, Ports und Messungen und hängt die Protokolle ans
Dolibarr-Modul netdiag an Kunde und Auftrag.
Stack
SvelteKit 2 · Svelte 5 · Tailwind 4 · Vite 7 · Capacitor 6 · SQLite-Offline
Entwicklung (Browser)
npm install
npm run dev # http://localhost:5175
Im Browser liefert ein Mock (src/lib/scanner.ts) Beispiel-Scandaten — die
Oberfläche lässt sich ohne Gerät entwickeln. API-Aufrufe gehen über den
Vite-Proxy an den Dolibarr-Testserver (192.168.155.11, siehe vite.config.ts).
Android-Build
npm run build
npx cap add android # einmalig
# android/ liegt komplett im Repo — cap sync kopiert nur die Web-Assets
npx cap sync android
npx cap open android
Release-APK über CI: Commit mit [apk] in der Message → Forgejo baut und lädt
die APK in die Package Registry (netdiag-apk). Siehe .forgejo/workflows/build.yml.
Architektur
src/lib/
api.ts JSON-API-Client (JWT, 401-Refresh, Timeout)
auth.svelte.ts Anmelde-Status
db.ts Offline-Speicher (SQLite nativ / localStorage Browser)
sync.svelte.ts Sync-Queue -> Dolibarr (idempotent über clientUuid)
scanner.ts Brücke zum nativen Plugin (+ Browser-Mock)
backButton.svelte.ts Hardware-Back (Single-Instance, KB #480/#549)
updater.ts APK-Auto-Update-Prüfung (KB #363)
tools/ erweiterbare Tool-Plattform
index.ts Registry — neues Tool hier eintragen
netzwerk/ IP-Scan, Port, Ping, IP-Konflikt, SNMP, Traceroute, Stress
internet/ Durchsatz-Test
telefonie/ (folgt: SIP, FreePBX, RTP)
src/routes/
login/ auftraege/ kunden/ protokoll/[id]/ einstellungen/
android/ natives Android-Projekt inkl. Kotlin-Plugin (einzige Quelle)
native-plugin/ nur noch Anleitung/Hinweise zum Plugin
Neues Tool hinzufügen
- Datei unter
src/lib/tools/<kategorie>/<id>.tsanlegen,Toolimplementieren. - In
src/lib/tools/index.tsimportieren und inTOOLSeintragen.
Kein Eingriff in App-Logik, Sync oder Datenbank — das Ergebnis ist generisches JSON. Braucht das Tool eine neue native Messroutine, eine Methode im Kotlin-Plugin ergänzen.
Bedienung
- Anmelden (Dolibarr-Zugang; auf dem Gerät zusätzlich Server-URL).
- Aufträge — aktive direkt sichtbar, abgeschlossene per Checkbox, Suche. Alternativ über Kunden suchen.
- Auftrag/Kunde antippen → Diagnose-Protokoll öffnet sich.
- Werkzeuge ausführen (IP-Scan füllt die Geräteliste, je Gerät weitere Tools).
- Abschließen & synchronisieren — Protokoll geht ans Dolibarr, PDF landet im ECM. Offline bleibt es lokal und synct automatisch bei Verbindung.