diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md
index 2e574f5..c08204a 100644
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -443,24 +443,42 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
     Mesh-Stabilität, Funkruhe im 2,4-GHz-WLAN — und zwar **heute, mit Hersteller-Firmware über den
     offiziellen Kanal**, also ohne Garantieverlust, ohne UART-Backup, ohne Test-VID. Die Infrastruktur
     steht bereits: **Zigbee2MQTT läuft als LXC 112 (`10.40.20.106`, `z2m25`)**.
-    ⚠️ **Zu prüfen, bevor das zur Empfehlung wird:** (a) ob die Alt-Firmware genauso zurückrollbar ist
-    wie ein normales Update (Wechsel des Funkstacks, nicht nur der Version); (b) der Entity-Bruch ist
-    derselbe wie bei Matter (Shelly-Integration → Z2M); (c) Zigbee und WLAN teilen sich 2,4 GHz —
-    Kanalplanung gegen `dirtyvader-iot` (ap1 ch1 / ap2 ch11) nötig, sonst tauscht man Funklast gegen
-    Funkstörung. **Das ist die Abwägung, die vor dem Dritt-Firmware-Pfad geführt gehört.**
+    ⚠️ **Zu prüfen, bevor das zur Empfehlung wird:** **(a)** ob die Alt-Firmware genauso zurückrollbar
+    ist wie ein normales Update (Wechsel des Funkstacks, nicht nur der Version) — **offen**;
+    **(b)** ~~der Entity-Bruch~~ ✅ **entschärft (User 2026-08-23): der Umbau behält die
+    Entity-Namen** — damit fällt der teuerste Posten der Abwägung weg, für Zigbee **und** Thread
+    gleichermaßen *(zwei Fallen dazu im Runbook: die alte `entity_id` ist erst nach dem Entfernen
+    frei, und `unique_id`/Statistiken sind trotzdem neu)*;
+    **(c)** Kanalplanung ✅ **erhoben 2026-08-23** — es gibt **drei** 802.15.4-Netze, nicht eines:
+    **Thread 15** (~30 Matter-Knoten), **ZHA 20** (**52 Geräte**, SONOFF Dongle-M über
+    `socket://10.40.30.137:6638`), **Z2M 25** (Sonoff Dongle Plus). Gegen WLAN **ap1 ch1 / ap2 ch11**
+    ist das sauber — **außer ZHA ch20 (2450), das direkt auf der Unterkante von WLAN ch11 (2451)
+    sitzt**, ausgerechnet 52 Geräte gegen den AP mit 26 Clients. Die Lücke 2423–2451 (ZB 16/17/18) ist
+    unbenutzt; ⚠️ ein ZHA-Kanalwechsel müsste von 52 Geräten mitgemacht werden, schlafende und ältere
+    Router folgen nicht zuverlässig → **erst Energy-Scan, dann entscheiden.**
+    🔴 **Und der Vorbehalt, der schwerer wiegt als alle drei: Christophs Z2M-Vorfall von 2024**
+    („Lichterdisko", Installation unsteuerbar, Neuaufbau). Fehlerklasse ist benennbar
+    (Broadcast-/Routing-Sturm — trifft ZHA genauso), Root Cause nicht mehr rekonstruierbar.
+    ⇒ **Mitigation ohne Ursachenkenntnis = Blast Radius trennen:** die zehn neuen Router komplett in
+    **ein** Zigbee-Netz, und zwar in das, das **nicht** Licht und Fernbedienungen trägt. Details und
+    Abbruchkriterium im Runbook.
 - 🩺 **HA-Gegencheck 2026-08-23: genau EIN Shelly ist offline** — `s4 kueche_mikrowelle` (23 Entities
   `unavailable`). Deckungsgleich mit dem Netz-Sweep, und es ist dasselbe Gerät, das bei **RSSI −93**
-  hinter Metall hängt. **s1/s2/s3 (`weihnachten_*`) existieren in HA gar nicht** — sie sind also nicht
-  „offline", sondern nie/nicht mehr eingebunden; im Inventar stehen sie weiter. ⇒ Für die
+  hinter Metall hängt. **s1/s2/s3 (`weihnachten_*`) sind in HA nur DEAKTIVIERT**, nicht gelöscht
+  (Christoph 2026-08-23) — deaktivierte Entities haben keinen Zustand und tauchen deshalb in keiner
+  Zustandssuche auf. Die Entities gibt es also zu Recht; sie kommen mit den Geräten zurück.
+  *(Meine erste Formulierung „existieren gar nicht" war falsch.)* ⇒ Für die
   PSK-Rotation heißt das: **drei Geräte, die niemand vermisst, aber die beim nächsten Einstecken mit
   dem alten PSK kommen.** Genau dafür ist die Übergangs-`access-list` da.
-- 🖨️ **Korrektur zur Geräteliste auf `dirtyvader-iot`:** der **P750W hängt auf VLAN30, nicht VLAN10**
-  (live 2026-08-23: Reservierung `10.40.30.5` auf `dhcp-v30`, ARP auf `vlan30`, `status=failed`,
-  `last-seen 3d15h` = **derzeit ausgeschaltet**, deshalb nicht unter den 26 assoziierten Clients).
-  ⚠️ Christoph hat am 08-23 „Drucker hängt auf VLAN10" gesagt — **das Gerät sagt etwas anderes**, und
-  `CLAUDE.md` sagt seit 08-08 ebenfalls VLAN30. Entweder ist ein Umzug geplant/gedacht und noch nicht
-  passiert, oder es ist eine Verwechslung mit dem **druckenden Mac** (der ist auf VLAN10). **Nicht
-  stillschweigend angeglichen** — zu klären, bevor jemand daraus eine Firewall-Regel ableitet.
+- 🖨️ **Es gibt ZWEI Drucker — geklärt 2026-08-23, beide Angaben waren richtig:**
+  **(1) P750W = Etikettendrucker, VLAN30** (`10.40.30.5`, Reservierung auf `dhcp-v30`, ARP `vlan30`;
+  am 08-23 aus, `last-seen 3d15h` — deshalb nicht unter den 26 assoziierten Clients).
+  **(2) Brother MFC = der eigentliche Drucker, VLAN10** — live bestätigt `10.40.10.6`, MAC
+  `30:05:5C:78:86:20` (OUI Brother Industries), ARP `delay` = aktiv, **statisch konfiguriert, keine
+  DHCP-Reservierung**.
+  📌 **Folge für TP5:** die Merkregel „Drucker fällt mit **udp/161 (SNMP)** aus, nicht mit 631"
+  (`ref_printer_snmp_before_ipp`) gilt dem **VLAN-übergreifenden** Fall. Der MFC steht im **selben
+  VLAN** wie die Macs — dort greift die `forward`-Kette gar nicht.
 - 🔀 **Reihenfolge revidiert (User 2026-08-23): PSK-Rotation und Thread-Umstellung laufen PARALLEL.**
   Sie blockieren einander nicht — der Passphrase-Override je MAC (`/interface wifi access-list`,
   s. Follow-up) macht den Flag-Day überflüssig: neuer PSK aufs Profil, die noch nicht migrierten