diff --git a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md
index 4aa5983..8542fcd 100644
--- a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md
+++ b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md
@@ -409,7 +409,7 @@ Einzelfall ist erklärt.
     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.** Ein ESP hat **ein** Radio —
+  - 🎯 ~~**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
@@ -418,6 +418,47 @@ Einzelfall ist erklärt.
     **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.**
+
 ### 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
diff --git a/docs/transaktionen/TP17.1-dtu-pin-ap2.json b/docs/transaktionen/TP17.1-dtu-pin-ap2.json
new file mode 100644
index 0000000..969ad58
--- /dev/null
+++ b/docs/transaktionen/TP17.1-dtu-pin-ap2.json
@@ -0,0 +1,14 @@
+{
+  "change_id": "TP17.1-dtu-pin-ap2",
+  "device": "crs326-core",
+  "scope": "wifi-access-list",
+  "match_config": [
+    "/interface wifi access-list"
+  ],
+  "reason": "DTU/Wechselrichter (54:F2:9F:12:51:F0) per access-list an ap2 binden. Grund: ein ESP hat EIN Radio, AP und STA teilen den Kanal -- der nicht abschaltbare DTU-AP sitzt auf ch1 (ap1) und stoert dort mit -59 dBm. Ueber ap2 wandert er auf ch11. Ist der Kanalplan nach dem Einbau der zwei neuen APs entschieden, wird das neu bewertet: entweder committen oder zurueckrollen.",
+  "started": "2026-08-23",
+  "expires": "2026-09-06",
+  "state": "open",
+  "snapshot": "docs/transaktionen/TP17.1-dtu-pin-ap2.snapshot.rsc",
+  "device_backup": ""
+}
diff --git a/docs/transaktionen/TP17.1-dtu-pin-ap2.snapshot.rsc b/docs/transaktionen/TP17.1-dtu-pin-ap2.snapshot.rsc
new file mode 100644
index 0000000..e66d501
--- /dev/null
+++ b/docs/transaktionen/TP17.1-dtu-pin-ap2.snapshot.rsc
@@ -0,0 +1,4 @@
+# Snapshot des Scopes 'wifi-access-list' auf crs326-core, 2026-08-23 (Transaktion TP17.1-dtu-pin-ap2)
+# Bewusst NUR dieser Abschnitt — der Vollexport gehoert nicht ins Repo.
+
+