diff --git a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md index 57a2aa0..a4836b6 100644 --- a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md +++ b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md @@ -74,7 +74,34 @@ warten. | **(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. +🔴 **KORRIGIERT 2026-08-23 (Folge-Session, an allen 12 Gen4 live nachgezählt):** die frühere Aussage +„die zwei `S4PL-00416EU` (s9, s13) deckt keiner der Wege ab" ist **falsch**. Beide bekommen +`PowerStripZB` angeboten, **mit stable-Build 2.0.0** — nicht nur Beta. **Weg (A) deckt 12 von 12 +Gen4-Geräten ab, nicht 10.** + +| Gerät | Modell | Bezeichnung | ALT-Variante | stable | beta | +|---|---|---|---|---|---| +| s9 | S4PL-00416EU | wohnzimmer_sideboard | `PowerStripZB` | 2.0.0 | 2.0.1-beta1 | +| s13 | S4PL-00416EU | arbeitszimmer_technik | `PowerStripZB` | 2.0.0 | 2.0.1-beta1 | +| s22 | S4SW-001P16EU | kueche_steckdose3-2 | `S1PMG4ZB` | 2.0.0 | 2.0.1-beta1 | +| s12 | S4SW-002P16EU | dieleug_steckdosen | `S2PMG4ZB` | 2.0.0 | 2.0.1-beta1 | +| s16 | S4SW-002P16EU | wohnzimmer_steckdosen | `S2PMG4ZB` | 2.0.0 | 2.0.1-beta1 | +| s17 | S4SW-002P16EU | bad_steckdosen | `S2PMG4ZB` | 2.0.0 | 2.0.1-beta1 | +| s18 | S4SW-002P16EU | kueche_steckdosen1 | `S2PMG4ZB` | 2.0.0 | 2.0.1-beta1 | +| s19 | S4SW-002P16EU | kueche_steckdosen3 | `S2PMG4ZB` | 2.0.0 | 2.0.1-beta1 | +| s20 | S4SW-002P16EU | kueche_steckdosen2 | `S2PMG4ZB` | 2.0.0 | 2.0.1-beta1 | +| s21 | S4SW-002P16EU | kueche_steckdosen4 | `S2PMG4ZB` | 2.0.0 | 2.0.1-beta1 | +| s25 | S4SW-002P16EU | bad_lichtschalter | `S2PMG4ZB` | 2.0.0 | 2.0.1-beta1 | +| s26 | S4SW-002P16EU | bad_luefter | `S2PMG4ZB` | 2.0.0 | 2.0.1-beta1 | + +**Kein Gerät bietet eine Thread-/Matter-Variante an** — der Frühindikator oben (`…MT`-Eintrag in +`alt`) ist damit weiterhin negativ. Weg (B) hat sich seit der Ersterhebung nicht bewegt. + +🔎 **Zur Rückrollbarkeit (Blocker (a)):** `OTA.Revert` ist auf **allen 12** Geräten als RPC-Methode +vorhanden, und Shelly liefert beide Funkvarianten über **denselben** Update-Kanal mit stable-Builds — +die Struktur ist symmetrisch angelegt, das Zigbee-Gerät sollte die WiFi-Variante seinerseits als `alt` +führen. ⚠️ **Bewiesen ist der Rundweg damit nicht.** Er lässt sich nur am Pilotgerät beweisen, und +genau das ist die Aufgabe von Schritt 1: **erst zurückflashen, dann weitermachen.** 💡 **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 @@ -636,10 +663,66 @@ nichts** — das ist ein normales Update über den Hersteller-Kanal. 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 1 — Pilot mit genau EINEM Gerät.** ▶️ **DURCHGEFÜHRT 2026-08-23 (Folge-Session) — Flash-Teil ✅** + +🔀 **Christophs Gerätewahl weicht bewusst vom Vorschlag ab: `s9 wohnzimmer_sideboard`** statt s26/s12. +Begründung: **„auf diese steckerleiste habe ich zugriff. die meisten sind aber unterputz."** Das ist +das bessere Kriterium — von den 12 Gen4 sind **nur `s9` und `s13` Steckerleisten**, die anderen zehn +sind Unterputz-Module. `s13` scheidet aus, dort hängt das **NAS** (28 W, live) und der Drucker. +Auf `s9` hängen Apple TV / VU+ / Sonos Arc+Amp / TV — beim Flash **alle vier aus**, also kein Ausfall. +*(Der Preis: `s9` hat Verbrauchsmessung — 2,2 / 0,4 / 16,4 / 14,4 kWh — das Energie-Dashboard braucht +später einen Fix-Lauf. Die Zugänglichkeit wog schwerer.)* + +#### 🎯 Der Mechanismus, live kartiert — drei UNDOKUMENTIERTE RPCs +Die offizielle API-Doku kennt für `alt`-Varianten keinen Parameter, und die +[Support-Seite](https://support.shelly.cloud/en/support/solutions/articles/103000360571-adding-shelly-devices-to-a-zigbee-network) +beschreibt einen **Modus-Umschalter** („Settings → Switch to Matter/Zigbee", zurück per 5 s Knopfdruck). +**Für unsere Modelle stimmt das nicht** — auf der WiFi-Firmware gibt es keinen `Zigbee.*`-Namespace +(`404 No handler`). Es ist ein **Firmware-Wechsel im Zwei-Slot-Modell**. Aus dem JS der Geräte-UI +extrahiert: + +| RPC | Wirkung | +|---|---| +| `Shelly.InstallAlt {app, stage}` | lädt die Alternativ-Firmware in den **inaktiven** Slot und rebootet hinein | +| `Shelly.SetAlternative {name}` | schaltet den Slot um — ⚠️ **auf unseren Geräten nicht vorhanden** | +| `Shelly.ListAlternatives` | 404 auf **beiden** Builds — hier nutzlos | + +#### Was der Flash gekostet und was er erhalten hat +Warntext der Geräte-UI, wörtlich: *„Switching to Zigbee resets all settings (except Wi-Fi). AP will be +disabled — access only via previously configured IP."* Live bestätigt: + +| | | +|---|---| +| ✅ **Überlebt** | WLAN **exakt**: `dirtyvader-iot`, statisch `10.40.30.216` — **das Gerät bleibt über IP erreichbar** · `eco_mode` | +| ❌ **Weg** | `Matter.*` komplett · der AP · **alle Ausgangsnamen** (`apple tv`/`vuplus`/`sonos arc + amp`/`tv` → `None`) · `initial_state` `restore_last` → `off` · `input:*` | +| 🆕 **Neu** | `Zigbee.*`: `StartNetworkSteering`, `GetStatus`, `Get/SetConfig`, `ReadAttr`, `WriteAttr`, `SendCommand`; `zigbee.enable=true` | + +📦 **Vollbackup vor dem Flash liegt im Scratchpad** (`s9-backup-*.json`: Config, Status, Components, +Schedule, Webhook, KVS) — daraus werden Namen und `initial_state` wiederhergestellt. + +#### ✅ Blocker (a) „Rückrollbarkeit" ist geschlossen +Die Zigbee-Firmware bietet ihrerseits `alt: {"PowerStrip": …"with Matter", stable 2.0.0}` an. +**Der Rückweg ist `Shelly.InstallAlt {app:"PowerStrip", stage:"stable"} über das Netz** — kein +5-Sekunden-Knopf, kein Öffnen von Unterputz-Dosen. *(Eine frühere Einschätzung in dieser Session, der +Rückweg sei physisch und die zehn Unterputz-Module damit faktisch Einbahnstraßen, war **falsch** — sie +stammte aus der Support-Seite, nicht vom Gerät.)* ⚠️ Bewiesen ist bisher das **Angebot**, nicht der +vollzogene Rundweg. + +#### 🟠 Eine Beobachtung, die für die Serie zählt +Der erste `InstallAlt` **brach reproduzierbar bei 2 % ab** (`result: null`, kein Fehler, kein Reboot). +Nach `eco_mode=false` auf `s9` lief derselbe Aufruf **glatt bis 100 %** durch (3,92 MB, +`Update succeeded (OK)`). **n = 1, keine bewiesene Kausalität** — aber `eco_mode` senkt die +Sendeleistung, und das Gerät war während des ersten Versuchs wiederholt nicht erreichbar. +⇒ **Empfehlung für die restlichen elf: `eco_mode=false` VOR dem Flash** (fällt ohnehin unter den +Flotten-Entscheid aus TP17.3) — es kostet nichts und beseitigt eine plausible Fehlerquelle. + +#### ⏳ Offen am Pilotgerät +`Zigbee.GetStatus` meldet `network_state: "failed"` — **noch keinem Zigbee-Netz beigetreten.** +Damit sind die vier Ausgänge derzeit **nicht aus HA steuerbar** (alle physisch aus, kein Ausfall). +Nächster Schritt ist der Join **in ZHA** (Entscheid s.o.) — und davor zwingend das **ZHA-Backup** +(Punkt 3 der Vorsichtsliste: genau das fehlte 2024). + +**Bei Weg (C)** wäre vorher ein **UART-Vollbackup** nötig gewesen, sonst gäbe 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 @@ -677,11 +760,15 @@ 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). +1. ✅ **Geklärt 2026-08-23, negativ: `s4 kueche_mikrowelle` ist ein `S3PL-00112EU` = Gen3** + (Modell aus `mcp/shelly/migration-log.jsonl`, Gerät selbst offline hinter Metall). Es gibt für + Gen3 **keine** Alternativfunk-Firmware. **Der erhoffte beste Pilot existiert nicht** — das Gerät + bleibt bei −93 dBm im WLAN und ist damit auch nach TP17.1 der Härtefall. Pilot bleibt `s26` oder `s12`. 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? + *(Z2M `z2m25` auf `10.40.20.106:8080` ist erreichbar, HTTP 200 — geprüft 2026-08-23.)* 4. ✅ **Geklärt (Christoph 2026-08-23): es sind ZWEI Drucker.** Der **P750W ist der Etikettendrucker** und hängt korrekt auf **VLAN30** (`10.40.30.5`). Der **eigentliche Drucker ist ein Brother MFC auf VLAN10** — live bestätigt: `10.40.10.6`, MAC `30:05:5C:78:86:20`