TP17.1: 2,4-GHz-Bild vollstaendig, UART-Prozedur, zwei Drucker geklaert

Alle vier Funknetze live erhoben: WLAN ap1 ch1 / ap2 ch11, Thread (OTBR) ch15,
ZHA ch20, Z2M ch25. Es sind DREI 802.15.4-Netze, nicht eines -- das war in der
bisherigen Planung nicht abgebildet.

Befund: das Band ist gut geplant bis auf ZHA ch20 (2450), das direkt auf der
Unterkante von WLAN ch11 (2451) sitzt -- ausgerechnet 52 ZHA-Geraete gegen den AP
mit 26 Clients. Thread ch15 und Z2M ch25 liegen je 2 MHz ausserhalb einer
WLAN-Bandkante, also sauber. Die Luecke 2423-2451 (ZB 16/17/18) ist unbenutzt,
aber ein Kanalwechsel muessen 52 Geraete mitmachen -- erst Energy-Scan.

Z2M-Vorbehalt aus dem 2024-Vorfall als eigenes Kapitel: die Fehlerklasse ist
benennbar (Broadcast-/Routing-Sturm, trifft ZHA genauso), der Root Cause aber
nicht mehr rekonstruierbar. Mitigation ohne Ursachenkenntnis = Blast Radius
trennen: die zehn neuen Router komplett in EIN Zigbee-Netz, und zwar nicht in
das, das Licht und Fernbedienungen traegt. Dazu einzeln joinen, Backup vorher,
keine Gruppen-Bindings, Abbruchkriterium vorher festlegen.

UART-Prozedur konkret dokumentiert: J6-Pinout (TXD GPIO16, RXD GPIO17, 3V3, GPIO0
als BOOT, GND), GPIO0 beim Einschalten LOW, Versorgung vom Adapter statt Netz,
Geraet muss aus der Wand. Kein Reset-Knopf. Faellt einmal je Geraet an, danach
alles OTA. Recovery = dasselbe rueckwaerts mit dem 8-MB-Image.

Zwei Korrekturen von Christoph uebernommen:
- Es gibt ZWEI Drucker. P750W = Etikettendrucker auf VLAN30 (stimmte), der
  eigentliche Brother MFC haengt auf VLAN10 -- live bestaetigt 10.40.10.6, OUI
  Brother, statisch. Auch in CLAUDE.md eingetragen, samt der Folge fuer TP5: der
  MFC steht im selben VLAN wie die Macs, die forward-Kette greift dort nicht.
- s1/s2/s3 (weihnachten) sind in HA DEAKTIVIERT, nicht fehlend. Meine Formulierung
  "existieren gar nicht" war falsch -- deaktivierte Entities haben keinen Zustand.

Entity-Bruch entschaerft: der Umbau behaelt die Entity-Namen (User-Entscheid).
Damit faellt der teuerste Posten der Abwaegung weg, fuer Zigbee wie fuer Thread.
Zwei Fallen dazu notiert (alte entity_id erst nach Entfernen frei; unique_id und
Statistiken sind trotzdem neu).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -103,5 +103,10 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
 - **✅✅ Edge-Cutover (2026-07-01; Router-Umzug 2026-08-08): FritzBox ausgebaut, Arris im Bridge-Mode.** Liwest hat die FB6660 dauerhaft gegen ein Arris getauscht (physisch weg). WAN terminiert auf **`crs326-core vlan100`** (VLAN100-Transfer), core zieht die öffentliche Liwest-IP `90.146.33.177` → kein Double-NAT. **core = Public-Edge + WG-Hub** (fm/dw live), NICHT mehr ap1. Telefonie nicht weitergeführt. Runbook `routeros/wan-cutover-runbook.md` (ap1-Teile historisch).
 - **hAP `device-mode=home` (ap1/ap2): scheduler + fetch blockiert** (`not allowed by device-mode`) → AP-Provisionierung idempotent **ohne** Scheduler. **`[/ping]` gibt nil in 7.23**. REST je AP `http://10.40.99.11|12/rest` (Creds = `ROUTER_AP{1,2}` in `~/.claude.json`). **Der L3-Router crs326-core ist KEIN device-mode=home** → dort gehen scheduler/fetch (z.B. DDNS-Updater).
 - **Erstzugriff Werks-hAP am CRS-Fabric:** Uplink `ether1` = Werks-WAN → `192.168.88.1` (LAN) darüber NICHT erreichbar. Weg: Gerät auf **LAN-Port (ether2)** patchen ODER **Core-Temp-Pfad** `192.168.88.2/24` auf core-`bridge` + srcnat masq `192.168.88.0/24`, dann scp+`/import` (danach Temp-Pfad + stale ARP `.88.1` entfernen). Winbox-Neighbors zeigt die APs NICHT (MNDP pro-VLAN, Mgmt auf vlan99) — kein L2-Fehler.
