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/teilprojekte.md

@@ -87,7 +87,8 @@ ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
 > 📋 **Offen und ohne Blockadewirkung:** **TP25** (Fund F = 5:05-Takt bei IoT, plus die Entscheidung
 > „5 GHz auf 20 MHz") · **TP16** (CF-Tunnel-HA degradiert, vier tote Alt-Tunnel) · **TP16.2/16.3** ·
 > **TP23 Stufe 2** · **TP24** (DC-USV) · **TP13/TP14.4** (beide mit fertigem Runbook) ·
-> **TP17.1** (Shelly Gen4 → Thread, aktiviert 08-23 — läuft im HA-Projekt) ·
+> **TP17.1** (Shelly Gen4 raus aus dem WLAN, entscheidungsreif) · 🔴 **TP17.3** (Shelly-Regression
+> nach der VLAN30-Migration — der einzige Punkt mit spürbarem Alltagsschaden) ·
 > 🔑 **Rotation des MikroTik-Admin-Passworts** — seit 08-23 bewusst **hinter** TP17.1 eingereiht.
 > Zugeschnittene Sitzungsvorschläge: [`handoff-20260822-naechste-schritte.md`](handoff-20260822-naechste-schritte.md).
 > ✅ **`crs326-core` ist transaktionsfrei** (seit 2026-08-22, geprüft): ein gemeldeter Drift ist ab
@@ -495,6 +496,76 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 - **Was:** je Gerät `Shelly.SetAuth` (User `admin`, realm-individueller `ha1` = sha256("admin:<device-id>:<pw>"), einheitliches Klartext-PW) via `mcp/shelly/migrate.py auth --go`. `SHELLY_DEVICE_PW` liegt in `mcp/shelly/.env` (gesetzt, len 13). Runner + Digest-Auth-Fallback in `_rpc` fertig.
 - **Warum zurückgestellt:** rein kosmetisch/Härtung; **bricht die HA-Shelly-Integration**, bis pro Config-Entry (22×) das Credential neu eingetragen ist → disruptiv, kein Mehrwert im abgeschotteten IOT-VLAN. **Erst nach** dem Netz-Teardown (TP19) neu bewerten.
 
+### TP17.3 — Shelly-Regression nach der VLAN30-Migration ▸ 🔴 **OFFEN, Leithypothese steht (2026-08-23)** — aus TP17 herausgelöst, User-Meldung
+> **User-Meldung 2026-08-23:** „vor einiger zeit hast du an den shellys änderungen vorgenommen. das
+> hatte bei einigen einen bösen seiteneffekt: **lüfter-shelly musste ich doppelt drücken**. der übelste
+> ist jedoch der von **diele ug: seit deinen änderungen spinnt er herum und blinkt wie ein wilder.
+> sobald AP on ist, ist die symptomatik weg.** ich muss vermutlich eh alle shellys neu machen."
+
+- 🔴 **Erste Konsequenz, sofort: der aktivierte AP auf `s23` ist ein WORKAROUND, kein Rest.** Ich hatte
+  ihn beim WLAN-Scan am selben Tag als „übrig gebliebenen Anker aus TP17, gehört abgeschaltet"
+  eingeordnet — **das war falsch**, und es hätte Christophs Notbehelf zerstört. Er ist bewusst an.
+  **Nicht abschalten, bevor die Ursache behoben ist.** *(Merkregel: ein Zustand, der nach einem
+  Verfahren „übrig" aussieht, kann eine Reparatur sein. Vor dem Aufräumen fragen, wozu er da ist.)*
+- **Symptome und Geräte:**
+  | Gerät | Modell | Symptom |
+  |---|---|---|
+  | **s23** `dieleug-wohnzimmer_licht` `.203` | **SPDM-002PE01EU**, app `ProDimmerx` = **Phasenanschnitt-Dimmer** (Diele UG/Licht + Wohnzimmer/Seitenlicht) | „blinkt wie ein wilder", **AP an ⇒ weg** |
+  | **s26** `bad_luefter` `.233` | S4SW-002P16EU (Gen4), `switch:0 in_mode=momentary` | muss **doppelt gedrückt** werden |
+
+#### Was die Migration am Gerät wirklich verändert hat (TP17, 2026-07-13)
+Vier Dinge, nicht nur die WLAN-Config: **(1)** STA-SSID/PSK · **(2)** **statische IP** statt DHCP
+(`ipv4mode=static`, gw/dns `10.40.30.1` — an allen 22 bestätigt) · **(3)** **`eco_mode`** nach einer
+RSSI-Politik · **(4)** AP-Anker an/aus.
+
+#### 🎯 Leithypothese: **`eco_mode`**, nicht die WLAN-Config
+- `eco_mode` **senkt den CPU-Takt und die WLAN-Sendeleistung** — so steht es in TP17 selbst.
+- Ein **Phasenanschnitt-Dimmer** braucht präzises **Nulldurchgangs-Timing**. Ein gedrosselter Takt
+  erzeugt Jitter in genau diesem Timing ⇒ **Flackern**. Das ist s23.
+- **Warum „AP an" heilt:** ein aktiver Access Point muss beaconen, das Funkteil darf nicht in die
+  Sparzustände. Der AP hebt also faktisch den Energiesparbetrieb auf — **er behandelt das Symptom
+  genau dort, wo die Hypothese die Ursache vermutet.** Diese Korrelation ist das stärkste Indiz.
+- **s26:** `momentary`-Eingang + gedrosselter Takt ⇒ die erste Flanke wird verschluckt ⇒ „doppelt drücken".
+- ✅ **Gegenprobe im Bestand:** **`s12 dieleug_steckdosen`** hängt am selben Ort, ist dasselbe
+  Gen4-Modell wie s26 — und hat **`eco_mode=false`**. Es ist unauffällig. *(Kein Beweis, aber die
+  Hypothese überlebt ihn.)*
+- ⚠️ **Was dagegen spricht und geprüft gehört:** s23 hat **−56 dBm**, also einen sehr guten Link — ein
+  reines Funkproblem wäre hier unplausibel, was die Hypothese stützt; aber der Pro Dimmer 2PM hat auch
+  eigene, dokumentierte Flacker-Themen (Leading/Trailing Edge, Kalibrierung, Mindestlast/LED-Treiber).
+  **Die eco-Hypothese ist die billigste und am schnellsten widerlegbare — deshalb zuerst.**
+
+#### Der diskriminierende Test (klein, reversibel, ein Gerät)
+1. `s23`: `Sys.SetConfig {"config":{"device":{"eco_mode":false}}}` — **AP zunächst AN lassen**.
+2. Beobachten (ein Abend reicht, das Symptom war auffällig).
+3. Dann **AP aus** (`WiFi.SetConfig ap.enable=false`). **Bleibt es stabil ⇒ `eco_mode` war die Ursache.**
+4. Flackert es wieder ⇒ **AP sofort wieder an**, Hypothese widerlegt, weiter mit Dimmer-Parametern.
+5. Danach `s26` analog (nur Schritt 1 + Tastentest).
+
+#### Zwei weitere Funde aus dem Sweep vom 2026-08-23 (read-only, alle 22 Geräte)
+- 🟠 **Die eco-Politik ist stale und war nie konsistent umgesetzt.** Regel von 2026-07-13 war
+  „eco **an** bei RSSI ≥ −80, **aus** darunter". Ist-Stand heute:
+  **gegen die Regel eco AN:** s21 (−89), s20 (−86), s8 (−85) · **gegen die Regel eco AUS:** s12 (−61), s17 (−79).
+  Die RSSI-Werte haben sich seit Juli durch TP25/TP28 ohnehin verschoben. **Die in TP17 vorgemerkte
+  „2. Evaluation nach TP3.3" hat nie stattgefunden** — sie ist hiermit fällig, und zwar als
+  Grundsatzentscheidung, nicht als Tabelle.
+- 🟠 **`restart_required = true` auf `s26` und `s12`** — dort liegt eine **geschriebene, aber nie
+  aktivierte** Konfigurationsänderung. Beide laufen seit 21 bzw. 33 Tagen ohne Neustart. Vor jedem
+  weiteren Schluss auf diesen Geräten: neu starten, sonst misst man einen Zwischenzustand.
+
+#### Scope / Abgrenzung
+- **Gehört hierher:** alles, was die Migration am **Gerät** verstellt hat (eco_mode, statische IP,
+  AP-Anker) und was daraus an Fehlverhalten folgt.
+- **Gehört nicht hierher:** die Funkumstellung selbst (**TP17.1**) und das Geräte-Passwort (**TP17.2**).
+- 🔗 **Aber die Verzahnung mit TP17.1 ist der Hebel:** wenn ohnehin **alle** Shellys angefasst werden,
+  ist das der Moment, `eco_mode` **grundsätzlich** zu entscheiden statt gerätweise zu pflegen.
+  Christophs „ich muss vermutlich eh alle shellys neu machen" ist damit nicht Resignation, sondern der
+  effiziente Weg — nur eben **nach** dem Test, nicht davor.
+- **Governance:** Shellys laufen **nicht** über Nautobot GC (kein Netzgerät im GC-Sinn). Änderungen
+  über `mcp/shelly/` bzw. direkte RPC. ⚠️ `migrate.py` hat **kein** Kommando für `eco_mode` — der
+  Sweep-Weg wäre eine kleine Ergänzung über denselben Pfad.
+- **Abh.:** keine. **Blockt nichts** — aber es ist der einzige Punkt in der ganzen Shelly-Familie mit
+  **spürbarem Alltagsschaden**, und damit vor TP17.1 zu priorisieren.
+
 ### TP18 — Souveräner Objektspeicher (Garage, Multi-Site, S3-Cold-Tier) ▸ 🔜 KONZEPT (2026-07-12)
 - **Auslöser:** 9-TB-Syno-Backup-Volume **zu 2/3 voll**; reine Daten ~3 TB, Tendenz steigend, „schlagartiger" Bedarf nicht ausgeschlossen. „Wenn skalieren, dann jetzt Syno-Nachfolger mitdenken."
 - **Kriterien (User-priorisiert):** (1) **keine Fremd-Abhängigkeit / kein Cloud-Lock-in** (Cloud-Opex abschreckend); (2) **Multi-Site BF/FM/DW**; (3) **HA** (Standort-Verlust überlebbar); (4) **billig/teuer trennen** — Variante **„kalt = Objektspeicher, heiß = lokal"** genügt (kein Hot/Cold *innerhalb* des Stores nötig); (5) **horizontal + vertikal skalierbar**; (6) **S3-API als Branchenstandard**, den jedes Backup-Tool spricht.