diff --git a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md
index 8425a53..57a2aa0 100644
--- a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md
+++ b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md
@@ -471,6 +471,38 @@ und zwar Handarbeit, die nur jemand vor Ort mit der Hersteller-App leisten kann,
 📌 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