TP17.1: Geraete befragt -- kein Thread-Update, aber offizielle Alt-Firmware (Zigbee)

Shelly.CheckForUpdate ueber die Flotte (read-only): stable ist ueberall 2.0.0,
fuer KEIN Geraet gibt es ein stabiles Update; beta waere 2.0.1-beta1 (Build
2026-08-19). Entscheidend ist der alt-Block: fuer die Gen4 liefert Shelly
alternative FUNK-Firmware ueber den normalen Update-Kanal -- S2PMG4ZB, S1PMG4ZB,
PowerStripZB, jeweils "with Zigbee". Gen3 hat keinen alt-Eintrag.

Zwei Folgerungen eingetragen:
- Frueindikator statt Pressemeldungen: eine kuenftige Thread-Variante erschiene
  mit hoher Wahrscheinlichkeit genau dort als weiterer alt-Eintrag. Pollen statt
  warten.
- Zigbee ist eine Option, die vorher nicht auf dem Tisch lag: erfuellt alle drei
  Ziele von TP17.1 (raus aus dem WLAN, Mesh, Funkruhe), heute, mit
  Hersteller-Firmware, ohne Garantieverlust und ohne UART-Backup -- und
  Zigbee2MQTT laeuft bereits als LXC 112. Offene Pruefpunkte notiert, u.a. dass
  Zigbee und WLAN sich 2,4 GHz teilen (Kanalplanung gegen ap1 ch1 / ap2 ch11).

Presselage korrigiert: Shellys offizielle Linie ist "wird evaluiert", nicht
"angekuendigt", Engpass ist der Flash-Platz. Die Thread-Firmware, die im Mai 2026
durch die Presse ging, ist die Dritt-Firmware.

Reihenfolge revidiert (User): PSK-Rotation und Funk-Umstellung laufen PARALLEL.
Der Passphrase-Override je MAC macht den Flag-Day ueberfluessig; die Reihenfolge
war nie technisch noetig, nur oekonomisch.

HA-Gegencheck: genau ein Shelly ist offline (s4 kueche_mikrowelle, RSSI -93),
deckungsgleich mit dem Netz-Sweep. s1/s2/s3 (weihnachten) existieren in HA gar
nicht -- sie kommen beim naechsten Einstecken mit dem alten PSK.

Drucker: NICHT stillschweigend auf VLAN10 geaendert. Das Geraet sagt VLAN30
(Reservierung 10.40.30.5 auf dhcp-v30, ARP vlan30, derzeit aus, last-seen 3d15h),
CLAUDE.md sagt seit 08-08 dasselbe. Als offener Klaerungspunkt notiert.

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

docs/teilprojekte.md

