admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

TP25 — WLAN-Stabilisierung #17

New Issue
Closed
opened 2026-09-07 11:26:37 +02:00 by admin · 11 comments
admin commented 2026-09-07 11:26:37 +02:00
Owner
Copy Link

Steuerungs-SSoT: Index/Status hier in Gitea; Prosa/Detail im Repo unter docs/teilprojekte.md (Abschnitt TP25).

  • Status: ⏳ (status:wip)
  • Abschluss: 2026-09-04
Steuerungs-SSoT: Index/Status hier in Gitea; **Prosa/Detail** im Repo unter `docs/teilprojekte.md` (Abschnitt `TP25`). - Status: ⏳ (status:wip) - Abschluss: 2026-09-04
admin added the status:wipthema:wlan labels 2026-09-07 11:26:37 +02:00
admin commented 2026-09-14 20:11:20 +02:00
Author
Owner
Copy Link

In-situ-Messung 2026-09-14 (Terrasse, live mit Christoph): ap2-Unterpunkt WIDERLEGT — Hardware sauber.

  • Anlass: Balkenspringen am iPhone F2:62:… auf der Terrasse, 2 Call-Aussetzer. Log 18:53–19:18: ~30 Roams, fast alle ap2-5G ↔ ap2-2,4G (−68…−81 dBm), 3× disconnected, not responding.
  • In-situ vor ap2 (1–2 m): −49…−51 dBm, >2 min stabil, 0 Roams ⇒ der offene Verdacht „ap2 RF/Antenne/HW" (2 m/−80, 23:02-Befund) ist in situ widerlegt; reproduziert sich seit dem 09-04-Kanalplan (5300/5320, tx-power 18 live) nicht mehr.
  • Am Terrassenplatz ist 2,4 GHz klar besser (−65…−73) als 5 GHz (−76…−81) — Zellkante, kein Defekt. Telefon dort ruhig (36 s im 1-s-Takt, 0 Roams). Thrash nur in der Band-Überlappungszone −70…−77; zusätzlich client-getrieben (floh selbst von −52 auf 2,4/−77; Steering-Objekte ohne Schwellen, AP drängt nichts).
  • Hebel „Access-List-Band-Boden": Machbarkeitsprüfung NEGATIV — kein band-Property in /interface/wifi/access-list, Interface-Scoping bricht am cap-wifiN-Rejoin, SSID-/MAC-Scope träfen 2,4 GHz mit (Lockout-Risiko, Schlafzimmer −84). Nicht umgesetzt.
  • Verbleibende Hebel: (1) ft=yes uniform auf sec-main (nahtlose Roams; wartet auf Christoph-Go → GC-ConfigPlan als Dry-Run), (2) Deckungsfix Variante 3 (ap1-5G erreichte die Terrasse heute mit −64).
  • Doku: docs/handoff-20260914-tp25-ap2-insitu-terrassse.md, Prosa in docs/teilprojekte.md → TP25 aktualisiert.
  • Randnotiz: CLAUDE.md „ap1 FUNKSTILL seit 08-30" ist überholt — ap1 dient live (09-04-Provisioning), heute 16:51 Radar-Event auf 5280 sauber abgehandelt.
**In-situ-Messung 2026-09-14 (Terrasse, live mit Christoph): ap2-Unterpunkt WIDERLEGT — Hardware sauber.** - Anlass: Balkenspringen am iPhone `F2:62:…` auf der Terrasse, 2 Call-Aussetzer. Log 18:53–19:18: ~30 Roams, fast alle **ap2-5G ↔ ap2-2,4G** (−68…−81 dBm), 3× `disconnected, not responding`. - In-situ vor ap2 (1–2 m): **−49…−51 dBm, >2 min stabil, 0 Roams** ⇒ der offene Verdacht „ap2 RF/Antenne/HW" (2 m/−80, 23:02-Befund) ist **in situ widerlegt**; reproduziert sich seit dem 09-04-Kanalplan (5300/5320, tx-power 18 live) nicht mehr. - Am Terrassenplatz ist **2,4 GHz klar besser** (−65…−73) als 5 GHz (−76…−81) — Zellkante, kein Defekt. Telefon dort ruhig (36 s im 1-s-Takt, 0 Roams). Thrash nur in der Band-Überlappungszone −70…−77; zusätzlich client-getrieben (floh selbst von −52 auf 2,4/−77; Steering-Objekte ohne Schwellen, AP drängt nichts). - **Hebel „Access-List-Band-Boden": Machbarkeitsprüfung NEGATIV** — kein `band`-Property in `/interface/wifi/access-list`, Interface-Scoping bricht am cap-wifiN-Rejoin, SSID-/MAC-Scope träfen 2,4 GHz mit (Lockout-Risiko, Schlafzimmer −84). Nicht umgesetzt. - Verbleibende Hebel: (1) `ft=yes` uniform auf `sec-main` (nahtlose Roams; wartet auf Christoph-Go → GC-ConfigPlan als Dry-Run), (2) Deckungsfix Variante 3 (ap1-5G erreichte die Terrasse heute mit −64). - Doku: `docs/handoff-20260914-tp25-ap2-insitu-terrassse.md`, Prosa in `docs/teilprojekte.md` → TP25 aktualisiert. - Randnotiz: CLAUDE.md „ap1 FUNKSTILL seit 08-30" ist überholt — ap1 dient live (09-04-Provisioning), heute 16:51 Radar-Event auf 5280 sauber abgehandelt.
admin commented 2026-09-14 20:34:41 +02:00
Author
Owner
Copy Link

