d0cb2f0934188e7be34c67b0ee97ca4341a8c015
User-Meldung: der Luefter-Shelly muss doppelt gedrueckt werden, und der Dimmer in der Diele UG flackert unkontrolliert seit der Migration -- mit eingeschaltetem AP ist das Symptom weg. KORREKTUR eines eigenen Fehlbefunds von heute Vormittag: ich hatte den aktivierten AP auf s23 als vergessenen Anker aus TP17 eingeordnet, der abgeschaltet gehoert. Er ist Christophs Workaround. Der als "Einzeiler" beschriebene Fix haette eine funktionierende Reparatur zerstoert. Merkregel dazu festgehalten: ein Zustand, der nach einem Verfahren uebrig aussieht, kann eine Reparatur sein -- vor dem Aufraeumen fragen, wozu er da ist, nicht ob er ins Schema passt. Leithypothese aus dem read-only-Sweep ueber alle 22 Geraete: nicht die WLAN-Config, sondern eco_mode. Es senkt den CPU-Takt; ein Phasenanschnitt-Dimmer braucht praezises Nulldurchgangs-Timing, und ein aktiver AP hebt die Energiesparzustaende auf -- das erklaert genau die Beobachtung "AP an, Symptom weg". s23 ist ein SPDM-002PE01EU (app ProDimmerx) mit eco_mode=true; s26 hat eco_mode=true bei momentary-Eingang, was zum verschluckten ersten Tastendruck passt. Gegenprobe: s12 am selben Ort, gleiches Modell wie s26, eco_mode=false, unauffaellig. Diskriminierender Test in vier Schritten notiert, reversibel, ein Geraet. Zwei Nebenfunde aus demselben Sweep: - Die eco-Politik von 2026-07-13 ist stale und war nie konsistent: drei Geraete haben eco an, obwohl sie unter -80 dBm liegen; zwei haben es aus, obwohl sie darueber liegen. Die fuer "nach TP3.3" vorgemerkte zweite Evaluation hat nie stattgefunden. - restart_required=true auf s26 und s12: dort liegt eine geschriebene, nie aktivierte Konfigurationsaenderung, seit 21 bzw. 33 Tagen ohne Neustart. Anker-Sweep gelaufen: s23 ist der einzige Shelly mit aktivem AP, die anderen 21 sind sauber de-anchored. 5-GHz-Scan nachgeholt: nur drei Fremdnetze, alle <= -83 dBm, das Band ist praktisch leer. Planungsaussage fuer die zwei neuen APs: im ETSI-Indoor-Band sind bei 40 MHz genau zwei ueberlappungsfreie Bloecke vorhanden, und beide sind vergeben -- AP drei und vier muessen ins DFS-Band. Dass DFS hier nutzbar ist, belegt ein Nachbar auf 5500. DTU: bleibt wie sie ist (User). Sie gehoert zur PV, ihr AP ist deren Konfignetz, die Messdaten kommen ohnehin ueber -iot. Als bekannter Dauersender auf ch1 dokumentiert, nicht bekaempft. 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%