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>