66c346fa94acdc59fdb4146c1277b405435fee2d
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>
docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden
bf-network-r6
BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.
SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.
Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md
Struktur:
docs/vlan-plan.md— VLAN-/Adressplan (final)docs/core-switch-prep.md— Core-Switch Status & Phasendocs/firmware-flash-runbook.md— FW-Flash Historieswitch/cli/CLI-REFERENCE.md— bestätigte CLI-Syntaxswitch/cli/*.cli/*.exp— reproduzierbare Konfig-Scriptsinventory/bf.csv/bf.md— IP-Doku (aus IPs.xlsx gespiegelt)inventory/bf-core-ports.csv/.md— Switch-Port-Map
Aktueller Stand (2026-06-09):
- Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
- Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
- Phase C (Firewall) + Phase D (Adress-Migration) ausstehend
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Languages
Python
57.9%
RouterOS Script
33.8%
Jinja
6.6%
Shell
1.7%