docs 🔧 TP2.1: Omada-Switch Standalone-Recovery + TP15-Korrektur (Omada raus)

sw2-Controller-Link brach beim VLAN20-Umzug (TP14.1), Werks-Reset beim
Rettungsversuch, fehlerhafte Wiederherstellung — Controller-Zustand jetzt
invalid. sw2 wird ohne Managementsoftware neu aufgesetzt (TP2 als Playbook,
neue Portbelegung offen). TP15 korrigiert: Omada bekommt keine Rolle mehr,
auch nicht WLAN (bleibt bei hAP ax²/CAPsMAN) — reines MikroTik-Ecosystem.
TP19-Update: Shelly wieder da, SwitchBot-Move erst nach VLAN1-Retirement.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -73,6 +73,13 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
 - **→ TP4 wird vorgezogen:** Alle VLANs im Controller definiert (status=false = kein Management-IP, normal).
   Traffic läuft noch auf VLAN 1 bis TP4 die L3-Interfaces + DHCP-Server je VLAN aktiviert.
 
+### TP2.1 — Omada-Switch (sw2/ES208G) → Standalone-Recovery (kein Controller) ▸ 🔜 AKTIV (2026-07-15) — `docs/tp2.1-omada-switch-standalone-runbook.md`
+- **Root Cause:** beim VLAN20-Umzug des Omada-Controllers (TP14.1, 2026-07-10) ist die Controller↔sw2-Verbindung zerbrochen (sw2 seither „Disconnected", ursprünglich als reiner Mgmt-Loss vertagt). Beim Rettungsversuch hat der User versehentlich einen **Werks-Reset** am Switch ausgelöst. Ein anschließender Wiederherstellungsversuch (durch Claude) hat Teile der Config **unbemerkt halluziniert** — der damalige „wiederhergestellte" Stand ist **nicht vertrauenswürdig**.
+- **Entscheidung (User 2026-07-15): Controller-Zustand als invalid betrachten, sw2 komplett neu — diesmal OHNE Managementsoftware.** Kein Omada-Controller-Re-Adopt, kein Omada-Ecosystem-Anschluss (s. TP15-Korrektur — Omada bekommt generell keine Rolle mehr, auch nicht WLAN). sw2 wird direkt über sein eigenes Web-UI/CLI konfiguriert, wie ein eigenständiger Switch.
+- **sw2 bleibt Solo:** „bekommt nie Geschwister" — keine weiteren Omada-Geräte geplant. Interimslösung bis zur Ablösung durch CRS326 (TP15).
+- **TP2 = Playbook**, nicht 1:1 übernehmen: gleicher VLAN-Bedarf (VLAN-Modell unverändert), aber **neue Portbelegung** wird gemeinsam mit User neu definiert (nicht ungeprüft aus der alten TP2-Tabelle übernommen) — offener nächster Schritt dieser Session.
+- Abh.: TP1 ✅ (VLAN-Trunk am Uplink). Verwandt: TP15 (löst sw2 mittelfristig durch CRS326 ab), TP14.1 (Auslöser).
+
 ### TP3 — WLAN / CAPsMAN ▸ ✅ KERN FERTIG (2026-06-18) — `routeros/tp3-capsman.rsc`
 - ✅ **5 sichtbare SSIDs live, beide APs, beide Bänder, je SSID→VLAN** (wifi datapath vlan-id):
   `dirtyvader-main`(10, WPA3-only, FT), `-iot`(30, **nur 2,4 GHz**, WPA2+3), `-media`(40, WPA2+3, **FT=no** wg. Sonos),
@@ -321,17 +328,17 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 ### TP14.5 — Session E: Freigabe-Gate → TP5-Firewall ▸ 🔜 (ZULETZT)
 - Erst wenn TP14.1–14.3 durch (alle Origins/Connectoren in VLAN20) → dann TP5 (Deny-by-default) starten. Reines Reihenfolge-Gate, kein eigener Change.
 
-### TP15 — HW-Refresh: Switching + WLAN-Ecosystem + DC-USV ▸ 🟡 ENTSCHIEDEN, Beschaffung läuft (2026-07-14) — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc`
-- **🧭 Grundsatzentscheid (2026-07-14): Ecosystem-Split nach Layer.** **MikroTik = config-gemanagter Kern** (Routing/L3/CAKE + alle Switches), **Omada = ausschließlich WLAN**. Begründung: Projektziel #1 **CAKE** nur RouterOS/OpenWrt/OPNsense (Omada-Gateway kann kein CAKE); WLAN = Schmerzpunkt → Omada-EAP; Switching = MikroTik. Grenze **„MikroTik = Kabel+Routing, Omada = Funk"** deckt sich mit den 2 bestehenden Control-Planes (MikroMCP + Omada-Controller). Verworfene Vollvarianten (Omada-only, MikroTik-only) samt Begründung + Ansible/Nautobot-Recherche → Memory.
-- **🛒 Switches: 2× CRS326-24G-2S+RM bestellt (2026-07-14 — CSS326-Fehlbestellung storniert → CRS).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2 raus aus Switching-Rolle) + Cudy ab.
+### TP15 — HW-Refresh: Switching + Router + DC-USV ▸ 🟡 ENTSCHIEDEN, Beschaffung läuft (2026-07-14, WLAN-Punkt korrigiert 2026-07-15) — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc`
+- **🧭 Grundsatzentscheid (2026-07-14, korrigiert 2026-07-15): reines MikroTik-Ecosystem — Routing + Switching + WLAN.** **Omada bekommt KEINE Rolle** (weder Switching noch WLAN — der ursprüngliche „Omada=WLAN"-Satz war ein Fehlschluss beim Dokumentieren, User-Korrektur 2026-07-15: „WLAN war NIE von Omada die Rede"). Begründung Switching: Projektziel #1 **CAKE** nur RouterOS/OpenWrt/OPNsense (Omada-Gateway kann kein CAKE) → Switching = MikroTik CRS. WLAN bleibt auf hAP ax²/CAPsMAN (kein EAP-Kauf), Coverage-Fix bleibt Platzierungsfrage (TP3.3). Verworfene Vollvarianten (Omada-only, MikroTik-only) samt Begründung + Ansible/Nautobot-Recherche → Memory. **Anlass der Korrektur:** Omada-Controller↔sw2-Link beim VLAN20-Umzug (TP14.1) zerbrochen, versehentlicher Werks-Reset bei Rettungsversuch, fehlerhafter Wiederherstellungsversuch → sw2 wird standalone neu eingerichtet, s. **TP2.1**.
+- **🛒 Switches: 2× CRS326-24G-2S+RM bestellt (2026-07-14 — CSS326-Fehlbestellung storniert → CRS).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2, s. TP2.1 — Solo/Interim bis CRS-Tausch) + Cudy ab.
   - ✅ **CRS = RouterOS-fähig → in-model:** MikroMCP-Write + Nautobot Golden Config (TP21) managen auch die **Switches**, nicht nur den Router → config-as-code deckt den **ganzen Kabel-Fabric**. (SwOS-Boot bliebe als Fallback möglich, aber nicht genutzt.)
