From d245d10542c49af86118a5fc8a7d929df7a043dd Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 23 Aug 2026 19:30:40 +0200 Subject: [PATCH] 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 --- docs/teilprojekte.md | 109 ++++++++++++++++++++++++++++++++----------- 1 file changed, 83 insertions(+), 26 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 81f8296..9db53fc 100644 --- a/docs/teilprojekte.md +++ b/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 -> nach der VLAN30-Migration — der einzige Punkt mit spürbarem Alltagsschaden) · +> **TP17.1** (Shelly Gen4 raus aus dem WLAN, entscheidungsreif) · ✅ **TP17.3 ERLEDIGT 2026-08-23** +> (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::"), 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 - 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.** +- ✅ **Die Alternativerklärung ist damit erledigt:** der Verdacht auf gerätespezifische Dimmer-Themen + (Leading/Trailing Edge, Kalibrierung, Mindestlast/LED-Treiber) hat sich nicht bestätigt — `eco_mode` + allein genügte. *Nebenbei: die Config dieses Geräts kennt für Phasenan-/-abschnitt ohnehin **keinen** + 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) -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). +#### 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 gelassen**. + `cfg_rev` 91 → 92, `eco_mode=false` gelesen. +2. ✅ Christoph beobachtet: **„licht in diele ug ist jetzt flackerfrei"**. + ⚠️ **Das ist noch kein Nachweis** — mit AP an war es vorher schon flackerfrei. Beide Hypothesen + 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) -- 🟠 **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. +🔴 **Korrektur einer Annahme aus dieser Session:** ich hatte gewarnt, `eco_mode` brauche einen +**Neustart**, um zu wirken, und der Test sei deshalb unvollständig. **Falsch** — das Gerät antwortet auf +`Sys.SetConfig` selbst mit `{"restart_required": false}`. Der Test war richtig formuliert, ein Reboot +des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin **nicht** ausgeführt. +*(Und daraus folgt der wichtigere Schluss: `eco_mode` kann das `restart_required` der 14 Geräte unten +**nicht** verursacht haben.)* + +#### Weitere Funde aus dem Sweep vom 2026-08-23 (read-only, alle 22 Geräte) +- 🔴 **Die eco-Politik ist damit nicht nur stale, sondern WIDERLEGT.** Regel von 2026-07-13 war + „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 - **spürbarem Alltagsschaden**, und damit vor TP17.1 zu priorisieren. +- **Abh.:** keine. **Blockt nichts.** Der Alltagsschaden ist seit 2026-08-23 behoben. + +#### 📌 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."