Eduard Wisch
881ca7956f
Aufraeumen vor den eigentlichen Korrekturen — ohne Verhaltensaenderung am Code. Doppelte Plugin-Quelle: Die drei Kotlin-Dateien lagen byte-identisch in native-plugin/ UND in android/app/src/main/java/de/data_it_solution/netdiag/. Gebaut wurde immer nur die Kopie unter android/ — eine Aenderung an der falschen Datei sah deshalb aus wie "der Fix wirkt nicht". native-plugin/ enthaelt jetzt nur noch die Anleitung, die auf den echten Ort verweist. Doku sagte drei Dinge, die nicht stimmen: - stresstest.ts behauptete "laeuft nativ als Foreground-Service". Tut es nicht — im Plugin steht an der Stelle nur ein Kommentar, dass man einen ergaenzen sollte. Bei ausgeschaltetem Display friert Android den Lauf ein. - iperf.ts/scanner.ts/README nannten den Durchsatztest "iperf-kompatibel". Er spricht kein iperf3-Protokoll (kein Cookie, kein Parameterblock) und scheitert gegen einen echten iperf3-Server. - ipscan.ts beschrieb sich als "ARP + Ping + Namen". Gefunden wird nur, wer auf Ping antwortet oder sich per mDNS meldet; die ARP-Tabelle wird lediglich nachgeschlagen und ist ab Android 10 meist gar nicht lesbar. Statt der falschen Zusagen stehen dort jetzt die tatsaechlichen Grenzen plus Verweis auf die Phase, die sie behebt. README: DHCP-Check und WLAN-Scan als Werkzeuge entfernt (sind nicht mehr in tools/index.ts registriert, tauchen aber in alten Protokollen noch auf). Geprueft: vite build ok, svelte-check 0 Fehler (2 vorbestehende Warnungen). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
74 lines
2.8 KiB
Markdown
74 lines
2.8 KiB
Markdown
# 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)
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
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
|
|
|
|
1. Datei unter `src/lib/tools/<kategorie>/<id>.ts` anlegen, `Tool` implementieren.
|
|
2. In `src/lib/tools/index.ts` importieren und in `TOOLS` eintragen.
|
|
|
|
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
|
|
|
|
1. **Anmelden** (Dolibarr-Zugang; auf dem Gerät zusätzlich Server-URL).
|
|
2. **Aufträge** — aktive direkt sichtbar, abgeschlossene per Checkbox, Suche.
|
|
Alternativ über **Kunden** suchen.
|
|
3. Auftrag/Kunde antippen → Diagnose-Protokoll öffnet sich.
|
|
4. **Werkzeuge** ausführen (IP-Scan füllt die Geräteliste, je Gerät weitere Tools).
|
|
5. **Abschließen & synchronisieren** — Protokoll geht ans Dolibarr, PDF landet
|
|
im ECM. Offline bleibt es lokal und synct automatisch bei Verbindung.
|