WLAN-Umfeldscan 2,4 GHz: Nachbarschaft leise, zwei laute Sender sind die eigenen
Scan auf beiden APs durchgefuehrt (User hat die Client-Unterbrechung freigegeben). Neuer Gotcha, auch in CLAUDE.md: /interface wifi scan geht am CAP NICHT, nur am Manager gegen cap-wifiN. Der Gegentest schliesst device-mode und Policy aus -- /tool fetch meldet auf demselben Geraet explizit "not allowed by device-mode", waehrend der Scan nur "not allowed" sagt, und die Gruppe full hat test und sniff. Ein CAP besitzt sein Radio nicht. Ergebnis: kein einziges Fremdnetz ueber -81 dBm. Die Nachbarschaft ist fuer eine Wohnlage bemerkenswert ruhig. Die zwei lautesten Stoerer im Band sind eigene Geraete, und keines davon ist ein AP: - Shelly s23 (dieleug-wohnzimmer_licht) sendet einen eigenen Access Point auf ch11 mit -51 dBm. WiFi.GetConfig bestaetigt ap.enable=true. Das ist ein uebrig gebliebener Anker aus dem TP17-Migrationsverfahren, bei dem das De-Anchoring nicht angekommen ist -- das Geraet funkt seither doppelt, als Client auf ch1 und als AP auf ch11. Fix waere ein Einzeiler, nicht ausgefuehrt weil nicht beauftragt. Die anderen 21 Anker sind nie gegengeprueft worden. - Hoymiles-DTU sendet ebenfalls einen Konfig-AP, auf ch1 mit -59 dBm. Fuer die Zigbee-Frage: das Fenster 2426-2448 ist nur schwach belegt, ZB18 bleibt valide -- aber ohne Handlungsdruck, CCA=4 gilt weiter. ZHA bleibt auf 20. Neue Randbedingung durch die zwei kommenden APs: 2,4 GHz hat drei ueberlappungsfreie Kanaele. Funken vier APs dort, ist ch6 belegt und ZB18 faellt aus. Empfehlung, die beides loest: die neuen APs als 5-GHz-Schwerpunkt fahren -- haelt ch6 frei, vermeidet Selbststoerung und legt Kapazitaet dorthin, wo sie laut TP25 fehlt. Homematic/HmIP nachgetragen (User-Hinweis): 37 Geraete an der CCU, classic und HmIP gemischt, beide auf 868 MHz -- ausserhalb dieser Rechnung. Eigener Ausfallmodus ist der 1-Prozent-Duty-Cycle, das Gegenstueck zum Broadcast-Sturm. Relevant fuer TP29, dessen Aktor genau die HmIP-HEATING-Geraete waeren. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -77,6 +77,12 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
|
||||
- **ap2 hängt an `crs326-branch ether24`** (Trunk, native VLAN1 + tagged 10-99); **branch-Uplink `ether1` → `crs326-core ether8`** (korrigiert 2026-08-16 — die frühere Angabe „→ sw1 GE8" stammt aus der Zeit vor dem Core-Tausch; MAC-hart belegt in TP22 Schritt 5).
|
||||
- **Mesh = NEIN** (beide APs haben wired Trunk-Uplink → Loop-Risiko).
|
||||
- **Beide APs = CAPs, Manager ist `crs326-core` (TP28 ✅ 2026-08-17).** Der Entscheid „kein CAPsMAN" von 2026-07-22 ist **revidiert**: er galt der Konstellation ap1=Manager+AP, in der ein Manager seine eigenen Radios nicht provisionieren kann — mit dem Core als Manager sind beide APs symmetrisch. Der Core braucht dafür **kein** `wifi-qcom`, `capsman` steckt im Basispaket.
|
||||
- 🔴 **`/interface wifi scan` geht am CAP NICHT — nur am Manager** (Fund 2026-08-23). Das Gerät
|
||||
antwortet `failure: not allowed (/interface/wifi/scan)`; das ist **weder device-mode noch eine
|
||||
Policy-Lücke** (Gegentest: `/tool fetch` sagt auf demselben Gerät explizit „not allowed **by
|
||||
device-mode**", und die Gruppe `full` hat `test`+`sniff`). Ein CAP besitzt sein Radio nicht.
|
||||
Richtig ist `/interface wifi scan cap-wifiN duration=…` **am Core** — dort läuft es einwandfrei.
|
||||
⚠️ Die `cap-wifiN`-Zuordnung vorher über `radio-mac` bestimmen, sie ist nicht stabil.
|
||||
- 🔴 **Messfalle: unter CAPsMAN führt der MANAGER die Tabellen.** `/interface/wifi/registration-table` und die `wireless`-Logs sind auf ap1/ap2 **leer**, obwohl das WLAN läuft. **Immer am Manager zählen.**
|
||||
- 🔴 **Die CAPs finden den Manager per Layer-2-Discovery** (`discovery-interfaces=vlan99`, `current-caps-man-address` ist eine **MAC**, keine IP). Deshalb müssen **MNDP (udp/5678)** und **CAPWAP (udp/5246-5247)** in der `input`-Kette des Core erlaubt bleiben — sonst kommt das WLAN nach dem nächsten AP-Reboot nicht zurück, während laufende Sessions unauffällig weiterlaufen (Fund 2026-08-18, TP5 Etappe 4).
|
||||
- 🔁 **Slave-VAPs aendern heisst zweimal arbeiten (2026-08-22).** `slave-configurations` in einer
|
||||
|
||||
@@ -305,11 +305,114 @@ drei- bis vierstellige Zahl. **Die Adjazenz existiert auf dem Papier und beißt
|
||||
| **18** | **2440** | **13 MHz** | **9 MHz** | ✅ **am besten zentriert** in der Lücke 2426–2451 |
|
||||
| 19 | 2445 | 18 MHz | 4 MHz | zu nah am WLAN |
|
||||
|
||||
🔴 **Vorbedingung für jeden Wechsel: die Nachbar-WLANs messen.** Die Lücke 2426–2448 ist genau
|
||||
**WLAN-Kanal 6**. Eigene APs stehen auf 1 und 11 — was die Nachbarn tun, ist **unbekannt**. Läuft
|
||||
nebenan ein AP auf ch6, wären 16/17/18 schlechter als das heutige 20. **Erst scannen, dann wechseln.**
|
||||
⚠️ Ein Scan auf ap1/ap2 nimmt das Radio kurz vom Kanal und wirft Clients — also bewusst terminieren,
|
||||
nicht nebenbei.
|
||||
✅ **Vorbedingung erfüllt: die Nachbar-WLANs sind am 2026-08-23 gemessen** (Kapitel unten). Ergebnis:
|
||||
das Fenster 2426–2448 ist nur **schwach** belegt (alles ≤ −81 dBm) — **ZB18 ist valide**. Der
|
||||
Handlungsdruck fehlt trotzdem (CCA = 4). 🔴 **Neue Randbedingung:** funken die **zwei neuen APs**
|
||||
ebenfalls auf 2,4 GHz, ist **ch6 belegt** und ZB18 fällt aus — dann sind 20 und 25 die einzig
|
||||
richtigen Plätze. Details und die Empfehlung dazu im Scan-Kapitel.
|
||||
---
|
||||
|
||||
## 📡 WLAN-Umfeldscan 2,4 GHz — durchgeführt 2026-08-23 (beide APs)
|
||||
|
||||
🔴 **Gotcha zuerst, er kostet sonst eine halbe Stunde: `/interface wifi scan` geht am CAP NICHT.**
|
||||
Auf ap1 direkt (SSH, User in Gruppe `full`) antwortet das Gerät `failure: not allowed
|
||||
(/interface/wifi/scan)`. **Das ist weder device-mode noch eine Policy-Lücke** — der Gegentest
|
||||
beweist es: `/tool fetch` meldet auf demselben Gerät explizit *„not allowed **by device-mode**"*, und
|
||||
die Gruppe `full` hat `test` und `sniff`. Ursache ist der **CAPsMAN-Zustand**: ein CAP besitzt sein
|
||||
Radio nicht. **Der Scan läuft am Manager gegen die `cap-wifiN`-Schnittstelle** und funktioniert dort
|
||||
einwandfrei. Reiht sich ein in „unter CAPsMAN führt der Manager die Tabellen".
|
||||
*(Zuordnung am Messtag über `radio-mac` bestimmt, nicht angenommen: ap1 = `cap-wifi3` (5 GHz) /
|
||||
`cap-wifi4` (2,4 GHz), ap2 = `cap-wifi1` / `cap-wifi2`.)*
|
||||
|
||||
### Fremdnetze — die Nachbarschaft ist leise
|
||||
|
||||
| WLAN-Kanal | Belegung ca. | Fremd-APs | stärkstes Fremdsignal |
|
||||
|---|---|---|---|
|
||||
| **1** (2412) | 2401–2423 | dahoam is dahoam −89, FRITZ!Box 6690 TM −87 | **−87** |
|
||||
| 3 / 4 (2417/2427) | 2406–2438 | meins.w −81/−93, Drei_H288A −81 | **−81** |
|
||||
| **6** (2437) | 2426–2448 | Liwest_9d44 −90, meins.liwest −88/−90, Liwest3422 −90 | **−88** |
|
||||
| 8 (2447) | 2436–2458 | meins.w −92, verstecktes Netz −84 | **−84** |
|
||||
| **11** (2462) | 2451–2473 | FRITZ!Box 7490 −81, LiwestBB93 −96, LiwestF0DA −90, LiwestEDBA −92, MIKENET2 −91 | **−81** |
|
||||
|
||||
⇒ **Kein einziges Fremdnetz über −81 dBm.** Die 2,4-GHz-Umgebung ist für eine Wohnlage
|
||||
bemerkenswert ruhig — die eigenen APs sind mit Abstand die lautesten Sender im Band.
|
||||
|
||||
### 🔴 Zwei laute Sender sind aber die eigenen — und keiner davon ist ein AP
|
||||
|
||||
| Sender | Kanal | Signal | Was es ist |
|
||||
|---|---|---|---|
|
||||
| `AC:15:18:7B:62:21` SSID **`AC15187B6220`** | **11** (2462) | **−51** (von ap1) | **Shelly s23** (`dieleug-wohnzimmer_licht`, Pro Dimmer 2PM, `10.40.30.203`) sendet einen **eigenen Access Point** |
|
||||
| `54:F2:9F:12:51:F1` SSID **`DTUBI-92337823`** | **1** (2412) | **−59** (von ap2) | **Hoymiles-DTU** (Solar-Datenlogger, VLAN30) sendet ebenfalls einen eigenen AP |
|
||||
|
||||
🎯 **Der Shelly-Fund ist ein Rückstand aus TP17 und live bestätigt:** `WiFi.GetConfig` liefert
|
||||
`ap.enable = true`, SSID `AC15187B6220`, WPA2. Das ist ein **übrig gebliebener „Anker"** aus dem
|
||||
Migrationsverfahren von 2026-07-13 — dort wurde je Gerät vor dem STA-Write die geräteeigene
|
||||
AP-Funktion als Notanker aktiviert und **nach dem Verify wieder abgeschaltet**. Bei s23 ist das
|
||||
De-Anchoring **nicht angekommen**. Das Gerät funkt seither doppelt: als **Client auf ch1**
|
||||
(`dirtyvader-iot` an ap1, RSSI −56) **und als AP auf ch11**.
|
||||
- **Fix ist ein Einzeiler** über den vorhandenen Pfad: `WiFi.SetConfig {"config":{"ap":{"enable":false}}}`
|
||||
bzw. `mcp/shelly/migrate.py deanchor`. ⏸️ **Nicht ausgeführt — nicht beauftragt.**
|
||||
- 📌 **Und es ist ein Auftrag an die Abnahme, nicht nur ein Einzelfall:** die anderen 21 Anker sind
|
||||
**nie gegengeprüft** worden. Ein Sweep über alle Shellys (`WiFi.GetConfig` → `ap.enable`) gehört vor
|
||||
die nächste Funkaktion — read-only, eine Minute.
|
||||
- Die **DTU** ist derselbe Fall in anderer Farbe (Hersteller-Konfig-AP, der nie abgeschaltet wurde) —
|
||||
ob sie sich abschalten lässt, ist offen.
|
||||
|
||||
### 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
|
||||
schwach** — alles dort ≤ **−81 dBm**. **ZB18 (2440) bleibt damit eine valide Option**, die Messung
|
||||
widerlegt sie nicht.
|
||||
- **Handlungsdruck entsteht dadurch trotzdem nicht.** `PHY_CCA_FAIL_COUNT` = 4 gilt weiter; das ist
|
||||
die Aussage über den Ort, der zählt (der Koordinator), während der Scan die Orte der **APs**
|
||||
beschreibt. **ZHA bleibt auf 20.**
|
||||
|
||||
### 📻 Nachtrag: Homematic / HmIP — **868 MHz, damit außerhalb dieser Rechnung**
|
||||
|
||||
**Christophs Ergänzung 2026-08-23.** Live nachgesehen: Integration `homematicip_local` an der CCU
|
||||
**`ccu.emsenhuber.net`** (RaspberryMatic, Technik UG, `10.40.20.232`) mit **37 Geräten** im
|
||||
Mischbetrieb — **Homematic classic** (BidCoS-RF, z.B. `HM-LC-Sw1-FM` „WC Lüfter", zentrale
|
||||
`HM-RCV-50`) **und HmIP** (u.a. `HmIP-HEATING` je Raum = die Heizungssteuerung).
|
||||
|
||||
✅ **Für die Kanalplanung ist das eine Entlastung:** beide Funkstandards liegen im **868-MHz-Band**
|
||||
(SRD860), nicht bei 2,4 GHz. **Homematic stört Zigbee, Thread und WLAN nicht — und wird von ihnen
|
||||
nicht gestört.** Es ändert an der Tabelle oben nichts.
|
||||
|
||||
⚠️ **Aber es ist ein fünftes Funkökosystem im Haus** (WLAN 2,4 · WLAN 5 · Zigbee ×2 · Thread ·
|
||||
Homematic) — und es hat **seinen eigenen Ausfallmodus, der dem Broadcast-Sturm entspricht:** das
|
||||
868-MHz-Band ist gesetzlich auf **1 % Duty Cycle** begrenzt. Wird das überschritten, stellt die
|
||||
Zentrale das Senden **minutenlang ein** — Symptom: „Befehle kommen nicht an, aber alles ist online".
|
||||
🔎 **Merkregel: bei Homematic-Aussetzern zuerst den Duty Cycle der CCU ansehen, nicht die
|
||||
Funkabdeckung.** Ausgelöst wird er typischerweise durch zu häufige Sollwert-Schreibvorgänge —
|
||||
also durch Automationen, nicht durch Geräte.
|
||||
|
||||
📌 **Bezug zu TP29** (Anwesenheitserkennung fürs Energiesparen): die `HmIP-HEATING`-Geräte **sind**
|
||||
der Aktor, den TP29 ansteuern würde. Wer dort präsenzabhängig regelt, schreibt Sollwerte — und läuft
|
||||
damit genau in die Duty-Cycle-Grenze. **Das gehört in TP29s Entwurf, bevor die erste Automation
|
||||
scharf geht.**
|
||||
### 🆕 Und was die zwei neuen APs damit zu tun haben
|
||||
|
||||
**Sehr viel — das ist der Punkt, an dem die AP-Frage und die Zigbee-Frage dieselbe Frage werden.**
|
||||
|
||||
2,4 GHz hat **drei** überlappungsfreie Kanäle: 1, 6, 11. Heute belegt das Haus **zwei** davon
|
||||
(ap1 = 1, ap2 = 11) und lässt **ch6 frei** — genau das Fenster, in dem ZB 16/17/18 liegen.
|
||||
|
||||
🔴 **Kommen zwei APs dazu und funken alle vier auf 2,4 GHz, ist ch6 belegt.** Damit fällt ein
|
||||
ZHA-Umzug auf 18 aus, und **ZB20 (zwischen 6 und 11) sowie ZB25 (über 11) sind dann die einzigen
|
||||
richtigen Plätze** — also exakt die heutige Belegung. *Die aktuelle Konfiguration wäre dann nicht nur
|
||||
vertretbar, sondern die einzig sinnvolle.*
|
||||
|
||||
💡 **Empfehlung für den AP-Aufbau, die beides löst:** **2,4 GHz nicht auf allen vier APs betreiben.**
|
||||
Vier 2,4-GHz-Zellen auf drei Kanälen stören sich zwangsläufig selbst, und die Reichweite von 2,4 GHz
|
||||
ist so groß, dass zwei Zellen die Wohnung ohnehin abdecken — die IoT-Geräte hängen heute an
|
||||
**zwei** APs und kommen zurecht. Die beiden neuen APs also als **5-GHz-Schwerpunkt** betreiben
|
||||
(2,4 GHz aus oder stark reduziert). Das
|
||||
- hält **ch6 frei** und damit die Zigbee-Option offen,
|
||||
- vermeidet Selbststörung im vollsten Band,
|
||||
- und legt die neue Kapazität dorthin, wo sie tatsächlich fehlt: **5 GHz an den Rändern** (TP25:
|
||||
die Redundanz ist der Schwachpunkt, nicht die Abdeckung).
|
||||
⚠️ **Vor dem Aufbau messen, nicht danach:** derselbe Scan auf 5 GHz (`cap-wifi1`/`cap-wifi3`) fehlt
|
||||
noch — 5 GHz ist das Band, in dem die neuen APs wirklich geplant werden müssen.
|
||||
---
|
||||
|
||||
## 🔌 UART-Backup: was das praktisch heißt (nur für Weg C nötig)
|
||||
|
||||
Reference in New Issue
Block a user