NetDiag — Netzwerk-Diagnose App (SvelteKit + Capacitor)

Find a file

Eduard Wisch 3898f2aa27 Kanalempfehlung und DFS-Anzeige mit dem Diagramm in Einklang gebracht Zwei Widersprüche, die beim Durchsehen der offenen Punkte auffielen. Beide entstanden erst dadurch, dass der Kanalgraph seit dem letzten Commit die Wahrheit zeigt — Empfehlung und Kennzeichnung waren noch auf dem alten Stand. 1. Kanalempfehlung ignorierte die Kanalbreite. interferenceWeight() rechnete nur mit dem Abstand der Kanalnummern. Ein 40-MHz-Netz auf Kanal 1 belegt real 2402-2442 MHz und damit auch Kanal 6 (2437), wurde wegen \|1-6\| = 5 aber als "stört nicht" gewertet. Gerechnet wird jetzt in MHz, mit derselben occupiedRange(), die auch das Diagramm zeichnet. Belegt mit tools/test-recommend.mjs: in zwei von drei realistischen Lagen nennt die alte Formel einen ANDEREN Kanal als den tatsächlich besten — z.B. bei einem starken 40-MHz-Netz auf Kanal 1 empfahl sie Kanal 6, obwohl dieses Netz genau dorthin reicht (richtig ist Kanal 11). In der Demo-Lage ändert sich die Spitzenempfehlung nicht, nur die Bewertung der übrigen Kanäle (K6 von 0,62 auf 0,80). 2. DFS-Kanäle 52-64 waren im Diagramm nicht als solche erkennbar. Der Block hieß "UNII-1/2A" und trug keine DFS-Kennzeichnung, während channelWarnings() Kanal 52-144 als DFS behandelt. Ein im Diagramm "frei" wirkender Kanal 56 hätte den Kunden ungewollt auf DFS gesetzt (möglicher Radar-Zwangswechsel), obwohl die Warnung darunter das Gegenteil sagte. UNII-1 (36-48) und UNII-2A (52-64) sind jetzt getrennte Blöcke mit korrekter Kennzeichnung. Damit die zusätzliche Aufteilung nicht zu mehr Scrollen führt: ein Block ohne Netze wird kompakt gezeichnet (ohne dBm-Skala, ~1/4 der Höhe) statt in voller Größe. Er bleibt sichtbar — er ist die Antwort auf "wo ist noch Platz". Nebenbei im Render-Werkzeug behoben: es stapelte alle Segmente mit gleicher Höhe und erzeugte dadurch künstliche Lücken im Testbild, die es in der App nicht gibt.		2026-08-15 17:59:41 +02:00
.forgejo/workflows	android/ fest ins Repo aufgenommen — Build wie beim Adressmanager [apk]	2026-05-19 18:09:23 +02:00
android	Phase 4: WLAN-Kanalanalyse — Kanalgraph, Kanalempfehlung, Momentaufnahmen	2026-08-15 16:16:15 +02:00
native-plugin	Phase 0: doppelte Plugin-Quelle aufgeloest, falsche Doku-Zusagen korrigiert	2026-08-14 18:39:40 +02:00
src	Kanalempfehlung und DFS-Anzeige mit dem Diagramm in Einklang gebracht	2026-08-15 17:59:41 +02:00
tools	Kanalempfehlung und DFS-Anzeige mit dem Diagramm in Einklang gebracht	2026-08-15 17:59:41 +02:00
.gitignore	WLAN-Diagramme lesbar gemacht: dBm-Achse, 5-GHz-Aufteilung, Farben je Netz	2026-08-15 17:24:59 +02:00
capacitor.config.ts	Initiales Commit — NetDiag App vollständig implementiert [apk]	2026-05-19 12:01:56 +02:00
package.json	Initiales Commit — NetDiag App vollständig implementiert [apk]	2026-05-19 12:01:56 +02:00
README.md	Phase 0: doppelte Plugin-Quelle aufgeloest, falsche Doku-Zusagen korrigiert	2026-08-14 18:39:40 +02:00
svelte.config.js	Initiales Commit — NetDiag App vollständig implementiert [apk]	2026-05-19 12:01:56 +02:00
tsconfig.json	Initiales Commit — NetDiag App vollständig implementiert [apk]	2026-05-19 12:01:56 +02:00
vite.config.ts	Initiales Commit — NetDiag App vollständig implementiert [apk]	2026-05-19 12:01:56 +02:00

README.md

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>.ts anlegen, Tool implementieren.
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

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.