-  - ⚠️ **kein PoE** → Omada-EAPs + Sonoff via **PoE-Injektoren**.
-- **📶 WLAN → Omada EAPs** (ersetzt hAP-Funk + CAPsMAN): löst CAP-ARP/Broadcast-Quirks (P750W-Fall), reifes 802.11k/v/r-Roaming, VLAN→SSID im bereits laufenden Controller. hAP ax² werden Reserve. (Ersetzt die alte hAP-be³-Linie dieses Docs.)
+  - ⚠️ **kein PoE** (Sonoff/PoE-Verbraucher via Injektor, falls nötig).
+- **📶 WLAN bleibt hAP ax²/CAPsMAN** — kein Hardware-/Ecosystem-Wechsel. Coverage-Schwachstellen (P750W-Fall, Terrasse/Kanten) bleiben Platzierungs-/Roaming-Thema von **TP3.3**, nicht durch neue Hardware gelöst.
 - **🧭 Router → RB5009 (mittelfristig):** L3/CAKE/Firewall vom hAP ax² lösen (device-mode=home blockt scheduler/fetch; „AP=Router"-Fragilität) → dedizierte RouterOS-Box, in MikroMCP + Nautobot. hAP ax² danach nur noch WLAN/Reserve.
-- **🔋 DC-USV** (unverändert gültig): MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CSS326 DC-input passt.
-- **Offen:** PoE-Injektor-Auswahl (EAP-Wattage); RB5009-Beschaffung; EAP-Modell (WiFi6 EAP6xx vs WiFi7 EAP7xx); Standort-Zuordnung der 2 Switches (Diele/OG) nach TP19-VLAN1-Retirement.
-- **Hinweis:** die A/B/C/D-Switch-Varianten in `hw-refresh-requirements.md` sind durch die CSS326-Beschaffung überholt (Doc = Recherche-Archiv + USV/Energie-Referenz).
-- Abh.: TP14 ✅ (IP-Migration). Verzahnt: **TP20** (Platform-DB), **TP21** (Nautobot GC).
+- **🔋 DC-USV** (unverändert gültig): MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt.
+- **Offen:** RB5009-Beschaffung; Standort-Zuordnung der 2 CRS326 (Diele/OG) nach TP19-VLAN1-Retirement; ob/wann sw2 durch einen 3. CRS326 abgelöst wird.
+- **Hinweis:** die A/B/C/D-Switch-Varianten in `hw-refresh-requirements.md` sind durch die CRS326-Beschaffung überholt (Doc = Recherche-Archiv + USV/Energie-Referenz).
+- Abh.: TP14 ✅ (IP-Migration). Verzahnt: **TP20** (Platform-DB), **TP21** (Nautobot GC), **TP2.1** (sw2-Standalone-Recovery).
 
 ### TP16 — CF-Tunnel: Round-Robin killen + reziprokes HA ▸ ✅ KERN UMGESETZT (2026-07-10) — `docs/cf-tunnel-mapping.md §10`, #1033
 > **✅ Umgesetzt (2026-07-10, eigene Session):** reziprokes **3-Tunnel-HA** live (bf-nas `70d6a4cf` / bf-pve `f7fdf3a6` / bf-mm `7a322261`), 6 Connectoren (2/Host, je Fremdhost), 19 FQDNs Loop-Smoke **0×530**, HA per Host-Ausfall-Sim bewiesen. Round-Robin-#1033 **strukturell weg**. As-Built = `docs/cf-tunnel-mapping.md §10`. **Offen: Schritt 5 Access-Strang (`vw` bypass→geschützt via WARP, `hass`/`ha-mcp` 400/403 → iPhone-WARP-Enrollment) = user-gated; `gateway-dw` (WG→404) klären.**
@@ -394,17 +401,18 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 
 ### TP19 — cudy-Teardown + VLAN1-Client-Retirement ▸ 🔜 AKTIV (nächste Priorität, User 2026-07-13)
 - **Ziel (Kapstein der Segmentierung, s. Zeile 27):** altes **cudy-WLAN weg** + **VLAN1 als Client-Netz stilllegen** (`defconf`/pool-v1-Client-DHCP zurückziehen). **Nicht** VLAN1 komplett: Switch-/AP-Mgmt (sw1 `.11`/sw2 `.12`/ap2 `.2`) bleiben **by design** in VLAN1 (statisch, kein DHCP nötig) bis zum separaten **MGMT-VLAN99-Cutover** (eigener TP). cudy1/cudy2 = `.41.246`/`.247` (Teardown-Ziele).
-- 🎯 **User-Gate (2026-07-13): sobald die verlorene Shelly + SwitchBot laufen → VLAN1 + cudy-WLAN außer Betrieb.** Twinkly nebenher (saisonal).
+- 🎯 **User-Gate (Update 2026-07-14): Shelly ist wieder da (kein Blocker mehr) — SwitchBot ist KEIN Prereq mehr, funktioniert laut User erst NACH VLAN1-Retirement (Reihenfolge ggü. 2026-07-13 umgedreht) → wandert in die Teardown-Nachlese.** TP19 damit direkt startbereit. Twinkly nebenher (saisonal).
   - **Verlorene Shelly — IDENTIFIZIERT via HA 2026-07-13** (User-Hinweis „du siehst ihn im HA"): HA-Device `shellyplugsg3-e4b063e41ab8`, **Modell = Shelly Plug S Gen3**, **MAC `e4:b0:63:e4:1a:b8`**, HA-device_id `7a21e8f3349e6660f8b35974fc989a7b`. **NICHT im 26er-Inventar** (Spare/Küchen-Steckdose, die Christoph beim Einrichten verbockt hat; er nannte sie „küche s20", aber s20=`98:a3:16:7c:5f:ec` läuft sauber auf `.30.206` — Verwechslung). **KEIN AP-Mode, nicht tot:** assoziiert am **Altnetz `elektrosmog.c`** (cudy → untagged VLAN1-L2), aber mit **bogus-IP `10.95.10.206`** (Fremd-Subnetz, User-Fehler) → unrouting-bar, daher weder in VLAN1/30-Sweep noch normal per IP erreichbar, aber **per MAC in HA/WiFi-Table sichtbar**. Der `.219/s12`-Verdacht war Sackgasse (s12 nur saisonal aus).
-  - **Recovery-Plan (remote, für neue Session, NACH SwitchBot — User-Reihenfolge):** ap1 bekommt **temporäre Zweit-IP `10.95.10.1/24` auf der Bridge** → `10.95.10.206` per L2 erreichbar → **ein** `WiFi.SetConfig {sta: ssid=dirtyvader-iot, pass=IOT-PSK, static, ip=10.40.30.<frei>}` + `Shelly.Reboot` → Gerät kommt auf VLAN30 hoch → temp-IP entfernen. Danach `.30.x`-Reservierung + Inventar (MAC `e4:b0:63:e4:1a:b8`) + eco-Policy. Umgeht die „blutige Nase" (IP am Gerät ändern während man drauf hängt = Verbindungsverlust) — vom Router aus in einem Rutsch. Christophs manueller Direkt-Versuch (AP-IP auf 10.40.30 „verdrehen") war genau deshalb gescheitert.
-  - **SwitchBot floor-lamp** `.41.184` (`b8:f8:62:09:f2:04`, live auf VLAN1/cudy) → **VLAN30 via SwitchBot-App** (kein Local-WiFi-API, nur App/BLE-Provisioning), Res. `.30.227` liegt. = Christoph-App-Task.
+  - **Update 2026-07-14: Shelly wieder da** (User-Meldung) — Live-Status (noch bogus-IP `10.95.10.206` oder inzwischen normal erreichbar?) **zu Sessionbeginn per HA/ARP verifizieren**; Recovery-Plan unten ggf. obsolet, falls sich das Gerät selbst erholt hat.
+  - **Recovery-Plan (falls beim Verify noch nötig):** ap1 bekommt **temporäre Zweit-IP `10.95.10.1/24` auf der Bridge** → `10.95.10.206` per L2 erreichbar → **ein** `WiFi.SetConfig {sta: ssid=dirtyvader-iot, pass=IOT-PSK, static, ip=10.40.30.<frei>}` + `Shelly.Reboot` → Gerät kommt auf VLAN30 hoch → temp-IP entfernen. Danach `.30.x`-Reservierung + Inventar (MAC `e4:b0:63:e4:1a:b8`) + eco-Policy. Umgeht die „blutige Nase" (IP am Gerät ändern während man drauf hängt = Verbindungsverlust) — vom Router aus in einem Rutsch. Christophs manueller Direkt-Versuch (AP-IP auf 10.40.30 „verdrehen") war genau deshalb gescheitert.
+  - **SwitchBot floor-lamp** `.41.184` (`b8:f8:62:09:f2:04`, live auf VLAN1/cudy) → **VLAN30 via SwitchBot-App** (kein Local-WiFi-API, nur App/BLE-Provisioning), Res. `.30.227` liegt. = Christoph-App-Task. ⚠️ **Update 2026-07-14: KEIN Prereq mehr — funktioniert laut User erst NACH VLAN1-Retirement** → verschoben in die Teardown-Nachlese (s.u.), blockiert den cudy-Abschuss nicht mehr.
 - ⚠️ **Prereqs — restliche VLAN1-Clients umziehen, SONST verwaisen sie beim cudy-Tod** (live ap1-ARP 2026-07-13):
   1. **Christophs Endgeräte → VLAN10** (`dirtyvader-main`): MacBook-Air `.41.182` (`c0:c7:db:de:71:be` — **= Claude-Sandbox-Client!** vor cudy-Abschuss umhängen, sonst Zugangs-Verlust), iPhone `.41.186` (aktuell off/asleep).
   2. **2 UNIDENTIFIZIERTE VLAN1-Geräte (2026-07-13):** `.41.133` (`02:11:32:22:1e:25`, lokal-administrierte/randomisierte MAC — Phone-Random? VM?) + `.41.198` (`34:2b:6e:6f:1f:ef`) → **vor Teardown identifizieren + verorten.**
   3. **Media → VLAN40 verifizieren:** Apple TV 4K + Philips TV 50PUS7304 (beide **aus**) einschalten, prüfen VLAN40 vs cudy/VLAN1. ⚠️ **Apple TV = vmtl. Thread-Border-Router** der 22-Matter-Flotte → nicht sorglos stromlos (TP17.1).
   4. **Saisonale Shellys s1/s2/s3/s12** (aus): nach cudy-Tod zeigt `sta` auf tote cudy-SSID → beim Einstecken AP-Mode statt Join. **Empfehlung: vor cudy-Abschuss** kurz einstecken + `migrate.py`, sonst AP-Onboarding später.
   5. **pve-Interim-IP `.41.100`** (bewusst als Fallback belassen) beim Teardown mit abräumen. Streu-Reste final per ARP/DHCP-Sweep auf 0.
