admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

TP17.1 Pilot: s9 laeuft auf Zigbee-Firmware -- Weg (A) traegt

Browse Source 
Christoph hat Weg (A) gewaehlt (Zigbee, Hersteller-Firmware) und als Pilot
s9 wohnzimmer_sideboard bestimmt -- nach dem Kriterium physische
Zugaenglichkeit. Das ist das bessere Kriterium: von den 12 Gen4 sind nur s9
und s13 Steckerleisten, die anderen zehn Unterputz. s13 scheidet aus (NAS
und Drucker haengen dort).

Ergebnis: s9 laeuft auf slot=0, app=PowerStripZB, ver 2.0.0.

Korrekturen am Runbook, alle live am Geraet erhoben:

- Deckung ist 12 von 12 Gen4, nicht 10. Die frueher als "von keinem Weg
  abgedeckt" gefuehrten S4PL-00416EU (s9, s13) bekommen PowerStripZB
  angeboten, mit stable-Build.
- s4 kueche_mikrowelle ist ein S3PL-00112EU = Gen3. Der im Runbook erhoffte
  beste Pilot existiert nicht; das Geraet bleibt bei -93 dBm im WLAN.
- Der Wechsel ist KEIN Modus-Umschalter, wie die Shelly-Support-Seite
  beschreibt, sondern ein Firmware-Wechsel im Zwei-Slot-Modell. Auf der
  WiFi-Firmware existiert kein Zigbee.*-Namespace. Drei undokumentierte
  RPCs aus dem UI-JS extrahiert: Shelly.InstallAlt, Shelly.SetAlternative,
  Shelly.ListAlternatives -- nur die erste ist hier nutzbar.
- Blocker (a) Rueckrollbarkeit ist geschlossen: die Zigbee-Firmware bietet
  PowerStrip ("with Matter", stable) ihrerseits als alt an, ueber das Netz.
  WLAN und statische IP ueberleben den Wechsel, das Geraet bleibt unter
  10.40.30.216 erreichbar. Eine frueher in derselben Session geaeusserte
  Einschaetzung, der Rueckweg sei physisch und die Unterputz-Module damit
  Einbahnstrassen, war falsch.

Verloren gehen: Matter komplett, der AP, alle Ausgangsnamen und
initial_state. Vollbackup vor dem Flash liegt vor.

Beobachtung fuer die Serie: der erste InstallAlt brach bei 2 % ab; nach
eco_mode=false lief derselbe Aufruf glatt durch. n=1, keine bewiesene
Kausalitaet -- aber eco_mode=false vor dem Flash kostet nichts.

Offen: s9 ist noch keinem Zigbee-Netz beigetreten (network_state failed),
die vier Ausgaenge sind derzeit nicht aus HA steuerbar. Vor dem Join in ZHA
fehlt das ZHA-Backup.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Christoph Emsenhuber
2026-08-23 20:06:25 +02:00
parent d245d10542
commit e8f7f809b0
1 changed files with 93 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

99
docs/tp17.1-shelly-gen4-funkmigration-runbook.md
View File

@@ -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`