Umgesetzt 2026-09-14, ~20:30 Uhr: ft=yes ft-over-ds=yes zurueck auf sec-main (Ruecknahme des 09-04-Entscheids; Go von Christoph nach Dry-Run/Fragenrunde).

Sequenz komplett durch:

  1. Template [6c]/sec-main-Stand aktualisiert + push-gc-template.py → GC-Repo-Commit 744a17e3
  2. --refresh-compliance → erwarteter Drift wifi-security (core), 139/140
  3. gc-manual-plan.py --deploy → Plan b1135f3e Completed, REST-Asserts gruen (ft=yes, ft-over-ds=yes). Ein Polling-Timeout am Skript (Netzwerkrunsch) war folgenlos — Gegenpruefung am Geraet zeigte den Befehl bereits wirksam; kein Zweit-Deploy.
  4. Erneuter Refresh: 140/140, 0 Drifts
  5. CAP-Abnahme: keine Inline-Overrides auf ap1/ap2/ap3 (security/security.ft an wifi1/wifi2 überall unset)

Offene Abnahme: Anruf auf der Terrasse ueberlebt einen Band-Wechsel (Christoph, live). Deckungsfix Variante 3 bleibt der offene TP25-Rest.

Commands: docs/transaktionen/TP25-ft-yes-secmain.commands.rsc · Doku: docs/teilprojekte.md TP25 (Stand 09-14) · Commit 89eb9dc.

**Umgesetzt 2026-09-14, ~20:30 Uhr: `ft=yes ft-over-ds=yes` zurueck auf `sec-main`** (Ruecknahme des 09-04-Entscheids; Go von Christoph nach Dry-Run/Fragenrunde). Sequenz komplett durch: 1. Template [6c]/sec-main-Stand aktualisiert + `push-gc-template.py` → GC-Repo-Commit `744a17e3` 2. `--refresh-compliance` → erwarteter Drift `wifi-security` (core), 139/140 3. `gc-manual-plan.py --deploy` → Plan `b1135f3e` **Completed**, REST-Asserts gruen (ft=yes, ft-over-ds=yes). Ein Polling-Timeout am Skript (Netzwerkrunsch) war folgenlos — Gegenpruefung am Geraet zeigte den Befehl bereits wirksam; **kein** Zweit-Deploy. 4. Erneuter Refresh: **140/140, 0 Drifts** 5. CAP-Abnahme: keine Inline-Overrides auf ap1/ap2/ap3 (`security`/`security.ft` an wifi1/wifi2 überall unset) Offene Abnahme: Anruf auf der Terrasse ueberlebt einen Band-Wechsel (Christoph, live). Deckungsfix Variante 3 bleibt der offene TP25-Rest. Commands: `docs/transaktionen/TP25-ft-yes-secmain.commands.rsc` · Doku: `docs/teilprojekte.md` TP25 (Stand 09-14) · Commit `89eb9dc`.
admin commented 2026-09-14 20:37:37 +02:00
Author
Owner
Copy Link

Abnahme ✅ DURCH (2026-09-14, 20:33–20:34 Uhr, live auf der Terrasse): Anruf ueberstand fuenf Band-Wechsel binnen 60 Sekunden (ap2-2,4G ↔ ap2-5G, −73…−82 dBm) — im Fenster nur roamed to-Events, keine disconnected-Zeile mehr (vorher, 20:29/20:31, gab es noch zwei volle Trennungen). Christoph: „call steht".

Damit ist Hebel (1) abgenommen. Offen in TP25 bleibt nur der Deckungsfix Variante 3, der das Band-Springen selbst beendet.

**Abnahme ✅ DURCH (2026-09-14, 20:33–20:34 Uhr, live auf der Terrasse):** Anruf ueberstand **fuenf Band-Wechsel binnen 60 Sekunden** (ap2-2,4G ↔ ap2-5G, −73…−82 dBm) — im Fenster nur `roamed to`-Events, **keine** `disconnected`-Zeile mehr (vorher, 20:29/20:31, gab es noch zwei volle Trennungen). Christoph: „call steht". Damit ist Hebel (1) abgenommen. Offen in TP25 bleibt nur der Deckungsfix Variante 3, der das Band-Springen selbst beendet.
admin commented 2026-09-14 21:04:25 +02:00
Author
Owner
Copy Link

Messplan „Wechselrichter/DTU vs. Terrasse" — angelegt 2026-09-14, auszuführen tagsüber.

Kontext (Log 09-14): Die DTU des Wechselrichters (54:F2:9F:12:51:F0, Hostname DTUBI-…) geht mit der Sonne an und ab (09-14: 07:09 online, 19:35 offline, seither Funkstille) — nachts ist sie für Terrassen-Probleme unbeteiligt (gilt rückwirkend für den 20:37-Verlust und den 19:47-Dropout). Tagsüber fährt sie einen ~5:05-Zyklus: connect → connection lost (bei −52/−53 dBm, bester Signalstärke) → reconnect + DHCP-Deassign/Assign, jeden Takt. Das ist das Fund-F-Muster, Kandidat (c) „Gerät selbst", und belegt bei jedem Takt ch11-Airtime (ap2-2,4 = ch11, Terrassen-Band).

Gerät (per Christoph 09-14): Wechselrichter = Hoymiles HMS-800W-2T. Das schränkt die Hebel ein:

  • Der 5-Minuten-Takt ist S-Miles-Cloud-Telemetrie per Design — per Firmware-Update nicht abstellbar.
  • DTU-WLite-S2: nur 2,4-GHz-WLAN, kein Ethernet.
  • Pin auf einen anderen AP kontraindiziert (−53 direkt an ap2; schwächerer AP ⇒ mehr Retries ⇒ mehr statt weniger Airtime).
  • Realistischer Pfad, ch11 dauerhaft stillzulegen: Original-DTU stilllegen, Telemetrie über OpenDTU/AhoyDTU-ESP32-Dongle (HMS-Serie gut unterstützt, lokale MQTT-Anbindung, kein Cloud-Takt). Eigenes Kleinteilprojekt mit Hardwarekauf (~30-50 €) — erst nach der Messung entscheiden.

