TP17.1 zieht ins Netz-Projekt zurueck, Runbook statt Uebergabe

User-Entscheid: das Arbeitspaket wird im Netz-Projekt gesteuert, nicht im
HA-Projekt. HA ist Betroffener (Entity-Bruch), nicht Eigentuemer -- die
Entscheidung ist eine Funk- und Netzentscheidung.

Aus der Uebergabe wird docs/tp17.1-shelly-gen4-funkmigration-runbook.md, auf den
heutigen Stand gebracht: die drei Wege (Zigbee offiziell / Thread abwarten /
Thread per Dritt-Firmware) als Vergleichstabelle, die Geraetebefunde, die
Zigbee-Kanalplanung gegen ap1 ch1 und ap2 ch11 als Rechenschritt, und die
Verzahnung mit der parallel laufenden PSK-Rotation inkl. der s1/s2/s3-Falle.

Titel geaendert: "Thread ODER Zigbee". Der reine Thread-Zuschnitt haette den
einzigen heute verfuegbaren Weg ausgeschlossen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -370,15 +370,19 @@ 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
+### TP17.1 — Shelly Gen4 raus aus dem WLAN (Thread oder Zigbee) ▸ 🔜 **ENTSCHEIDUNGSREIF (2026-08-23)** — 📋 `docs/tp17.1-shelly-gen4-funkmigration-runbook.md`
 > **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.
+> 📋 **Runbook: [`tp17.1-shelly-gen4-funkmigration-runbook.md`](tp17.1-shelly-gen4-funkmigration-runbook.md)**
+> — Bestand, die drei Wege im Vergleich, Ablauf, Abnahme, Verzahnung mit der PSK-Rotation.
+> 📌 **Wohnort ist das Netz-Projekt (User-Entscheid 2026-08-23).** Eine erste Fassung lag kurz im
+> HA-Projekt (`ha-xstate`); sie ist dort **entfernt**, damit es keine zweite Wahrheit gibt. **HA ist
+> Betroffener, nicht Eigentümer:** die Entities brechen, aber die Entscheidung ist eine Funk- und
+> Netzentscheidung. *(Der Titel sagt jetzt „Thread **oder Zigbee**" — der ursprüngliche
+> Thread-Zuschnitt hat den heute tatsächlich verfügbaren Weg ausgeschlossen, s. Nachtrag unten.)*
 
 - 🔀 **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

docs/tp17.1-shelly-gen4-funkmigration-runbook.md

