TP17.3 angelegt: Shelly-Regression nach der VLAN30-Migration

User-Meldung: der Luefter-Shelly muss doppelt gedrueckt werden, und der Dimmer in
der Diele UG flackert unkontrolliert seit der Migration -- mit eingeschaltetem AP
ist das Symptom weg.

KORREKTUR eines eigenen Fehlbefunds von heute Vormittag: ich hatte den aktivierten
AP auf s23 als vergessenen Anker aus TP17 eingeordnet, der abgeschaltet gehoert.
Er ist Christophs Workaround. Der als "Einzeiler" beschriebene Fix haette eine
funktionierende Reparatur zerstoert. Merkregel dazu festgehalten: ein Zustand, der
nach einem Verfahren uebrig aussieht, kann eine Reparatur sein -- vor dem Aufraeumen
fragen, wozu er da ist, nicht ob er ins Schema passt.

Leithypothese aus dem read-only-Sweep ueber alle 22 Geraete: nicht die WLAN-Config,
sondern eco_mode. Es senkt den CPU-Takt; ein Phasenanschnitt-Dimmer braucht praezises
Nulldurchgangs-Timing, und ein aktiver AP hebt die Energiesparzustaende auf -- das
erklaert genau die Beobachtung "AP an, Symptom weg". s23 ist ein SPDM-002PE01EU
(app ProDimmerx) mit eco_mode=true; s26 hat eco_mode=true bei momentary-Eingang, was
zum verschluckten ersten Tastendruck passt. Gegenprobe: s12 am selben Ort, gleiches
Modell wie s26, eco_mode=false, unauffaellig. Diskriminierender Test in vier Schritten
notiert, reversibel, ein Geraet.

Zwei Nebenfunde aus demselben Sweep:
- Die eco-Politik von 2026-07-13 ist stale und war nie konsistent: drei Geraete haben
  eco an, obwohl sie unter -80 dBm liegen; zwei haben es aus, obwohl sie darueber
  liegen. Die fuer "nach TP3.3" vorgemerkte zweite Evaluation hat nie stattgefunden.
- restart_required=true auf s26 und s12: dort liegt eine geschriebene, nie aktivierte
  Konfigurationsaenderung, seit 21 bzw. 33 Tagen ohne Neustart.

Anker-Sweep gelaufen: s23 ist der einzige Shelly mit aktivem AP, die anderen 21 sind
sauber de-anchored.

5-GHz-Scan nachgeholt: nur drei Fremdnetze, alle <= -83 dBm, das Band ist praktisch
leer. Planungsaussage fuer die zwei neuen APs: im ETSI-Indoor-Band sind bei 40 MHz
genau zwei ueberlappungsfreie Bloecke vorhanden, und beide sind vergeben -- AP drei
und vier muessen ins DFS-Band. Dass DFS hier nutzbar ist, belegt ein Nachbar auf 5500.

DTU: bleibt wie sie ist (User). Sie gehoert zur PV, ihr AP ist deren Konfignetz, die
Messdaten kommen ohnehin ueber -iot. Als bekannter Dauersender auf ch1 dokumentiert,
nicht bekaempft.

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

docs/tp17.1-shelly-gen4-funkmigration-runbook.md

@@ -350,13 +350,29 @@ Migrationsverfahren von 2026-07-13 — dort wurde je Gerät vor dem STA-Write di
 AP-Funktion als Notanker aktiviert und **nach dem Verify wieder abgeschaltet**. Bei s23 ist das
 De-Anchoring **nicht angekommen**. Das Gerät funkt seither doppelt: als **Client auf ch1**
 (`dirtyvader-iot` an ap1, RSSI −56) **und als AP auf ch11**.
