diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md
index 6ddb8f7..5a6971f 100644
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -1151,6 +1151,19 @@ Airtime-Hebel bleibt DNS-Hoheit ueber die Cloud**, von Christoph bewusst zurueck
 Aufzeichnungen noch benoetigt, bis hmsmqtt + WLAN stabil); ob eine DTU ohne Cloud ruhiger oder
 gespraechiger wird, ist selbst eine offene Messfrage. Pin auf anderen AP kontraindiziert
 (−53 direkt an ap2); 5-Min-Takt ist S-Miles-Telemetrie per Design, kein Ethernet an der DTU-WLite.
+✅ **Netzwerk-Mechanismus geklaert (09-14, Nacht; [Issue #17, Kommentar
+#228](https://gitea.emsenhuber.net/admin/bf-infra/issues/17#issuecomment-228)):** Der **Fund-F-5:05-Zyklus
+ist das Cloud-Recovery-Verhalten der DTU.** Wireshark-Analyse (hms-mqtt-publisher PR #110, HMS-800W-2T):
+lokaler Poll <30 s resettet den Countdown und setzt Cloud-Updates aus; **nach 4–5 min erfolgloser
+Cloud-Updates** startet die DTU eine neue TCP-Session — und dabei (unser Log-Beweis 09-14) eine
+**vollstaendige WiFi-Disassoziation inkl. DHCP-Churn**. Die heute gemessenen Zyklus-Abstaende decken
+sich mit dem Befund aufs Minutenkomma. Ursache war hmsmqtt mit **30 500 ms** (Grenzzone);
+DTU-Firmware aelter, hmsmqtt funktioniert (⇒ #134-Key-Rotation-Falle nicht primaer).
+**Hebel = Poll-Rate, nicht DNS-Hoheit:** Christoph hat **30500 → 45000 ms** gesetzt (09-14 abends;
+Community-Wert, 10 Monate stabil). **Verifikation ab 09-15 frueh:** morgendlicher Log-Lauf muss ohne
+4–5-min-Zyklen bleiben — zugleich Fund-F-Abschlussbeweis. Fallback bei fortbestehendem Zyklus:
+DTU-Firmware klaeren (01.01.00+ ⇒ ~90 s oder Downgrade, ha-hoymiles-wifi#134). Messplan #225 wird
+damit zur Verifikationsmessung nach der Umstellung.
 Randnotizen: ap1 „FUNKSTILL" im CLAUDE.md ist überholt (dient live, Radar-Event 16:51 auf 5280
 sauber abgehandelt); Template-Abschnitt [6c] („Fund E WIEDER OFFEN", Stand 08-30) ist inhaltlich
 überholt — beim nächsten Template-Edit mit aktualisieren, kein separater Edit nur für den Kommentar.