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 <noreply@anthropic.com>

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.