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

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 → 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 (die automatous-io-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 — 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_ids 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 → 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
• 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)