@@ -0,0 +1,175 @@
+# TP17.1 — Shelly Gen4 raus aus dem WLAN (Thread oder Zigbee) · Runbook
+
+> **Status 2026-08-23:** 🔜 **entscheidungsreif, nicht startbereit.** Schritt 0 ist eine Abwägung,
+> kein Flash. Steuerung/Scope: [`teilprojekte.md`](teilprojekte.md) → **TP17.1**.
+> **Kein Netz-Eingriff bisher**, alle Zahlen hier sind read-only erhoben.
+>
+> 📌 **Wohnort dieses Arbeitspakets: das Netz-Projekt** (User-Entscheid 2026-08-23). Eine erste
+> Fassung lag kurzzeitig im HA-Projekt (`ha-xstate`) — sie ist dort **entfernt**, damit es keine
+> zweite Wahrheit gibt. HA ist Betroffener, nicht Eigentümer: die Entities brechen, aber die
+> Entscheidung ist eine Funk- und Netzentscheidung.
+
+## Das Ziel (Christophs Begründung, dreiteilig)
+
+1. **Die PSK-Rotation wird billiger.** Jedes Gerät, das den Funk wechselt, fällt aus der Rechnung.
+2. **Mesh-Stabilität** — netzgespeiste Geräte sind immer Router-Knoten, nie Sleepy End Devices.
+3. **Ruhe im WLAN.** 26 der 27 WLAN-Clients des ganzen Netzes hängen auf `dirtyvader-iot`.
+
+⚠️ **Punkt 1 trägt nur teilweise.** Kandidaten sind **10 Geräte**; danach blieben grob **16** auf dem
+IoT-SSID. Die Rotation wird **kleiner, nicht überflüssig** — und Gen3 kann nie folgen, dort fehlt
+802.15.4. *(Seit 2026-08-23 ist das ohnehin entschärft: Rotation und Funkmigration laufen **parallel**,
+s.u.)*
+
+---
+
+## Bestand (live 2026-08-23, `mcp/shelly/discover.py`, read-only)
+
+**22 von 26 Shellys erreichbar** auf VLAN30, **alle auf Firmware 2.0.0**:
+
+| Gen | Anzahl | Modelle |
+|---|---|---|
+| **Gen4** | **12** | 9× `S4SW-002P16EU` (2PM) · 1× `S4SW-001P16EU` (1PM) · 2× `S4PL-00416EU` (Power Strip) |
+| Gen3 | 8 | `S3PL-00112EU`, `S3PL-30116EU` |
+| Gen2 | 2 | `SPDM-002PE01EU`, `SNDC-0D4P10WW` |
+
+**Die 12 Gen4:** s25 bad_lichtschalter `.205` · s20 kueche_steckdosen2 `.206` · s21 kueche_steckdosen4
+`.207` · s12 dieleug_steckdosen `.219` · s16 wohnzimmer_steckdosen `.223` · s17 bad_steckdosen `.224` ·
+s18 kueche_steckdosen1 `.225` · s19 kueche_steckdosen3 `.226` · s26 bad_luefter `.233` *(alle 2PM)* ·
+s22 kueche_steckdose3-2 `.202` *(1PM)* · **s9 wohnzimmer_sideboard `.216`** und **s13
+arbeitszimmer_technik `.220`** *(Power Strip)*.
+
+**Nicht erreichbar (4):** `s1`/`s2`/`s3` (weihnachten_*, saisonal ausgesteckt — **in HA gar nicht
+eingebunden**) und **`s4 kueche_mikrowelle`** — der einzige, den auch HA als `unavailable` führt.
+Hängt hinter Metall bei **RSSI −93 dBm**, Generation unbekannt. **Falls Gen4: bester Pilot überhaupt**,
+denn 802.15.4 kommt dorthin, wo 2,4-GHz-WLAN scheitert.
+
+---
+
+## 🔴 Die Firmware-Lage — der Kern der Entscheidung
+
+**Direkt an den Geräten erhoben** (`Shelly.CheckForUpdate`, read-only, 2026-08-23):
+
+| | Befund |
+|---|---|
+| Stable | **2.0.0 überall — für kein Gerät ein stabiles Update** |
+| Beta | `2.0.1-beta1`, Build 2026-08-19, für alle inkl. Gen3 |
+| **Alt-Varianten (nur Gen4)** | `S2PMG4ZB` · `S1PMG4ZB` · `PowerStripZB` — jeweils **„with Zigbee"** |
+| Gen3 | **kein `alt`-Eintrag** → Alternativfunk ist Gen4-only |
+
+**Thread gibt es von Shelly heute nicht.** Die offizielle Linie ist **„wird evaluiert"** (Stand Juli
+2026, genannter Engpass: **Flash-Platz**), kein Release-Datum. Was im Mai 2026 als „Thread für Gen4"
+durch die Presse ging, war die **Dritt**-Firmware.
+
+🎯 **Der wichtigste Nebenbefund:** Shelly liefert alternative **Funk**-Firmware über den **normalen
+Update-Kanal**, nicht über einen Bastelpfad. Eine Thread-Variante erschiene mit hoher
+Wahrscheinlichkeit **genau dort** als weiterer `alt`-Eintrag. ⇒ **Frühindikator statt Warten auf
+Pressemeldungen:** `Shelly.CheckForUpdate` auf einem Gen4 pollen und auf einen `…MT`/Thread-Eintrag
+warten.
+
+### Die drei Wege im Vergleich
+
+| Weg | Deckt ab | Preis | Reife |
+|---|---|---|---|
+| **(A) Zigbee, offiziell — heute verfügbar** | **10 der 12** (2PM, 1PM, Power Strip) | Entity-Bruch (Shelly-Integration → Z2M); 2,4-GHz-Kanalplanung nötig | Hersteller-Firmware, offizieller Kanal, **keine** Garantie-/Cloud-Frage |
+| **(B) Thread, offiziell — warten** | offen | nur Wartezeit | existiert nicht; „wird evaluiert", Flash-Platz als Engpass |
+| **(C) Thread, Dritt-Firmware — heute möglich** | 10 der 12 via [hencou](https://github.com/hencou/shelly_gen4_matter_module) *(die [automatous-io](https://github.com/automatous-io/shelly-1-gen4-matter-thread)-Variante deckt hier **0** ab)* | **Garantie + Cloud + offizielle OTA weg**; Rückweg nur mit **UART-Vollbackup je Gerät**; PM-Kalibrierung Platzhalter; Test-VID | nur *Shelly 1 Gen4* auf echter Hardware verifiziert, andere Profile **ungetestet** |
+
+**Die zwei `S4PL-00416EU` (s9, s13) deckt keiner der Wege ab** — sie bleiben im WLAN.
+
+💡 **Empfehlung, falls gefragt: (A) prüfen, bevor (C) erwogen wird.** Zigbee erfüllt **alle drei Ziele
+oben** — heute, mit Hersteller-Firmware, ohne Garantieverlust, ohne UART-Backup. Zigbee2MQTT läuft
+bereits als **LXC 112 (`10.40.20.106`, `z2m25`)**. Was vorher zu klären ist:
+- **(a) Rückrollbarkeit:** Ist der Wechsel des Funkstacks so zurückrollbar wie ein normales Update?
+  Das ist ein anderer Vorgang als ein Versionssprung — vor dem ersten Gerät klären.
+- **(b) Kanalplanung:** Zigbee und WLAN teilen sich 2,4 GHz. Ohne Plan gegen `dirtyvader-iot`
+  (**ap1 ch1 / ap2 ch11**) tauscht man Funklast gegen **Funkstörung**. Zigbee-Kanäle 15/20/25 liegen
+  zwischen bzw. über den WLAN-Kanälen — das ist der Rechenschritt, nicht der Bauchentscheid.
+- **(c) Entity-Bruch:** derselbe wie bei Matter. Er ist der Preis jedes Funkwechsels, nicht ein
+  Argument für einen bestimmten Weg.
+
+---
+
+## Vorbedingungen aus dem Netz (stehen bereits, nur für den Thread-Weg relevant)
+
+- ✅ **Thread-Border-Router läuft**, ~30 Matter-Knoten produktiv (OTBR auf demselben Host wie HA).
+- ✅ **Commissioning-Pfad 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.
+- 🔴 **Nötig ist der Umweg, weil TP12.1 offen ist:** zwischen VLAN10 (iPhone) und VLAN20 (Border
+  Router) wird **kein IPv6 geroutet** → Commissioning-Etappe 2 bricht ab. Und `ble_proxy` ist
+  wirkungslos, seit der ESP32-BT-Proxy ausgeschlossen wurde (User 2026-08-22).
+  ⇒ **Jedes weitere Thread-Gerät zahlt diesen Umweg erneut** — das stärkste Argument für TP12.1.
+- ⚠️ **Firewall ist deny-by-default** — ein neuer Dienst über eine VLAN-Grenze braucht eine explizite
+  Regel. Für den **Zigbee**-Weg heißt das: der Pfad Gerät → Z2M (`10.40.20.106`) läuft über den
+  Zigbee-Koordinator, nicht über IP — es entsteht **kein** neuer VLAN-Übergang. Ein Punkt weniger.
+
+---
+
+## Ablauf
+
+**Schritt 0 — entscheiden, nicht flashen.** Weg (A), (B) oder (C). Grundlage ist die Tabelle oben.
+Das ist Christophs Abwägung; sie hängt an Garantie, Rückweg und daran, wie lange er auf (B) warten
+will.
+
+**Schritt 1 — Pilot mit genau EINEM Gerät.** Kandidat: **`s26 bad_luefter`** oder **`s12
+dieleug_steckdosen`** — beide 2PM Gen4, funktional unkritisch, **keine** Verbrauchsmessung im
+Energie-Dashboard. **Nicht** mit einem Küchengerät anfangen (Kühl-/Tiefkühlschrank hängen dort).
+Bei Weg (C) vorher **UART-Vollbackup**, sonst gibt es keinen Rückweg.
+
+**Schritt 2 — HA-Seite bilanzieren, bevor das zweite Gerät drankommt.** Welche `entity_id`s sind neu,
+was zeigt noch auf die alten? `grep` über die HA-Automationen und die FSM-Configs im
+`ha-xstate`-Repo (`machines/*.json`). **Erst wenn der Pilot in HA vollständig verdrahtet ist**, war er
+erfolgreich.
+
+**Schritt 3 — Wellen zu 3–4 Geräten**, nach Raum gruppiert, gleiches Abnahmekriterium.
+
+**Schritt 4 — Zahl zurückmelden:** wie viele Geräte sind aus `dirtyvader-iot` verschwunden. Diese Zahl
+macht die PSK-Rotation planbar.
+
+### Abnahmekriterium
+
+**Pro Gerät ein frischer Knoten im Zielnetz UND eine funktionierende HA-Entity** — nicht die Anzeige
+in einer Tabelle. Im Netz-Projekt hat genau diese Verwechslung einmal **14 Stunden** gekostet: die
+Registration-Table zeigte 25 zufriedene Clients, während keiner davon eine IP bekam.
+
+---
+
+## Verzahnung mit der PSK-Rotation (parallel, nicht nacheinander)
+
+**User-Entscheid 2026-08-23:** beides läuft **gleichzeitig**. Möglich macht das der
+**Passphrase-Override je MAC** in `/interface wifi access-list` (RouterOS 7): neuer PSK aufs Profil,
+noch nicht migrierte Geräte übergangsweise per MAC mit dem alten weiter, danach Liste leeren — **kein
+Flag-Day**.
+
+🔑 **Die eine Regel, die die Parallelität kostenlos macht:** ein Gerät, das ohnehin den Funk wechselt,
+bekommt den **neuen PSK gar nicht** — nur einen Übergangseintrag, und verschwindet später ganz.
+
+⚠️ **Nicht vergessen:** `s1`/`s2`/`s3` sind ausgesteckt und **in HA nicht eingebunden**. Sie kommen
+beim nächsten Einstecken mit dem **alten** PSK zurück — sie gehören auf die Override-Liste, sonst
+stehen sie im Dezember im AP-Mode.
+
+---
+
+## Offene Fragen für die erste Sitzung
+
+1. Ist **`s4 kueche_mikrowelle`** ein Gen4? Falls ja → bester Pilot, größter Gewinn (−93 dBm heute).
+2. Wie viele der 10 Kandidaten sind physisch zugänglich? Unterputz-Module hinter Schaltern zu öffnen
+   ist bei Weg (C) Pflicht (UART), bei Weg (A) nicht.
+3. Bei Weg (A): **welcher Zigbee-Kanal**, gemessen gegen ap1 ch1 / ap2 ch11 — und was sagt der
+   bestehende Z2M-Koordinator dazu, der schon IKEA-Geräte trägt?
+4. 🖨️ **Ungeklärt:** Christoph nennt den **P750W auf VLAN10**, das Gerät sagt **VLAN30**
+   (Reservierung `10.40.30.5` auf `dhcp-v30`, ARP `vlan30`, derzeit aus, last-seen 3d15h) — und
+   `CLAUDE.md` sagt seit 08-08 dasselbe. Geplanter Umzug oder Verwechslung mit dem druckenden Mac
+   (`10.40.10.82`)? **Vor der nächsten Firewall-Regel klären.**
+
+---
+
+## Verweise
+
+- Steuerung: [`teilprojekte.md`](teilprojekte.md) → **TP17.1**, **TP12.1** (IPv6/Matter),
+  Follow-up **PSK-Rotation**
+- Migrationshistorie der Shellys (VLAN1 → VLAN30, 26 Geräte, 0 Fehler) inkl. Anker-Verfahren gegen den
+  AP-Mode-Fallstrick: [`teilprojekte-archiv.md` → TP17](teilprojekte-archiv.md#tp17)
+- Werkzeug: `mcp/shelly/` — `discover.py` (read-only), `migrate.py` (Dry-Run default).
+  ⚠️ **Kein Rotate-Kommando vorhanden**, es bräuchte eine Variante über denselben `set_sta`-Pfad.
+- HA-Seite: `~/dev/ha-xstate` (FSM-Configs `machines/*.json`)