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 <noreply@anthropic.com>

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.<octet>`, 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.
 
 <a id="tp19"></a>
 

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:<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.
@@ -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.)*