Erster Lauf mit beiden Ping-Strecken (23:30-23:41, per Stopp-Knopf beendet).
TERRASSE, die Frage des Aufbaus:
2026-08-21, ap2 tief: 43 % Verlust, laengste Luecke 20,4 s, -72 dBm
2026-08-22, ap2 auf 2,5 m: 9 % Verlust, laengste Luecke 1,0 s, -69,0 dBm
Gleiches Geraet, gleiche Rolle. 1,0 s liegt unter der Hoerbarkeitsschwelle im
Videocall. Der Dead Spot, der TP25 seit dem 08-20 getragen hat, ist weg.
STRUKTURBEFUND: die Referenz hat in 17 von 21 Raumabschnitten 0 % Verlust --
die Alltagsabdeckung ist ueberall in Ordnung. Der Gegen-AP traegt dagegen fast
nirgends: Schlafzimmer -84,6/38 %, Bad -82,3/24 %, Kueche -82,0/23 %, Terrasse
-78,7/19 %. Faellt ein AP aus, ist die halbe Wohnung "verbunden, aber tot".
Ein dritter AP kaufte damit REDUNDANZ, keine Abdeckung -- nach Christophs
eigener Randbedingung derzeit nicht begruendet.
KORREKTUR zum 22:43-Lauf: "die Kueche ist ein Loch fuer beide APs" gilt nur
fuer die aeusserste Ecke. Hier hat die Referenz in der Kueche 1 % Verlust bei
-71 dBm. Der Unterschied ist der Weg -- der Vorlauf ging ausdruecklich allen
Waenden entlang in die totesten Winkel. Beide Aussagen gelten, sie messen
verschiedene Orte.
Fund E weiter abgestuft: der Sticky-Client vom 08-20 reproduzierte sich nicht
(Treppe: sauberer Wechsel ap2/5G -> ap1/5G, 0 % ueber 57 s). Nicht umsetzen,
bevor ein Sticky-Fall erneut gemessen ist. Ein Lauf widerlegt Fund B nicht,
er zeigt nur, dass es nicht der Normalfall ist.
WERKZEUG: die Auswertung wies die groesste Sonden-Luecke auf der Treppe als
"⚠️ eher Ruhezustand" aus (4,6 s). Das war unser eigener Eingriff -- um
23:35:10 wechselte der Pin, das S22 war 23:35:12-16 abgemeldet. Ein Artefakt
als "Geraet war erreichbar, wollte nur nicht" zu beschriften ist doppelt
falsch. Pin-Wechsel werden jetzt erkannt und als solche benannt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Auswertung liest jetzt beide Geraete und stellt sie je Raum untereinander:
REFERENZ (iPhone, frei) was du an dieser Stelle wirklich hast
SONDE (S22, Gegen-AP) was die Rueckfallebene noch leisten koennte
Damit faellt der Terrassen-Vergleich beim naechsten Lauf von selbst raus, und
die Lesart wird eindeutig: gute Referenz + schlechte Sonde = alles haengt an
EINEM AP; beide schlecht = echtes Loch ohne Rueckfallebene (der Kuechenfall).
Rueckwaertskompatibel: Laeufe ohne walk-ping-iphone.csv/beide-telefone.csv
laufen einspaltig weiter und liefern fuer den Lauf vom 22.8. Ziffer fuer Ziffer
dieselben Zahlen wie vorher. Das Geraet heisst dort "Geraet" -- welches es war,
steht in den Dateien nicht, also wird es auch nicht behauptet.
Drei Fehler, die der Abnahmetest zutage foerderte und die alle den naechsten
Rundgang gekostet haetten:
1. Die Gegen-AP-Automatik war nach dem Start AUS. Wer den Klick vergisst, geht
die ganze Runde mit beiden Telefonen auf DEMSELBEN AP -- im Test genau so
passiert. tp25-runde.sh schaltet sie jetzt scharf; /auto nimmt dafuer ?an=1
(ein Toggle waere falsch: bei schon laufender Konsole haette der Start sie
ausgeschaltet).
2. "Funk da, aber keine einzige Ping-Antwort" erschien als "—", also wie eine
Datenluecke. Beim Test lag das iPhone gesperrt auf dem Tisch: angemeldet mit
-47 dBm und trotzdem stumm. Wer das als Luecke liest, sucht danach ein
Funkloch, das es nicht gibt. Jetzt: "keine Antwort" + "⚠️ Display gesperrt?".
3. Der Aufraeumer meldete "AP-Pin geloest", und danach standen die Regeln
trotzdem am Core. Wettlauf: er loeste den Pin, waehrend die Konsole noch
lief, und deren Automatik setzte ihn binnen zwei Sekunden wieder. Das
Telefon waere nach JEDER Runde gepinnt geblieben. Jetzt erst Konsole toeten,
dann Pin loesen.
Zuletzt: tp25-pin-s22.sh laeuft auf sshpass -e. Damit steht das Router-Passwort
in keiner Kommandozeile mehr -- `grep -rn "sshpass -p" docs/ nautobot/` findet
nur noch die Erwaehnung in teilprojekte.md. Die Rotation kann jetzt kommen.
Abnahme (mehrere echte Laeufe): Automatik meldet EIN, beide Telefone stehen auf
verschiedenen APs, beide werden gepingt, ein Klick auf Stopp beendet alles,
Pin danach "off", kein Prozess uebrig.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beim Bauen der Gegen-AP-Automatik fiel auf, dass die feste AP-Tabelle in
server.py und tp25-gehweg-auswertung.py nicht zum Live-Zustand passt: heute
sind cap-wifi1/2 = ap2 und cap-wifi3/4 = ap1. Der Manager vergibt die Nummern
dynamisch beim Anmelden der CAPs; ap1 hat sich beim Rueckbau auf ether15 neu
angemeldet.
Der erste Schluss daraus war voreilig ("die alten Auswertungen sind
falsch beschriftet"). Die Gegenprobe widerlegt ihn: mit der HEUTIGEN Karte
haette Technik OG am 08-21 von ap1 mit -43 dBm versorgt worden sein -- in dem
Raum, in dem ap2 steht. Die alte Tabelle war zu ihrer Zeit also richtig und
ist erst durch das Umstecken falsch geworden.
Konsequenz, und das ist der eigentliche Fix: eine live nachgeschlagene Karte
auf alte Daten anzuwenden ist nicht die Loesung, sondern derselbe Fehler mit
umgekehrtem Vorzeichen. Die Zuordnung gehoert zum Messzeitpunkt.
- tp25-walk-messung.sh friert sie als ap-map.txt im Laufverzeichnis ein.
- tp25-gehweg-auswertung.py nimmt ausschliesslich diese Datei. Fehlt sie
(alle Laeufe vor heute), bleiben die rohen cap-wifiN stehen, mit lauter
Warnung -- unbeschriftet ist ehrlicher als falsch beschriftet.
teilprojekte.md: TP25 um den Werkzeug-Fund, den neuen Messaufbau (eine Runde
statt zwei) und den Pausenstand ergaenzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ein iPhone mit gesperrtem Display beantwortet ICMP nicht. In der Verlustspalte
sieht das exakt aus wie ein Funkloch, und heute haette es fast zu einem falschen
Befund gefuehrt: 58 Sekunden Ping-Luecke auf der Terrasse -- bei -53 dBm, 275 Mbps
PHY-Rate und weiterlaufenden 3 kbit/s Hintergrundverkehr. Das Geraet war
erreichbar, es wollte nur nicht antworten.
Die Auswertung markiert solche Luecken jetzt (gutes Durchschnittssignal plus hohe
PHY-Rate) und sagt dazu, dass sie NICHT als Funkloch zu lesen sind. Bewertet wird
der Durchschnitt des Abschnitts, nicht sein Minimum -- ein einzelner schwacher
Sample beim Durchgehen darf den Befund nicht kippen.
Dazu die Rohdaten des Gangs mit ap1 am Sideboard.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zweiter Gehweg-Durchgang, diesmal methodisch sauber: Ping vom Core statt vom
Laptop, Konsole auf dem iPhone (Wake Lock haelt es wach, sonst misst man
Ruhezustand), Raumwechsel per Klick markiert.
Das Ergebnis ist eindeutig und macht die Roaming-Geschichte klein. Im ganzen Haus
null Paketverlust -- Technik UG und OG, Diele, Kinder-, Schlaf- und
Arbeitszimmer, Treppe, alle 0 %, und die Uebergaben ap1<->ap2 auf der Treppe
kosten 0,2 s. Auf der Terrasse dagegen 43 % Verlust ueber 162 Sekunden, am Stueck
fehlen 20,4 Sekunden, bei -72 dBm. Dort ist ein Call nicht gestoert, sondern weg.
Die Topologie erklaert es vollstaendig: ap2 steht in Technik OG, das nur ueber
das Arbeitszimmer zugaenglich ist -- zur Terrasse liegen Technik OG,
Arbeitszimmer, Diele OG und die Aussenwand dazwischen.
Das dreht die Massnahmen um. Ein signal-range-Boden (Fund E) wuerde die Terrasse
VERSCHLECHTERN, weil es dort keinen besseren AP gibt, auf den er steuern koennte
-- er wuerde nur rauswerfen. Stattdessen: 5 GHz auf 20 MHz (+3 dB, ein Wort im
Template), dann ap2 von Technik OG in die Diele OG umhaengen, die an Terrasse,
Arbeitszimmer und Treppe grenzt. Kein neuer AP noetig, damit ist auch die
User-Randbedingung erfuellt.
Konsole nachgezogen: Marker werden URL-dekodiert und behalten ihre Gross- und
Kleinschreibung (aus "RAUM=Diele OG" wurde "RAUM%3DDIELE%20OG"), Diele OG ist
ergaenzt, und das Raumraster steht jetzt oben -- ohne JavaScript laedt die Seite
nach jedem Klick neu, und dann muss der naechste Raum ohne Scrollen erreichbar
sein.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pingt der messende Laptop das Telefon an, laeuft der Weg ueber zwei
Funkstrecken -- Laptop -> AP -> Core -> AP -> Telefon. Fehlt dann ein Paket, ist
nicht entscheidbar, welches der beiden Geraete weg war, und genau diese
Trennschaerfe ist der ganze Zweck der Messung. Vom Core aus ist die Strecke bis
zum AP durchgehend Kabel.
Ausloeser war unfreiwillig: das MacBook ist mitten in einem Lauf vom Dock ans
WLAN gewechselt und hat dabei die IP gewechselt -- die Konsole war ploetzlich
nicht mehr erreichbar, und der Ping haette ab da zwei Funkstrecken gemessen.
Das Ping-Protokoll ist jetzt eine CSV (ts_local,seq,ms; leeres ms = Verlust), die
Auswertung liest beide Formate, damit die Laeufe von gestern lesbar bleiben.
RouterOS-Dauern kommen als "3ms441us" oder "529us" und werden entsprechend
geparst.
Eine Falle steckt im Skript-Kommentar: tr puffert blockweise, sobald die Ausgabe
in eine Pipe geht -- die ersten ~130 Zeilen haengen im Puffer und die Datei
bleibt scheinbar leer. Das \r kommt deshalb im Shell-Loop weg, nicht per tr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Gehweg-Messung erzeugte bisher eine Zeitachse, aus der niemand ablesen
konnte, WO es schlecht war -- der teure Abschnitt von gestern liegt bei
"15:07 bis 15:09", und das ist kein Satz, aus dem eine Massnahme folgt.
Die Konsole bekommt deshalb ein Raster mit einem Button je Raum; der aktive Raum
wird hervorgehoben und die Verweildauer mitgezaehlt. Die Liste steht per
TP25_ROOMS in der Umgebung, damit ein fehlender Raum kein Codeeingriff ist.
tp25-gehweg-auswertung.py verbindet die drei Mitschnitte -- Ping aufs Telefon,
Funkwerte vom Manager, Raum-Marken -- zu einer Tabelle mit Signal, Paketverlust
und laengster Luecke je Raum, samt AP, auf dem der Client dort haengt.
Dazu die Lehre aus dem ersten Durchgang, diesmal als Anleitung statt als Fussnote:
die Konsole gehoert waehrend der Messung auf DAS TELEFON. Der Wake Lock haelt das
Display an und das Polling das Geraet wach -- ohne das beantwortet ein iPhone die
Pings verzoegert oder gar nicht, und 44 % Verlust sind Ruhezustand statt Funk.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
