2f183190ed63bfa4d884c0ea3b02cd9e8ade169b
Christophs strukturelle Frage hat TP17.1 gekippt: "zigbee sollte die antwort auf die vielen radios auf -iot geben. nutzt aber wenig wenn man das wifi nicht abdrehen kann bzw. es nicht mehr aktivieren kann ohne reset." Der Pilot hat den Weg technisch vollstaendig bewiesen -- und gezeigt, dass das Ziel so nicht erreichbar ist. Das Geraet bleibt WLAN-Client; der gemessene Funkgewinn ist klein (12 von 26 IoT-Clients, je 150-200 KB rx / 0,6-3 MB tx in sechs Stunden); und WLAN abzuschalten waere unumkehrbar, weil die Zigbee-Firmware keinen AP hat, Shelly kein Zigbee-OTA macht und InstallAlt eine IP braucht. Der Weg ist nicht gescheitert, das Ziel war mit ihm nicht erreichbar. Das Runbook bleibt als Wissensspeicher. Rueckbau: ZHA-Knoten entfernt -- Leave VOR dem Flash, damit kein Geisterrouter im 52-Geraete-Mesh bleibt. s9 zurueck auf PowerStrip, Config aus dem Backup. Alle vier roten EZSP-Zaehler blieben 0, Retry-Quote fiel im Delta auf 8,9 %. Neue Merkregel: der Rueckflash zog einen OFFENEN AP hoch (ap.enable=true, is_open=true). Abgeschaltet und mit dem IoT-PSK abgesichert. Nach jedem Shelly-Firmwarewechsel den AP pruefen. eco_mode flottenweit aus (User: "der rotz macht nur probleme"): 13 Geraete umgestellt, null Fehler, 9 standen schon so. Jetzt eco=false auf allen 22 erreichbaren Shellys ausser s24, das es nicht unterstuetzt. Dafuer migrate.py um ein eco-Kommando ergaenzt -- mit Retry je Geraet, weil ein Timeout an einem schwachen Link den Sweep sonst abreisst. Die Gegenmessung widerlegt meine eigene Warnung: eco aus hebt die Sendeleistung NICHT messbar an. 13 geaenderte Geraete im Mittel -0,9 dB, Kontrollgruppe von 13 unveraenderten +0,0 dB bei gleicher Streuung. Die TP17-Aussage, eco senke Takt UND Sendeleistung, stimmt nur zur Haelfte. Vorbedingung der Passwort-Rotation geprueft: alle vier Skripte laufen laengst auf sshpass -e, die gegenteilige Notiz war veraltet. Uebrig war CLAUDE.md, das sshpass -p weiterhin aktiv als Reboot-Weg empfahl -- genau das Muster, das den Leak verursacht hat. Auf sshpass -e korrigiert. TP17.2 aus "zurueckgestellt" aktiviert und an die PSK-Rotation gekoppelt. 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%