Christoph Emsenhuber d245d10542 TP17.3 geloest: eco_mode war die Ursache der Shelly-Regression
Beide von Christoph gemeldeten Geraete sind repariert:

  s23 dieleug-wohnzimmer_licht (.203, ProDimmer 2PM)
      eco_mode=false, Geraete-AP abgeschaltet
      -> beide Lampenausgaenge flackerfrei, Workaround entfaellt
  s26 bad_luefter (.233, Gen4 2PM)
      eco_mode=false + Reboot
      -> Doppeldruck weg

Der diskriminierende Test lief in der im TP vorgesehenen Reihenfolge: erst
eco_mode aus bei weiter aktivem AP (nicht aussagekraeftig, beide Hypothesen
sagen dort dasselbe voraus), dann AP aus -- und genau die Konstellation, die
vorher geflackert hat, blieb stabil.

Weitere Ergebnisse aus dem Sweep ueber alle 22 erreichbaren Shellys:

- Die RSSI-basierte eco-Politik aus TP17 ist damit nicht nur stale, sondern
  widerlegt. Der Flotten-Entscheid "eco flottenweit aus" haengt jetzt an
  TP17.1, weil er die Sendeleistung von ~20 IoT-Geraeten anhebt und damit
  ins Funkbild von TP25 greift.
- restart_required stand auf 14 von 22 Geraeten, nicht auf 2. Entwarnung:
  Reboot von s26 mit Config-Vergleich davor/danach -- identisch. Kein Geraet
  sitzt auf versteckten Aenderungen.
- Was das Bit gesetzt hat, ist am Geraet nicht rekonstruierbar (169 RPC-
  Methoden, Config-Diff, Geraetelog -- alle drei Wege negativ). Nicht erneut
  untersuchen.
- eco_mode braucht keinen Reboot; das Geraet antwortet selbst mit
  restart_required=false. Eine anderslautende Warnung von mir war falsch.
- AP-Anker-Sweep erledigt: nur s23 hatte einen AP an, kein Rest im Bestand.
- Nebenbefund: alle Shellys ziehen NTP von time.cloudflare.com statt vom
  Core -- statische IPs sehen DHCP-Option 42 nie. Betrifft jedes statisch
  adressierte Geraet im Netz.
- inventory/bf.csv fuehrt s12 noch auf der alten .41.219.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:30:40 +02:00
2026-06-15 19:00:40 +02:00

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 & Phasen
  • docs/firmware-flash-runbook.md — FW-Flash Historie
  • switch/cli/CLI-REFERENCE.md — bestätigte CLI-Syntax
  • switch/cli/*.cli / *.exp — reproduzierbare Konfig-Scripts
  • inventory/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.
Readme 21 MiB
Languages
Python 57.9%
RouterOS Script 33.8%
Jinja 6.6%
Shell 1.7%