Aufloesung am Geraet: channel_select=0 -- keine feste Kanalwahl

get-config read-only ueber Port 10081 abgefragt (hoymiles-wifi 0.5.6, isoliertes venv,
nur lesende Kommandos, Passwortfelder in der Ausgabe redigiert).

channel_select = 0. Damit ist Christophs These "Kanalwahl fix eingebrannt" widerlegt,
und zwar an der Quelle statt durch Indizien. Seine Beobachtung war trotzdem richtig,
nur die Ursache eine andere.

Die tragfaehige Erklaerung: das Geraet sucht nicht. Es haelt an dem AP fest, mit dem es
provisioniert wurde, und gibt auf, wenn der es abweist, statt sich einen anderen zu
suchen -- genau das beobachtete Verhalten. Nicht der Kanal ist starr, sondern die
AP-Bindung. Typisch fuer einfache ESP-Firmware ohne Roaming-Logik.

Folge, die eine Option wiederbelebt: ap1s eigenen Kanal umzulegen wirkt. Ohne
channel_select folgt der DTU dem AP, an dem er haengt -- der Stoerer wandert mit, ohne
dass das Geraet je abgewiesen wird oder neu provisioniert werden muss. Das ist der
einzige risikoarme Weg, ihn von ch1 wegzubekommen, und er faellt beim Kanalplan fuer
die zwei neuen APs ohnehin an.

Die access-list bleibt gesperrt -- nicht wegen des Kanals, sondern wegen der
Aufgeben-Eigenschaft.

Nebenbefund mit Vorsicht notiert: dtu_ap_pass und lock_password liefern nur 1 Zeichen
zurueck, mit hoher Wahrscheinlichkeit ein maskierter Platzhalter. Daraus wird
ausdruecklich KEINE Passwortschwaeche abgeleitet.

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

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