From cdc47ad1381d2934147b173fe43231c9bb941e80 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 23 Aug 2026 07:32:31 +0200 Subject: [PATCH] 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 --- docs/teilprojekte.md | 58 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 55 insertions(+), 3 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index cbf55b9..c9f1920 100644 --- a/docs/teilprojekte.md +++ b/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