From d0cb2f0934188e7be34c67b0ee97ca4341a8c015 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 23 Aug 2026 11:57:13 +0200 Subject: [PATCH] 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 --- docs/teilprojekte.md | 73 ++++++++++++++++++- ...p17.1-shelly-gen4-funkmigration-runbook.md | 52 ++++++++++--- 2 files changed, 115 insertions(+), 10 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index c08204a..81f8296 100644 --- a/docs/teilprojekte.md +++ b/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::"), 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. diff --git a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md index 38f0585..04d2e8f 100644 --- a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md +++ b/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)