9 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 3f29a373ac |
SIP-Erreichbarkeit, Fingerabdruck-Anmeldung, Token raus aus der Adresszeile [apk]
All checks were successful
Build APK / build-apk (push) Successful in 2m48s
Die vier letzten offenen Punkte der Roadmap. SIP-Erreichbarkeit (neues Werkzeug, Kategorie Telefonie) - Sip.kt: OPTIONS nach RFC 3261 ueber UDP, bei Schweigen TCP nachgeschoben. Antwortet nur TCP, ist das der Fingerabdruck einer Firewall, die UDP verwirft - eine andere Reparatur als "Anlage aus". - sip-bewertung.ts ohne Laufzeit-Import, damit tools/pruefe-sip.mjs die Regeln direkt nachrechnen kann (14 Faelle + 4 Texte, alle korrekt). - Leitsatz: JEDE Statuszeile beweist eine antwortende Instanz. 401/407 sind deshalb gruen mit Hinweis "Anmeldung verlangt" - beim Provider der Normalzustand. Als Ausfall gemeldet wuerde der Techniker am falschen Ende suchen. - RTP-Sprachqualitaet bewusst NICHT: ohne aufgebautes Gespraech nicht ehrlich messbar. Die Grenze steht im Ergebnis und landet im Kunden-PDF. Fingerabdruck-Anmeldung (Biometrie.kt, BiometricPrompt + Android-Keystore) - Der Kern ist nicht der Dialog, sondern was danach passiert: die Klartextfassung des Tokens wird aus den Capacitor Preferences ENTFERNT. Vorher stand es offen in CapacitorStorage.xml und war auf einem entsperrten Geraet ohne Weiteres lesbar - ein zusaetzlich verschluesseltes Token haette daran nichts geaendert. - Kein zweiter Faktor: der Finger ersetzt das Passwort (Eddys Vorgabe). Gueltigkeit und Widerruf bleiben bei awlauth - hinterlegt ist dasselbe Token. - 401 unterscheidet jetzt "Token abgelehnt" von "gar nicht angemeldet". Ohne das loeschte der erste Startaufruf die gerade eingerichtete Anmeldung wieder (im Emulator aufgefallen, Ursache im logcat). Token nicht mehr in der Adresszeile - updateDownloadUrl() ohne ?jwt=; der APK-Herunterlader im Plugin schickt Authorization: Bearer. instanceFollowRedirects=false, sonst ginge der Header bei einer Weiterleitung an ein fremdes Ziel mit. - pdfUrl() war seit dem Initialcommit tot (kein Aufrufer) und ist durch fetchProtocolPdf() ersetzt - Header statt Token in der URL. Im Emulator geprueft: SIP gegen einen eigenen Responder (200/401/Port zu), Fingerabdruck vollstaendig durchgespielt (einrichten, Neustart, anmelden, abbrechen), Speicher jeweils nachgesehen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
|||
| 94fa804bd2 |
Geraete-Vergleich zweier Protokolle - ohne MAC-Adressen
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>
|
|||
| 2f7b1c91a4 |
DNS-Pruefung: eigener UDP-Client fragt jeden Server namentlich
Neu: Dns.kt (eigener DNS-Client auf UDP/53, Aufbau wie Snmp.kt) und das
Werkzeug "DNS-Pruefung". Unterschied zur Internet-Kette: dort antwortet, wen
das System fuer richtig haelt, und der Systemcache liegt dazwischen. Hier geht
je ein Paket an je einen Server aus der Netzkonfiguration - nur so laesst sich
sagen, WELCHER Server hakt, und genau das ist beim Kunden die
Reparaturanweisung ("die Fritzbox antwortet, der zweite DHCP-Eintrag zeigt
ins Leere").
Vier Ausgaenge, bewusst nicht zu "geht/geht nicht" verkuerzt:
ok, unbekannt (NXDOMAIN - ein FUNKTIONIERENDER Server!), ohneAdresse
(SERVFAIL/REFUSED - Stoerung), keineAntwort (Ausfall).
Beim Emulator-Test einen Fehlalarm gefunden und behoben: die erste Fassung
meldete "DNS-Server antworten unterschiedlich", sobald zwei Resolver
verschiedene IPs lieferten. Gegen www.google.de gemessen taten sie das sofort
(10.0.2.3 -> 192.178.24.195, 9.9.9.9 -> 192.178.183.94) - bei jedem CDN normal.
Die Warnung waere bei praktisch jeder Messung gekommen und haette im
Kundendokument eine gelbe Ampel ohne Befund erzeugt. Gewertet wird jetzt nur
noch der Sortenunterschied privat gegen oeffentlich - so sieht Split-Horizon
oder ein Fremd-DNS aus. Beide Antworten stehen ohnehin einzeln im Protokoll.
tools/pruefe-dns.mjs: 10 Bewertungsfaelle plus 10 Adressbereiche fuer
istPrivat() (172.16-31 macht eine naive Zeichenkettenpruefung falsch).
Im Emulator gemessen: 10.0.2.3 und 9.9.9.9 beide befragt und beantwortet;
der Cache-Effekt ist sichtbar (16 ms lokal, 500 ms zu Quad9).
Ausserdem: inputmode fuer die Eingabefelder im ToolDialog ('decimal' bei
Adress-/Netzfeldern, damit die Tastatur einen Punkt hat - mit 'numeric' laesst
sich keine IP eingeben), Autokorrektur und Grossschreibung aus (sonst wird aus
"fritz.box" beim Tippen "Fritz.Box").
Der Debug-Selbsttest uebernimmt jetzt die Vorgabewerte des Werkzeugs - vorher
mass er mit leeren Parametern etwas anderes als der Techniker vor Ort (die
DNS-Pruefung fragte "1 von 1 Servern", weil der Vergleichsserver fehlte).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|||
| 7d79358c02 |
Geraete-Aktionen nach Geraetetyp sortieren statt sie zu verstecken
"SNMP-Switch" stand an jeder IP-Kamera und erzeugte dort zuverlaessig eine Messung "nicht messbar" im Kundenprotokoll - eine Zeile, die niemandem hilft und den Abnahmebeleg verwaessert. Bewusst KEIN hartes Filtern: Device.deviceType ist freier Text aus zwei unabhaengigen Quellen (Kotlin guessDeviceType, TS typeFromMdns) und wird aus MAC-Hersteller, mDNS-Diensten und offenen Ports geraten. Ein managed Switch, der als "Linux-Geraet" durchgeht, verloere beim Filtern ausgerechnet SNMP - schlimmer als die ueberfluessige Zeile, die wir loswerden wollen. Unpassende Werkzeuge stehen deshalb nachrangig (kleiner, blasser, mit Titel-Hinweis) hinter den passenden, statt zu verschwinden. Leerer oder unbekannter Typ: alles gleichrangig, nie weniger. Die SNMP-Liste ist absichtlich grosszuegig (Switch, Router, Gateway, NAS, Drucker, Server, USV, Accesspoint, Firewall) - Drucker sind in der Praxis die haeufigste SNMP-Quelle ueberhaupt. tools/pruefe-geraeteaktionen.mjs rechnet 13 Faelle nach und prueft dabei zwei Zusicherungen: die erwartete Einsortierung UND dass kein Werkzeug verschwindet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
|||
| 460b85d708 |
Internet-Kette: Anschluss, Gateway, Namensaufloesung und HTTPS in einem Lauf
Die haeufigste Aussage beim Kunden ist "Internet geht nicht". Bisher musste der Techniker Ping, Traceroute und Browser einzeln bedienen und selbst schlussfolgern, welches Glied hakt. Das Werkzeug misst alle vier Stufen in einem Lauf und benennt das Fehlerglied. Neue native Methoden: dnsResolve (System-Resolver; die Grenze - Server nicht waehlbar, Cache dazwischen - steht im Code und im Ergebnis) und httpsCheck. Bei httpsCheck ist instanceFollowRedirects=false keine Feinheit, sondern der Kern: ein Gaeste-WLAN beantwortet jede Anfrage mit einer Umleitung auf sein Portal. Wer ihr folgt, bekommt ein sauberes 200 und meldet "Internet in Ordnung", obwohl ohne Anmeldung nichts geht. linkInfo liefert zusaetzlich NET_CAPABILITY_VALIDATED und _CAPTIVE_PORTAL - Androids eigenes Urteil, das uns keine einzige Messung kostet. Drei Entscheidungen fuer die Ehrlichkeit der Aussage: 1. Die Kette bricht nicht ab. Sehr viele Router beantworten Ping grundsaetzlich nicht - ein Abbruch dort meldete "Gateway tot" bei voellig gesundem Internet. 2. Eine stille Stufe ist kein Fehler, wenn eine spaetere antwortet. Wer eine Antwort aus dem Internet bekommt, hat sein Gateway benutzt. Ergebnis: gruen mit Hinweis statt rot. 3. Anmeldeseite schlaegt Fehlerglied. Sonst stuende im Kundendokument "Kein Internet - HTTPS antwortet nicht", obwohl der Techniker nur auf "Anmelden" tippen muss. Beim Pruefen aufgefallen und korrigiert. Die Bewertung liegt in kette-bewertung.ts ohne jeden Laufzeit-Import, damit tools/pruefe-kette.mjs sie laden kann: elf konstruierte Faelle gegen von Hand ermittelte Sollwerte, alle korrekt. Der Browser-Mock liefert fuer DNS und HTTPS bewusst nur den Gutfall und beweist nichts - das steht dort auch so. Dabei repariert: tools/pruefe-monitor.mjs importierte eine .mjs-Kopie aus einem /tmp-Sitzungsverzeichnis und lief nach dessen Wegfall nicht mehr, waehrend in der ROADMAP "alle Faelle korrekt" stand. Die Rechnung liegt jetzt in monitor-auswertung.ts, beide Pruefer laden die TS-Datei direkt. Neu in der Debug-Seite: "Internet-Kette pruefen (misst nur, speichert nichts)". Beantwortet vor Ort die erste aller Fragen - kommt das Messgeraet selbst ins Netz? - und ist der einzige Weg, die native Schicht im Emulator zu pruefen, solange die Testinstanz nur HTTP spricht (der WebView blockiert aus der Origin https://localhost jede HTTP-Anfrage, siehe ROADMAP). Im Emulator geprueft: Gutfall (alle vier Stufen mit Messwerten, validated=ja) und Flugmodus (Status "nicht messbar", Fehlerglied Anschluss, ausdruecklich KEINE Aussage ueber das Kundennetz). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
|||
| 6483589592 |
Geraete-Monitor: Auswertung als Messung, drei Rechenfehler vorher behoben
Die Ueberwachung endete bisher mit einem Toast und verschwand — fuer Kunde,
PDF und Server existierte sie nicht (Sitzungen werden nicht synchronisiert).
Damit fehlte ausgerechnet der Nachweis fuer die haeufigste Reklamation
("die Kamera faellt staendig aus"). Genau dafuer wird ueberwacht.
Vor der Auswertung mussten drei Luecken in der Datengrundlage geschlossen
werden. Alle drei haetten das Ergebnis systematisch beschoenigt:
1. Der Startzustand wurde gemessen, aber nicht gemeldet. Ein Geraet, das vom
Anfang bis zum Ende des Termins tot war, hatte NULL Ereignisse — die
Auswertung haette ihm 100 % Verfuegbarkeit ins Kundendokument geschrieben.
Das Plugin erzeugt dafuer jetzt beim Start ein down-Ereignis und setzt
downSince, damit ein spaeteres up eine echte Ausfalldauer bekommt statt 0.
2. Ein beim Beenden noch offener Ausfall wurde nirgends abgeschlossen und
zaehlte gar nicht. stopMonitor liefert jetzt startedAt/endedAt/zustand,
die Auswertung rechnet ihn bis zum Sitzungsende zu.
3. Die Gesamtaussage ist das SCHLECHTESTE Geraet, nicht der Mittelwert — ein
Totalausfall verschwindet sonst zwischen neun gesunden Geraeten.
Ausserdem am Monitor:
- PARTIAL_WAKE_LOCK (12 h Grenze). Der Monitor war der einzige Langzeitpfad
ohne CPU-Sperre; der WifiLock allein haelt nur das Funkmodul wach. Bei
ausgeschaltetem Display streckt Android die Schleife, und es fehlen genau
die Messpunkte, auf denen die Aussage "ueber sechs Stunden stabil" beruht.
- Thread.sleep -> delay(): blockierte den Dispatcher-Thread ueber die gesamte
Wartezeit und nahm ihn parallelen Messungen weg.
- Reisst der Lauf ab (Prozess tot, App beendet), wird trotzdem ein
Teilergebnis gespeichert und als unvollstaendig gekennzeichnet, mit dem
letzten echten Messpunkt als Endzeit. Vorher wurde die Endzeit auf "jetzt"
gesetzt — eine Verfuegbarkeit ueber Stunden auszuweisen, in denen gar nicht
gemessen wurde, waere eine Falschaussage im Abnahmeprotokoll.
- Der Browser-Mock ist jetzt eine echte Zustandsmaschine. Vorher wuerfelte er
je Tick unabhaengig up oder down und erzeugte Folgen wie up,up,down,down,
die es in der Wirklichkeit nicht gibt (ein Ereignis IST ein Wechsel) — eine
Auswertung liess sich damit nicht sinnvoll pruefen.
Dolibarr-Seite gleich mit: die sechs neuen Schluessel in BEIDE Feldtabellen
(netdiagKundenfelder + messfelder.ts). Ohne das stuende im Kunden-PDF nur die
Ampel — der Fehler, der bei der Whitelist schon einmal passiert ist.
Geprueft: neues Werkzeug tools/pruefe-monitor.mjs rechnet sechs konstruierte
Faelle gegen von Hand ermittelte Sollwerte durch, darunter die drei kritischen
(durchgehend totes Geraet -> 0 % statt 100 %, offener Ausfall am Ende,
ein totes unter neun gesunden). Alle korrekt. Danach im Emulator ueber eine
echte Ueberwachung von 59 s: Messung entsteht, alle Felder korrekt beschriftet.
|
|||
| d44c002078 |
Kanalgraph bei vielen Netzen lesbar: Namen entzerrt, Netzauswahl
Eddys Meldung: bei zu vielen Netzen überschreiben sich die Namen; die Netze
müssten "von der Signalstärke nach oben weiter auseinander gezogen werden".
Mit 15 Netzen (Mehrfamilienhaus) nachgestellt und bestätigt.
Ursache: die Wunschhöhe eines Labels hängt am Messwert, und reale Nachbarnetze
liegen fast alle zwischen -65 und -85 dBm — in einem Band von nur ~40 Einheiten
drängten sich zehn und mehr Namen.
Die BLÖCKE lassen sich dafür aber nicht verschieben: ihre Höhe IST der
Messwert. Ein Netz mit -70 dBm auf Höhe -50 zu zeichnen hätte die dBm-Achse
zur Falschaussage gemacht — genau der Fehler, der beim Umbau von Parabel auf
Trapez behoben wurde. Verschoben wird deshalb nur der NAME:
- Vom Wunschplatz aus wird abwechselnd nach oben und unten die nächste freie
Zeile gesucht (bis 12 Stufen). Zwei Namen stören sich nur, wenn sie sich
auch waagerecht überlappen — nebeneinanderliegende Netze behalten ihre Höhe.
Vorher: nur 4 Versuche nach oben, danach fiel das Label ersatzlos weg.
- Eine dünne Linie in der Netzfarbe führt vom versetzten Namen zum Scheitel
seines Blocks, damit die Zuordnung eindeutig bleibt.
- Findet ein Name gar keinen Platz, wird das ausgewiesen ("15 Netze · 3 ohne
Namen") statt stillschweigend wegzufallen.
Netzauswahl (Eddys Vorschlag): Kästchen je Netz in der Liste, dazu die
Schnellwahl "nur starke" (eigenes Netz + alles über -70 dBm) und "alle".
Ein Hinweisband nennt die Zahl der ausgeblendeten Netze und bietet
"Alle zeigen" an.
WICHTIG dabei: Das Ausblenden betrifft ausschließlich die Zeichnung.
Kanalempfehlung und Warnregeln rechnen weiter mit ALLEN sichtbaren Netzen —
sonst würde das Ausblenden eines starken Störers dessen Kanal plötzlich als
"frei" empfehlen. Im Emulator gegengeprüft: nach "nur starke" (11 von 18
ausgeblendet) blieben die Empfehlungswerte 0,83 / 1,33 / 1,38 unverändert.
Demodaten auf 18 Netze erweitert und ein Render-Szenario "dicht24" (15 Netze)
ergänzt, damit sich diese Dichte auch ohne echten Empfang prüfen lässt.
Gerendert, angesehen und zusätzlich im Emulator auf dem Gerät geprüft.
|
|||
| 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. |
|||
| d74a89b2d5 |
WLAN-Diagramme lesbar gemacht: dBm-Achse, 5-GHz-Aufteilung, Farben je Netz
Eddys Rückmeldung nach dem ersten Einsatz auf dem Handy: das zweite Diagramm
ergibt keinen Sinn, Zahlen überlappen, und die Signalstärke ist in den
Diagrammen nirgends ablesbar. Alle drei Punkte bestätigt und behoben.
Ursache (nachgerechnet, nicht geraten): die 745 MHz des 5-GHz-Bandes wurden
in dieselbe Breite gequetscht wie die 80 MHz des 2,4-GHz-Bandes — 9,3-fach
schlechtere Auflösung, 8,6 statt 80 Einheiten je 20-MHz-Kanal. Bei 8,6
Einheiten Tick-Abstand und 12,6 Einheiten Breite einer dreistelligen Zahl ist
Überlappung unvermeidbar ("3640444852566064"). Der vorhandene Tick-Filter
filterte nachweislich 0 von 25 Ticks weg, weil er nur gegen den
Frequenzbereich prüfte, in dem ohnehin alle Kanäle liegen.
Kanalgraph:
- 5 GHz in die regulatorischen Blöcke geteilt (UNII-1/2A, UNII-2C, UNII-3),
ein gemeinsamer Maßstab je Band -> 20-MHz-Kanal jetzt ~24 statt 8,6
Einheiten breit, alle Kanalzahlen einzeln lesbar.
- Leere Blöcke werden gezeichnet ("frei — keine Netze") statt weggelassen.
Weglassen ließe das Band voller aussehen als es ist und versteckt genau
die gesuchte Antwort: wo ist noch Platz.
- Trapez statt Parabel — die Fläche zeigt den tatsächlich belegten
Frequenzbereich. Bei der Parabel lag nur die Spitze auf dem Messwert; mit
dBm-Achse wäre alles außer der Bogenmitte falsch abgelesen worden.
- Kanalbreite über centerFreq0 statt Primärfrequenz: ein 80-MHz-Netz auf
Kanal 36 wurde sonst um 5180 statt 5210 gezeichnet, Nachbarkanäle sahen
fälschlich frei aus.
- Farbe je Netz (stabil über BSSID-Hash), gleiche Farbe in Graph, Zeitverlauf
und Netzliste. Vorher verschmolzen überlappende graue Blöcke zu einer Fläche.
- Belegte Kanalnummern hell, freie gedämpft; SSID von hinten gekürzt (sonst
heißen alle FRITZ!Box-Netze gleich); gekappte Blöcke werden markiert.
dBm-Achse (neue gemeinsame Komponente RssiAxis, für Kanalgraph UND
Zeitverlauf — damit sie konstruktiv nicht auseinanderlaufen können):
- feste Skala -95..-30 dBm, 2,0 Einheiten je dB (glatte Rasterlinien),
beschriftet -30/-50/-70/-90, Einheit "dBm", Praxiszonen grün/rot.
- Bewusst "Empfangspegel", nicht "Sendestärke": die Achse zeigt den Pegel am
Standort des Handys, nicht die Leistung des Routers.
- Schrift 7 -> 9/10 (war ~7,6 CSS-px, unter der Lesegrenze), Kontrast der
Achsenbeschriftung von zinc-600 (2,29:1, unter WCAG-Minimum) auf zinc-200/300.
Momentaufnahme wird jetzt synchronisiert: sie lag bisher nur lokal und kam nie
im Protokoll auf dem Server an, obwohl sie genau dafür gemacht wird. Landet
jetzt zusätzlich als Messung (tool='wifikanal') in Sync und PDF.
Klartext-Fazit über dem Diagramm ("Dein Netz: Kanal 6 · -48 dBm (sehr gut) ·
2,4 GHz freister Kanal: 1") — unter Zeitdruck schneller als jedes Diagramm.
Neu: tools/render-chart.mjs rendert die echten Svelte-Komponenten
serverseitig zu SVG/PNG, inklusive Randfällen (1 Netz, 25 Netze, 5 Netze auf
einem Kanal, Bandränder, leeres Band, Zeitverlauf mit Aussetzer). Das ist die
Lehre aus dem Fehler: in Phase 4 wurde die Chart-Mathematik nur durchgerechnet
(keine NaN, nichts außerhalb des Zeichenbereichs) und daraus geschlossen, das
genüge. Rechnerisch korrekt heißt nicht lesbar — ein Diagramm muss man ansehen.
Weiterhin offen: der Emulator hat keine WLAN-Hardware und liefert immer 0
Netze. Alle Diagramme sind mit realistischen Testdaten gerendert und geprüft,
aber nicht mit echtem Empfang auf dem Handy.
Details: ROADMAP_UMSETZUNG.md Phase 4 / Nachbesserung
|
