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)