DTU geklaert: AP laesst sich nicht abschalten, ist aber verschluesselt und verschiebbar

Am Geraet geprueft und recherchiert. Es ist kein separater DTU-Kasten, sondern der
Wechselrichter mit eingebautem DTU -- daher DTUBI, Built-In.

Abschalten: existiert nicht. Hoymiles bietet keine Funktion dafuer an, im
Herstellerumfeld wird sie von Nutzern gefordert. Christophs Recherche hat nichts
gefunden, weil es nichts zu finden gibt.

Entwarnung: der AP ist bereits verschluesselt (wpa2-psk;wpa-psk). Der bekannte Fall
"Hoymiles-DTU funkt ein offenes WLAN" trifft hier nicht zu. Ab FW 3.0.8 gibt es die
AP-Passwort-Einstellung, die offenbar gesetzt ist.

Die Fallback-Idee (AP nur wenn kein Link) ist ein Standardmuster, aber hier mit
Haken: das Geraet hat LAN-seitig null offene TCP-Ports -- geprueft, nur ICMP
antwortet, Daten kommen per MQTT-Push. Die Weboberflaeche existiert ausschliesslich
auf dem AP. Bei funktionierender STA-Verbindung waere sie damit unerreichbar, obwohl
man sie genau dann braucht.

Der Hebel, den es stattdessen gibt: ein ESP hat ein Radio, AP und STA laufen
zwangslaeufig auf demselben Kanal. Der DTU-AP sitzt auf ch1, weil seine STA-Verbindung
dort haengt. Bindet man den Wechselrichter per access-list an ap2, wandert sein AP
mit. Nicht abschaltbar, aber verschiebbar -- und dieselbe Regel erklaert den Shelly
s23: wer den Stoerer verschieben will, verschiebt den Client.

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

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

@@ -365,14 +365,39 @@ Reparatur sein.** Vor dem Aufräumen fragen, wozu er da ist — nicht, ob er ins
 ⇒ **Der Anker-Sweep bleibt trotzdem sinnvoll** und ist am 2026-08-23 gelaufen: **s23 ist der einzige
 Shelly mit aktivem AP**, alle anderen 21 sind sauber de-anchored. Die Sorge war unbegründet, der
 Einzelfall ist erklärt.
-- ☀️ **Die DTU ist ein anderer Fall — und sie bleibt vorerst, wie sie ist (User 2026-08-23):** sie
-  gehört zur **PV-Anlage**, ihr AP *ist* deren Konfigurationsnetz, und die Messdaten kommen ohnehin
-  über `dirtyvader-iot` an. Ein Weg, den AP abzuschalten, ist nicht bekannt.
-  🔴 **Nicht auf Verdacht daran drehen:** die PV-Datenstrecke ist produktiv und gehört niemandem hier
-  im Netz — ein abgeschalteter Konfig-AP kann die einzige Rückfallebene sein, wenn die DTU je den
-  WLAN-Zugang verliert. **Als bekannter Dauersender auf ch1 dokumentieren, nicht bekämpfen.**
-  *(Falls es je juckt: erst in der Hoymiles-/S-Miles-App nachsehen, ob der AP dort deaktivierbar ist —
-  nicht am Gerät herumprobieren.)*
+- ☀️ **Die DTU: abschalten geht nicht — recherchiert und am Gerät geprüft (2026-08-23).**
+  Es ist **kein separater DTU-Kasten**, sondern der **Wechselrichter selbst mit eingebautem DTU**
+  („DTU **B**uilt-**I**n" — daher `DTUBI`). Hostname `DTUBI-414392337823`, `10.40.30.8`,
+  MAC `54:F2:9F:12:51:F0`; der AP läuft auf `…:F1` (STA-MAC + 1, das übliche ESP-Muster).
+  - ❌ **Eine Funktion zum Abschalten des APs existiert nicht.** Hoymiles bietet sie nicht an; im
+    Herstellerumfeld wird sie von Nutzern gefordert. **Christophs Recherche hat nichts gefunden, weil
+    es nichts zu finden gibt.**
+  - ✅ **Was es ab Firmware 3.0.8 gibt: ein AP-Passwort.** Und hier die **Entwarnung** — der AP ist
+    **bereits verschlüsselt**: der Scan meldet `security=wpa2-psk;wpa-psk`. Der bekannte Fall
+    „Hoymiles-DTU funkt ein **offenes** WLAN" trifft hier **nicht** zu.
+  - 🔎 **Warum es hier auch nicht wünschenswert wäre:** das Gerät hat auf der **LAN-Seite null offene
+    TCP-Ports** (geprüft: 80/443/8080/8000/10081/502/1883/8899/22/23 — alle zu, nur ICMP antwortet).
+    Die Messdaten kommen per **MQTT-Push** (18 Sensoren in HA, `hms_41439233`). ⇒ **Die
+    Weboberfläche existiert ausschließlich auf dem AP — er ist die einzige Konfigurationsschnittstelle
+    des Wechselrichters.**
+  - 💡 **Zu Christophs Entwurfsidee („AP nur, wenn kein Link"):** das Muster ist Standard —
+    Captive-Portal-/WiFiManager-Fallback, so machen es Tasmota, ESPHome und viele ESP-Firmwares. Dass
+    Hoymiles es nicht tut, ist eine Herstellerentscheidung, kein technisches Hindernis.
+    ⚠️ **Aber es hätte hier einen Haken:** solange die STA-Verbindung *funktioniert*, käme der AP nie —
+    und damit wäre die **MQTT-/Broker-Konfiguration unerreichbar**, obwohl man sie genau dann ändern
+    will, wenn das WLAN läuft. Das Fallback-Muster ist gut für Geräte mit LAN-seitiger Weboberfläche.
+    **Dieses hier hat keine.**
+  - 🎯 **Der Hebel, den es stattdessen gibt: den AP-Kanal verschieben.** 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 (ap1). **Bindet man den Wechselrichter per
+    `access-list` an ap2 (ch11), wandert sein AP mit.** Man kann ihn also nicht abschalten,
+    aber **dorthin verschieben, wo er weniger stört** — Werkzeug ist dasselbe wie in TP25
+    ([`tp25-pin-s22.sh`](tp25-pin-s22.sh)), und seit 2026-08-23 steht `wifi-access-list` unter einer
+    ComplianceRule, ist also transaktionsfähig.
+    📌 **Dieselbe Regel erklärt auch den Shelly s23:** dessen AP folgt seiner STA-Zuordnung. Wer den
+    Störer verschieben will, verschiebt den **Client**, nicht den AP.
+  - 🔴 **Nicht auf Verdacht am Gerät herumprobieren:** die PV-Datenstrecke ist produktiv, und der AP
+    ist die einzige Rückfallebene, wenn der Wechselrichter je den WLAN-Zugang verliert.
 
 ### Was das für die Zigbee-Kanalfrage heißt