TP17.3 geloest: eco_mode war die Ursache der Shelly-Regression

Beide von Christoph gemeldeten Geraete sind repariert:

  s23 dieleug-wohnzimmer_licht (.203, ProDimmer 2PM)
      eco_mode=false, Geraete-AP abgeschaltet
      -> beide Lampenausgaenge flackerfrei, Workaround entfaellt
  s26 bad_luefter (.233, Gen4 2PM)
      eco_mode=false + Reboot
      -> Doppeldruck weg

Der diskriminierende Test lief in der im TP vorgesehenen Reihenfolge: erst
eco_mode aus bei weiter aktivem AP (nicht aussagekraeftig, beide Hypothesen
sagen dort dasselbe voraus), dann AP aus -- und genau die Konstellation, die
vorher geflackert hat, blieb stabil.

Weitere Ergebnisse aus dem Sweep ueber alle 22 erreichbaren Shellys:

- Die RSSI-basierte eco-Politik aus TP17 ist damit nicht nur stale, sondern
  widerlegt. Der Flotten-Entscheid "eco flottenweit aus" haengt jetzt an
  TP17.1, weil er die Sendeleistung von ~20 IoT-Geraeten anhebt und damit
  ins Funkbild von TP25 greift.
- restart_required stand auf 14 von 22 Geraeten, nicht auf 2. Entwarnung:
  Reboot von s26 mit Config-Vergleich davor/danach -- identisch. Kein Geraet
  sitzt auf versteckten Aenderungen.
- Was das Bit gesetzt hat, ist am Geraet nicht rekonstruierbar (169 RPC-
  Methoden, Config-Diff, Geraetelog -- alle drei Wege negativ). Nicht erneut
  untersuchen.
- eco_mode braucht keinen Reboot; das Geraet antwortet selbst mit
  restart_required=false. Eine anderslautende Warnung von mir war falsch.
- AP-Anker-Sweep erledigt: nur s23 hatte einen AP an, kein Rest im Bestand.
- Nebenbefund: alle Shellys ziehen NTP von time.cloudflare.com statt vom
  Core -- statische IPs sehen DHCP-Option 42 nie. Betrifft jedes statisch
  adressierte Geraet im Netz.
- inventory/bf.csv fuehrt s12 noch auf der alten .41.219.

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

docs/teilprojekte.md

@@ -87,8 +87,9 @@ 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 raus aus dem WLAN, entscheidungsreif) · 🔴 **TP17.3** (Shelly-Regression
+> **TP17.1** (Shelly Gen4 raus aus dem WLAN, entscheidungsreif) · ✅ **TP17.3 ERLEDIGT 2026-08-23**
-> nach der VLAN30-Migration — der einzige Punkt mit spürbarem Alltagsschaden) ·
+> (Shelly-Regression: Ursache **`eco_mode`** bewiesen, `s23` + `s26` repariert; der Flotten-Entscheid
+> „eco flottenweit aus" hängt jetzt an TP17.1) ·
 > 🔑 **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
@@ -496,7 +497,7 @@ 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
+### TP17.3 — Shelly-Regression nach der VLAN30-Migration ▸ ✅ **ERLEDIGT (2026-08-23, Folge-Session): beide Geräte repariert, Ursache `eco_mode` bewiesen** — offen nur noch der Flotten-Entscheid (gehört TP17.1) — 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.
@@ -507,6 +508,8 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
   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.)*
+  ✅ **Aufgelöst 2026-08-23:** die Ursache ist behoben, der AP auf `s23` ist **abgeschaltet** und wird
+  nicht mehr gebraucht. Der Workaround hat exakt das getan, was die Hypothese vorhersagte.
 - **Symptome und Geräte:**
   | Gerät | Modell | Symptom |
   |---|---|---|