+- 🖨️ **ZWEI Drucker, nicht verwechseln (geklärt 2026-08-23):** der **Brother MFC** ist der
+  *eigentliche* Drucker und hängt auf **VLAN10** (`10.40.10.6`, MAC `30:05:5C:78:86:20`, **statisch**,
+  keine DHCP-Reservierung) — er steht damit im *selben* VLAN wie die Macs, die `forward`-Kette greift
+  dort gar nicht. Der **P750W ist der Etikettendrucker** auf **VLAN30** (`10.40.30.5`) — nur für ihn
+  gilt der VLAN-übergreifende SNMP-Fall unten.
 - **P750W (Brother, VLAN30) läuft auf `dirtyvader-iot`** (User-bestätigt 2026-08-08) — **kein** Access-List-Pin nötig; die alte „nur am co-located L3-GW-AP erreichbar"-Logik ist mit L3-GW auf dem Core hinfällig. Coverage-Kanten/Terrasse grenzwertig (−76..−89 dBm); TX am AT-Max (18/15 dBm); echter Fix = Platzierung. SSoT `docs/wifi-p750w-coverage-and-map.md`. ⚠️ **Power-Save ist KEIN Thema dieses Netzes** — die früher hier stehende Merkregel „DHCP-geht-aber-Ping-nicht = ARP/Power-Save" war eine Fehldiagnose (2026-08-13 korrigiert: der Drucker war schlicht ausgeschaltet, das Ping-Symptom war WARP, s.u.). Nicht wieder einführen.
 - **Ping auf JEDE lokale IP tot, aber Web/App/Print (TCP) geht überall = WARP-Client lokal versehentlich noch aktiv** (2026-08-13 live beobachtet, BF vor Ort): `cloudflared`/WARP ist QUIC-Proxy, kann **kein ICMP**, reicht TCP aber durch — auch wenn man physisch im BF-LAN steht, nimmt der Client bei aktivem WARP trotzdem den Tunnel-Umweg. **Fix: WARP trennen**, kein Router-Eingriff nötig. **Vor jeder Firewall-/Mangle-/VLAN-Suche zuerst prüfen**, wenn das Symptom „Ping auf ALLES tot, TCP geht" lautet — das ist ein Client-, kein Netzproblem. Strukturell schließt **TP16.1** (natives WireGuard-CF-Mesh auf `crs326-core` statt cloudflared-QUIC) genau diese ICMP-Lücke. Memory `ref_warp_local_icmp_trap`.

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

@@ -38,8 +38,8 @@ s18 kueche_steckdosen1 `.225` · s19 kueche_steckdosen3 `.226` · s26 bad_luefte
 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 — **in HA gar nicht
-eingebunden**) und **`s4 kueche_mikrowelle`** — der einzige, den auch HA als `unavailable` führt.
+**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.
 
@@ -81,14 +81,140 @@ oben** — heute, mit Hersteller-Firmware, ohne Garantieverlust, ohne UART-Backu
 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:** Zigbee und WLAN teilen sich 2,4 GHz. Ohne Plan gegen `dirtyvader-iot`
-  (**ap1 ch1 / ap2 ch11**) tauscht man Funklast gegen **Funkstörung**. Zigbee-Kanäle 15/20/25 liegen
-  zwischen bzw. über den WLAN-Kanälen — das ist der Rechenschritt, nicht der Bauchentscheid.
-- **(c) Entity-Bruch:** derselbe wie bei Matter. Er ist der Preis jedes Funkwechsels, nicht ein
-  Argument für einen bestimmten Weg.
+- **(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).** Das ist die einzige
+  echte Nachbarschaft im Haus — und sie trifft ausgerechnet das Netz mit **52 Geräten** gegen den AP
+  mit **26 Clients**.
+- 💡 **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**,
+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.
+
+---
+
+## ⚠️ 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.
+
+---
+
+## 🔌 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).
@@ -157,10 +283,14 @@ stehen sie im Dezember im AP-Mode.
    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?
-4. 🖨️ **Ungeklärt:** Christoph nennt den **P750W auf VLAN10**, das Gerät sagt **VLAN30**
-   (Reservierung `10.40.30.5` auf `dhcp-v30`, ARP `vlan30`, derzeit aus, last-seen 3d15h) — und
-   `CLAUDE.md` sagt seit 08-08 dasselbe. Geplanter Umzug oder Verwechslung mit dem druckenden Mac
-   (`10.40.10.82`)? **Vor der nächsten Firewall-Regel klären.**
+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.
 
 ---