From 0a7f2e2c08b5d8cbc316d2f13345ac2afaa25987 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 23 Aug 2026 20:16:37 +0200 Subject: [PATCH] TP17.1 Pilot: s9 ist in ZHA, Ende-zu-Ende bewiesen, kein Sturm ZHA-Backup zuerst (is_complete true, Kanal 20, PAN 5B5A) -- das ist der Punkt, der 2024 gefehlt hat. Dann permit_join + StartNetworkSteering: network_state joined nach 10 Sekunden. Abnahme nach Runbook-Kriterium erfuellt. ZHA hat vier switch-Entities angelegt. Gegenprobe quer ueber beide Wege: turn_on ueber ZHA gesendet, Ergebnis ueber die WLAN-RPC des Shelly gelesen -- switch:0 output=True, 2.1 W. Der Zigbee-Befehl hat das physische Relais geschaltet. Danach wieder aus, Ausgangszustand hergestellt. Zaehlervergleich vor/nach dem Join: alle vier roten Zaehler unveraendert 0. NEIGHBOR_ADDED +1 (genau der neue Router), NEIGHBOR_REMOVED weiterhin 0. Broadcast:Unicast im Delta 1,8:1 gegen eine Normallage von 6,7:1 -- unicast-lastiger Interview-Traffic, das Gegenteil einer Sturmsignatur. Erhoeht und vor dem zweiten Geraet erneut zu lesen: Retry-Quote im Delta 44 % (Normallage ~15 %) und PHY_CCA_FAIL_COUNT 7 -> 19. Der Pilot ist damit noch nicht fertig -- Schritt 2 (HA-Seite) steht: alte Shelly-Entities entfernen, bevor umbenannt wird, sonst haengt HA ein _2 an; vier Ziel-entity_ids notiert; zwei Gruppen-Helper (sonos wohnzimmer, tv) referenzieren s9 und brechen sonst; Ausgangsnamen und initial_state aus dem Backup zurueckschreiben; Energie-Statistiken brauchen einen Fix-Lauf. Co-Authored-By: Claude Opus 5 --- ...p17.1-shelly-gen4-funkmigration-runbook.md | 45 ++++++++++++++++--- 1 file changed, 40 insertions(+), 5 deletions(-) diff --git a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md index a4836b6..97da5d1 100644 --- a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md +++ b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md @@ -716,11 +716,46 @@ Sendeleistung, und das Gerät war während des ersten Versuchs wiederholt nicht ⇒ **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). +#### ✅ ZHA-Join DURCH (2026-08-23) — mit Vorher/Nachher-Messung +**Reihenfolge eingehalten:** ZHA-Backup zuerst (`ha_manage_radio zigbee network_backup`, +`is_complete: true`, Kanal 20, PAN `5B5A`, Koordinator SONOFF Dongle-M, EZSP 13 / bellows 1.0.0). +⚠️ Das Backup enthält den **Netzwerkschlüssel im Klartext** — es liegt in HA, **keine lokale Kopie**. +Dann `permit_join 240 s` + `Zigbee.StartNetworkSteering` am Gerät → **`network_state: joined` nach 10 s.** + +**Abnahme nach Runbook-Kriterium erfüllt — frischer Knoten UND funktionierende Entity:** +ZHA hat vier Entities angelegt (`switch.shelly_power_strip_schalter`, `…_2`, `…_3`, `…_4`). +Gegenprobe **quer über beide Wege**: `switch.turn_on` über ZHA gesendet, das Ergebnis über die +**WLAN-RPC des Shelly** gelesen → `switch:0 output=True, 2.1 W`. Der Zigbee-Befehl hat das physische +Relais geschaltet. *(Zuordnung damit belegt: Entity 1 → `switch:0` = „apple tv". Danach wieder aus — +Ausgangszustand hergestellt.)* + +**Zählervergleich vor/nach dem Join** (kumuliert). **Alle vier roten Zähler unverändert 0:** +`BROADCAST_TABLE_FULL`, `ALLOCATE_PACKET_BUFFER_FAILURE`, `PHY_TO_MAC_QUEUE_LIMIT_REACHED`, +`TYPE_NWK_RETRY_OVERFLOW`. `NEIGHBOR_ADDED` **+1** (genau der neue Router), `NEIGHBOR_REMOVED` +weiterhin **0** — nichts wurde verdrängt. +🔑 **Broadcast : Unicast im Delta = 1,8 : 1**, also weit *unter* der Normallage von 6,7 : 1 — der Join +war unicast-lastig (Interview), das **Gegenteil** einer Sturmsignatur. +🟠 **Zwei Werte sind erhöht und gehören nach dem Einschwingen erneut gelesen, bevor Gerät zwei +drankommt:** Retry-Quote im Delta **44 %** (Normallage ~15 %) und `PHY_CCA_FAIL_COUNT` **7 → 19**. +Beides ist für einen Join mit vollem Interview erwartbar — aber es ist genau die Kennzahl, deren +Verdopplung das Runbook als Warnsignal führt. **Nicht ungeprüft weitermachen.** + +#### ⏳ Offen am Pilotgerät — Schritt 2 (HA-Seite bilanzieren) +Der Pilot ist **noch nicht fertig**: „erst wenn der Pilot in HA vollständig verdrahtet ist, war er +erfolgreich." + +1. **Die alten Shelly-Entities leben alle noch** (67 Treffer auf `s9`) — die Shelly-Integration + erreicht das Gerät weiter über WLAN und liefert RSSI/Uptime/Cloud, nur die `switch.*` sind weg. + ⇒ Erst das alte Gerät aus der Shelly-Integration **entfernen**, sonst hängt HA beim Umbenennen ein + `_2` an (Falle aus dem Entity-Bruch-Kapitel oben). +2. **Ziel-`entity_id`s** (aus den erhaltenen Sensor-Namen ableitbar): + `switch.shelly_s9_0_wohnzimmer_apple_tv` · `…_s9_1_wohnzimmer_vuplus` · + `…_s9_2_wohnzimmer_sonos_arc_amp` · `…_s9_3_wohnzimmer_tv` +3. 🔴 **Zwei Gruppen-Helper referenzieren `s9` in ihrer Config und brechen sonst:** + **`sonos wohnzimmer`** (`01KFN557CED9WWDSKMVF1MW4CQ`) und **`tv`** (`01KFN57B9V1D30J39VH75V0GA9`). +4. **Ausgangsnamen und `initial_state=restore_last`** aus dem Backup wieder setzen (der Flash hat sie + auf `None`/`off` zurückgesetzt). +5. **Energie-Dashboard:** 2,2 / 0,4 / 16,4 / 14,4 kWh hängen an den alten `unique_id`s — Fix-Lauf nötig. **Bei Weg (C)** wäre vorher ein **UART-Vollbackup** nötig gewesen, sonst gäbe es keinen Rückweg.