diff --git a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md
index 8542fcd..8425a53 100644
--- a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md
+++ b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md
@@ -459,6 +459,18 @@ Wechselrichter, mit der bekannten Falle, dass `SetConfig` den *ganzen* Satz übe
 existiert — nicht, dass der Client diesen Kanal benutzen darf. **Signalstärke ist kein Nachweis für
 Assoziationsfähigkeit.**
 
+🔴🔴 **Nachtrag, und er verschärft die Merkregel: das Gerät hat sich NICHT selbst erholt.**
+Auch nachdem die Sperre entfernt war und ap1 wieder frei auf ch1 sendete, blieb der DTU weg. Zurück
+kam er erst, als Christoph ihm über die **S-Miles-App die WLAN-Zugangsdaten erneut übergab** — „als
+wäre es ein neues WLAN". Danach war er binnen Sekunden wieder auf `cap-wifi4-virtual1` (ap1,
+`dirtyvader-iot`, −51 dBm).
+⇒ **Ein einmal abgewiesener DTU gibt seine gespeicherte Verbindung dauerhaft auf.** Ein `reject` gegen
+dieses Gerät ist damit **kein Experiment, sondern ein Ausfall mit Handarbeit als einzigem Rückweg** —
+und zwar Handarbeit, die nur jemand vor Ort mit der Hersteller-App leisten kann, nicht per Fernzugriff.
+**Für den produktiven PV-Datenpfad heißt das: die access-list ist für dieses Gerät gesperrtes Gebiet.**
+📌 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.
+
 ### 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