diff --git a/CLAUDE.md b/CLAUDE.md index 6f5aa33..adad8a4 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -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 diff --git a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md index e3d0bbc..38f0585 100644 --- a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md +++ b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md @@ -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)