@@ -518,7 +521,7 @@ Vier Dinge, nicht nur die WLAN-Config: **(1)** STA-SSID/PSK · **(2)** **statisc
 (`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
+#### 🎯 ✅ BESTÄTIGTE URSACHE: **`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.
@@ -529,28 +532,74 @@ RSSI-Politik · **(4)** AP-Anker an/aus.
 - ✅ **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
+- ✅ **Die Alternativerklärung ist damit erledigt:** der Verdacht auf gerätespezifische Dimmer-Themen
-  reines Funkproblem wäre hier unplausibel, was die Hypothese stützt; aber der Pro Dimmer 2PM hat auch
+  (Leading/Trailing Edge, Kalibrierung, Mindestlast/LED-Treiber) hat sich nicht bestätigt — `eco_mode`
-  eigene, dokumentierte Flacker-Themen (Leading/Trailing Edge, Kalibrierung, Mindestlast/LED-Treiber).
+  allein genügte. *Nebenbei: die Config dieses Geräts kennt für Phasenan-/-abschnitt ohnehin **keinen**
-  **Die eco-Hypothese ist die billigste und am schnellsten widerlegbare — deshalb zuerst.**
+  Parameter; Stellschrauben wären nur `warmup`, `range_map`, `gamma`, `min_brightness_on_toggle`
+  gewesen.* Der Link war mit −54 dBm die ganze Zeit sehr gut, ein reines Funkproblem war nie plausibel.
 
-#### Der diskriminierende Test (klein, reversibel, ein Gerät)
+#### Der diskriminierende Test (klein, reversibel, ein Gerät) — ▶️ AUSGEFÜHRT 2026-08-23
-1. `s23`: `Sys.SetConfig {"config":{"device":{"eco_mode":false}}}` — **AP zunächst AN lassen**.
+1. ✅ `s23`: `Sys.SetConfig {"config":{"device":{"eco_mode":false}}}` — **AP zunächst AN gelassen**.
-2. Beobachten (ein Abend reicht, das Symptom war auffällig).
+   `cfg_rev` 91 → 92, `eco_mode=false` gelesen.
-3. Dann **AP aus** (`WiFi.SetConfig ap.enable=false`). **Bleibt es stabil ⇒ `eco_mode` war die Ursache.**
+2. ✅ Christoph beobachtet: **„licht in diele ug ist jetzt flackerfrei"**.
-4. Flackert es wieder ⇒ **AP sofort wieder an**, Hypothese widerlegt, weiter mit Dimmer-Parametern.
+   ⚠️ **Das ist noch kein Nachweis** — mit AP an war es vorher schon flackerfrei. Beide Hypothesen
-5. Danach `s26` analog (nur Schritt 1 + Tastentest).
+   sagen an dieser Stelle dasselbe voraus. *(Merkregel [[feedback_abnahme_wirkung_nicht_anzeige]].)*
+3. ✅ **AP aus** (`WiFi.SetConfig ap.enable=false`) — damit war der Test scharf: `eco_mode=false`,
+   `ap.enable=false`, STA `got ip 10.40.30.203` bei −54 dBm.
+4. 🎯 **ERGEBNIS — Christoph, 2026-08-23: „beide lampenausgänge getestet. funktioniert perfekt, kein
+   flackern."** Genau die Konstellation, die vorher geflackert hat, ist ohne AP stabil.
+   ⇒ **`eco_mode` war die Ursache. Hypothese bestätigt, `s23` repariert.**
+5. ✅ `s26 bad_luefter` analog: `eco_mode=false` gesetzt (`cfg_rev` 18 → 19) **+ Reboot** (s.u.).
+   🎯 **ERGEBNIS — Christoph: „lüfter perfekt."** Der Doppeldruck ist weg.
+   ⇒ **Beide gemeldeten Geräte repariert, beide Symptome durch dieselbe Ursache erklärt.**
 
-#### Zwei weitere Funde aus dem Sweep vom 2026-08-23 (read-only, alle 22 Geräte)
+🔴 **Korrektur einer Annahme aus dieser Session:** ich hatte gewarnt, `eco_mode` brauche einen
-- 🟠 **Die eco-Politik ist stale und war nie konsistent umgesetzt.** Regel von 2026-07-13 war
+**Neustart**, um zu wirken, und der Test sei deshalb unvollständig. **Falsch** — das Gerät antwortet auf
-  „eco **an** bei RSSI ≥ −80, **aus** darunter". Ist-Stand heute:
+`Sys.SetConfig` selbst mit `{"restart_required": false}`. Der Test war richtig formuliert, ein Reboot
-  **gegen die Regel eco AN:** s21 (−89), s20 (−86), s8 (−85) · **gegen die Regel eco AUS:** s12 (−61), s17 (−79).
+des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin **nicht** ausgeführt.
-  Die RSSI-Werte haben sich seit Juli durch TP25/TP28 ohnehin verschoben. **Die in TP17 vorgemerkte
+*(Und daraus folgt der wichtigere Schluss: `eco_mode` kann das `restart_required` der 14 Geräte unten
-  „2. Evaluation nach TP3.3" hat nie stattgefunden** — sie ist hiermit fällig, und zwar als
+**nicht** verursacht haben.)*
-  Grundsatzentscheidung, nicht als Tabelle.
+
-- 🟠 **`restart_required = true` auf `s26` und `s12`** — dort liegt eine **geschriebene, aber nie
+#### Weitere Funde aus dem Sweep vom 2026-08-23 (read-only, alle 22 Geräte)
-  aktivierte** Konfigurationsänderung. Beide laufen seit 21 bzw. 33 Tagen ohne Neustart. Vor jedem
+- 🔴 **Die eco-Politik ist damit nicht nur stale, sondern WIDERLEGT.** Regel von 2026-07-13 war
-  weiteren Schluss auf diesen Geräten: neu starten, sonst misst man einen Zwischenzustand.
+  „eco **an** bei RSSI ≥ −80, **aus** darunter" — sie hat an `s23` **realen Alltagsschaden** erzeugt und
+  war nie konsistent umgesetzt. Ist-Stand des Sweeps 2026-08-23 (22 Geräte, live):
+  **eco AUS:** s7 (−90), s12 (−64), s17 (−76), s18 (−81), s19 (−88) · **eco AN:** alle übrigen 16,
+  darunter s20 (−85) und s21 (−85) — die RSSI-Regel ist an keiner Kante mehr erkennbar. Die Werte haben
+  sich seit Juli durch TP25/TP28 ohnehin verschoben. Die in TP17 vorgemerkte „2. Evaluation nach TP3.3"
+  hat nie stattgefunden.
+  ⇒ **Zu entscheiden ist nicht mehr eine Tabelle, sondern ein Grundsatz: `eco_mode` flottenweit AUS.**
+  Argumente dafür: nachgewiesener Schaden; die Regel wurde nie befolgt; `eco_mode` ist ohne Reboot
+  schaltbar und sofort reversibel; 5 Geräte laufen längst ohne und sind unauffällig.
+  ⚠️ **Was dagegen abzuwägen ist:** eco aus hebt die **WLAN-Sendeleistung** auf ~20 Geräten an — das ist
+  eine Airtime-/Funkbild-Änderung und berührt **TP25** (2,4 GHz ist die knappe Ressource, 26 von 27
+  Clients hängen auf `dirtyvader-iot`). **Nicht nebenbei ausrollen, sondern gebündelt mit TP17.1**, wenn
+  ohnehin alle Shellys angefasst werden — dann ist auch messbar, was es am Funkbild ändert.
+- ✅ **AP-Anker-Sweep erledigt (der offene read-only-Punkt aus der Übergabe):** `WiFi.GetConfig →
+  ap.enable` über alle 22 Geräte. **Nur `s23` hatte einen AP an** (= Christophs Workaround, inzwischen
+  abgeschaltet), die übrigen 21 stehen auf `false`. **Kein Aufräumbedarf, kein weiterer Anker im Bestand.**
+- 🔵 **Nebenbefund, gehört nicht hierher, aber nicht verlieren:** alle Shellys stehen auf
+  `sys.sntp.server = time.cloudflare.com`. Kanonisch ist seit 2026-08-18 **der Core als Zeitquelle**,
+  ausgeliefert per **DHCP-Option 42** — die Shellys haben aber aus TP17 **statische IPs** und sehen die
+  Option nie. Funktioniert (Uhrzeit stimmt, udp/123 aus VLAN30 geht raus), ist aber ein blinder Fleck in
+  der NTP-Vereinheitlichung. **Gleiche Klasse für jedes statisch adressierte Gerät im Netz.**
+- 🔵 **`inventory/bf.csv` ist bei `s12` stale:** dort steht noch `10.40.41.219`, live ist das Gerät auf
+  `10.40.30.219` (migriert). Die drei `weihnachten_*` (s1–s3) sind saisonal stromlos, `s4
+  kueche_mikrowelle` offline — das erklärt 26 Einträge vs. 22 erreichbare.
+- 🟠 **`restart_required = true` — nicht auf 2 Geräten, sondern auf 14 von 22** (Sweep 2026-08-23,
+  Folge-Session): s5, s6, s7, s10, s12, s13, s16, s17, s18, s19, s20, s21, s24, s26. Uptimes 22–41 Tage.
+  ✅ **Entwarnung, empirisch:** `s26` wurde kontrolliert neu gestartet und die Config **davor/danach
+  verglichen** — sie ist **identisch**. Der Flag stand für **keine** abweichende Konfiguration; er ist
+  ein *sticky* Bit, das nur nie zurückgesetzt wurde. **Die Geräte sitzen nicht auf versteckten
+  Änderungen.** Reboots können damit gefahrlos gebündelt mit TP17.1 laufen.
+- 🔍 **Was `restart_required` gesetzt hat, ist am Gerät NICHT rekonstruierbar** — drei Wege zu Ende
+  gegangen: (a) **169 RPC-Methoden** auf `s26`, keine gibt Auskunft über Pending-Zustand; (b) der
+  **Config-Diff über die Gruppengrenze trägt nicht** — die Gen3-Familie `S3PL-00112EU` hat *identische*
+  Configs, davon s6/s7/s10 flagged und s8/s11/s14/s15 sauber; (c) **kein persistentes Gerätelog**
+  (`sys.debug.file_log.enable=false`, `/debug/log` ist ein Live-Stream ohne Ring-Puffer).
+  Ausgeschlossen sind immerhin `matter.enable`, `ble.rpc.enable`, `cloud`, `mqtt`, `ws` (trennen die
+  Gruppen alle nicht) — und **`eco_mode`** (s.o.). *Nicht erneut untersuchen; der Aufwand ist gedeckelt
+  und das Ergebnis negativ.*
 
 #### Scope / Abgrenzung
 - **Gehört hierher:** alles, was die Migration am **Gerät** verstellt hat (eco_mode, statische IP,
@@ -563,8 +612,16 @@ RSSI-Politik · **(4)** AP-Anker an/aus.
 - **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
+- **Abh.:** keine. **Blockt nichts.** Der Alltagsschaden ist seit 2026-08-23 behoben.
-  **spürbarem Alltagsschaden**, und damit vor TP17.1 zu priorisieren.
+
+#### 📌 Was noch offen ist (Stand 2026-08-23, Folge-Session)
+1. ✅ Tastentest `s26` — **erledigt, Doppeldruck weg.**
+2. **Flotten-Entscheid `eco_mode` aus** für die übrigen ~20 Geräte — **gebündelt mit TP17.1** wegen der
+   Funkbild-/Airtime-Wirkung (s.o.). Gehört Christoph.
+3. **`migrate.py` um ein `eco`-Kommando ergänzen**, wenn 2. beschlossen wird — heute gibt es dafür
+   keinen Pfad im Werkzeug, der Sweep lief ad hoc.
+4. Reboots der verbleibenden 13 `restart_required`-Geräte — **gefahrlos** (empirisch an `s26` belegt),
+   deshalb kein eigener Termin, sondern Mitnahme bei TP17.1.
 
 ### 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."