diff --git a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md index 7053aea..e3d0bbc 100644 --- a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md +++ b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md @@ -117,9 +117,12 @@ hier **drei** 802.15.4-Netze neben dem WLAN, nicht eines: - **Thread ch15 (2425)** liegt **2 MHz über** der Oberkante von WLAN ch1. Knapp, aber sauber. - **Z2M ch25 (2475)** liegt **2 MHz über** der Oberkante von WLAN ch11. Ebenso sauber — das ist die klassisch richtige Wahl. -- 🔴 **ZHA ch20 (2450) liegt direkt auf der Unterkante von WLAN ch11 (2451).** Das ist die einzige - echte Nachbarschaft im Haus — und sie trifft ausgerechnet das Netz mit **52 Geräten** gegen den AP - mit **26 Clients**. +- 🟠 **ZHA ch20 (2450) liegt direkt auf der Unterkante von WLAN ch11 (2451)** — die einzige + Nachbarschaft im Haus, und sie trifft das Netz mit **52 Geräten** gegen den AP mit **26 Clients**. + ⚠️ **Aber: gemessen beißt sie nicht.** `PHY_CCA_FAIL_COUNT` des Koordinators steht bei **4** über + die gesamte Zählperiode → keine nennenswerte Kanalbelegung. **Kein Handlungsbedarf**, Begründung im + Kapitel „Kanalwahl für ZHA" unten. *(Meine erste Einschätzung „🔴 der eine Konflikt" war aus der + Frequenztabelle abgeleitet, nicht gemessen.)* - 💡 **Die Lücke zwischen WLAN ch1 und ch11 (2423–2451) ist unbenutzt.** Dort liegen **ZB 16/17/18** (2430/2435/2440) — mitten im Freiraum, nichts sendet da. ⚠️ **Trotzdem nicht blind umziehen:** einen Kanalwechsel müssen 52 Geräte mitmachen; schlafende und @@ -139,10 +142,12 @@ Netzes, dem sie beitreten. Drei Optionen, und die Wahl ist eine **Blast-Radius** | **Getrennt halten** | 10 Router in **ein** Netz, das andere unangetastet lassen ⇒ wenn es schiefgeht, läuft die andere Hälfte des Hauses weiter | 🔑 **Empfehlung: die Trennung als Sicherheitsnetz nutzen, die es faktisch schon gibt.** Zwei -unabhängige Zigbee-Netze sind ein Vorteil, kein Zufall — die Shellys gehören **komplett in eines**, -und zwar in das, das **nicht** die Beleuchtung und die Fernbedienungen trägt. Dann kann eine -Routing-Störung durch die neuen Router keine „Lichterdisko" mehr auslösen, weil die Lichter gar nicht -in diesem Netz hängen. +unabhängige Zigbee-Netze sind ein Vorteil, kein Zufall — die Shellys gehören **komplett in eines**. +✅ **Welches, ist seit dem Inventar vom 2026-08-23 entschieden: ZHA.** Begründung im Kapitel +„Welche Geräte sind für fehlerhaftes Routing anfällig?" unten — kurz: ZHA hat schon 24 Router (einer +mehr fällt kaum ins Gewicht), Z2M hätte mit zehn Shellys **mehr als doppelt so viele wie heute**, und +in Z2M hängt die **Wandbeleuchtung an ZLL-Altgeräten** — dort *ist* eine Routing-Störung die +Lichterdisko. --- @@ -179,6 +184,134 @@ Vorsicht und Backups, kein Grund, den Weg auszuschließen. --- +## 🌩️ Broadcast-/Routing-Sturm erkennen — Zähler, Baseline, Abbruchkriterium + +**Der Vorfall von 2024 war unsichtbar, weil niemand hingesehen hat, bevor es zu spät war.** Das ist +lösbar: der EZSP-Koordinator führt Zähler mit, die einen Sturm **beschreiben**, bevor er als +„Lichterdisko" auffällt. Hier die **Baseline vom 2026-08-23** (ZHA, read-only aus den Diagnostics) — +gegen die wird nach jedem Join verglichen. + +### Die Zähler, auf die es ankommt + +| Zähler | Baseline (kumuliert) | Bedeutung, wenn er steigt | +|---|---|---| +| 🔴 **`BROADCAST_TABLE_FULL`** | **0** | **Der eine Zähler, der einen Sturm beweist.** Broadcasts kommen schneller, als der Stack sie nachhalten kann. Alles > 0 ist ein Alarm. | +| 🔴 **`ALLOCATE_PACKET_BUFFER_FAILURE`** | **0** | Koordinator hat keine Puffer mehr → **genau der Zustand „nichts mehr steuerbar"**. | +| 🔴 **`PHY_TO_MAC_QUEUE_LIMIT_REACHED`** | **0** | Das Radio kommt mit dem Senden nicht nach. | +| 🔴 **`TYPE_NWK_RETRY_OVERFLOW`** | **0** | Netzwerk-Retries laufen über. | +| 🟠 `ROUTE_DISCOVERY_INITIATED` | 65 | Routen-Thrash. Ein paar pro Tag sind normal, ein Sprung um Dutzende in Minuten nicht. | +| 🟠 `NEIGHBOR_STALE` / `NEIGHBOR_REMOVED` | 372 / **0** | Topologie-Unruhe. `REMOVED > 0` heißt: Router verschwinden aus der Nachbarschaftstabelle. | +| 🟠 `MAC_TX_UNICAST_RETRY` / `…_FAILED` | 1.086 / 341 | **Retry-Quote ≈ 15 %, Fehlerquote ≈ 5 %** bei 6.222 Erfolgen. Das ist die Normallage dieses Netzes — Verdopplung = Warnsignal. | +| 🟠 `PHY_CCA_FAIL_COUNT` | **4** | Kanal war belegt, als gesendet werden sollte = **Funkstörung** (WLAN oder Zigbee). | +| 🟠 `NWK_FRAME_COUNTER_FAILURE` | 25 | Replay/Rejoin-Schleifen — ein Gerät, das immer wieder neu beitritt. | +| ℹ️ `MAC_RX_BROADCAST` vs `MAC_RX_UNICAST` | 124.282 vs 18.620 | **Verhältnis 6,7 : 1.** Das ist die Normallage (Link-Status alle 15 s je Router). **Das Verhältnis ist die Kennzahl, nicht der Absolutwert** — wandert es Richtung 20:1, läuft ein Sturm an. | + +📌 **Ablesen:** ZHA-Config-Entry → Diagnostics → `data.application_state.counters.ezsp_counters`. +`_last_reset_value` = Langzeitsumme, `_raw_value` = seit dem letzten Reset. **Für Z2M** (hier 2.6.2) +ist das Gegenstück `zigbee2mqtt/bridge/health` — es liefert je Gerät `leave_count`, +`network_address_changes` und Fehlerzähler; `network_address_changes > 0` ist dort das +Äquivalent zu „Topologie unruhig". + +### Was man als Mensch sieht, bevor die Zähler gelesen werden + +- Kommandos brauchen **Sekunden** statt sofort — oder kommen **doppelt** an (Licht geht an und gleich wieder aus). +- Geräte fallen **in Wellen** auf `unavailable`, nicht einzeln. +- Lichter schalten **von selbst** — ein Broadcast, der im Netz kreist und mehrfach zugestellt wird. **Das ist die „Lichterdisko".** +- Im HA-Log häufen sich `Failed to send request … device did not respond`. + +🔑 **Merkregel: der Unterschied zwischen „ein Gerät zickt" und „das Netz kippt" ist die +Gleichzeitigkeit.** Ein einzelnes stummes Gerät ist ein Gerät. Drei Geräte gleichzeitig, die vorher +liefen, sind das Netz. + +### Abbruchkriterium für den Test — vorher festlegen, nicht im Moment entscheiden + +**Rückbau des Testgeräts, sobald EINES davon eintritt:** +1. `BROADCAST_TABLE_FULL`, `ALLOCATE_PACKET_BUFFER_FAILURE`, `PHY_TO_MAC_QUEUE_LIMIT_REACHED` oder + `TYPE_NWK_RETRY_OVERFLOW` **verlässt die Null**. +2. Retry-Quote **verdoppelt** sich gegenüber der Baseline (≈15 % → >30 %). +3. Ein Referenzgerät, das vorher prompt reagierte, braucht **wiederholt >2 s**. +4. Zwei oder mehr Geräte gehen **gleichzeitig** auf `unavailable`. + +**Nicht** „das pendelt sich schon ein" — genau diese Hoffnung hat 2024 den Neuaufbau gekostet. + +--- + +## 🧭 Welche Geräte sind für fehlerhaftes Routing anfällig? (Inventar 2026-08-23) + +**Beide Netze vollständig durchgesehen.** Die Risiken sind konkret benennbar — und sie sind in +**beiden** Netzen vorhanden, nur unterschiedlich. + +### ZHA — 52 Geräte, davon **24 Router** + +| Klasse | Geräte | Einschätzung | +|---|---|---| +| Philips/Signify Hue | **14 Router** (LCT012 ×3, LST002 ×2, LCL006 ×2, 5060931P7 ×4, 4090331P9 ×2, 915005997801) | Als Router **gutmütig und stabil**. Aber: siehe Aqara-Zeile. | +| IKEA | Signal Repeater ×2, STARKVIND, VINDSTYRKA, Driver 30W ×2, Floor lamp | unauffällig; die Repeater sind explizit als Router gedacht | +| 🟠 **GLEDOPTO** | GL-SD-001, GL-C-006, GL-C-008 (**3 Router**) | **Dokumentierte Schwäche als Router** (ältere Firmware-Stände, Kind-Tabellen). Im Auge behalten. | +| 🟠 Sunricher | HK-LN-DIM-A | meist unauffällig | +| 🔴 **LUMI / Aqara** | `lumi.weather` ×3 (End Devices) | **Der klassische Instabilitätsherd.** Aqara-End-Devices halten sich nicht an die übliche Rejoin-Mechanik und **fallen weg, wenn sie an einem Nicht-Aqara-Router hängen** — Hue-Router sind der meistdokumentierte Fall, und davon stehen hier **14**. | + +⇒ 🐤 **Die drei `lumi.weather` sind der Kanarienvogel.** Sie reagieren als Erste, wenn sich die +Topologie ändert. **Vor und nach dem Shelly-Join gezielt auf ihr `last_seen` schauen** — nicht auf den +Durchschnitt des Netzes. + +### Z2M — 15 Geräte, davon **7 Router** + +| Klasse | Geräte | Einschätzung | +|---|---|---| +| 🔴 **Busch-Jaeger ZLL** | 6× „Zigbee Light Link power supply/relay/dimmer/wall-switch", **sw 1.2.0** | **Zigbee-Light-Link-Altbestand.** ZLL-Stacks sind älter als Zigbee 3.0, mit knappen Routing-/Kind-Tabellen — und **das ist die Wandbeleuchtung** (Küche, Wohnzimmer ×2, Kinderzimmer, Klo, Schlafzimmer). ⇒ **Genau die Geräte, aus denen eine „Lichterdisko" besteht.** | +| 🔴 **Tuya-Familie** | Tongou Smart circuit breaker (Router) · Mini human breathe sensor · 24G mmWave · Soil sensor · **`_TZE284_7zazvlyn` „Automatically generated definition"** | Tuya ist die unberechenbarste Klasse; das letzte Gerät ist **nicht einmal sauber unterstützt** (Auto-Definition) — sein Verhalten ist unbekannt. | +| 🟠 Aqara | Presence sensor FP300 | dieselbe Familie wie oben, End Device | +| ℹ️ COOLO / IKEA | Soil moisture, TRADFRI on/off | unauffällig | + +🎯 **Damit ist die Netzwahl für den Test entschieden — und zwar gegen die Intuition:** + +> **Das Testgerät gehört in ZHA, nicht in Z2M.** Drei Gründe: +> 1. **Proportion.** ZHA hat **24 Router** — einer mehr ändert die Topologie kaum. Z2M hat **7**; zehn +> Shellys würden den Router-Bestand dort **mehr als verdoppeln**. Genau solche abrupten +> Topologiewechsel erzeugen die Route-Thrash-Phase, die man fürchtet. +> 2. **Blast Radius.** In Z2M hängt die **Wandbeleuchtung** an ZLL-Altgeräten. Ein Routing-Problem dort +> *ist* die Lichterdisko. In ZHA hängen Lampen, die sich zur Not einzeln schalten lassen. +> 3. **Messbarkeit.** Für ZHA gibt es die Zählertabelle oben mit einer **echten Baseline**. Für Z2M +> gibt es `bridge/health`, aber keine vergleichbar feinen Funkzähler. +> +> ⚠️ **Der Preis dieser Wahl:** die drei Aqara-`lumi.weather` sitzen in ZHA und könnten sich auf den +> neuen, unerprobten Shelly-Router umhängen. Das ist beherrschbar (beobachten, notfalls den Shelly +> wieder entfernen) — und es ist der Grund, warum der Test **ein** Gerät umfasst und nicht drei. + +--- + +## 📡 Kanalwahl für ZHA — gemessen, nicht geschätzt + +🔄 **Korrektur meines eigenen Befundes von vorhin.** Ich hatte ZHA ch20 als „🔴 der eine Konflikt im +Haus" markiert, weil 2450 MHz auf der Unterkante von WLAN ch11 (2451) liegt. **Die Zähler des +Koordinators widersprechen dem:** `PHY_CCA_FAIL_COUNT` steht bei **4** über die gesamte Zählperiode +(gegen 6.222 erfolgreiche Sendungen). Wäre die WLAN-Nachbarschaft ein echtes Problem, stünde dort eine +drei- bis vierstellige Zahl. **Die Adjazenz existiert auf dem Papier und beißt nicht.** + +**Empfehlung: ZHA bleibt vorerst auf Kanal 20.** +- Ein Kanalwechsel müssten **52 Geräte** mitmachen. Schlafende und ältere Router folgen dem + `nwk_update_id`-Broadcast **nicht zuverlässig** und bleiben auf dem alten Kanal zurück — sie sind + dann verwaist und müssen einzeln neu angelernt werden. **Das ist exakt die Fehlerklasse von 2024**, + ausgelöst durch die Maßnahme, die sie verhindern sollte. +- Der Nutzen ist nach der CCA-Messung **nicht belegt**. Ein Risiko ohne belegten Nutzen ist kein Trade. + +**Falls doch einmal gewechselt wird — dann auf `18`:** + +| Kandidat | Mitte | Abstand zu Thread (2425) | Abstand zu WLAN ch11 (2451) | Urteil | +|---|---|---|---|---| +| 16 | 2430 | 3 MHz | 19 MHz | zu nah an Thread | +| 17 | 2435 | 8 MHz | 14 MHz | brauchbar | +| **18** | **2440** | **13 MHz** | **9 MHz** | ✅ **am besten zentriert** in der Lücke 2426–2451 | +| 19 | 2445 | 18 MHz | 4 MHz | zu nah am WLAN | + +🔴 **Vorbedingung für jeden Wechsel: die Nachbar-WLANs messen.** Die Lücke 2426–2448 ist genau +**WLAN-Kanal 6**. Eigene APs stehen auf 1 und 11 — was die Nachbarn tun, ist **unbekannt**. Läuft +nebenan ein AP auf ch6, wären 16/17/18 schlechter als das heutige 20. **Erst scannen, dann wechseln.** +⚠️ Ein Scan auf ap1/ap2 nimmt das Radio kurz vom Kanal und wirft Clients — also bewusst terminieren, +nicht nebenbei. +--- + ## 🔌 UART-Backup: was das praktisch heißt (nur für Weg C nötig) **Kurzantwort: ja, einmal physisch ans Gerät — aber es ist keine Taste, und es ist genau einmal.**