Initial import from bf-network-r6.opencode — opencode migration

docs/tp25-runde-20260822-2330-auswertung.md

@@ -0,0 +1,93 @@
+# TP25 — Rundgang 2026-08-22, 23:30–23:41: der Terrassen-Vergleich
+
+**Rohdaten:** [`messdaten/tp25-runde-terrasse-vergleichbash/`](messdaten/tp25-runde-terrasse-vergleichbash/)
+· erster Lauf mit **beiden** Ping-Strecken (3 065 / 3 067 Antworten), `beide-telefone.csv`,
+eingefrorener `ap-map.txt`, per Stopp-Knopf beendet.
+Vorgänger (Worst-Corner-Runde, 22:43): [`tp25-runde-20260822-auswertung.md`](tp25-runde-20260822-auswertung.md).
+
+---
+
+## ✅ Die Terrasse ist repariert — das Anheben von ap2 auf 2,5 m hat gewirkt
+
+| | 2026-08-21 (ap2 tief) | 2026-08-22 (ap2 auf 2,5 m) |
+|---|---|---|
+| Verlust | **43 %** | **9 %** |
+| längste Lücke | **20,4 s** | **1,0 s** |
+| Signal | −72 dBm | −69,0 dBm ⌀ |
+
+Beide Male dasselbe Gerät in derselben Rolle (iPhone, frei roamend). **1,0 s liegt unter der
+Schwelle, ab der eine Unterbrechung im Videocall hörbar wird** (~2 s). Der Dead Spot, der TP25
+seit dem 08-20 getragen hat, ist damit weg.
+
+⚠️ Einschränkung: unterschiedliche Wege und Standzeiten, kein Laborvergleich. Aber 20,4 s → 1,0 s
+ist zu groß, um Messrauschen zu sein.
+
+Die Rückfallebene dort bleibt dünn: ap1 liefert auf der Terrasse −78,7 dBm und 19 % Verlust.
+
+---
+
+## 🔎 Der strukturelle Befund: das Netz ist gut, die Redundanz ist es nicht
+
+Die Referenz (iPhone, frei roamend) ist in **17 von 21** Raumabschnitten bei **0 % Verlust**;
+der schlechteste Wert im ganzen Haus sind die 9 % auf der Terrasse. Im Alltag ist die Abdeckung
+also in Ordnung — überall.
+
+Der Gegen-AP dagegen trägt fast nirgends:
+
+| Raum | Referenz | Gegen-AP |
+|---|---|---|
+| Schlafzimmer | −68,1 · 4 % | **−84,6 · 38 %** |
+| Bad | −61,8 · 0 % | **−82,3 · 24 %** |
+| Küche | −71,1 · 1 % | **−82,0 · 23 %** |
+| Terrasse | −69,0 · 9 % | **−78,7 · 19 %** |
+| Wohnzimmer | −60,6 · 0 % | −73,9 · 14 % |
+| Kinderzimmer | −59,0 · 0 % | −79,7 · 14 % |
+
+Im UG trägt ap2 durchgehend nur noch 2,4 GHz, im OG erreicht ap1 die Terrasse nur über 2,4 GHz.
+**Fällt einer der beiden APs aus, ist die halbe Wohnung unbrauchbar** — nicht offline, sondern
+im Zustand „verbunden, aber tot".
+
+---
+
+## Korrektur zum Vorlauf: die Küche
+
+Der Lauf vom 22:43 ergab „die Küche ist ein Loch für BEIDE APs" (iPhone 89 s getrennt, S22 57 %
+Verlust). **Das reproduziert sich hier nicht:** die Referenz hat in der Küche **1 % Verlust bei
+−71,1 dBm**. Der Unterschied ist der Weg — der 22:43-Lauf ging ausdrücklich „allen Mauern entlang
+in die totesten Winkel", dieser nicht.
+
+⇒ Richtig ist: **ap1 versorgt die Küche im normalen Aufenthaltsbereich gut**; in der äußersten
+Ecke bricht sie weg, und ap2 kann sie dort nicht auffangen. Beide Aussagen gelten, sie messen
+verschiedene Orte.
+
+---
+
+## Was das für die offenen Punkte bedeutet
+
+**Dritter AP: nach Christophs eigener Randbedingung derzeit NICHT begründet.** „Kein neuer AP,
+solange nicht alles aus den vorhandenen rausgeholt ist" — die Alltagsabdeckung ist gut, der
+Dead Spot ist weg. Ein dritter AP würde jetzt **Redundanz** kaufen, keine Abdeckung. Das ist
+eine andere, teurere Frage, und sie ist Christophs.
+
+**Fund E (`signal-range`-Boden): weiter abgestuft.** Der Sticky-Client-Befund vom 08-20 hat sich
+in diesem Lauf **nicht reproduziert** — auf der Treppe wechselt die Referenz sauber von ap2/5 GHz
+auf ap1/5 GHz, 0 % Verlust über 57 s. Ein Boden bliebe wirkungslos bis schädlich, weil es in den
+schwachen Räumen keinen besseren AP gibt, auf den er steuern könnte. **Nicht umsetzen, bevor ein
+Sticky-Fall erneut gemessen ist.** (Ein Lauf widerlegt Fund B nicht — er zeigt nur, dass es nicht
+der Normalfall ist.)
+
+**5 GHz auf 20 MHz (+3 dB):** die letzte offene Funkmaßnahme. Sie würde vor allem die dünne
+Rückfallebene stärken, nicht die Alltagsabdeckung — die braucht sie nicht mehr.
+
+---
+
+## Werkzeug-Nachtrag
+
+Die Auswertung beschriftete die größte Lücke der Sonde auf der Treppe als „⚠️ eher Ruhezustand"
+(4,6 s). **Das war unser eigener Eingriff:** um 23:35:10 wechselte der Pin von ap1 auf ap2, das
+S22 war daraufhin von 23:35:12 bis 23:35:16 abgemeldet. Ein Messartefakt als „Gerät war
+erreichbar, wollte nur nicht antworten" auszuweisen, ist doppelt falsch — die Auswertung erkennt
+Pin-Wechsel jetzt und schreibt „⚠️ Pin-Wechsel".
+
+Die `jserrors.log` des Laufs enthält nur `Script error.` und einen `window.ethereum`-TypeError —
+das kommt von einer Browser-Erweiterung auf dem Telefon, nicht aus der Konsole. Ohne Belang.