@@ -416,7 +416,56 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 - **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**
+- 🔬 **Nachtrag 2026-08-23 (abends) — die Geräte selbst befragt (`Shelly.CheckForUpdate`, read-only).
+  Ergebnis: es gibt heute KEIN Thread-Update, aber die offizielle Alt-Firmware-Schiene existiert — sie
+  liefert bisher ZIGBEE.**
+  | Was | Stand am Gerät |
+  |---|---|
+  | Stable | **2.0.0 auf allen 22** — für **keines** ein stabiles Update verfügbar |
+  | Beta | `2.0.1-beta1` (Build **2026-08-19**) für alle, auch Gen3 |
+  | **Alt-Varianten (nur Gen4!)** | `S2PMG4ZB` „Shelly 2 PM Gen4 **with Zigbee**" · `S1PMG4ZB` (1 PM Gen4) · `PowerStripZB` (Power Strip Gen4) — je stable 2.0.0 + beta |
+  | Gen3 (`S3PL-*`) | **kein `alt`-Eintrag** → Alternativfunk ist eine reine Gen4-Sache, wie erwartet |
+  - 🎯 **Das ist die wichtigste Erkenntnis für die Planung:** Shelly liefert alternative
+    **Funk**-Firmware für Gen4 **über den normalen Update-Kanal**, nicht über einen Bastelpfad. Käme
+    eine Thread/Matter-Variante, erschiene sie mit hoher Wahrscheinlichkeit **genau dort** als weiterer
+    `alt`-Eintrag. ⇒ **Billiger Frühindikator statt Warten auf Pressemeldungen:**
+    `Shelly.CheckForUpdate` auf einem Gen4 pollen und auf einen `…MT`/Thread-Eintrag warten.
+  - 📰 **Presselage (recherchiert 08-23):** Shellys offizielle Linie ist **„wird evaluiert"**, nicht
+    „ist angekündigt" — Stand Juli 2026, mit **Flash-Platz** als genanntem Engpass. Ein Release-Datum
+    gibt es nicht. *(Die Thread-Firmware, die im Mai 2026 als „für Gen4 verfügbar" durch die Presse
+    ging, ist die **Dritt**-Firmware von automatous-io, nicht Shelly.)*
+  - 💡 **Und daraus folgt eine Option, die vorher nicht auf dem Tisch lag: ZIGBEE statt Thread.** Sie
+    erfüllt **alle drei** Ziele von TP17.1 — Geräte raus aus dem WLAN (PSK-Rotation wird billiger),
+    Mesh-Stabilität, Funkruhe im 2,4-GHz-WLAN — und zwar **heute, mit Hersteller-Firmware über den
+    offiziellen Kanal**, also ohne Garantieverlust, ohne UART-Backup, ohne Test-VID. Die Infrastruktur
+    steht bereits: **Zigbee2MQTT läuft als LXC 112 (`10.40.20.106`, `z2m25`)**.
+    ⚠️ **Zu prüfen, bevor das zur Empfehlung wird:** (a) ob die Alt-Firmware genauso zurückrollbar ist
+    wie ein normales Update (Wechsel des Funkstacks, nicht nur der Version); (b) der Entity-Bruch ist
+    derselbe wie bei Matter (Shelly-Integration → Z2M); (c) Zigbee und WLAN teilen sich 2,4 GHz —
+    Kanalplanung gegen `dirtyvader-iot` (ap1 ch1 / ap2 ch11) nötig, sonst tauscht man Funklast gegen
+    Funkstörung. **Das ist die Abwägung, die vor dem Dritt-Firmware-Pfad geführt gehört.**
+- 🩺 **HA-Gegencheck 2026-08-23: genau EIN Shelly ist offline** — `s4 kueche_mikrowelle` (23 Entities
+  `unavailable`). Deckungsgleich mit dem Netz-Sweep, und es ist dasselbe Gerät, das bei **RSSI −93**
+  hinter Metall hängt. **s1/s2/s3 (`weihnachten_*`) existieren in HA gar nicht** — sie sind also nicht
+  „offline", sondern nie/nicht mehr eingebunden; im Inventar stehen sie weiter. ⇒ Für die
+  PSK-Rotation heißt das: **drei Geräte, die niemand vermisst, aber die beim nächsten Einstecken mit
+  dem alten PSK kommen.** Genau dafür ist die Übergangs-`access-list` da.
+- 🖨️ **Korrektur zur Geräteliste auf `dirtyvader-iot`:** der **P750W hängt auf VLAN30, nicht VLAN10**
+  (live 2026-08-23: Reservierung `10.40.30.5` auf `dhcp-v30`, ARP auf `vlan30`, `status=failed`,
+  `last-seen 3d15h` = **derzeit ausgeschaltet**, deshalb nicht unter den 26 assoziierten Clients).
+  ⚠️ Christoph hat am 08-23 „Drucker hängt auf VLAN10" gesagt — **das Gerät sagt etwas anderes**, und
+  `CLAUDE.md` sagt seit 08-08 ebenfalls VLAN30. Entweder ist ein Umzug geplant/gedacht und noch nicht
+  passiert, oder es ist eine Verwechslung mit dem **druckenden Mac** (der ist auf VLAN10). **Nicht
+  stillschweigend angeglichen** — zu klären, bevor jemand daraus eine Firewall-Regel ableitet.
+- 🔀 **Reihenfolge revidiert (User 2026-08-23): PSK-Rotation und Thread-Umstellung laufen PARALLEL.**
+  Sie blockieren einander nicht — der Passphrase-Override je MAC (`/interface wifi access-list`,
+  s. Follow-up) macht den Flag-Day überflüssig: neuer PSK aufs Profil, die noch nicht migrierten
+  Geräte übergangsweise per MAC mit dem alten weiter. **Einzige Regel, damit die Parallelität nichts
+  kostet:** ein Gerät, das ohnehin auf Thread/Zigbee wandert, bekommt den neuen PSK **gar nicht** —
+  es kommt auf die Override-Liste und verschwindet später ganz. *(Die frühere Formulierung „blockt
+  die Rotation" war zu streng; die Reihenfolge war nie technisch nötig, nur ökonomisch.)*
+- **Abh.:** keine harten fürs Netz. **Läuft parallel zur PSK-Rotation** (User-Entscheid 08-23,
+  vorher als Blocker geführt). 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).
 
@@ -785,8 +834,11 @@ 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").** ⏭️ **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.
+  aber erst später").** ⏭️ ~~**Nachgelagert seit 2026-08-23: erst TP17.1, dann rotieren.**~~
+  **Revidiert noch am selben Tag (User): beides läuft PARALLEL.** Der Passphrase-Override je MAC
+  (s.u.) macht den Flag-Day überflüssig, damit war die Reihenfolge nie technisch nötig — nur
+  ökonomisch. Regel für die Parallelität: **ein Gerät, das ohnehin auf Thread/Zigbee wandert,
+  bekommt den neuen PSK gar nicht**, sondern nur einen Übergangs-Eintrag in der `access-list`.
   ⚠️ 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