Messfrage: Sind die ~5-Minuten-Bursts der DTU auf ch11 im Client-Timing messbar, oder ist die Terrasse rein ein Link-Budget-Problem?

Setup (TP25-Methodik, tagsüber bei laufender Produktion):

  1. Referenz-Client auf ap2-2,4/ch11 pinnen (tp25-pin-multi.sh), Terrassenposition.
  2. Ping-Strecke über 30–60 min (deckt ≥6 DTU-Zyklen) — gleiche Methodik wie die TP25-Referenzläufe.
  3. Parallel: Manager-Log (wireless) mitschreiben; DTU-Zyklus-Zeitpunkte aus dem Log extrahieren.
  4. Korrelation: Verlust-/Latenz-Sitzen gegen die 5:05-Taktmarken.

Entscheidungskriterium:

  • Verluste häufen sich zeitlich mit den DTU-Bursts ⇒ Hebel „DTU ersetzen (OpenDTU)" gerechtfertigt.
  • Keine Korrelation ⇒ ch11-These begraben; die Terrasse bleibt reines Link-Budget, und Variante 3 (Deckungsfix) bleibt der einzige Hebel — für Tag UND Nacht (der 20:37-Verlust passierte nachweislich ohne DTU).

Nachtrag zur Abnahme: Die ft=yes-Abnahme (20:33–20:34, 5 Band-Wechsel, Call stand) bleibt gültig; der 20:37-Totalverlust ist ein anderes Muster (Roam auf ap1-2,4 bei −89 dBm, danach iOS-Aufgeben, kein Wiederverbindungsversuch) — identisch schon um 19:01 mit ft=no gesehen, also keine ft=yes-Regression, sondern der bekannte strukturelle Rest.

**Messplan „Wechselrichter/DTU vs. Terrasse" — angelegt 2026-09-14, auszuführen tagsüber.** **Kontext (Log 09-14):** Die DTU des Wechselrichters (`54:F2:9F:12:51:F0`, Hostname `DTUBI-…`) geht **mit der Sonne an und ab** (09-14: 07:09 online, 19:35 offline, seither Funkstille) — nachts ist sie für Terrassen-Probleme **unbeteiligt** (gilt rückwirkend für den 20:37-Verlust und den 19:47-Dropout). Tagsüber fährt sie einen **~5:05-Zyklus**: connect → `connection lost` (bei −52/−53 dBm, bester Signalstärke) → reconnect + DHCP-Deassign/Assign, jeden Takt. Das ist das Fund-F-Muster, Kandidat (c) „Gerät selbst", und belegt bei jedem Takt ch11-Airtime (ap2-2,4 = ch11, Terrassen-Band). **Gerät (per Christoph 09-14): Wechselrichter = Hoymiles HMS-800W-2T.** Das schränkt die Hebel ein: - Der 5-Minuten-Takt ist **S-Miles-Cloud-Telemetrie per Design** — per Firmware-Update nicht abstellbar. - DTU-WLite-S2: nur 2,4-GHz-WLAN, **kein Ethernet**. - Pin auf einen anderen AP kontraindiziert (−53 direkt an ap2; schwächerer AP ⇒ mehr Retries ⇒ mehr statt weniger Airtime). - Realistischer Pfad, ch11 dauerhaft stillzulegen: Original-DTU stilllegen, Telemetrie über **OpenDTU/AhoyDTU-ESP32-Dongle** (HMS-Serie gut unterstützt, lokale MQTT-Anbindung, kein Cloud-Takt). Eigenes Kleinteilprojekt mit Hardwarekauf (~30-50 €) — erst nach der Messung entscheiden. **Messfrage:** Sind die ~5-Minuten-Bursts der DTU auf ch11 im Client-Timing messbar, oder ist die Terrasse rein ein Link-Budget-Problem? **Setup (TP25-Methodik, tagsüber bei laufender Produktion):** 1. Referenz-Client auf **ap2-2,4/ch11 pinnen** (`tp25-pin-multi.sh`), Terrassenposition. 2. Ping-Strecke über 30–60 min (deckt ≥6 DTU-Zyklen) — gleiche Methodik wie die TP25-Referenzläufe. 3. Parallel: Manager-Log (wireless) mitschreiben; DTU-Zyklus-Zeitpunkte aus dem Log extrahieren. 4. Korrelation: Verlust-/Latenz-Sitzen gegen die 5:05-Taktmarken. **Entscheidungskriterium:** - Verluste häufen sich zeitlich mit den DTU-Bursts ⇒ Hebel „DTU ersetzen (OpenDTU)" gerechtfertigt. - Keine Korrelation ⇒ ch11-These begraben; die Terrasse bleibt reines Link-Budget, und **Variante 3 (Deckungsfix) bleibt der einzige Hebel** — für Tag UND Nacht (der 20:37-Verlust passierte nachweislich ohne DTU). **Nachtrag zur Abnahme:** Die ft=yes-Abnahme (20:33–20:34, 5 Band-Wechsel, Call stand) bleibt gültig; der 20:37-Totalverlust ist ein anderes Muster (Roam auf ap1-2,4 bei −89 dBm, danach iOS-Aufgeben, kein Wiederverbindungsversuch) — identisch schon um 19:01 mit ft=no gesehen, also **keine ft=yes-Regression**, sondern der bekannte strukturelle Rest.
admin commented 2026-09-14 21:13:04 +02:00
Author
Owner
Copy Link