-- **Fix ist ein Einzeiler** über den vorhandenen Pfad: `WiFi.SetConfig {"config":{"ap":{"enable":false}}}`
-  bzw. `mcp/shelly/migrate.py deanchor`. ⏸️ **Nicht ausgeführt — nicht beauftragt.**
-- 📌 **Und es ist ein Auftrag an die Abnahme, nicht nur ein Einzelfall:** die anderen 21 Anker sind
-  **nie gegengeprüft** worden. Ein Sweep über alle Shellys (`WiFi.GetConfig` → `ap.enable`) gehört vor
-  die nächste Funkaktion — read-only, eine Minute.
-- Die **DTU** ist derselbe Fall in anderer Farbe (Hersteller-Konfig-AP, der nie abgeschaltet wurde) —
-  ob sie sich abschalten lässt, ist offen.
+- ~~**Fix ist ein Einzeiler**~~ ⏸️ **Nicht ausgeführt — und das war Glück, s. Korrektur unten.**
+
+🔴🔴 **KORREKTUR am selben Tag — ich habe diesen Fund falsch eingeordnet.** Der AP auf s23 ist **kein
+vergessener Anker, sondern Christophs WORKAROUND**: das Gerät (Pro Dimmer 2PM, „Diele UG/Licht")
+**flackert unkontrolliert, seit die Migration daran gearbeitet hat — und mit eingeschaltetem AP ist
+das Symptom weg.** Der Fix, den ich oben als „Einzeiler" beschrieben habe, hätte also eine
+funktionierende Reparatur zerstört. **`ap.enable` auf s23 bleibt an**, bis die Ursache behoben ist.
+➡️ Eigenes Teilprojekt dafür: **TP17.3** in [`teilprojekte.md`](teilprojekte.md) — Leithypothese ist
+**`eco_mode`** (gedrosselter CPU-Takt vs. Nulldurchgangs-Timing eines Phasenanschnitt-Dimmers; ein
+aktiver AP hebt die Energiesparzustände auf und erklärt damit genau die Beobachtung).
+📌 **Merkregel, die das kostet: ein Zustand, der nach einem Verfahren „übrig" aussieht, kann eine
+Reparatur sein.** Vor dem Aufräumen fragen, wozu er da ist — nicht, ob er ins Schema passt.
+⇒ **Der Anker-Sweep bleibt trotzdem sinnvoll** und ist am 2026-08-23 gelaufen: **s23 ist der einzige
+Shelly mit aktivem AP**, alle anderen 21 sind sauber de-anchored. Die Sorge war unbegründet, der
+Einzelfall ist erklärt.
+- ☀️ **Die DTU ist ein anderer Fall — und sie bleibt vorerst, wie sie ist (User 2026-08-23):** sie
+  gehört zur **PV-Anlage**, ihr AP *ist* deren Konfigurationsnetz, und die Messdaten kommen ohnehin
+  über `dirtyvader-iot` an. Ein Weg, den AP abzuschalten, ist nicht bekannt.
+  🔴 **Nicht auf Verdacht daran drehen:** die PV-Datenstrecke ist produktiv und gehört niemandem hier
+  im Netz — ein abgeschalteter Konfig-AP kann die einzige Rückfallebene sein, wenn die DTU je den
+  WLAN-Zugang verliert. **Als bekannter Dauersender auf ch1 dokumentieren, nicht bekämpfen.**
+  *(Falls es je juckt: erst in der Hoymiles-/S-Miles-App nachsehen, ob der AP dort deaktivierbar ist —
+  nicht am Gerät herumprobieren.)*
 
 ### Was das für die Zigbee-Kanalfrage heißt
 
@@ -411,8 +427,26 @@ ist so groß, dass zwei Zellen die Wohnung ohnehin abdecken — die IoT-Geräte
 - vermeidet Selbststörung im vollsten Band,
 - und legt die neue Kapazität dorthin, wo sie tatsächlich fehlt: **5 GHz an den Rändern** (TP25:
   die Redundanz ist der Schwachpunkt, nicht die Abdeckung).
-⚠️ **Vor dem Aufbau messen, nicht danach:** derselbe Scan auf 5 GHz (`cap-wifi1`/`cap-wifi3`) fehlt
-noch — 5 GHz ist das Band, in dem die neuen APs wirklich geplant werden müssen.
+### 5 GHz — gemessen 2026-08-23, das Band ist praktisch leer
+
+| Kanal | Fremdnetz | Signal |
+|---|---|---|
+| 5180 (ch36) | dahoam is dahoam-5G | −89 |
+| 5200 (ch40) | LiwestBB93-5G | −88 |
+| **5500 (ch100, DFS)** | meins.liwest | −83 |
+
+⇒ **Drei Fremdnetze, alle ≤ −83 dBm.** 5 GHz ist hier faktisch unbelegt — die neue Kapazität hat also
+Platz, und der Vorschlag „neue APs als 5-GHz-Schwerpunkt" ist damit auch messtechnisch gedeckt.
+
+🔴 **Aber die Kanäle werden knapp, und das ist die Planungsaussage:** unter ETSI gibt es im
+**Indoor-Band 5180–5240** bei 40 MHz genau **zwei** überlappungsfreie Blöcke — `5180/Ce` (ap1) und
+`5220/Ce` (ap2). **Beide sind vergeben.** Ein dritter und vierter AP muss auf 5 GHz also ins
+**DFS-Band (5500–5700)** ausweichen — dort liegen laut TP25-Analyse **11 zusätzliche Kanäle**, in ETSI
+ohne `/I`-Leistungsbeschränkung.
+✅ **Und DFS ist in dieser Lage nachweislich nutzbar:** der Nachbar `meins.liwest` funkt auf **5500**.
+⚠️ Preis bleibt die CAC-Wartezeit beim Start und ein erzwungener Kanalwechsel im Radar-Fall (30 min
+Sperre). Der TP25-Vorbehalt dagegen („bei Abbruch-Symptomatik unangenehm") ist seit dem Terrassen-Fix
+vom 08-22 **schwächer geworden** — die Abwägung gehört neu geführt, wenn die zwei APs bleiben.
 ---
 
 ## 🔌 UART-Backup: was das praktisch heißt (nur für Weg C nötig)