Initial import from bf-network-r6.opencode — opencode migration

docs/tp17.1-shelly-gen4-funkmigration-runbook.md

@@ -0,0 +1,848 @@
+# TP17.1 — Shelly Gen4 raus aus dem WLAN (Thread oder Zigbee) · Runbook
+
+> ❌ **TP17.1 IST VERWORFEN (User-Entscheid 2026-08-23).** Dieses Runbook bleibt als **Wissensspeicher**
+> stehen — es ist kein Arbeitsauftrag mehr.
+>
+> **Warum:** der Pilot hat den Zigbee-Weg technisch **vollständig bewiesen** (s. Schritt 1 unten),
+> aber gezeigt, dass das **Ziel** so nicht erreichbar ist — das Gerät bleibt WLAN-Client, der
+> gemessene Funkgewinn ist klein, und WLAN abzuschalten wäre unumkehrbar (kein AP auf der
+> Zigbee-Firmware, kein Zigbee-OTA, `InstallAlt` braucht IP).
+> **Der Weg ist nicht gescheitert, das Ziel war mit ihm nicht erreichbar.**
+>
+> ✅ **Rückbau am 2026-08-23 durchgeführt:** ZHA-Knoten entfernt (Leave **vor** dem Flash), `s9` zurück
+> auf `PowerStrip`, Config aus dem Backup. ⚠️ **Der Rückflash zog einen OFFENEN AP hoch**
+> (`ap.enable=true, is_open=true`) — abgeschaltet und mit dem IoT-PSK abgesichert.
+> **Merkregel: nach jedem Shelly-Firmwarewechsel den AP prüfen.**
+>
+> 🔭 **Weiter gültig ist der Frühindikator:** `Shelly.CheckForUpdate` auf einem Gen4 auf einen
+> `…MT`/Thread-`alt`-Eintrag beobachten. Erscheint er, ist die Rechnung neu zu machen.
+>
+> 📌 **Was hier bleibt und Wert hat:** der kartierte Firmware-Mechanismus (drei undokumentierte RPCs,
+> Zwei-Slot-Modell), das gemessene 2,4-GHz-Bild aller vier Funknetze, die ZHA-Sturmzähler mit
+> Baseline und Abbruchkriterium — und die Erkenntnis, dass ein ZHA-Join dieses Netz **nicht**
+> destabilisiert (alle vier roten EZSP-Zähler blieben 0).
+
+> **Status 2026-08-23:** 🔜 **entscheidungsreif, nicht startbereit.** Schritt 0 ist eine Abwägung,
+> kein Flash. Steuerung/Scope: [`teilprojekte.md`](teilprojekte.md) → **TP17.1**.
+> **Kein Netz-Eingriff bisher**, alle Zahlen hier sind read-only erhoben.
+>
+> 📌 **Wohnort dieses Arbeitspakets: das Netz-Projekt** (User-Entscheid 2026-08-23). Eine erste
+> Fassung lag kurzzeitig im HA-Projekt (`ha-xstate`) — sie ist dort **entfernt**, damit es keine
+> zweite Wahrheit gibt. HA ist Betroffener, nicht Eigentümer: die Entities brechen, aber die
+> Entscheidung ist eine Funk- und Netzentscheidung.
+
+## Das Ziel (Christophs Begründung, dreiteilig)
+
+1. **Die PSK-Rotation wird billiger.** Jedes Gerät, das den Funk wechselt, fällt aus der Rechnung.
+2. **Mesh-Stabilität** — netzgespeiste Geräte sind immer Router-Knoten, nie Sleepy End Devices.
+3. **Ruhe im WLAN.** 26 der 27 WLAN-Clients des ganzen Netzes hängen auf `dirtyvader-iot`.
+
+⚠️ **Punkt 1 trägt nur teilweise.** Kandidaten sind **10 Geräte**; danach blieben grob **16** auf dem
+IoT-SSID. Die Rotation wird **kleiner, nicht überflüssig** — und Gen3 kann nie folgen, dort fehlt
+802.15.4. *(Seit 2026-08-23 ist das ohnehin entschärft: Rotation und Funkmigration laufen **parallel**,
+s.u.)*
+
+---
+
+## Bestand (live 2026-08-23, `mcp/shelly/discover.py`, read-only)
+
+**22 von 26 Shellys erreichbar** auf VLAN30, **alle auf Firmware 2.0.0**:
+
+| Gen | Anzahl | Modelle |
+|---|---|---|
+| **Gen4** | **12** | 9× `S4SW-002P16EU` (2PM) · 1× `S4SW-001P16EU` (1PM) · 2× `S4PL-00416EU` (Power Strip) |
+| Gen3 | 8 | `S3PL-00112EU`, `S3PL-30116EU` |
+| Gen2 | 2 | `SPDM-002PE01EU`, `SNDC-0D4P10WW` |
+
+**Die 12 Gen4:** s25 bad_lichtschalter `.205` · s20 kueche_steckdosen2 `.206` · s21 kueche_steckdosen4
+`.207` · s12 dieleug_steckdosen `.219` · s16 wohnzimmer_steckdosen `.223` · s17 bad_steckdosen `.224` ·
+s18 kueche_steckdosen1 `.225` · s19 kueche_steckdosen3 `.226` · s26 bad_luefter `.233` *(alle 2PM)* ·
+s22 kueche_steckdose3-2 `.202` *(1PM)* · **s9 wohnzimmer_sideboard `.216`** und **s13
+arbeitszimmer_technik `.220`** *(Power Strip)*.
+
+**Nicht erreichbar (4):** `s1`/`s2`/`s3` (weihnachten_*, saisonal ausgesteckt — die HA-Entities sind
+**deaktiviert, nicht gelöscht**, deshalb tauchen sie in keiner Zustandssuche auf; Christoph 2026-08-23) und **`s4 kueche_mikrowelle`** — der einzige, den auch HA als `unavailable` führt.
+Hängt hinter Metall bei **RSSI −93 dBm**, Generation unbekannt. **Falls Gen4: bester Pilot überhaupt**,
+denn 802.15.4 kommt dorthin, wo 2,4-GHz-WLAN scheitert.
+
+---
+
+## 🔴 Die Firmware-Lage — der Kern der Entscheidung
+
+**Direkt an den Geräten erhoben** (`Shelly.CheckForUpdate`, read-only, 2026-08-23):
+
+| | Befund |
+|---|---|
+| Stable | **2.0.0 überall — für kein Gerät ein stabiles Update** |
+| Beta | `2.0.1-beta1`, Build 2026-08-19, für alle inkl. Gen3 |
+| **Alt-Varianten (nur Gen4)** | `S2PMG4ZB` · `S1PMG4ZB` · `PowerStripZB` — jeweils **„with Zigbee"** |
+| Gen3 | **kein `alt`-Eintrag** → Alternativfunk ist Gen4-only |
+
+**Thread gibt es von Shelly heute nicht.** Die offizielle Linie ist **„wird evaluiert"** (Stand Juli
+2026, genannter Engpass: **Flash-Platz**), kein Release-Datum. Was im Mai 2026 als „Thread für Gen4"
+durch die Presse ging, war die **Dritt**-Firmware.
+
+🎯 **Der wichtigste Nebenbefund:** Shelly liefert alternative **Funk**-Firmware über den **normalen
+Update-Kanal**, nicht über einen Bastelpfad. Eine Thread-Variante erschiene mit hoher
+Wahrscheinlichkeit **genau dort** als weiterer `alt`-Eintrag. ⇒ **Frühindikator statt Warten auf
+Pressemeldungen:** `Shelly.CheckForUpdate` auf einem Gen4 pollen und auf einen `…MT`/Thread-Eintrag
+warten.
+
+### Die drei Wege im Vergleich
+
+| Weg | Deckt ab | Preis | Reife |
+|---|---|---|---|
+| **(A) Zigbee, offiziell — heute verfügbar** | **10 der 12** (2PM, 1PM, Power Strip) | Entity-Bruch (Shelly-Integration → Z2M); 2,4-GHz-Kanalplanung nötig | Hersteller-Firmware, offizieller Kanal, **keine** Garantie-/Cloud-Frage |
+| **(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** |
+
+🔴 **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
+bereits als **LXC 112 (`10.40.20.106`, `z2m25`)**. Was vorher zu klären ist:
+- **(a) Rückrollbarkeit:** Ist der Wechsel des Funkstacks so zurückrollbar wie ein normales Update?
+  Das ist ein anderer Vorgang als ein Versionssprung — vor dem ersten Gerät klären.
+- **(b) Kanalplanung: ✅ erledigt, s. eigenes Kapitel unten.** Kurzfassung: Thread 15, ZHA 20,
+  Z2M 25, WLAN 1 + 11. Sauber bis auf **ZHA ch20, das auf der Unterkante von WLAN ch11 sitzt**.
+- **(c) Entity-Bruch: ✅ entschärft (User-Entscheid 2026-08-23) — „wir werden so umbauen, dass die
+  Entitäten ihren Namen behalten."** Der Umbau benennt die neuen Entities auf die alten `entity_id`s
+  zurück, damit Automationen, Dashboards und die FSM-Configs unverändert bleiben.
+  ⚠️ **Zwei Fallen dabei:** (1) die alte `entity_id` ist erst frei, wenn die alte Integration das
+  Gerät **losgelassen** hat — sonst hängt HA ein `_2` an; also erst entfernen, dann neu anlernen,
+  dann umbenennen. (2) **Der Name überlebt, die History nicht** zwangsläufig — der Recorder keyt auf
+  `entity_id`, das passt, aber `unique_id` und Device-Zuordnung sind neu. Energie-Dashboard-Statistiken
+  brauchen ggf. einen Fix-Lauf.
+  ⇒ Damit fällt der teuerste Posten der ganzen Abwägung weg. **Er gilt für Weg (A) und (C) gleich.**
+
+---
+
+## 📻 Das 2,4-GHz-Bild — alle vier Netze, live erhoben 2026-08-23
+
+**Das ist der Rechenschritt, der bei „einfach auf Zigbee umstellen" gern übersprungen wird.** Es gibt
+hier **drei** 802.15.4-Netze neben dem WLAN, nicht eines:
+
+| Netz | Kanal | Mitte | belegt ca. | Geräte | Quelle |
+|---|---|---|---|---|---|
+| **WLAN ap1** | 1 | 2412 | **2401–2423** | — | CAPsMAN |
+| **Thread (OTBR)** | **15** | 2425 | 2424–2426 | ~30 Matter-Knoten | `ha_manage_radio thread` |
+| **ZHA** | **20** | 2450 | 2449–2451 | **52 Geräte** | ZHA-Diagnostics, EZSP/bellows |
+| **WLAN ap2** | 11 | 2462 | **2451–2473** | **26 Clients** | CAPsMAN |
+| **Z2M (`z2m25`)** | **25** | 2475 | 2474–2476 | — | `configuration.yaml`, zstack |
+
+- **ZHA-Koordinator:** SONOFF **Dongle-M**, angebunden **über Netz** (`socket://10.40.30.137:6638`),
+  PAN 23386, `tx_power=8`. Zwei weitere ZHA-Einträge (Dongle Plus V2, Dongle-M_10E8) stehen auf
+  *ignore* — das ist Absicht, sonst griffe ZHA nach dem Z2M-Stick.
+- **Z2M-Koordinator:** ITead **Sonoff Zigbee 3.0 USB Dongle Plus**, `adapter: zstack`.
+
+🎯 **Befund: das Band ist gut geplant — mit genau einer Ausnahme.**
+- **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)** — 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
+  ältere Router folgen dem `nwk_update_id`-Broadcast nicht zuverlässig und bleiben zurück. Das ist
+  **dieselbe Fehlerklasse wie der Vorfall von 2024** (s.u.). Erst **Energy-Scan** in ZHA fahren, dann
+  entscheiden — nicht umgekehrt.
+
+### Wohin kämen die Shelly-Zigbee-Geräte?
+
+Sie wären **netzgespeiste Router**, keine End Devices — sie verändern also die Routing-Topologie des
+Netzes, dem sie beitreten. Drei Optionen, und die Wahl ist eine **Blast-Radius**-Frage:
+
+| | Wirkung |
+|---|---|
+| **In ZHA** (52 Geräte, ch20) | dichteres Mesh dort, wo die Fernbedienungen hängen — **aber** das ist das Netz, das die Automationen trägt, und es sitzt auf dem einzigen kontendierten Kanal |
+| **In Z2M** (ch25, sauberer Kanal) | technisch der bessere Kanal — **aber** genau das Netz, mit dem 2024 die Installation zusammenbrach (s.u.) |
+| **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**.
+✅ **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.
+
+---
+
+## ⚠️ Christophs Z2M-Vorbehalt — ernst zu nehmen, und benennbar
+
+> **Erfahrung (2024):** „mir hats vor 2 jahren die ganze installation gekillt. nichts mehr steuerbar,
+> musste alles resetten und neu aufbauen. **Lichterdisko** war das damals."
+
+**Das ist kein diffuses Unbehagen, sondern eine bekannte Fehlerklasse.** „Alles unsteuerbar +
+Lichter feuern von selbst" ist das Bild eines **Zigbee-Broadcast-/Routing-Sturms**: das Netz sättigt
+sich mit Broadcasts, Routing-Tabellen thrashen, Kommandos kommen mehrfach oder gar nicht an. Typische
+Auslöser sind **Gruppen-/Binding-Schleifen**, ein einzelnes fehlerhaftes Router-Gerät (billige Bulbs
+sind berüchtigt), oder schlicht zu viele Broadcasts auf einem überlasteten Kanal. **Nicht** ursächlich
+ist üblicherweise „Z2M als Software" — dieselbe Klasse trifft ZHA genauso.
+
+⚠️ **Der Root Cause von damals ist heute nicht mehr rekonstruierbar** (Netz wurde neu aufgebaut, keine
+Logs). Deshalb ist die ehrliche Aussage: *wir wissen nicht, ob es wiederkommt* — aber wir können die
+Bedingungen ungünstig machen:
+
+1. **Blast Radius trennen** (s.o.) — die wirksamste Maßnahme, weil sie ohne Ursachenkenntnis wirkt.
+2. **Nicht im Batch beitreten lassen.** 10 neue Router auf einmal ändern die Topologie schlagartig.
+   Einzeln, mit ein paar Tagen Abstand — und dazwischen schauen, ob Kommandos noch prompt ankommen.
+3. **Vorher einen Rückweg festhalten:** Z2M/ZHA-Backup (`coordinator_backup.json` bzw. ZHA-Backup)
+   **vor** dem ersten Join. Genau das hat 2024 gefehlt — der Wiederaufbau war nötig, weil es kein
+   Netz-Backup gab, nicht weil die Geräte kaputt waren.
+4. **Keine Gruppen-Bindings für die Shellys** anlegen, solange sie neu sind. Direktes Binding ist der
+   Pfad, auf dem Schleifen entstehen; über HA gesteuert passiert das nicht.
+5. **Ein Abbruchkriterium vorher festlegen:** wenn nach einem Join die Latenz eines bekannten Geräts
+   spürbar steigt, das Gerät wieder entfernen — **nicht** „wird sich schon einpendeln".
+
+📌 **Und die nüchterne Gegenrechnung:** 10 zusätzliche *Router* machen ein Zigbee-Mesh normalerweise
+**stabiler**, nicht instabiler — das ist der Regelfall. Der Vorfall von 2024 ist ein Grund für
+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 erfüllt: die Nachbar-WLANs sind am 2026-08-23 gemessen** (Kapitel unten). Ergebnis:
+das Fenster 2426–2448 ist nur **schwach** belegt (alles ≤ −81 dBm) — **ZB18 ist valide**. Der
+Handlungsdruck fehlt trotzdem (CCA = 4). 🔴 **Neue Randbedingung:** funken die **zwei neuen APs**
+ebenfalls auf 2,4 GHz, ist **ch6 belegt** und ZB18 fällt aus — dann sind 20 und 25 die einzig
+richtigen Plätze. Details und die Empfehlung dazu im Scan-Kapitel.
+---
+
+## 📡 WLAN-Umfeldscan 2,4 GHz — durchgeführt 2026-08-23 (beide APs)
+
+🔴 **Gotcha zuerst, er kostet sonst eine halbe Stunde: `/interface wifi scan` geht am CAP NICHT.**
+Auf ap1 direkt (SSH, User in Gruppe `full`) antwortet das Gerät `failure: not allowed
+(/interface/wifi/scan)`. **Das ist weder device-mode noch eine Policy-Lücke** — der Gegentest
+beweist es: `/tool fetch` meldet auf demselben Gerät explizit *„not allowed **by device-mode**"*, und
+die Gruppe `full` hat `test` und `sniff`. Ursache ist der **CAPsMAN-Zustand**: ein CAP besitzt sein
+Radio nicht. **Der Scan läuft am Manager gegen die `cap-wifiN`-Schnittstelle** und funktioniert dort
+einwandfrei. Reiht sich ein in „unter CAPsMAN führt der Manager die Tabellen".
+*(Zuordnung am Messtag über `radio-mac` bestimmt, nicht angenommen: ap1 = `cap-wifi3` (5 GHz) /
+`cap-wifi4` (2,4 GHz), ap2 = `cap-wifi1` / `cap-wifi2`.)*
+
+### Fremdnetze — die Nachbarschaft ist leise
+
+| WLAN-Kanal | Belegung ca. | Fremd-APs | stärkstes Fremdsignal |
+|---|---|---|---|
+| **1** (2412) | 2401–2423 | dahoam is dahoam −89, FRITZ!Box 6690 TM −87 | **−87** |
+| 3 / 4 (2417/2427) | 2406–2438 | meins.w −81/−93, Drei_H288A −81 | **−81** |
+| **6** (2437) | 2426–2448 | Liwest_9d44 −90, meins.liwest −88/−90, Liwest3422 −90 | **−88** |
+| 8 (2447) | 2436–2458 | meins.w −92, verstecktes Netz −84 | **−84** |
+| **11** (2462) | 2451–2473 | FRITZ!Box 7490 −81, LiwestBB93 −96, LiwestF0DA −90, LiwestEDBA −92, MIKENET2 −91 | **−81** |
+
+⇒ **Kein einziges Fremdnetz über −81 dBm.** Die 2,4-GHz-Umgebung ist für eine Wohnlage
+bemerkenswert ruhig — die eigenen APs sind mit Abstand die lautesten Sender im Band.
+
+### 🔴 Zwei laute Sender sind aber die eigenen — und keiner davon ist ein AP
+
+| Sender | Kanal | Signal | Was es ist |
+|---|---|---|---|
+| `AC:15:18:7B:62:21` SSID **`AC15187B6220`** | **11** (2462) | **−51** (von ap1) | **Shelly s23** (`dieleug-wohnzimmer_licht`, Pro Dimmer 2PM, `10.40.30.203`) sendet einen **eigenen Access Point** |
+| `54:F2:9F:12:51:F1` SSID **`DTUBI-92337823`** | **1** (2412) | **−59** (von ap2) | **Hoymiles-DTU** (Solar-Datenlogger, VLAN30) sendet ebenfalls einen eigenen AP |
+
+🎯 **Der Shelly-Fund ist ein Rückstand aus TP17 und live bestätigt:** `WiFi.GetConfig` liefert
+`ap.enable = true`, SSID `AC15187B6220`, WPA2. Das ist ein **übrig gebliebener „Anker"** aus dem
+Migrationsverfahren von 2026-07-13 — dort wurde je Gerät vor dem STA-Write die geräteeigene
+AP-Funktion als Notanker aktiviert und **nach dem Verify wieder abgeschaltet**. Bei s23 ist das
+De-Anchoring **nicht angekommen**. Das Gerät funkt seither doppelt: als **Client auf ch1**
+(`dirtyvader-iot` an ap1, RSSI −56) **und als AP auf ch11**.
+- ~~**Fix ist ein Einzeiler**~~ ⏸️ **Nicht ausgeführt — und das war Glück, s. Korrektur unten.**
+
+🔴🔴 **KORREKTUR am selben Tag — ich habe diesen Fund falsch eingeordnet.** Der AP auf s23 ist **kein
+vergessener Anker, sondern Christophs WORKAROUND**: das Gerät (Pro Dimmer 2PM, „Diele UG/Licht")
+**flackert unkontrolliert, seit die Migration daran gearbeitet hat — und mit eingeschaltetem AP ist
+das Symptom weg.** Der Fix, den ich oben als „Einzeiler" beschrieben habe, hätte also eine
+funktionierende Reparatur zerstört. **`ap.enable` auf s23 bleibt an**, bis die Ursache behoben ist.
+➡️ Eigenes Teilprojekt dafür: **TP17.3** in [`teilprojekte.md`](teilprojekte.md) — Leithypothese ist
+**`eco_mode`** (gedrosselter CPU-Takt vs. Nulldurchgangs-Timing eines Phasenanschnitt-Dimmers; ein
+aktiver AP hebt die Energiesparzustände auf und erklärt damit genau die Beobachtung).
+📌 **Merkregel, die das kostet: ein Zustand, der nach einem Verfahren „übrig" aussieht, kann eine
+Reparatur sein.** Vor dem Aufräumen fragen, wozu er da ist — nicht, ob er ins Schema passt.
+⇒ **Der Anker-Sweep bleibt trotzdem sinnvoll** und ist am 2026-08-23 gelaufen: **s23 ist der einzige
+Shelly mit aktivem AP**, alle anderen 21 sind sauber de-anchored. Die Sorge war unbegründet, der
+Einzelfall ist erklärt.
+- ☀️ **Die DTU: abschalten geht nicht — und das ist jetzt am PROTOKOLL belegt, nicht am Forum
+  (2026-08-23).** Es ist kein separater DTU-Kasten, sondern der **Wechselrichter mit eingebautem DTU**
+  („DTU **B**uilt-**I**n"). Hostname `DTUBI-414392337823`, `10.40.30.8`, MAC `54:F2:9F:12:51:F0`;
+  der AP läuft auf `…:F1` (STA-MAC + 1, übliches ESP-Muster).
+  - 🔴 **Korrektur eines eigenen Fehlbefunds vom selben Tag:** ich hatte „**null offene TCP-Ports**"
+    gemeldet. **Falsch — `10081` ist offen.** Ursache war ein kaputter Port-Test: `timeout` gibt es auf
+    macOS nicht, jeder Aufruf lief auf `command not found` und wurde als „zu" gewertet.
+    **Merkregel: ein Test, der bei jedem Port dasselbe Ergebnis liefert, hat sich selbst widerlegt** —
+    ein leeres Ergebnis ist kein Befund, sondern ein Verdacht auf einen kaputten Test.
+    *(Gültig bleibt: **80/443/8080/8000 sind zu** — dieser Teil lief ohne `timeout`. Es gibt LAN-seitig
+    also **keine Weboberfläche**, wohl aber ein vollwertiges Konfigurationsprotokoll.)*
+  - 🔌 **Was auf `10081` läuft:** das proprietäre Hoymiles-Protokoll (Protobuf). Das HA-Addon
+    **`ha-hoymiles-wifi-addon` v0.5** (`DennisOSRM/hms-mqtt-publisher`, Rust) pollt darüber alle
+    30,5 s und schiebt die Telemetrie in den MQTT-Broker — **es ist rein lesend**.
+  - 🎯 **Die Antwort steckt in der Protokolldefinition, nicht im Addon.** Die Schwester-Bibliothek
+    `suaveolent/hoymiles-wifi` legt den vollen Befehlssatz offen: `get-real-data`, `get-config`,
+    `network-info`, `app-information-data`, `get-version-info`, `get-alarm-list` — und schreibend
+    `set-power-limit`, `turn-on/off-inverter`, `restart-dtu`, `identify-dtu`, `firmware-update`,
+    **`set-wifi`**.
+    In `SetConfig.proto` stehen die relevanten Felder:
+    | Feld | Nr. | Bedeutung |
+    |---|---|---|
+    | `dtu_ap_ssid` | 48 | **SSID des geräteeigenen APs** |
+    | `dtu_ap_pass` | 49 | **Passwort des geräteeigenen APs** |
+    | `wifi_ssid` / `wifi_password` | 15 / 16 | das WLAN, in das sich der Wechselrichter einbucht |
+    | `netmode_select` · `channel_select` · `dhcp_switch` | 8 · 9 · 25 | Netzmodus, Kanalwahl, DHCP |
+    🔴 **Und entscheidend: es gibt KEIN `ap_enable`.** Das Protokoll kennt SSID und Passwort des APs —
+    **aber keinen Schalter, ihn abzuschalten.** Damit ist „geht nicht" kein Forumsgerücht mehr, sondern
+    aus der Schnittstellendefinition ableitbar.
+  - ✅ **Entwarnung: der AP ist verschlüsselt** — der Scan meldet `security=wpa2-psk;wpa-psk`. Der
+    bekannte Fall „Hoymiles-DTU funkt ein **offenes** WLAN" trifft hier **nicht** zu.
+    💡 **Die einzige sinnvolle Härtung, die das Protokoll hergibt:** `dtu_ap_pass` auf ein eigenes
+    Passwort setzen, falls dort noch das Werkspasswort vom Geräteaufkleber steht.
+  - ⚠️ **Wenn jemand das je anfasst, zwei Fallen:** **(a)** `SetConfig` überträgt den **ganzen**
+    Konfigurationssatz — wer ein Feld ändern will, muss vorher `get-config` lesen und alles andere
+    unverändert zurückschreiben, sonst überschreibt man Felder mit Leerwerten. **(b)** Ein falsch
+    gesetztes `wifi_ssid`/`wifi_password` kappt die STA-Verbindung. Rettung wäre dann ausgerechnet der
+    AP — **der nicht abschaltbare AP ist die Rückfallebene.** Das ist das beste Argument, ihn zu lassen.
+  - 💡 **Zu Christophs Entwurfsidee („AP nur, wenn kein Link"):** das Muster ist Standard
+    (Captive-Portal-/WiFiManager-Fallback; Tasmota, ESPHome und viele ESP-Firmwares machen es so).
+    Dass Hoymiles es nicht tut, ist eine Herstellerentscheidung, kein technisches Hindernis — **und mit
+    dem Protokoll auf 10081 wäre es sogar unproblematisch**, weil die Konfiguration auch ohne AP
+    erreichbar bliebe. *(Mein früheres Gegenargument „dann käme man gar nicht mehr an die Konfiguration"
+    beruhte auf dem falschen Port-Befund und ist damit hinfällig.)*
+  - 🎯 ~~**Der Hebel, den es praktisch gibt: den AP-Kanal verschieben.**~~ 🔴 **WIDERLEGT am 2026-08-23 — s. Fehlschlag unten.** Ein ESP hat **ein** Radio —
+    **AP und STA laufen zwangsläufig auf demselben Kanal**. Der DTU-AP sitzt auf **ch1**, weil seine
+    STA-Verbindung an einem AP auf ch1 hängt. **Bindet man den Wechselrichter per `access-list` an ap2
+    (ch11), wandert sein AP mit.** Werkzeug wie in TP25 ([`tp25-pin-s22.sh`](tp25-pin-s22.sh)); seit
+    2026-08-23 steht `wifi-access-list` unter einer ComplianceRule, ist also transaktionsfähig.
+    📌 **Dieselbe Regel erklärt den Shelly s23:** wer den Störer verschieben will, verschiebt den
+    **Client**, nicht den AP.
+  - 🔴 **Nicht auf Verdacht am Gerät herumprobieren:** die PV-Datenstrecke ist produktiv.
+
+#### 🔴 Versuch „DTU an ap2 binden" — FEHLGESCHLAGEN und zurückgerollt (2026-08-23)
+
+**Auftrag:** den nicht abschaltbaren DTU-AP von ch1 wegbekommen, indem man den *Client* an ap2 (ch11)
+bindet — die Idee „verschieben statt abschalten" aus dem Absatz oben.
+
+**Ablauf:** Transaktion `TP17.1-dtu-pin-ap2` (Scope `wifi-access-list`) eröffnet, fünf
+`action=reject`-Regeln für `54:F2:9F:12:51:F0` auf ap1s 2,4-GHz-Interfaces per ConfigPlan deployt.
+Der DTU flog um **14:38:48** von `cap-wifi4-virtual1` (`disconnected, access-list changed, signal
+strength -51`) — **und kam nie bei ap2 an.** Nach 2,5 Minuten zurückgerollt; auch danach blieb er weg.
+
+🎯 **Die Ursache ist Christophs Verdacht, und sie ist am Protokoll belegbar: der DTU hat eine feste
+Kanalwahl.** `SetConfig.proto` kennt **`channel_select` (Feld 9)** und `netmode_select` (8). Zwei
+Beobachtungen bestätigen es:
+- Sein **eigener AP sendet auf ch1** — und ein ESP hat **ein** Radio, AP und STA teilen zwingend den
+  Kanal. Der AP auf 2412 heißt: **das Radio steht auf Kanal 1.**
+- Christophs Wiederverbinden über die **S-Miles-App** scheiterte mit „Verbindung fehlgeschlagen" —
+  das Symptom, das er von Frequenz-Fehlanpassungen kennt.
+
+⇒ **ap2 läuft auf ch11. Der DTU kann dort gar nicht assoziieren.** Die Sperre auf ap1 hat ihn deshalb
+nicht *umgeleitet*, sondern schlicht **ausgesperrt**.
+
+🔴 **Damit ist die Empfehlung „AP-Kanal verschieben, indem man den Client bindet" für dieses Gerät
+WIDERLEGT.** Sie gilt weiter für Geräte, die frei scannen (z.B. die Shellys) — **nicht** für ein
+Gerät mit fixierter Kanalwahl. Wer den DTU-AP wirklich von ch1 wegbekommen will, hat nur zwei Wege:
+**(a)** `channel_select` per `SetConfig` über Port 10081 ändern — ein Schreibvorgang am produktiven
+Wechselrichter, mit der bekannten Falle, dass `SetConfig` den *ganzen* Satz überträgt; oder
+**(b)** ap1 selbst auf einen anderen Kanal legen — dann folgt der DTU-AP dorthin, wo ap1 ist.
+*(b) ist der ungefährlichere Weg und wird mit dem Kanalplan für die zwei neuen APs ohnehin neu gestellt.*
+
+📌 **Zwei Merkregeln, die das gekostet hat:**
+1. **Ein `reject` auf AP A ist keine Umleitung auf AP B.** Es ist ein Rausschmiss — ob das Gerät
+   woanders unterkommt, ist seine Entscheidung, nicht unsere. Bei Geräten mit fixem Kanal, fixem
+   BSSID oder trägem Rescan ist die Antwort: **nirgends.** Das ist dieselbe Klasse wie die
+   TP25-Falle „ein abgewiesener Verbindungsversuch ist von einem Funkloch nicht zu unterscheiden".
+2. **Vor einem Pin prüfen, ob das Ziel überhaupt erreichbar ist** — also ob der Client den Kanal des
+   Ziel-APs benutzen *kann*. Der Beleg lag die ganze Zeit vor: der DTU-AP sendete auf **2412**, ap2
+   läuft auf **2462**. Das war vor dem Eingriff sichtbar und hätte ihn verhindert.
+⚠️ **Und die Abnahme war zu lasch:** „ap2 hört den DTU mit −59 dBm" belegt nur, dass ein *Pfad*
+existiert — nicht, dass der Client diesen Kanal benutzen darf. **Signalstärke ist kein Nachweis für
+Assoziationsfähigkeit.**
+
+🔴🔴 **Nachtrag, und er verschärft die Merkregel: das Gerät hat sich NICHT selbst erholt.**
+Auch nachdem die Sperre entfernt war und ap1 wieder frei auf ch1 sendete, blieb der DTU weg. Zurück
+kam er erst, als Christoph ihm über die **S-Miles-App die WLAN-Zugangsdaten erneut übergab** — „als
+wäre es ein neues WLAN". Danach war er binnen Sekunden wieder auf `cap-wifi4-virtual1` (ap1,
+`dirtyvader-iot`, −51 dBm).
+⇒ **Ein einmal abgewiesener DTU gibt seine gespeicherte Verbindung dauerhaft auf.** Ein `reject` gegen
+dieses Gerät ist damit **kein Experiment, sondern ein Ausfall mit Handarbeit als einzigem Rückweg** —
+und zwar Handarbeit, die nur jemand vor Ort mit der Hersteller-App leisten kann, nicht per Fernzugriff.
+**Für den produktiven PV-Datenpfad heißt das: die access-list ist für dieses Gerät gesperrtes Gebiet.**
+📌 Nebenbefund: dass die Re-Provisionierung auf ap1 (**ch1**) sofort funktionierte, während der
+Wechsel zu ap2 (**ch11**) scheiterte, stützt die Kanal-These zusätzlich — widerlegt sie jedenfalls nicht.
+
+#### 🔬 Auflösung: `get-config` gelesen — **es gibt KEINE feste Kanalwahl** (2026-08-23)
+
+**Read-only über Port 10081** abgefragt (`hoymiles-wifi` 0.5.6 in einem isolierten venv, nur
+`get-config`; Passwortfelder in der Ausgabe redigiert). Die 62 Felder der Antwort sagen:
+
+| Feld | Wert | Bedeutung |
+|---|---|---|
+| **`channel_select`** | **`0`** | 🎯 **kein fixer Kanal — 0 = automatisch** |
+| `netmode_select` | `1` | Netzmodus WLAN |
+| `wifi_ssid` | `dirtyvader-iot` | ✔ erwartet |
+| `dtu_ap_ssid` | `DTUBI-92337823` | ✔ der störende AP |
+| `dtu_ap_pass` / `lock_password` | gesetzt, aber nur **1 Zeichen** zurückgeliefert | ⚠️ mit hoher Wahrscheinlichkeit ein **maskierter Platzhalter**, kein echtes Ein-Zeichen-Passwort — **daraus KEINE Schwäche ableiten** |
+| `server_domain_name` · `serverport` | `dataeu.hoymiles.com` · `10081` | spricht weiterhin mit der Hoymiles-Cloud |
+| `wifi_ip_addr` | `10.40.30.8` | ✔ |
+
+🔴 **Damit ist Christophs These „die Kanalwahl ist fix eingebrannt" widerlegt** — und zwar an der
+Quelle, nicht durch Indizien. Seine *Beobachtung* war trotzdem richtig, nur die Ursache eine andere.
+
+✅ **Die tragfähige Erklärung ist stattdessen: das Gerät sucht nicht.** Es hält an dem AP fest, mit dem
+es provisioniert wurde, und **wenn der es abweist, gibt es auf statt sich einen anderen zu suchen** —
+exakt das beobachtete Verhalten (kam auch nach entfernter Sperre nicht zurück, brauchte eine
+Re-Provisionierung). Das ist typisch für einfache ESP-Firmware ohne Roaming-Logik. **Nicht der Kanal
+ist starr, sondern die AP-Bindung.**
+
+🎯 **Und das macht eine Option wieder lebendig, die ich vorschnell mitbeerdigt hatte:**
+**ap1s eigenen Kanal umzulegen wirkt.** Ohne `channel_select` folgt der DTU dem AP, an dem er hängt —
+wandert ap1 auf einen anderen Kanal, wandert der DTU-AP mit, ohne dass das Gerät je abgewiesen wird
+oder neu provisioniert werden muss. **Das ist der einzige risikoarme Weg, den Störer von ch1
+wegzubekommen** — und er fällt beim Kanalplan für die zwei neuen APs ohnehin an.
+⚠️ **Weiterhin gesperrt bleibt die `access-list`**: nicht wegen des Kanals, sondern wegen der
+Aufgeben-Eigenschaft. Ein `reject` gegen dieses Gerät kostet einen Vor-Ort-Einsatz.
+
+### Was das für die Zigbee-Kanalfrage heißt
+
+- Das Fenster **2426–2448** (WLAN ch4–8), in dem ZB **16/17/18** liegen, ist **belegt, aber nur
+  schwach** — alles dort ≤ **−81 dBm**. **ZB18 (2440) bleibt damit eine valide Option**, die Messung
+  widerlegt sie nicht.
+- **Handlungsdruck entsteht dadurch trotzdem nicht.** `PHY_CCA_FAIL_COUNT` = 4 gilt weiter; das ist
+  die Aussage über den Ort, der zählt (der Koordinator), während der Scan die Orte der **APs**
+  beschreibt. **ZHA bleibt auf 20.**
+
+### 📻 Nachtrag: Homematic / HmIP — **868 MHz, damit außerhalb dieser Rechnung**
+
+**Christophs Ergänzung 2026-08-23.** Live nachgesehen: Integration `homematicip_local` an der CCU
+**`ccu.emsenhuber.net`** (RaspberryMatic, Technik UG, `10.40.20.232`) mit **37 Geräten** im
+Mischbetrieb — **Homematic classic** (BidCoS-RF, z.B. `HM-LC-Sw1-FM` „WC Lüfter", zentrale
+`HM-RCV-50`) **und HmIP** (u.a. `HmIP-HEATING` je Raum = die Heizungssteuerung).
+
+✅ **Für die Kanalplanung ist das eine Entlastung:** beide Funkstandards liegen im **868-MHz-Band**
+(SRD860), nicht bei 2,4 GHz. **Homematic stört Zigbee, Thread und WLAN nicht — und wird von ihnen
+nicht gestört.** Es ändert an der Tabelle oben nichts.
+
+⚠️ **Aber es ist ein fünftes Funkökosystem im Haus** (WLAN 2,4 · WLAN 5 · Zigbee ×2 · Thread ·
+Homematic) — und es hat **seinen eigenen Ausfallmodus, der dem Broadcast-Sturm entspricht:** das
+868-MHz-Band ist gesetzlich auf **1 % Duty Cycle** begrenzt. Wird das überschritten, stellt die
+Zentrale das Senden **minutenlang ein** — Symptom: „Befehle kommen nicht an, aber alles ist online".
+🔎 **Merkregel: bei Homematic-Aussetzern zuerst den Duty Cycle der CCU ansehen, nicht die
+Funkabdeckung.** Ausgelöst wird er typischerweise durch zu häufige Sollwert-Schreibvorgänge —
+also durch Automationen, nicht durch Geräte.
+
+📌 **Bezug zu TP29** (Anwesenheitserkennung fürs Energiesparen): die `HmIP-HEATING`-Geräte **sind**
+der Aktor, den TP29 ansteuern würde. Wer dort präsenzabhängig regelt, schreibt Sollwerte — und läuft
+damit genau in die Duty-Cycle-Grenze. **Das gehört in TP29s Entwurf, bevor die erste Automation
+scharf geht.**
+### 🆕 Und was die zwei neuen APs damit zu tun haben
+
+**Sehr viel — das ist der Punkt, an dem die AP-Frage und die Zigbee-Frage dieselbe Frage werden.**
+
+2,4 GHz hat **drei** überlappungsfreie Kanäle: 1, 6, 11. Heute belegt das Haus **zwei** davon
+(ap1 = 1, ap2 = 11) und lässt **ch6 frei** — genau das Fenster, in dem ZB 16/17/18 liegen.
+
+🔴 **Kommen zwei APs dazu und funken alle vier auf 2,4 GHz, ist ch6 belegt.** Damit fällt ein
+ZHA-Umzug auf 18 aus, und **ZB20 (zwischen 6 und 11) sowie ZB25 (über 11) sind dann die einzigen
+richtigen Plätze** — also exakt die heutige Belegung. *Die aktuelle Konfiguration wäre dann nicht nur
+vertretbar, sondern die einzig sinnvolle.*
+
+💡 **Empfehlung für den AP-Aufbau, die beides löst:** **2,4 GHz nicht auf allen vier APs betreiben.**
+Vier 2,4-GHz-Zellen auf drei Kanälen stören sich zwangsläufig selbst, und die Reichweite von 2,4 GHz
+ist so groß, dass zwei Zellen die Wohnung ohnehin abdecken — die IoT-Geräte hängen heute an
+**zwei** APs und kommen zurecht. Die beiden neuen APs also als **5-GHz-Schwerpunkt** betreiben
+(2,4 GHz aus oder stark reduziert). Das
+- hält **ch6 frei** und damit die Zigbee-Option offen,
+- vermeidet Selbststörung im vollsten Band,
+- und legt die neue Kapazität dorthin, wo sie tatsächlich fehlt: **5 GHz an den Rändern** (TP25:
+  die Redundanz ist der Schwachpunkt, nicht die Abdeckung).
+### 5 GHz — gemessen 2026-08-23, das Band ist praktisch leer
+
+| Kanal | Fremdnetz | Signal |
+|---|---|---|
+| 5180 (ch36) | dahoam is dahoam-5G | −89 |
+| 5200 (ch40) | LiwestBB93-5G | −88 |
+| **5500 (ch100, DFS)** | meins.liwest | −83 |
+
+⇒ **Drei Fremdnetze, alle ≤ −83 dBm.** 5 GHz ist hier faktisch unbelegt — die neue Kapazität hat also
+Platz, und der Vorschlag „neue APs als 5-GHz-Schwerpunkt" ist damit auch messtechnisch gedeckt.
+
+🔴 **Aber die Kanäle werden knapp, und das ist die Planungsaussage:** unter ETSI gibt es im
+**Indoor-Band 5180–5240** bei 40 MHz genau **zwei** überlappungsfreie Blöcke — `5180/Ce` (ap1) und
+`5220/Ce` (ap2). **Beide sind vergeben.** Ein dritter und vierter AP muss auf 5 GHz also ins
+**DFS-Band (5500–5700)** ausweichen — dort liegen laut TP25-Analyse **11 zusätzliche Kanäle**, in ETSI
+ohne `/I`-Leistungsbeschränkung.
+✅ **Und DFS ist in dieser Lage nachweislich nutzbar:** der Nachbar `meins.liwest` funkt auf **5500**.
+⚠️ Preis bleibt die CAC-Wartezeit beim Start und ein erzwungener Kanalwechsel im Radar-Fall (30 min
+Sperre). Der TP25-Vorbehalt dagegen („bei Abbruch-Symptomatik unangenehm") ist seit dem Terrassen-Fix
+vom 08-22 **schwächer geworden** — die Abwägung gehört neu geführt, wenn die zwei APs bleiben.
+---
+
+## 🔌 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.**
+
+**Der J6-Header** (7-polig, 1,27 mm Raster, auf der Rückseite der Platine):
+
+| Pin | Funktion | GPIO |
+|---|---|---|
+| 2 | **TXD** → RXD des Adapters | GPIO16 |
+| 3 | **RXD** ← TXD des Adapters | GPIO17 |
+| 4 | **3,3 V** — Versorgung vom Adapter | — |
+| 6 | **BOOT** — muss beim Einschalten **LOW** sein | GPIO0 |
+| 7 | **GND** | — |
+
+**Der Ablauf je Gerät:** Modul stromlos machen und **ausbauen** → Gehäuse öffnen → fünf Pins an einen
+USB-UART-Adapter (**3,3 V, kein 5 V!**) → **GPIO0 beim Anlegen der Versorgung auf LOW** ziehen →
+`esptool.py read_flash` über die vollen **8 MB** → das Image wegsichern → dann erst flashen.
+
+- ⚡ **Nicht am Netz.** Die Versorgung kommt beim Flashen vom Adapter, nicht von 230 V — das Gerät muss
+  also aus der Wand.
+- 🔘 **Kein Reset-Knopf.** Der ESP32-C6 geht über die Strapping-Leitung in den Download-Modus. Viele
+  Adapter schalten das per **DTR/RTS** automatisch; ob das an diesem J6 durchgeschleift ist, steht
+  nicht in der Doku — **am ersten Gerät ausprobieren**, sonst GPIO0 von Hand nach GND brücken.
+- ✅ **Danach nie wieder UART.** Alle weiteren Updates laufen **OTA** (Matter-OTA, Dashboard-Upload).
+  Der Aufwand fällt **einmal je Gerät** an, nicht bei jedem Update.
+- 🔁 **Recovery** = dasselbe Prozedere rückwärts, mit dem gesicherten 8-MB-Image. Bricht dabei der
+  Strom weg, während der Bootloader geschrieben wird, ist das Gerät **nur noch per UART** zu retten —
+  ein zweites Mal öffnen, kein Weg über die Luft.
+- ⚠️ **Der Weg ohne UART existiert** (Paket über die Shelly-Web-UI hochladen), **kann aber kein Backup
+  erzeugen** und ist damit praktisch einseitig.
+
+🎯 **Konsequenz für die Wegwahl:** die Frage „wie viele Module sitzen Unterputz hinter einem Schalter"
+entscheidet über den Aufwand von Weg (C) mehr als alles andere. **Weg (A) Zigbee braucht davon
+nichts** — das ist ein normales Update über den Hersteller-Kanal.
+---
+
+## Vorbedingungen aus dem Netz (stehen bereits, nur für den Thread-Weg relevant)
+
+- ✅ **Thread-Border-Router läuft**, ~30 Matter-Knoten produktiv (OTBR auf demselben Host wie HA).
+- ✅ **Commissioning-Pfad erprobt:** temporäre SSID `dirtyvader-infra` (VLAN20) nach
+  [`matter-pairing-infra-ssid-runbook.md`](matter-pairing-infra-ssid-runbook.md) — am 2026-08-22 mit
+  dem TIMMERFLOTTE bewiesen. `cfg-infra`/`dp-infra`/`sec-infra` stehen dauerhaft am Manager.
+- 🔴 **Nötig ist der Umweg, weil TP12.1 offen ist:** zwischen VLAN10 (iPhone) und VLAN20 (Border
+  Router) wird **kein IPv6 geroutet** → Commissioning-Etappe 2 bricht ab. Und `ble_proxy` ist
+  wirkungslos, seit der ESP32-BT-Proxy ausgeschlossen wurde (User 2026-08-22).
+  ⇒ **Jedes weitere Thread-Gerät zahlt diesen Umweg erneut** — das stärkste Argument für TP12.1.
+- ⚠️ **Firewall ist deny-by-default** — ein neuer Dienst über eine VLAN-Grenze braucht eine explizite
+  Regel. Für den **Zigbee**-Weg heißt das: der Pfad Gerät → Z2M (`10.40.20.106`) läuft über den
+  Zigbee-Koordinator, nicht über IP — es entsteht **kein** neuer VLAN-Übergang. Ein Punkt weniger.
+
+---
+
+## Ablauf
+
+**Schritt 0 — entscheiden, nicht flashen.** Weg (A), (B) oder (C). Grundlage ist die Tabelle oben.
+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.** ▶️ **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.
+
+#### ✅ 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.
+
+**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
+`ha-xstate`-Repo (`machines/*.json`). **Erst wenn der Pilot in HA vollständig verdrahtet ist**, war er
+erfolgreich.
+
+**Schritt 3 — Wellen zu 3–4 Geräten**, nach Raum gruppiert, gleiches Abnahmekriterium.
+
+**Schritt 4 — Zahl zurückmelden:** wie viele Geräte sind aus `dirtyvader-iot` verschwunden. Diese Zahl
+macht die PSK-Rotation planbar.
+
+### Abnahmekriterium
+
+**Pro Gerät ein frischer Knoten im Zielnetz UND eine funktionierende HA-Entity** — nicht die Anzeige
+in einer Tabelle. Im Netz-Projekt hat genau diese Verwechslung einmal **14 Stunden** gekostet: die
+Registration-Table zeigte 25 zufriedene Clients, während keiner davon eine IP bekam.
+
+---
+
+## Verzahnung mit der PSK-Rotation (parallel, nicht nacheinander)
+
+**User-Entscheid 2026-08-23:** beides läuft **gleichzeitig**. Möglich macht das der
+**Passphrase-Override je MAC** in `/interface wifi access-list` (RouterOS 7): neuer PSK aufs Profil,
+noch nicht migrierte Geräte übergangsweise per MAC mit dem alten weiter, danach Liste leeren — **kein
+Flag-Day**.
+
+🔑 **Die eine Regel, die die Parallelität kostenlos macht:** ein Gerät, das ohnehin den Funk wechselt,
+bekommt den **neuen PSK gar nicht** — nur einen Übergangseintrag, und verschwindet später ganz.
+
+⚠️ **Nicht vergessen:** `s1`/`s2`/`s3` sind ausgesteckt und **in HA nicht eingebunden**. Sie kommen
+beim nächsten Einstecken mit dem **alten** PSK zurück — sie gehören auf die Override-Liste, sonst
+stehen sie im Dezember im AP-Mode.
+
+---
+
+## Offene Fragen für die erste Sitzung
+
+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`
+   (OUI = Brother Industries), ARP-Status `delay` = aktiv, **keine DHCP-Reservierung** (statisch
+   konfiguriert). Beide Angaben waren richtig, sie meinten verschiedene Geräte.
+   📌 **Für TP5 relevant:** die Merkregel „Drucker fällt mit **udp/161 SNMP** aus, nicht mit 631"
+   (`ref_printer_snmp_before_ipp`) betrifft den **VLAN-übergreifenden** Fall. Der MFC steht im
+   **selben VLAN** wie die Macs — dort greift die `forward`-Kette gar nicht.
+
+---
+
+## Verweise
+
+- Steuerung: [`teilprojekte.md`](teilprojekte.md) → **TP17.1**, **TP12.1** (IPv6/Matter),
+  Follow-up **PSK-Rotation**
+- Migrationshistorie der Shellys (VLAN1 → VLAN30, 26 Geräte, 0 Fehler) inkl. Anker-Verfahren gegen den
+  AP-Mode-Fallstrick: [`teilprojekte-archiv.md` → TP17](teilprojekte-archiv.md#tp17)
+- Werkzeug: `mcp/shelly/` — `discover.py` (read-only), `migrate.py` (Dry-Run default).
+  ⚠️ **Kein Rotate-Kommando vorhanden**, es bräuchte eine Variante über denselben `set_sta`-Pfad.
+- HA-Seite: `~/dev/ha-xstate` (FSM-Configs `machines/*.json`)