Korrektur zu Kommentar #225 — der OpenDTU/AhoyDTU-Dongle ist für DASSES Gerät KEIN Hebel (Recherche 2026-09-14, abends):

  • Christoph hat bereits eine AhoyDTU — nachweislich inkompatibel, und das ist dokumentierter Stand, kein Einzelfall: HMS-XXXXW-2T (W = eingebaute DTU „DTUBI", protobuf-NetworkCommands-Protokoll) wird von AhoyDTU/OpenDTU nicht unterstützt (Ahoy-Issue lumapu/ahoy#1189 seit 09-2023 offen, kein PR; nur die Nicht-W-Variante HMS-800-2T ginge per CMT2300-Funk).
  • Die funktionierende lokale Ebene für das HMS-800W-2T redet mit der internen DTU übers Netzwerk: hms-mqtt-publisher (= Christophs „hmsmqtt"), dtuGateway (ESP32), ha-hoymiles-wifi (HA-Component), hoymiles_proto. Keines davon nimmt die DTU von der Luft — sie bleibt auf ch11 und in der Cloud; hmsmqtt pollt sogar zusaetzlich (~30-s-Takt, kleine Payloads).
  • ⇒ Der einzige Hebel, der die DTU-Airtime wirklich senkt, bleibt DNS-Hoheit ueber die Cloud — von Christoph bewusst zurueckgestellt: „noch benoetige ich die Aufzeichnungen in der Cloud, solange bis hmsmqtt und das WiFi stabil sind." Die ch11-Entschaerfung steht damit hinter dieser Sequenzierung. Unbekannt bleibt dabei: ob eine DTU ohne erreichbare Cloud ruhiger oder gespraechiger (Retries) wird — eigene Messung, wenn es so weit ist.
  • Der Messplan aus #225 bleibt unberuehrt gueltig (Tag-Messung: ch11-Pin + Ping gegen die 5:05-Taktmarken). Nur der dort genannte „Hebel falls messbar" ist von „Dongle ersetzen" auf „DNS-Hoheit nach Christophs Sequenzierung" zu lesen.

Und zur Klarstellung gegenueber der Abend-Diagnose: Die DTU war am Abend nachweislich außer Betrieb (seit 19:35:16, kein Event danach) — die Abend-Ausfaelle (19:01/19:12/19:12-Window, 19:47, 20:37) sind vollstaendig durch Link-Budget + Client-Verhalten erklaert; 19:47 und 20:37 passierten demonstrativ ohne DTU. Der DTU-Strang ist ein getrennter Tag-Hypothesenzweig, kein Bestandteil der Terrassen-Diagnose.

**Korrektur zu Kommentar #225 — der OpenDTU/AhoyDTU-Dongle ist für DASSES Gerät KEIN Hebel** (Recherche 2026-09-14, abends): - Christoph hat bereits eine AhoyDTU — **nachweislich inkompatibel**, und das ist dokumentierter Stand, kein Einzelfall: HMS-**XXXXW**-2T (W = eingebaute DTU „DTUBI", protobuf-NetworkCommands-Protokoll) wird von AhoyDTU/OpenDTU **nicht unterstützt** (Ahoy-Issue lumapu/ahoy#1189 seit 09-2023 offen, kein PR; nur die Nicht-W-Variante HMS-800-**2T** ginge per CMT2300-Funk). - Die funktionierende lokale Ebene für das HMS-800W-2T redet **mit der internen DTU übers Netzwerk**: hms-mqtt-publisher (= Christophs „hmsmqtt"), dtuGateway (ESP32), ha-hoymiles-wifi (HA-Component), hoymiles_proto. **Keines davon nimmt die DTU von der Luft** — sie bleibt auf ch11 und in der Cloud; hmsmqtt pollt sogar zusaetzlich (~30-s-Takt, kleine Payloads). - ⇒ Der **einzige** Hebel, der die DTU-Airtime wirklich senkt, bleibt **DNS-Hoheit ueber die Cloud** — von Christoph bewusst zurueckgestellt: „noch benoetige ich die Aufzeichnungen in der Cloud, solange bis hmsmqtt und das WiFi stabil sind." Die ch11-Entschaerfung steht damit hinter dieser Sequenzierung. Unbekannt bleibt dabei: ob eine DTU ohne erreichbare Cloud ruhiger oder *gespraechiger* (Retries) wird — eigene Messung, wenn es so weit ist. - Der Messplan aus #225 bleibt unberuehrt gueltig (Tag-Messung: ch11-Pin + Ping gegen die 5:05-Taktmarken). Nur der dort genannte „Hebel falls messbar" ist von „Dongle ersetzen" auf „DNS-Hoheit nach Christophs Sequenzierung" zu lesen. Und zur Klarstellung gegenueber der Abend-Diagnose: Die DTU war am Abend nachweislich außer Betrieb (seit 19:35:16, kein Event danach) — die Abend-Ausfaelle (19:01/19:12/19:12-Window, 19:47, 20:37) sind **vollstaendig** durch Link-Budget + Client-Verhalten erklaert; 19:47 und 20:37 passierten demonstrativ **ohne** DTU. Der DTU-Strang ist ein getrennter Tag-Hypothesenzweig, kein Bestandteil der Terrassen-Diagnose.
admin commented 2026-09-14 22:02:25 +02:00
Author
Owner
Copy Link

Netzwerk-Mechanismus geklaert: Der Fund-F-5:05-Zyklus ist das Cloud-Recovery-Verhalten der DTU (Recherche 2026-09-14, abends; Quellen: DennisOSRM/hms-mqtt-publisher PR #110 mit Wireshark-Analyse am HMS-800W-2T, suaveolent/ha-hoymiles-wifi #134):

  1. Die DTU hat EINE Befehls-Queue: Ein lokaler Poll <30 s nach dem letzten Request liefert Stale-Daten, resettet den 30-s-Countdown und setzt dabei die Cloud-Updates still aus.
  2. Cloud-Update-Takt: normal 60 s. Nach 4–5 Minuten erfolgloser Cloud-Updates startet die DTU eine neue TCP-Session.
  3. Sie resettet dabei mehr als TCP — unser Log 09-14 zeigt im 4–5-Min-Takt eine vollstaendige WiFi-Disassoziation (connection lost bei −52/−53, 2 s spaeter reconnect, jedes Mal DHCP deassign+assign). Die gemessenen Abstände heute Morgen (07:09:30→07:13:54→07:18:00→07:23:08→07:27:19) decken sich mit dem Wireshark-Befund „after 4–5 minutes" fast aufs Minutenkomma. ⇒ Fund F ist neu interpretiert: nicht „geraeteseitig unklar", sondern Cloud-Recovery nach Polling-Kollision.
  4. Konsequenz fuer ch11: Jeder Zyklus = Reassoziation + 4-Way-Handshake + DHCP-Burst bei −53 dBm auf ch11. Die Tagzeit-Belastung ist durch die Poll-Rate steuerbar — ohne DNS-Hoheit, ohne Dongle.

Ist-Aufnahme (Christoph 09-14, Nacht): hmsmqtt lief mit 30 500 ms — exakt die Grenzzone (keine Stale-Daten, aber die 60-s-Cloud-Fenster werden regelmaessig verdraengt). DTU-Firmware: eine aeltere, hmsmqtt funktioniert ⇒ die #134-Key-Rotation-Falle (nur Firmware 01.01.00+) ist nicht der primaere Verdacht.

Aktion: ✅ Christoph hat update_interval 30500 → 45000 ms gesetzt (Community-Wert, 10 Monate stabil laut Wireshark-Autor; S-Miles zeigt „current power" eh nur alle 15 min). Kein Netz-Write.

Verifikation ab 2026-09-15 frueh: DTU geht ~07:09 mit der Sonne online — der morgendliche Log-Lauf (get_log prefix=54:F2) muss ohne 4–5-min-connection lost-Zyklen bleiben, nur noch saubere Sonnenkanten. Das ist zugleich der Fund-F-Abschlussbeweis. Falls der Zyklus bei 45 s bleibt: DTU-Firmware-Version klaeren (01.01.00+ ⇒ ~90 s oder Downgrade, ha-hoymiles-wifi#134). Messplan #225 wird damit zur Verifikationsmessung nach der Umstellung, nicht mehr zur Ursachensuche.

**Netzwerk-Mechanismus geklaert: Der Fund-F-5:05-Zyklus ist das Cloud-Recovery-Verhalten der DTU** (Recherche 2026-09-14, abends; Quellen: DennisOSRM/hms-mqtt-publisher PR #110 mit Wireshark-Analyse am HMS-800W-2T, suaveolent/ha-hoymiles-wifi #134): 1. Die DTU hat EINE Befehls-Queue: Ein lokaler Poll <30 s nach dem letzten Request liefert Stale-Daten, **resettet den 30-s-Countdown** und setzt dabei die Cloud-Updates still aus. 2. Cloud-Update-Takt: normal 60 s. **Nach 4–5 Minuten erfolgloser Cloud-Updates startet die DTU eine neue TCP-Session.** 3. **Sie resettet dabei mehr als TCP** — unser Log 09-14 zeigt im 4–5-Min-Takt eine vollstaendige WiFi-Disassoziation (`connection lost` bei −52/−53, 2 s spaeter reconnect, **jedes Mal DHCP deassign+assign**). Die gemessenen Abstände heute Morgen (07:09:30→07:13:54→07:18:00→07:23:08→07:27:19) decken sich mit dem Wireshark-Befund „after 4–5 minutes" fast aufs Minutenkomma. ⇒ **Fund F ist neu interpretiert: nicht „geraeteseitig unklar", sondern Cloud-Recovery nach Polling-Kollision.** 4. Konsequenz fuer ch11: Jeder Zyklus = Reassoziation + 4-Way-Handshake + DHCP-Burst bei −53 dBm auf ch11. **Die Tagzeit-Belastung ist durch die Poll-Rate steuerbar — ohne DNS-Hoheit, ohne Dongle.** **Ist-Aufnahme (Christoph 09-14, Nacht):** hmsmqtt lief mit **30 500 ms** — exakt die Grenzzone (keine Stale-Daten, aber die 60-s-Cloud-Fenster werden regelmaessig verdraengt). DTU-Firmware: eine aeltere, hmsmqtt funktioniert ⇒ die #134-Key-Rotation-Falle (nur Firmware 01.01.00+) ist nicht der primaere Verdacht. **Aktion:** ✅ **Christoph hat `update_interval` 30500 → 45000 ms gesetzt** (Community-Wert, 10 Monate stabil laut Wireshark-Autor; S-Miles zeigt „current power" eh nur alle 15 min). Kein Netz-Write. **Verifikation ab 2026-09-15 frueh:** DTU geht ~07:09 mit der Sonne online — der morgendliche Log-Lauf (`get_log prefix=54:F2`) muss **ohne** 4–5-min-`connection lost`-Zyklen bleiben, nur noch saubere Sonnenkanten. Das ist zugleich der Fund-F-Abschlussbeweis. Falls der Zyklus bei 45 s bleibt: DTU-Firmware-Version klaeren (01.01.00+ ⇒ ~90 s oder Downgrade, ha-hoymiles-wifi#134). Messplan #225 wird damit zur Verifikationsmessung nach der Umstellung, nicht mehr zur Ursachensuche.
admin commented 2026-09-15 12:11:59 +02:00
Author
Owner
Copy Link

Verifikation ✅ DURCH (2026-09-15, 12:11 Uhr): 45000 ms hat den 5:05-Zyklus eliminiert — Fund F ist damit abgeschlossen.

  • DTU online seit 06:41:49 (Sonnenaufgang), Registration-Table: uptime 5 h 29 min, 0 Disconnects — eine einzige ununterbrochene Assoziation.
  • Vergleich 09-14: gleiche DTU, Intervall 30500 ms → fünf Disconnect/Reconnect-Zyklen inkl. DHCP-Churn in den ersten 18 Minuten (07:09–07:27).
  • cap-wifi-Karte seit gestern unverändert (kein Rejoin, Attribution belastbar): die DTU sitzt heute auf ap3-2,4 (cap-wifi4-virtual1, −49 dBm) statt ap2/ch11 — beim Boot hat sie den AP gewechselt; sie ist damit aktuell auch vom Terrassen-Band weg.
  • Damit bestätigt sich die Kausalkette aus Kommentar #228: Polling-Kollision (30,5 s) → Cloud-Updates ausgesetzt → nach 4–5 min vollständiger WiFi-Reset inkl. DHCP. Intervall 45 s → keine Kollision → kein Zyklus. Fund F („IoT-Clients trennen exakt alle ~5:05") ist gelöst: Ursache war die DTU-Cloud-Recovery, getriggert durch hmsmqtt.
  • Messplan #225 (ch11-Pin + Ping gegen die 5:05-Taktmarken) ist damit gegenstandslos — der zu messende Effekt existiert nicht mehr. Eine ch11-Tagzeitmessung bleibt nur sinnvoll, falls die Terrasse tagsueber weiterhin Call-Probleme zeigt; Primaerverdacht dort bleibt das Link-Budget (Variante 3).
**Verifikation ✅ DURCH (2026-09-15, 12:11 Uhr): 45000 ms hat den 5:05-Zyklus eliminiert — Fund F ist damit abgeschlossen.** - DTU online seit **06:41:49** (Sonnenaufgang), Registration-Table: **uptime 5 h 29 min, 0 Disconnects** — eine einzige ununterbrochene Assoziation. - Vergleich 09-14: gleiche DTU, Intervall 30500 ms → **fünf Disconnect/Reconnect-Zyklen inkl. DHCP-Churn in den ersten 18 Minuten** (07:09–07:27). - cap-wifi-Karte seit gestern unverändert (kein Rejoin, Attribution belastbar): die DTU sitzt heute auf **ap3-2,4 (cap-wifi4-virtual1, −49 dBm)** statt ap2/ch11 — beim Boot hat sie den AP gewechselt; sie ist damit aktuell auch vom Terrassen-Band weg. - **Damit bestätigt sich die Kausalkette aus Kommentar #228**: Polling-Kollision (30,5 s) → Cloud-Updates ausgesetzt → nach 4–5 min vollständiger WiFi-Reset inkl. DHCP. Intervall 45 s → keine Kollision → kein Zyklus. **Fund F („IoT-Clients trennen exakt alle ~5:05") ist gelöst: Ursache war die DTU-Cloud-Recovery, getriggert durch hmsmqtt.** - Messplan #225 (ch11-Pin + Ping gegen die 5:05-Taktmarken) ist damit **gegenstandslos** — der zu messende Effekt existiert nicht mehr. Eine ch11-Tagzeitmessung bleibt nur sinnvoll, falls die Terrasse tagsueber weiterhin Call-Probleme zeigt; Primaerverdacht dort bleibt das Link-Budget (Variante 3).
admin commented 2026-09-15 12:17:12 +02:00
Author
Owner
Copy Link

terminiert: Deckungsfix Variante 3 — Umsetzung 2026-09-15/16 (Christoph: „heute oder morgen").

Das ist der letzte offene TP25-Posten: der Terrasse (Tag UND Nacht) ein eindeutig dominantes Signal geben, damit das Fund-E-iPhone weder band-flappt noch auf −89-Kandidaten ausweicht und aufgibt (Muster vom 09-14: Thrash in der Überlappungszone −70…−77, Kollaps-Roam auf ap1-2,4 bei −89).

Plan gemäß TP25 Variante 3 (s. teilprojekte.md TP25 + Archiv-Langfassung): Deckenstrahler (cAP ax) an den guten Platz, der verdrängte hAP ax² wandert in den Drei-Räume-Schatten (Schlafzimmer/Bad/Küche — die Messlücke vom 08-22: 17 von 21 Abschnitten 0 % Verlust, aber Schlafzimmer −84,6/38 %, Bad −82,3/24 %, Küche −82,0/23 %). Voraussetzungen laut Plan: PoE-in/Strom am Zielort + Trunk mit VLAN 10/30/40/50/99.

Vorgehen (bewährte Reihenfolge):

  1. Vorher-Messung am Terrassenplatz (Registration-Signal des iPhones, 1-s-Takt wie am 09-14) — die gestrigen Werte (5 GHz −76…−81, 2,4 GHz −65…−73) sind die Referenz.
  2. Physikalische Umsetzung + Provisioning nach Kanalplan (09-04 committed; ap1 = Band B 5260/5280 + ch1, ap2 = 5300/5320 + ch11, ap3 = 5180 + ch6 — nur Platzierung ändern, Kanalplan bleibt).
  3. Nachher-Messung gleicher Strecken + Abnahme: Anruf auf der Terrasse übersteht Band-Wechsel ohne Aufgeben des WLAN (ft=yes seit 09-14 im Soll).
  4. GC-Weg für jede Config-Änderung: Template → push-gc-template.py → --refresh-compliance → ggf. gc-manual-plan.py --deploy; keine Direkt-Writes.

Offen vor Ort: Zielraum für den verdrängten hAP konkretisieren (Steckdose/PoE-Situation), danach ggf. ap1-Uplink-Thema (CLAUDE.md: Umzug ans Sideboard → core ether3) mitdenken. Messplan #225 bleibt gegenstandslos (ch11-Zyklus eliminiert); die Vorher/Nachher-Terrassenmessung ist die einzige Messung, die noch zählt.

**terminiert: Deckungsfix Variante 3 — Umsetzung 2026-09-15/16 (Christoph: „heute oder morgen").** Das ist der letzte offene TP25-Posten: der Terrasse (Tag UND Nacht) ein **eindeutig dominantes Signal** geben, damit das Fund-E-iPhone weder band-flappt noch auf −89-Kandidaten ausweicht und aufgibt (Muster vom 09-14: Thrash in der Überlappungszone −70…−77, Kollaps-Roam auf ap1-2,4 bei −89). **Plan gemäß TP25 Variante 3** (s. teilprojekte.md TP25 + Archiv-Langfassung): Deckenstrahler (cAP ax) an den guten Platz, der verdrängte hAP ax² wandert in den Drei-Räume-Schatten (Schlafzimmer/Bad/Küche — die Messlücke vom 08-22: 17 von 21 Abschnitten 0 % Verlust, aber Schlafzimmer −84,6/38 %, Bad −82,3/24 %, Küche −82,0/23 %). Voraussetzungen laut Plan: PoE-in/Strom am Zielort + Trunk mit VLAN 10/30/40/50/99. **Vorgehen (bewährte Reihenfolge):** 1. **Vorher-Messung** am Terrassenplatz (Registration-Signal des iPhones, 1-s-Takt wie am 09-14) — die gestrigen Werte (5 GHz −76…−81, 2,4 GHz −65…−73) sind die Referenz. 2. Physikalische Umsetzung + Provisioning nach Kanalplan (09-04 committed; ap1 = Band B 5260/5280 + ch1, ap2 = 5300/5320 + ch11, ap3 = 5180 + ch6 — nur Platzierung ändern, Kanalplan bleibt). 3. **Nachher-Messung** gleicher Strecken + **Abnahme: Anruf auf der Terrasse** übersteht Band-Wechsel ohne Aufgeben des WLAN (ft=yes seit 09-14 im Soll). 4. GC-Weg für jede Config-Änderung: Template → `push-gc-template.py` → `--refresh-compliance` → ggf. `gc-manual-plan.py --deploy`; keine Direkt-Writes. **Offen vor Ort:** Zielraum für den verdrängten hAP konkretisieren (Steckdose/PoE-Situation), danach ggf. ap1-Uplink-Thema (CLAUDE.md: Umzug ans Sideboard → `core ether3`) mitdenken. Messplan #225 bleibt gegenstandslos (ch11-Zyklus eliminiert); die Vorher/Nachher-Terrassenmessung ist die einzige Messung, die noch zählt.
admin commented 2026-09-15 18:04:02 +02:00
Author
Owner
Copy Link

AP-Zuordnung definitiv geklärt + ap1-Redundanz-Test (Handoff)

Positionen live verifiziert (IP/MAC/Switch-Port):

  • ap1 = Sideboard (core ether3) · ap2 = Technik UG (core ether21) · ap3 = Technik OG (branch ether24)

Der Tausch hat ap2↔ap3 vertauscht statt ap1↔ap3 (ap1/ap2-Verwechslung) — ap1 blieb am Sideboard, der cAP ax (ap3) steht jetzt in OG statt am guten Platz. MAC-Korrektur: ap2 ether1 = :39 (nicht :3A — das ist die Bridge-MAC); Radios :3E/:3F.

Rundgang (alle an, natürlich): 0 Disconnects, −45…−77 dBm, Roaming über alle 3 APs, Terrasse −58 stabil an OG, ap1 nur kurz gestreift (−52…−60).

ap1-Aus-Test (Provisioning action=none + re-provision): Main-Client voll abgedeckt (tiefster Wert −80 an der Terrasse), alle 27 IOT-Geräte kehren zurück (23 ap2 + 4 ap3), aber ~4 Wohnzimmer-IOT marginal −77…−80 dBm. ⇒ ap1 technisch redundant, aber mit Signal-Reserve-Verlust. ap1 wieder an.

Offen: (1) ap1 behalten oder abbauen? (2) Tausch auf Plan korrigieren (cAP ax → Sideboard)? (3) Drei-Räume-Schatten (Schlafzimmer/Bad/Küche) gezielt nachmessen. (4) Doku-Drift (CLAUDE.md-MAC/Positionen, Nautobot-Location) schließen.

**AP-Zuordnung definitiv geklärt + ap1-Redundanz-Test** ([Handoff](https://gitea.emsenhuber.net/admin/bf-infra/src/branch/main/docs/handoff-20260915-tp25-zuordnung-und-redundanz.md)) Positionen live verifiziert (IP/MAC/Switch-Port): - **ap1** = Sideboard (core ether3) · **ap2** = Technik UG (core ether21) · **ap3** = Technik OG (branch ether24) Der Tausch hat **ap2↔ap3** vertauscht statt **ap1↔ap3** (ap1/ap2-Verwechslung) — ap1 blieb am Sideboard, der cAP ax (ap3) steht jetzt in OG statt am guten Platz. MAC-Korrektur: ap2 `ether1` = `:39` (nicht `:3A` — das ist die Bridge-MAC); Radios `:3E`/`:3F`. **Rundgang (alle an, natürlich):** 0 Disconnects, −45…−77 dBm, Roaming über alle 3 APs, Terrasse −58 stabil an OG, ap1 nur kurz gestreift (−52…−60). **ap1-Aus-Test** (Provisioning `action=none` + re-provision): Main-Client voll abgedeckt (tiefster Wert −80 an der Terrasse), alle **27 IOT-Geräte** kehren zurück (23 ap2 + 4 ap3), aber **~4 Wohnzimmer-IOT marginal −77…−80 dBm**. ⇒ ap1 **technisch redundant**, aber mit Signal-Reserve-Verlust. ap1 wieder an. Offen: (1) ap1 behalten oder abbauen? (2) Tausch auf Plan korrigieren (cAP ax → Sideboard)? (3) Drei-Räume-Schatten (Schlafzimmer/Bad/Küche) gezielt nachmessen. (4) Doku-Drift (CLAUDE.md-MAC/Positionen, Nautobot-Location) schließen.
admin commented 2026-09-15 18:40:31 +02:00
Author
Owner
Copy Link

TP25 Entscheid 2026-09-15 — MacBook-Klebrigkeit auf 5G: wird nicht umgesetzt.

Threshold-Deploy (st-main-5g, -72/5s, nur 5G) ist live (140/140), Terrasse am iPhone verifiziert (2,4G statt 5G/-80). Das MacBook ignoriert die 802.11v-Transition-Request unter der -72-Schwelle (macOS klebrig). Einziger Gegenhebel waere transition-time=immediate (deauth-Erzwingung) — verworfen (Abbruch-Risiko, kein Bedarf, da das MacBook dort funktioniert). Details: docs/handoff-20260915-tp25-steering-threshold-und-terrasse.md

TP25 Entscheid 2026-09-15 — **MacBook-Klebrigkeit auf 5G: wird nicht umgesetzt.** Threshold-Deploy (st-main-5g, -72/5s, nur 5G) ist live (140/140), Terrasse am iPhone verifiziert (2,4G statt 5G/-80). Das MacBook ignoriert die 802.11v-Transition-Request unter der -72-Schwelle (macOS klebrig). Einziger Gegenhebel waere transition-time=immediate (deauth-Erzwingung) — verworfen (Abbruch-Risiko, kein Bedarf, da das MacBook dort funktioniert). Details: docs/handoff-20260915-tp25-steering-threshold-und-terrasse.md
admin closed this issue 2026-09-22 13:08:10 +02:00
admin commented 2026-09-22 13:08:10 +02:00
Author
Owner
Copy Link

Geschlossen 2026-09-22 — Platzierung final, alle Punkte aufgelöst.

Die vier „Offen"-Punkte aus dem Stand-Block 09-15 waren seit dem Steering-Handoff
(09-15, 18:39, §6) erledigt, aber nie in teilprojekte.md nachgezogen — genau dieser
Drift ist jetzt behoben:

  1. ap1 behalten/abbauen → behalten (Christoph).
  2. Tausch korrigieren (cAP ax → Sideboard) → verworfen — Prämisse „Sideboard-AP
    deckt die Terrasse" war widerlegt; ap1 = Innenraum-König, cAP ax gehört nach OG.
  3. Drei-Räume-Schatten nachmessen → verworfen — Signal beim Rundgang gut.
  4. Doku-Drift → ✅ geschlossen.

Platzierung final: ap1 Sideboard (core ether3) · ap2 Technik UG (core ether21) ·
ap3 Technik OG (branch ether24). Steering st-main-5g (−72/5s) deployed, 140/140;
MacBook-Klebrigkeit per Entscheid „wird nicht umgesetzt".

**Geschlossen 2026-09-22 — Platzierung final, alle Punkte aufgelöst.** Die vier „Offen"-Punkte aus dem Stand-Block 09-15 waren seit dem Steering-Handoff (09-15, 18:39, §6) erledigt, aber nie in `teilprojekte.md` nachgezogen — genau dieser Drift ist jetzt behoben: 1. **ap1 behalten/abbauen** → **behalten** (Christoph). 2. **Tausch korrigieren (cAP ax → Sideboard)** → **verworfen** — Prämisse „Sideboard-AP deckt die Terrasse" war widerlegt; ap1 = Innenraum-König, cAP ax gehört nach OG. 3. **Drei-Räume-Schatten nachmessen** → **verworfen** — Signal beim Rundgang gut. 4. **Doku-Drift** → ✅ geschlossen. **Platzierung final:** ap1 Sideboard (`core ether3`) · ap2 Technik UG (`core ether21`) · ap3 Technik OG (`branch ether24`). Steering `st-main-5g` (−72/5s) deployed, 140/140; MacBook-Klebrigkeit per Entscheid „wird nicht umgesetzt".
admin added status:done and removed status:wip labels 2026-09-22 13:08:15 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
status:concept
status:done
status:dropped
status:idea
status:paused
status:todo
status:wip
thema:backlog
thema:cloudflare-proxy
thema:firewall-dns
thema:identity
thema:infra
thema:ipv6-matter
thema:nautobot-doku
thema:wlan
No Label status:done thema:wlan
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/bf-infra#17
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?