-- **Teardown-Sequenz (nach Prereqs):** VLAN1-Client-Sweep = leer (nur Mgmt bleibt) → cudy1/cudy2 stromlos/Reset/ausbauen → ap1 `defconf`/pool-v1-Client-DHCP zurückziehen (VLAN1-Mgmt-Reachability für sw1/sw2/ap2 erhalten) → Interim-Krücken aufräumen (ap2 `frame-types=admit-only-vlan-tagged` = auto-weg mit VLAN1; `st-main rrm/wnm` Roaming-Provisorium neu bewerten) → Inventar/`ip-plan`/DNS `.41→Ziel` final.
+- **Teardown-Sequenz (nach Prereqs):** VLAN1-Client-Sweep = leer (nur Mgmt bleibt) → cudy1/cudy2 stromlos/Reset/ausbauen → **SwitchBot floor-lamp via App/BLE auf VLAN30 provisionieren (jetzt erst möglich, Res. `.30.227`)** → ap1 `defconf`/pool-v1-Client-DHCP zurückziehen (VLAN1-Mgmt-Reachability für sw1/sw2/ap2 erhalten) → Interim-Krücken aufräumen (ap2 `frame-types=admit-only-vlan-tagged` = auto-weg mit VLAN1; `st-main rrm/wnm` Roaming-Provisorium neu bewerten) → Inventar/`ip-plan`/DNS `.41→Ziel` final.
 - Abh.: **TP14 ✅** (Hosts raus aus VLAN1), **TP17 ✅** (Shellys raus). Verwandt: `project_vlan1_dhcp_incident` (cudy-Dual-DHCP-Leak), **VLAN99-MGMT-Cutover** (Folge-TP, entkoppelt), TP5 (Deny-by-default danach sauberer). SSoT hier + Runbook.
 
 ### TP20 — Platform-Datenbank (Postgres Precious-Tier + MariaDB Tier-2) ▸ 🔜 KONZEPT (2026-07-14) — Memory `project_mikrotik_commit_nautobot_gc`