DTU: kein ap_enable im Protokoll -- und ein eigener Port-Fehlbefund korrigiert

Christophs Hinweis war richtig, die Antwort steckte im Addon-Umfeld -- allerdings
nicht im Addon selbst (ha-hoymiles-wifi-addon v0.5 alias hms-mqtt-publisher ist rein
lesend und pollt nur Telemetrie), sondern in der Protokolldefinition, die die
Schwester-Bibliothek suaveolent/hoymiles-wifi offenlegt.

SetConfig.proto kennt dtu_ap_ssid (48) und dtu_ap_pass (49), dazu wifi_ssid/-password,
netmode_select, channel_select und dhcp_switch. Es gibt KEIN ap_enable. Damit ist
"AP laesst sich nicht abschalten" aus der Schnittstellendefinition ableitbar statt aus
Forenberichten.

KORREKTUR eines eigenen Fehlbefunds: ich hatte "null offene TCP-Ports" gemeldet.
Falsch, 10081 ist offen. Ursache war ein kaputter Port-Test -- timeout existiert auf
macOS nicht, jeder Aufruf lief auf command not found und wurde als geschlossen
gewertet. Merkregel festgehalten: ein Test, der bei jedem Port dasselbe Ergebnis
liefert, hat sich selbst widerlegt.

Folge: mein Gegenargument gegen die Fallback-Idee ("dann kaeme man gar nicht mehr an
die Konfiguration") ist hinfaellig -- ueber 10081 bleibt die Konfiguration auch ohne
AP erreichbar. Die Idee ist technisch sauber, Hoymiles implementiert sie nur nicht.

Gueltig bleibt: 80/443/8080/8000 sind zu, es gibt LAN-seitig keine Weboberflaeche.
Und der AP ist verschluesselt (wpa2-psk), der bekannte Fall vom offenen DTU-WLAN
trifft hier nicht zu. Einzige sinnvolle Haertung waere dtu_ap_pass, falls dort noch
das Werkspasswort steht.

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

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

@@ -365,39 +365,58 @@ 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: 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 —
+- ☀️ **Die DTU: abschalten geht nicht — und das ist jetzt am PROTOKOLL belegt, nicht am Forum
+  (2026-08-23).** Es ist kein separater DTU-Kasten, sondern der **Wechselrichter mit eingebautem DTU**
+  („DTU **B**uilt-**I**n"). Hostname `DTUBI-414392337823`, `10.40.30.8`, MAC `54:F2:9F:12:51:F0`;
+  der AP läuft auf `…:F1` (STA-MAC + 1, übliches ESP-Muster).
+  - 🔴 **Korrektur eines eigenen Fehlbefunds vom selben Tag:** ich hatte „**null offene TCP-Ports**"
+    gemeldet. **Falsch — `10081` ist offen.** Ursache war ein kaputter Port-Test: `timeout` gibt es auf
+    macOS nicht, jeder Aufruf lief auf `command not found` und wurde als „zu" gewertet.
+    **Merkregel: ein Test, der bei jedem Port dasselbe Ergebnis liefert, hat sich selbst widerlegt** —
+    ein leeres Ergebnis ist kein Befund, sondern ein Verdacht auf einen kaputten Test.
+    *(Gültig bleibt: **80/443/8080/8000 sind zu** — dieser Teil lief ohne `timeout`. Es gibt LAN-seitig
+    also **keine Weboberfläche**, wohl aber ein vollwertiges Konfigurationsprotokoll.)*
+  - 🔌 **Was auf `10081` läuft:** das proprietäre Hoymiles-Protokoll (Protobuf). Das HA-Addon
+    **`ha-hoymiles-wifi-addon` v0.5** (`DennisOSRM/hms-mqtt-publisher`, Rust) pollt darüber alle
+    30,5 s und schiebt die Telemetrie in den MQTT-Broker — **es ist rein lesend**.
+  - 🎯 **Die Antwort steckt in der Protokolldefinition, nicht im Addon.** Die Schwester-Bibliothek
+    `suaveolent/hoymiles-wifi` legt den vollen Befehlssatz offen: `get-real-data`, `get-config`,
+    `network-info`, `app-information-data`, `get-version-info`, `get-alarm-list` — und schreibend
+    `set-power-limit`, `turn-on/off-inverter`, `restart-dtu`, `identify-dtu`, `firmware-update`,
+    **`set-wifi`**.
+    In `SetConfig.proto` stehen die relevanten Felder:
+    | Feld | Nr. | Bedeutung |
+    |---|---|---|
+    | `dtu_ap_ssid` | 48 | **SSID des geräteeigenen APs** |
+    | `dtu_ap_pass` | 49 | **Passwort des geräteeigenen APs** |
+    | `wifi_ssid` / `wifi_password` | 15 / 16 | das WLAN, in das sich der Wechselrichter einbucht |
+    | `netmode_select` · `channel_select` · `dhcp_switch` | 8 · 9 · 25 | Netzmodus, Kanalwahl, DHCP |
+    🔴 **Und entscheidend: es gibt KEIN `ap_enable`.** Das Protokoll kennt SSID und Passwort des APs —
+    **aber keinen Schalter, ihn abzuschalten.** Damit ist „geht nicht" kein Forumsgerücht mehr, sondern
+    aus der Schnittstellendefinition ableitbar.
+  - ✅ **Entwarnung: der AP ist verschlüsselt** — der Scan meldet `security=wpa2-psk;wpa-psk`. Der
+    bekannte Fall „Hoymiles-DTU funkt ein **offenes** WLAN" trifft hier **nicht** zu.
+    💡 **Die einzige sinnvolle Härtung, die das Protokoll hergibt:** `dtu_ap_pass` auf ein eigenes
+    Passwort setzen, falls dort noch das Werkspasswort vom Geräteaufkleber steht.
+  - ⚠️ **Wenn jemand das je anfasst, zwei Fallen:** **(a)** `SetConfig` überträgt den **ganzen**
+    Konfigurationssatz — wer ein Feld ändern will, muss vorher `get-config` lesen und alles andere
+    unverändert zurückschreiben, sonst überschreibt man Felder mit Leerwerten. **(b)** Ein falsch
+    gesetztes `wifi_ssid`/`wifi_password` kappt die STA-Verbindung. Rettung wäre dann ausgerechnet der
+    AP — **der nicht abschaltbare AP ist die Rückfallebene.** Das ist das beste Argument, ihn zu lassen.
+  - 💡 **Zu Christophs Entwurfsidee („AP nur, wenn kein Link"):** das Muster ist Standard
+    (Captive-Portal-/WiFiManager-Fallback; Tasmota, ESPHome und viele ESP-Firmwares machen es so).
+    Dass Hoymiles es nicht tut, ist eine Herstellerentscheidung, kein technisches Hindernis — **und mit
+    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 —
     **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.
+    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
+    2026-08-23 steht `wifi-access-list` unter einer ComplianceRule, ist also transaktionsfähig.
+    📌 **Dieselbe Regel erklärt den Shelly s23:** wer den Störer verschieben will, verschiebt den
+    **Client**, nicht den AP.
+  - 🔴 **Nicht auf Verdacht am Gerät herumprobieren:** die PV-Datenstrecke ist produktiv.
 
 ### Was das für die Zigbee-Kanalfrage heißt