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`

docs/tp2.1-omada-switch-standalone-runbook.md

@@ -0,0 +1,143 @@
+# TP2.1 — Omada-Switch (sw2/ES208G) Standalone-Recovery — Runbook
+
+**Stand: 2026-07-15.** Steuerung/Scope: `docs/teilprojekte.md` → TP2.1 (Playbook-Referenz: TP2).
+Für eine frische Session gedacht — kein Vorwissen aus der Vorgänger-Session vorausgesetzt.
+
+---
+
+## TL;DR
+sw2 (TP-Link Omada ES208G) ist faktisch **jungfräulich** (Werks-Reset). Er wird **diesmal ohne
+Omada-Controller/Managementsoftware** direkt über sein eigenes lokales Web-UI eingerichtet —
+Omada bekommt in diesem Netz generell keine Rolle mehr (auch nicht WLAN, s. TP15-Korrektur).
+sw2 bleibt Solo (keine weiteren Omada-Geräte) und ist ohnehin nur Interim bis zur CRS326-Ablösung (TP15).
+**Vor jeder Config-Änderung:** Portbelegung mit Christoph gemeinsam finalisieren (Draft unten) —
+das war der letzte offene Punkt der Vorgänger-Session.
+
+---
+
+## Root Cause (kurz, für Kontext — nicht Teil der Ausführung)
+Beim VLAN20-Umzug des Omada-Controllers (TP14.1, 2026-07-10) ist die Controller↔sw2-Verbindung
+zerbrochen (sw2 seither "Disconnected" im Controller). 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. Christoph hat 2026-07-15 entschieden: **Controller-Zustand = invalid**, sw2 wird
+sauber neu aufgesetzt, diesmal **ohne** Controller/Managementsoftware-Abhängigkeit.
+
+---
+
+## Zugang
+
+- **Modell:** TP-Link Omada ES208G ("Easy Managed" Tier — Basis-VLAN/QoS lokal möglich, kein CLI
+  bekannt, nur Web-UI, im Gegensatz zu ALLNET/sw1 das Telnet-CLI hat).
+- **Bekannte MAC (verifiziert via ap1-ARP, TP17-Runbook 2026-07-11):** `a8:29:48:ee:b9:04` — nutzen,
+  um den Switch nach dem Reset wiederzufinden, egal welche IP er gerade trägt.
+- **Letzte bekannte statische IP (vor Adoption):** `10.40.41.12` (VLAN1).
+- **Standalone-Creds (vor Controller-Adoption, aus `omada/.secrets`, gitignored):**
+  `OMADA_USER=admin`, `OMADA_PASS=` siehe `omada/.secrets` im Repo-Root. **Nach Werks-Reset vermutlich
+  ungültig** (Reset setzt i.d.R. auch Login auf Default zurück — TP-Link-Standard meist `admin`/`admin`
+  bei Erstzugriff, Passwort-Setup-Wizard beim ersten Login). Verifizieren, nicht blind annehmen.
+- **Omada-Controller-UI** (`https://10.40.20.175:8043`) wird für diese Aufgabe **nicht** mehr gebraucht
+  — Login-Problem dort ist damit ohnehin gegenstandslos (Controller-Pfad wird verlassen).
+
+## Schritt 0 — Switch nach dem Reset finden
+
+TP-Link Easy-Smart/Omada-Switches fallen nach Werks-Reset typischerweise auf DHCP-Client zurück
+(mit Fallback auf eine statische Default-IP, falls kein DHCP antwortet — Gerätehandbuch/Label am
+Switch prüfen, meist `192.168.0.1`). Da VLAN1-DHCP (`defconf`/pool-v1) auf ap1 noch aktiv ist
+(TP19 hat VLAN1 noch nicht abgeschaltet) und der Uplink-Port (sw1 GE8 → sw2 Port1, vermutlich
+weiterhin Trunk mit VLAN1 native/untagged) das durchreicht, ist eine frische DHCP-Lease der
+wahrscheinlichste Fall:
+
+1. **Per MAC suchen:** `mikromcp list_dhcp_leases` (ap1) nach `a8:29:48:ee:b9:04` filtern → liefert
+   die aktuell vergebene IP. Alternativ `list_arp_entries`/`list_neighbors` auf ap1.
+2. **Falls keine Lease sichtbar:** Switch braucht ggf. direkten Trunk-/Access-Pfad zum DHCP-Server
+   (VLAN1 muss durchgängig sein von sw2 bis ap1) — sonst Fallback auf TP-Link **SDM/Discovery-
+   Utility** (Broadcast-basiert, L2-only, braucht einen Rechner im selben Segment) oder physische
+   Default-IP `192.168.0.1` (Laptop temporär auf `192.168.0.x` setzen, direkt an einen freien
+   Switch-Port).
+3. **Erstlogin:** Browser → `http://<gefundene-IP>` (TP-Link Easy-Smart-Switches sind oft nur HTTP,
+   nicht HTTPS wie der ES208G-Controller-Pfad — beides probieren). Login-Screen prüfen: Default-Creds
+   oder Passwort-Setup-Assistent?
+4. **Firmware-Stand notieren** (Werks-Reset ändert die Firmware nicht, nur die Config).
+
+## Schritt 1 — Portbelegung gemeinsam finalisieren (BLOCKIEREND, zuerst!)
+
+**Das war der letzte offene Punkt der Vorgänger-Session — nicht ungeprüft übernehmen.** Draft unten
+basiert auf der TP2-Tabelle (2026-06-15) + bekannten Änderungen seither (Mac mini/NAS jetzt mit
+VLAN20-IPs). Vor jeder Port-Config-Änderung mit Christoph durchgehen:
+
+| Port | Alt-Rolle (TP2, 2026-06-15) | Alt-Profil | Vermutlich noch aktuell? |
+|---|---|---|---|
+| 1 | uplink → ALLNET GE8 | Trunk-ALL | ja, kritisch (einziger Netz-Pfad zu sw2) |
+| 2 | ap2 (hAP ax² #2) | Trunk-ALL | ja, kritisch (TP3.1 braucht 10/30/40/50/90 tagged + VLAN1 untagged) |
+| 3 | frei | Access-MAIN | zu bestätigen |
+| 4 | dock/monitor (Docking-Station) | Access-MAIN | **"Lifeline-Port" laut TP2 — zu bestätigen, ob noch live** |
+| 5 | drucker | Access-MAIN | zu bestätigen |
+| 6 | frei | Access-MAIN | zu bestätigen |
+| 7 | macmini | Access-INFRA (→ VLAN20 heute) | Mac mini hat jetzt `.20.167` — falls noch hier eingesteckt, Profil bleibt sinngemäß gleich |
+| 8 | ds923+ (NAS, 2. Port) | Access-MAIN | **"nicht anfassen" laut TP2 — zu bestätigen, ob noch live** |
+
+**Offene Fragen an Christoph, bevor Port 3-8 angefasst werden:**
+- Hängt an jedem Port noch das, was TP2 sagt, oder hat sich seither was am Verkabelungsplan geändert?
+- Soll die Portbelegung 1:1 aus TP2 übernommen werden, oder gibt es neue Geräte/Bedarf?
+- Bleiben Port 4 (Docking-Station) und Port 8 (NAS) "nicht anfassen"-Ports, oder dürfen die jetzt
+  sauber neu durchkonfiguriert werden (kein Controller mehr im Weg)?
+
+**Kein Portstatus wird geändert, bevor diese Tabelle final ist.**
+
+## Schritt 2 — VLAN-Datenbank anlegen
+
+VLAN-Modell ist unverändert (kanonisch, s. `CLAUDE.md`): 10/20/30/40/50/90/99/100 (+ VLAN1 als
+Mgmt/Legacy bis TP19 abgeschlossen). Analog zum ALLNET-Vorgehen (`switch/ui-guides/01-trunk-ap-ports.md`):
+
+1. Im Switch-Web-UI: VLAN-Sektion → alle 8 VLANs anlegen (IDs, optional Namen wie am Controller
+   vorher: MAIN/INFRA/IOT/MEDIA/UNTRUSTED/GUEST/MGMT/WAN — WAN(100) vermutlich nicht relevant an
+   diesem Access-Switch, prüfen ob er ihn überhaupt braucht).
+2. **VLAN1 bleibt überall untagged/native** bis TP19 den VLAN1-Rückbau macht — kein Lockout-Risiko
+   eingehen (siehe ALLNET-Gotcha: "mgmt-VLAN-Wechsel = Lockout-Risiko, VLAN muss existieren + Port
+   muss es tragen, in einem Schritt").
+
+## Schritt 3 — Ports nach finalisierter Tabelle konfigurieren
+
+Je Port: Mode (Trunk/Access), PVID, VLAN-Membership (Untagged/Tagged) — analog zum ALLNET-Klickpfad
+(`switch/ui-guides/01-trunk-ap-ports.md`, Schritte 1-2), aber im Omada-Easy-Smart-UI (Menüführung
+kann leicht abweichen, Absicht ist identisch: Trunk-Ports = VLAN1 untagged + Ziel-VLANs tagged,
+Access-Ports = PVID auf Ziel-VLAN, restliche VLANs nicht Mitglied).
+
+⚠️ **Port 1 (Uplink) und Port 2 (ap2) zuletzt/vorsichtig anfassen** — das sind die einzigen Pfade,
+über die der Switch selbst und ap2 erreichbar bleiben. Bei jedem Zwischenschritt Erreichbarkeit
+(Switch-UI + ap2-Mgmt `10.40.41.2`) verifizieren, bevor der nächste Port angefasst wird.
+
+## Schritt 4 — Persistieren
+
+Save/Apply im UI (Config-Persistenz nicht vergessen — sonst nach Stromausfall/Reboot wieder weg,
+analog zum ALLNET-`save`-Gotcha).
+
+## Schritt 5 — Verifikation
+
+- Switch-UI weiterhin erreichbar (kein Lockout).
+- ap2-Mgmt (`10.40.41.2`) weiterhin erreichbar (Port 2 nicht kaputt konfiguriert).
+- Je Access-Port: angeschlossenes Gerät bekommt weiterhin eine passende IP/ist erreichbar
+  (Docking-Station, Drucker, Mac mini, NAS — je nachdem was laut Schritt 1 noch dranhängt).
+- `mikromcp list_neighbors`/ARP-Sweep zur Gegenprobe, dass nichts verwaist ist.
+
+## Rollback
+
+- **Kein Controller mehr im Spiel** → kein "Re-Adopt"-Rollback-Pfad. Bei Fehlkonfiguration: einzelne
+  Port-/VLAN-Settings im lokalen UI zurückdrehen, oder im Notfall erneuter Werks-Reset (Switch dann
+  wieder bei Schritt 0).
+- **Physischer Zugriff nötig, falls Web-UI durch eigene Fehlkonfiguration unerreichbar wird** (z.B.
+  Mgmt-VLAN versehentlich von einem live erreichbaren Port entfernt) — Reset-Taster am Gerät.
+
+## Nachziehen (nach erfolgreichem Abschluss)
+
+- `docs/teilprojekte.md` TP2.1 auf ✅ setzen, finale Portbelegung dokumentieren.
+- `docs/ip-plan.md` Zeile sw2 aktualisieren (falls IP sich geändert hat).
+- `CLAUDE.md` Hardware-Tabelle (Zeile Omada Access-Switch) aktualisieren — "Adoption pending" ist
+  obsolet, durch "Standalone, kein Controller" ersetzen.
+- `omada/.secrets` mit neuen Creds aktualisieren (falls Passwort sich geändert hat), Berechtigung
+  `chmod 600` sicherstellen.
+- Prüfen, ob `mcp/omada/.env`/omada-mcp irgendwo noch sw2-spezifische Annahmen hat, die jetzt falsch
+  sind (omada-mcp spricht ohnehin nur noch mit dem Controller für andere Zwecke, falls der überhaupt
+  noch gebraucht wird — zu klären, ob der Controller-Container jetzt komplett überflüssig ist und
+  abgebaut werden kann, da Omada keine Rolle mehr im Netz hat).