Christoph Emsenhuber
a4833efcdb
Nachtrag zum fehlgeschlagenen Pin. Auch nach dem Rollback, mit freiem ap1 auf ch1, blieb der DTU weg. Zurueck kam er erst, als Christoph ihm ueber die S-Miles-App die WLAN-Zugangsdaten erneut uebergab -- danach binnen Sekunden wieder auf ap1, dirtyvader-iot, -51 dBm, verifiziert in der Registration-Table. Damit verschaerft sich die Lehre: ein einmal abgewiesener DTU gibt seine gespeicherte Verbindung dauerhaft auf. Ein reject gegen dieses Geraet ist kein Experiment, sondern ein Ausfall, dessen einziger Rueckweg Handarbeit vor Ort mit der Hersteller-App ist -- nicht per Fernzugriff behebbar. Die access-list ist fuer dieses Geraet gesperrtes Gebiet, solange der PV-Datenpfad produktiv ist. Nebenbefund: dass die Re-Provisionierung auf ap1 (ch1) sofort klappte, waehrend der Wechsel auf ap2 (ch11) scheiterte, stuetzt die Kanal-These zusaetzlich. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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