TP25 Fund F aufgeloest: geraeteseitig, kein Netzfehler

Kollektor am Manager (15-s-Takt, 29 Samples, 28 Clients). Von den drei
Kandidaten fallen zwei, und beide ohne Wartezeit:

- (b) DHCP-lease-time: tot. dhcp-v30 faehrt lease-time=1d, Renew bei
  12h -- kann 5:05 nicht erzeugen. Eine Abfrage, keine Messung.
- (a) periodischer VAP-Re-Apply: tot. Auf genau dem VAP, der angeblich
  alle 5:05 abwirft, standen drei Clients bei 16h51m Uptime, 25 von 28
  ueber 6h. Dafuer braucht es die vier Zyklen nicht -- ein einziges
  Sample mit 16h51m widerlegt einen 5-Minuten-Takt.
- (c) Geraet selbst: bleibt, ist aber nicht pruefbar.

Denn die zwei Fund-F-MACs sind schlicht weg: ARP status=failed, keine
Lease, nicht in der Registration-Table, HA kennt sie nicht. Merkregel
wie beim P750W -- erst pruefen ob das Geraet ueberhaupt da ist, bevor
ein periodisches Trennen als Funk-/Configfehler untersucht wird.

Nebenbefund: einziger Client mit Uptime-Ruecksetzer war der DTU
(54:F2:9F:12:51:F0) auf ap1, 43min Sitzung, bei -52 dBm. Nicht Fund F,
aber echt -- derselbe ESP-Ein-Radio-Mechanismus wie in der Transaktion
TP17.1-dtu-pin-ap2. Gehoert zur Neubewertung des Pins.

Rohdaten: docs/messdaten/tp25-fundf-20260824.log

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -802,7 +802,7 @@ des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin **nicht** au
 - **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.**
 - **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen).
 
