From c376caed7bff1207a68f3b8514ffb5988dabacf6 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 23 Aug 2026 07:10:19 +0200 Subject: [PATCH] TP17.1 aktiviert: Shelly Gen4 auf Thread -- PSK-Rotation wird nachgelagert User-Entscheid 2026-08-23: das IoT-WLAN-Passwort bleibt vorerst wie es ist. Stattdessen zuerst die Shelly Gen4 auf Matter over Thread umstellen; danach haengen deutlich weniger Geraete am WLAN und die Rotation wird billig. Damit ist die Rotation NACHFOLGER von TP17.1, nicht mehr eigenstaendiger Follow-up. TP17.1 stand seit 2026-07-11 als Projektion im (inzwischen archivierten) TP17. Es hat jetzt wieder offene Arbeit und steht deshalb nach der eigenen Split-Regel wieder vorne in teilprojekte.md. Umsetzung liegt im HA-Projekt: ~/dev/ha-xstate/docs/shelly-gen4-thread-migration.md Bestand live gesweept (mcp/shelly/discover.py, read-only, VLAN30): 22 von 26 erreichbar -- 12 Gen4, 8 Gen3, 2 Gen2, alle fw 2.0.0. Nicht erreichbar: s1/s2/s3 (saisonal) und s4 kueche_mikrowelle (RSSI -93). Recherchiert und als Praemissen-Korrektur eingetragen: Shelly unterstuetzt Matter over Thread OFFIZIELL NICHT und plant es nicht -- Gen4 kann offiziell nur Matter over WiFi, was hier nutzlos waere (Geraet bliebe im WLAN, braeuchte den PSK weiter). Thread nur ueber Dritt-Firmware; das brauchbare Projekt deckt 10 der 12 Geraete ab (Plug S Gen4 faellt raus), kostet Garantie + Shelly-Cloud und hat als Rueckweg nur ein UART-Vollbackup je Geraet. Selbst bei vollem Erfolg blieben 12 Geraete im WLAN -- Gen3 hat kein 802.15.4 und kann nie folgen. Nebeneffekt fuer TP12.1: je mehr Thread-Geraete kommen, desto oefter zahlt man den -infra-SSID-Umweg beim Commissioning. Das ist das erste Argument fuer TP12.1, das nicht an einem einzelnen Fuehler haengt. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte-archiv.md | 11 +++++++ docs/teilprojekte.md | 57 +++++++++++++++++++++++++++++++++++-- 2 files changed, 66 insertions(+), 2 deletions(-) diff --git a/docs/teilprojekte-archiv.md b/docs/teilprojekte-archiv.md index 90f4518..d573077 100644 --- a/docs/teilprojekte-archiv.md +++ b/docs/teilprojekte-archiv.md @@ -868,6 +868,17 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - ✅ **Reservierungs-/Pool-Konvention (User 2026-07-11):** alle Shellys bekommen **statische IP** (`10.40.30.`, gw/dns `.30.1`) **+ in-pool DHCP-Reservierung** als Backup. `pool-v30` auf `.100-.250` erweitert (Reservierungen jetzt in-pool); `set_sta` auf `static=true` umgestellt; s24-Inventar + `.30.204`-Reservierung angelegt. **Vollständiger HA-MAC-Scan:** 2 verpasste Media-Geräte **Apple TV 4K + Philips TV** (aus, → VLAN40) — **vor cudy-Abschuss** VLAN verifizieren; **Apple TV = vmtl. Thread-Border-Router** (TP17.1). **`.41.246/.247 = cudy1/cudy2`** (Teardown-Ziele). Tasmota bestätigt tot. - **Offene Schritte (morgen, „nur noch go", Runbook `docs/tp17-shelly-go-runbook.md`):** die **16 verbliebenen VLAN1-Shellys** (s4–s11, s13, s15, s17, s19–s21, s25, s26 auf `10.40.41.2xx`) per `WiFi.SetConfig`→`dirtyvader-iot` umklemmen (Batch, je Gerät `.30.x` verifizieren) → Geräte-PW setzen → HA/ioBroker-Re-Point → SwitchBot/Tasmota/3. Nicht-Shelly → saisonale s1/s2/s3/s12 beim nächsten Einstecken → cudy-Alt-WLAN abbauen → DNS/Inventar/`ip-plan` nachziehen. - Abh.: SSID/VLAN30 (TP3/TP4 ✅), DHCP-v30 ✅. Verwandt: `project_vlan1_dhcp_incident` (cudy-Rest-Leak), TP5 (IOT-Firewall danach). Memory `project_shelly_migration_tp17`. +- ➡️ **Nachtrag 2026-08-23: die Projektion „TP17.1 — Gen4 auf Thread/Matter" ist keine Projektion + mehr.** Christoph hat sie aktiviert; sie steht als **offenes TP17.1** in + [`teilprojekte.md`](teilprojekte.md), die Umsetzung liegt im HA-Projekt + (`~/dev/ha-xstate/docs/shelly-gen4-thread-migration.md`). Der damals notierte Vorbehalt + „Firmware-Verfügbarkeit + Thread-Border-Router offen" hat sich **halb** aufgelöst: der Border + Router läuft (~30 Matter-Knoten), die **Firmware gibt es von Shelly aber bis heute nicht** — + offiziell ist Gen4 nur Matter *over WiFi*, Thread nur über Dritt-Firmware. Auch der zweite + Vorbehalt gilt unverändert: **Matter = neue Entities**, der Konflikt mit „HA-Entities unverändert" + ist real und in der Übergabe ausgeführt. +- 📊 **Bestandszahl, live 2026-08-23:** 22 der 26 Shellys erreichbar — **12 Gen4**, 8 Gen3, 2 Gen2. + Die „~11 Gen4" aus der Schätzung von 2026-07-11 waren also nah dran. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 544a272..e4e05f2 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) · -> 🔑 **Rotation des MikroTik-Admin-Passworts** (User: „machen wir, aber erst später"). +> **TP17.1** (Shelly Gen4 → Thread, aktiviert 08-23 — läuft im HA-Projekt) · +> 🔑 **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 > jetzt **echt**, nicht beabsichtigt — `python3 nautobot/gc-transaktion.py status`. @@ -369,6 +370,51 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na liefert das Entscheidungskriterium). ⚠️ **Berührt TP5:** der Mesh-Verkehr braucht bei deny-by-default eine explizite `forward`-Zeile — s. TP5 Etappe 2. +### TP17.1 — Shelly Gen4 auf Matter over Thread ▸ 🔜 **AKTIVIERT (User-Entscheid 2026-08-23)** — Umsetzung im HA-Projekt, Übergabe geschrieben +> **User-Formulierung (2026-08-23):** „wir lassen das pwd vorerst wie es ist. wir werden alle shelly +> gen4 auf thread umstellen — neue firmware. das machen wir im ha-projekt. das sehe ich als subpunkt +> zu pwd ändern. der vorteil: wir müssen dann weit weniger geräte umstellen, steigern +> thread-stabilität und bringen zudem mehr ruhe ins wifi." +> +> 📥 **Übergabe liegt im HA-Projekt: `~/dev/ha-xstate/docs/shelly-gen4-thread-migration.md`.** +> Dort steht die Geräte- und HA-Seite (Bestand, Firmware-Lage, Ablauf, Entity-Bruch). **Hier steht +> nur, was das Netz angeht** — und die Reihenfolge-Entscheidung. + +- 🔀 **Die Reihenfolge ist der eigentliche Entscheid:** die **PSK-Rotation** (Follow-up unten) wird + **nachgelagert**, nicht vorgezogen. Begründung des Users: jedes Gerät, das vorher auf Thread + wandert, muss beim PSK-Wechsel nicht mehr angefasst werden. Damit ist die Rotation **Nachfolger** + von TP17.1, nicht mehr eigenständig. *(Sie war nie dringend — Anlass war ein Passwort in einem + Sitzungstranskript, kein Vorfall.)* +- 📊 **Bestand live gesweept 2026-08-23** (`mcp/shelly/discover.py`, read-only, VLAN30): **22 von 26 + erreichbar**, davon **12 Gen4** (9× 2PM Gen4 `S4SW-002P16EU`, 1× 1PM Gen4, 2× Plug S Gen4), 8 Gen3, + 2 Gen2 — alle auf Firmware 2.0.0. Nicht erreichbar: s1/s2/s3 (weihnachten_*, saisonal) und **s4 + `kueche_mikrowelle`** (Metallgehäuse, RSSI −93 — der Härtefall des WLAN-Betriebs). +- 🔴 **Die Prämisse „neue Firmware" trägt so nicht, und das ändert die Rechnung:** **Shelly + unterstützt Matter over Thread offiziell nicht** und plant es nicht. Gen4 kann offiziell nur + **Matter over WiFi** — was hier nutzlos wäre, weil das Gerät im WLAN bliebe und den PSK weiter + bräuchte. Thread geht nur über **Dritt-Firmware** (die ESP32-C6-Hardware kann es). Das brauchbare + Projekt (`hencou/shelly_gen4_matter_module`) deckt 1/1 Mini/1PM/2PM Gen4 ab = **10 der 12** Geräte; + die zwei **Plug S Gen4 fallen raus**. Preis: Garantie und Shelly-Cloud weg, Rückweg nur mit + **UART-Vollbackup je Gerät**, PM-Kalibrierung zunächst Platzhalter. + ⇒ **Selbst bei vollem Erfolg blieben 12 Geräte im WLAN** (8 Gen3 + 2 Gen2 + 2 Plug S + die 4 + ausgesteckten). Die Rotation wird **kleiner, nicht überflüssig** — und Gen3 kann nie folgen, dort + fehlt 802.15.4. **Das ist Christophs Abwägung vor dem ersten Flash, nicht die des Umsetzenden.** +- ✅ **Was netzseitig schon steht und nicht nochmal gebaut werden muss:** Thread-Border-Router läuft + mit ~30 produktiven Matter-Knoten; der **Commissioning-Weg ist erprobt** — temporäre SSID + `dirtyvader-infra` (VLAN20) nach [`matter-pairing-infra-ssid-runbook.md`](matter-pairing-infra-ssid-runbook.md), + am 2026-08-22 mit dem TIMMERFLOTTE bewiesen. `cfg-infra`/`dp-infra`/`sec-infra` stehen dauerhaft am + Manager, das Anlernen ist ein Zweizeiler plus eine Config-Transaktion. +- 🔴 **Der Umweg bleibt nötig, weil TP12.1 offen ist** (kein IPv6-Routing VLAN10↔VLAN20 → Matter- + Commissioning-Etappe 2 bricht ab), und `ble_proxy` ist wirkungslos, seit der ESP32-BT-Proxy + ausgeschlossen wurde. **Je mehr Thread-Geräte kommen, desto öfter zahlt man diesen Umweg** — das + ist das stärkste neue Argument für TP12.1, das bisher nur an einem einzigen Fühler hing. +- **Abnahme (aus TP28 gelernt):** pro Gerät ein **frischer Thread-Knoten und eine funktionierende + HA-Entity** — nicht die Anzeige in einer Tabelle. Ein Gerät, das in Thread hängt und in HA halbtot + ist, ist ein Rückschritt. +- **Abh.:** keine harten fürs Netz. **Blockt die PSK-Rotation** (bewusst). Verwandt: **TP12.1** + (IPv6/Matter — profitiert direkt), **TP25** (jedes Gerät weniger im 2,4-GHz-Band ist Funkruhe), + **TP17** im [Archiv](teilprojekte-archiv.md#tp17) (Migrationshistorie + `mcp/shelly/`-Werkzeug). + ### TP17.2 — einheitliches Geräte-Passwort (Shelly `SetAuth`) ▸ ⏸️ ZURÜCKGESTELLT (Kosmetik, User 2026-07-13) - **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. @@ -734,7 +780,12 @@ den Weg, über den man den Fehler zurücknehmen wollte. weil vorher gemessene Werte wertlos sind. - **TP10 —** DDNS-Auto-Updater für `bf4.emsenhuber.net` (auf dem Core möglich, `device-mode` erlaubt scheduler). - 🔑 **Admin-Passwort der vier MikroTik rotieren (offen seit 2026-08-22, User: „machen wir, - aber erst später").** Anlass: das Core-Passwort ist bei einer Debug-Ausgabe im Klartext in + aber erst später").** ⏭️ **Nachgelagert seit 2026-08-23: erst TP17.1 (Shelly Gen4 → Thread), + dann rotieren** — jedes Gerät, das vorher aus dem WLAN verschwindet, muss nicht angefasst werden. + ⚠️ Der Entscheid betrifft **beide** Passwörter: der **IoT-WLAN-PSK** steht im Klartext im + TP17-Text ([Archiv](teilprojekte-archiv.md#tp17)) und damit auch in der Git-Historie — **bleibt + auf User-Entscheid 2026-08-23 vorerst unverändert**, weil Redigieren ihn nicht aus der Historie + holt und Rotieren heute ~22 Shellys kostet. Nach TP17.1 sind es deutlich weniger. Anlass: das Core-Passwort ist bei einer Debug-Ausgabe im Klartext in ein Sitzungstranskript geraten. Ursache war `sshpass -p`, das es in die **Kommandozeile** schreibt — sichtbar in `ps` und in jedem argv-Trace. `docs/tp6-marker/server.py` ist auf `sshpass -e` umgestellt (Passwort nur in der Umgebung des Kindprozesses); **`docs/tp6-monitor-core.sh` @@ -757,6 +808,8 @@ den Weg, über den man den Fehler zurücknehmen wollte. **TP8** (Identity/802.1X) · **TP11** (Monitoring) · **TP12** (IPv6) · **TP13** (Botschafts-WLANs) · **TP16.2** (Härtung bypass-Dienste) · **TP18** (Garage-Objektspeicher) · **TP20.1** (Vaultwarden → Platform-PG) · **TP23** (DNS-Policy, s. Regel oben). +*(**TP17.1** — Shelly Gen4 → Thread, aktiviert 2026-08-23 — läuft **nicht hier**, sondern im +HA-Projekt `~/dev/ha-xstate`; netzseitig ist nichts zu bauen. Es blockt bewusst die PSK-Rotation.)* *(**TP16.1** stand hier bis 2026-08-17 fälschlich als offen — es ist seit demselben Tag ✅ abgeschlossen und steht unten unter „Durch" (Volltext im [Archiv](teilprojekte-archiv.md#tp16-1)). Nachfolger ist **TP16.3**, das oben unter Follow-ups läuft.)*