Werkzeuge waren zu umstaendlich, um sie beim Kunden wirklich zu benutzen: die Produktivdaten zeigen 19 Protokolle, aber nur 26 Messungen, fast durchweg ein einzelner IP-Scan. Der Standardfall "IP-Scan im aktuellen Netz" kostete drei Tipper, obwohl das einzige Feld ausdruecklich leer bleiben darf. - Kurzer Tap auf eine Werkzeugkarte startet sofort, langes Halten oeffnet die Optionen. Auf den betroffenen Karten steht "Tippen startet · Halten fuer Optionen" - sonst ist das Verhalten unsichtbar und der erste versehentliche Scan ueberrascht. - quickRun wird je Werkzeug AUSDRUECKLICH gesetzt, nicht hergeleitet: ToolParamField kennt kein 'required', die Pflicht steht allein im run()-Rumpf. portscan.ports hat keinen Vorgabewert und ist optional, iperf.host hat ebenfalls keinen und ist Pflicht - eine Heuristik ueber "hat Default" wuerde genau falsch herum raten. iperf bleibt deshalb bewusst ohne Schnellstart. - Der Lauf bleibt zwingend im ToolDialog: dort sitzen Bildschirmsperre, Fortschritt mit Abbrechen und die EINZIGE Fehlerbehandlung eines Werkzeuglaufs (runTool selbst hat kein try/catch). Ein Schnellstart daran vorbei wuerde Fehler verschlucken. - Die Vorschau wird nicht uebersprungen, sondern nur ohne Warnung automatisch durchgewunken. Der IP-Scan warnt ab ~1000 Adressen - genau der Fall, in dem ein versehentlicher Tap sonst minutenlang das falsche Netz absucht. - Langdruck bricht ab, sobald der Finger mehr als 10 px wandert: das Werkzeug-Raster liegt in einem Scroll-Bereich, sonst oeffnet jeder Wisch nach einer halben Sekunde den Dialog. - Nach einer Messung wird zum Ergebnis gescrollt und es 2,5 s hervorgehoben. Bei 46 Geraeten liegt die neue Karte sonst dutzende Bildschirme entfernt. block:'center', weil die feste Aktionsleiste den unteren Rand verdeckt; bei einer Geraete-Messung wird die Geraetekarte angesteuert, denn dort hinein wird gerendert. - Verwendete Parameter stehen in der Messkarte. Seit dem Schnellstart laeuft eine Messung auch ohne Dialog - dann ist das der einzige Ort, an dem man sieht, WOMIT gemessen wurde. Beschriftung aus tool.params, nicht aus der Ergebnistabelle: 'count' heisst dort "Gefundene Geraete", als Ping-Parameter aber "Anzahl Pakete". - Zuletzt benutzte Parameter werden gemerkt (neues Modul toolparams.ts). Ortsgebundene Schluessel wie 'subnet' ausdruecklich NICHT: ein aus dem vorigen Kundennetz uebernommener Netzbereich waere schlimmer als gar keiner, der Schnellstart wuerde stillschweigend das falsche Netz scannen. Im Emulator geprueft, und dabei zwei Fehler gefunden, die im Code nicht auffielen: die Parameterzeile wiederholte "Ziel: 8.8.8.8" direkt ueber dem Ergebnis (jetzt werden Werte ausgelassen, die das Ergebnis ohnehin nennt), und Traceroute schrieb "1 Hops" ins Kundendokument (jetzt "1 Station"). |
||
|---|---|---|
| .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.