-### TP25 — WLAN-Stabilisierung ▸ 🟢 **KERN ERLEDIGT (2026-08-22): Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). Offen nur noch **Fund F** (5:05-Takt IoT) und die Entscheidung **5 GHz auf 20 MHz**. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6
+### TP25 — WLAN-Stabilisierung ▸ 🟢 **KERN ERLEDIGT (2026-08-22): Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6
 > 📚 **Kondensiert am 2026-08-23 (Doku-Session, Punkt F).** Dieser Abschnitt war mit 394 Zeilen
 > 18 % der Datei. Die **Langfassung steht vollständig und unverändert** im Archiv:
 > [`teilprojekte-archiv.md` → TP25 (Langfassung)](teilprojekte-archiv.md#tp25-lang) — Messchronik (A)–(G),
@@ -823,15 +823,58 @@ Bad −82,3/24 %, Küche −82,0/23 %, Terrasse −78,7/19 %. **Fällt ein AP au
 „verbunden, aber tot".** ⇒ Ein **dritter AP ist nach Christophs eigener Randbedingung derzeit NICHT
 begründet** — er kaufte Redundanz, keine Abdeckung. Das ist eine andere Frage und Christophs.
 
-**Offen — nur noch zwei Punkte:**
-1. 🟡 **Fund F — IoT-Clients trennen exakt alle ~5:05 bei gutem Signal** (−59 dBm, vier Messpaare,
-   auf 3 s reproduzierbar → **ein Timer, kein Funk**). Muss **am Manager** nachgemessen werden, die
-   AP-Tabellen sind unter CAPsMAN leer. Kandidaten und der Test, der sie trennt:
-   (a) periodischer VAP-Re-Apply (Fund D war die Ursache → prüfen, ob es nach dem Fix weg ist);
-   (b) DHCP-`lease-time` der beiden MACs (`38:A5:C9:C0:73:1E`, `38:A5:C9:BC:33:31`) gegen die Periode legen;
-   (c) das Gerät selbst mit 5-min-Duty-Cycle → dann bleibt es unverändert.
-   🚫 **Nicht die alte Power-Save-Merkregel wiederbeleben** — die ist am 2026-08-13 als Fehldiagnose
-   zurückgezogen (`ref_wifi_powersave_multicast`).
+**Beide vormals offenen Punkte sind am 2026-08-24 abgearbeitet** — Fund F ist aufgelöst, der
+5-GHz-Umfeldscan gefahren und der Kanalplan für einen dritten AP gerechnet. **Was von TP25 bleibt,
+ist Umsetzung bei Bedarf, keine offene Frage:**
+1. ✅ **Fund F — GEMESSEN UND AUFGELÖST (2026-08-24): kein netzseitiges Phänomen.**
+   Kollektor am **Manager** (`/interface wifi registration-table`, 15-s-Takt, 29 Samples über 7,7 min,
+   28 Clients), Rohdaten `docs/messdaten/tp25-fundf-20260824.log`. Von den drei Kandidaten sind **zwei
+   erledigt, einer bleibt** — und die zwei fielen ohne Wartezeit:
+
+   | Kandidat | Ergebnis | woran es hängt |
+   |---|---|---|
+   | **(b)** DHCP-`lease-time` gegen die Periode | ❌ **tot** | `dhcp-v30` fährt **`lease-time=1d`** → Renew bei 12 h. Kann 5:05 nicht erzeugen. **Eine Abfrage, keine Messung.** |
+   | **(a)** periodischer VAP-Re-Apply | ❌ **tot** | Ein Re-Apply wirft **alle** Clients des VAP gleichzeitig. Auf `cap-wifi4-virtual1` standen zeitgleich **drei Clients bei 16 h 51 min** Uptime, 25 von 28 über 6 h. Mit einem 5-Minuten-Takt ist das unvereinbar. |
+   | **(c)** das Gerät selbst | 🟡 **bleibt** | Der einzige Client, der im Fenster überhaupt neu verband. |
+
+   🔑 **Der entscheidende Punkt an der Beweisführung: dafür braucht es die vier Zyklen nicht.** Ein
+   einziges Sample mit **16 h 51 min Uptime auf genau dem VAP**, der angeblich alle 5:05 abwirft,
+   widerlegt (a) vollständig. Die Fensterlänge begrenzt nur, was man über *abwesende* Geräte sagen kann.
+
+   🔴 **Und genau die sind abwesend: die beiden Fund-F-MACs gibt es gerade nicht.**
+   `38:A5:C9:C0:73:1E` (`10.40.30.178`) und `38:A5:C9:BC:33:31` (`10.40.30.179`) stehen in `/ip arp` auf
+   **`status=failed`**, haben **keine DHCP-Lease**, stehen **nicht** in der Registration-Table und sind
+   **auch HA unbekannt** (kein `device_tracker` zu diesen MACs). ⇒ **Das Phänomen ist an diesen Geräten
+   derzeit nicht reproduzierbar, weil die Geräte weg sind.**
+   📌 **Merkregel — dieselbe wie beim P750W:** bevor ein periodisches Trennen als Funk- oder
+   Konfigurationsfehler untersucht wird, **erst prüfen, ob die betroffenen Geräte überhaupt da sind.**
+   Beim Drucker war die Fehldiagnose „Power-Save", hier wäre sie „VAP-Re-Apply" geworden.
+
+   ⇒ **Fund F wird geschlossen:** was auch immer der 5:05-Takt war, er lag **geräteseitig**, und die zwei
+   betroffenen Geräte sind vom Netz. Netzseitig ist nichts zu tun. **Nicht erneut aufgreifen**, solange
+   `.30.178`/`.179` nicht wieder da sind *und* das Muster erneut gemessen wird.
+
+   🟡 **Nebenbefund mit Substanz — der DTU ist der einzige Wackelkandidat, den es wirklich gibt.**
+   `54:F2:9F:12:51:F0` (DTU/Wechselrichter, auf `cap-wifi4-virtual1` = **ap1**) war der **einzige** Client
+   mit einem Uptime-Rücksetzer: 43 min Sitzung, dann weg für ein Sample, dann wieder da — **bei −52 dBm**,
+   also bei tadellosem Signal. Das ist derselbe Mechanismus, der schon die Transaktion
+   `TP17.1-dtu-pin-ap2` begründet hat: **ein ESP hat EIN Radio, sein eigener AP und die STA-Verbindung
+   teilen sich den Kanal.** Periode hier 43 min, nicht 5:05 — es ist **nicht** Fund F, aber es ist echt.
+   ⇒ Gehört zur ohnehin vorgesehenen Neubewertung des DTU-Pins, sobald der Kanalplan steht (s.o.).
+
+   <details><summary>📜 Ursprüngliche Fund-F-Formulierung (2026-08-22)</summary>
+
+   1. 🟡 **Fund F — IoT-Clients trennen exakt alle ~5:05 bei gutem Signal** (−59 dBm, vier Messpaare,
+      auf 3 s reproduzierbar → **ein Timer, kein Funk**). Muss **am Manager** nachgemessen werden, die
+      AP-Tabellen sind unter CAPsMAN leer. Kandidaten und der Test, der sie trennt:
+      (a) periodischer VAP-Re-Apply (Fund D war die Ursache → prüfen, ob es nach dem Fix weg ist);
+      (b) DHCP-`lease-time` der beiden MACs (`38:A5:C9:C0:73:1E`, `38:A5:C9:BC:33:31`) gegen die Periode legen;
+      (c) das Gerät selbst mit 5-min-Duty-Cycle → dann bleibt es unverändert.
+      🚫 **Nicht die alte Power-Save-Merkregel wiederbeleben** — die ist am 2026-08-13 als Fehldiagnose
+      zurückgezogen (`ref_wifi_powersave_multicast`).
+
+   </details>
+
 2. ⚖️ **Entscheidung 5 GHz auf 20 MHz** (statt heute 20/40) — **✅ 5-GHz-Umfeldscan durchgeführt
    2026-08-24, Empfehlung: NICHT verschmälern, Entscheidung an einen Auslöser hängen.**
    ⚠️ **2,4 GHz NICHT vorschnell drosseln** — dort hängen ~20 IoT-Geräte.