# shelly-mcp — Shelly-Verwaltung & VLAN1→VLAN30-Migration (TP17) Tooling, um die ~26 Shellys von der alten cudy-WLAN/VLAN1 (`10.40.41.2xx`) auf die IOT-SSID **`dirtyvader-iot`** (VLAN30, `dhcp-v30`/pool-v30) umzuklemmen und danach dauerhaft zu verwalten. Steuerung/Status: `docs/teilprojekte.md` → **TP17**. ## Ist-Stand (Recon 2026-07-11) - **16 live**, alle **Gen3/Gen4** → uniforme RPC-API (`WiFi.SetConfig`), `auth=off`. Kein Gen1-Sonderfall. - **10 nicht erreichbar:** `weihnachten_*` (s1/s2/s3, saisonal ausgesteckt) + s12/s14/s16/s18/s22/s23 (aus / DHCP-drift). s24 hat keine MAC im Inventar. - Recon-Snapshot: `python3 discover.py 10.40.41.180-250 --json`. ## Migrationsmechanismus (per Gerät) Gen2+ RPC (HTTP POST `http:///rpc`): ``` WiFi.SetConfig {"config":{"sta":{"ssid":"dirtyvader-iot","pass":"","enable":true}}} ``` → `Shelly.Reboot` (oder greift nach kurzer Zeit selbst) → Gerät verschwindet aus VLAN1, kommt per `dhcp-v30` auf `10.40.30.x` (mit MAC-Reservierung = stabile IP). ⚠️ **Falsches PSK → Gerät geht in AP-Mode (SSID `Shelly*`) → physischer Reset nötig.** Immer erst `WiFi.GetStatus`/`Sys.GetStatus` gegenchecken, Pilot vor Batch. ## Dateien - `discover.py` — read-only Sweep, identifiziert Shellys per `/shelly`, matcht MAC gegen `inventory/bf.csv`, meldet DHCP-Drift und Inventar-Lücken. Basis des MCP-`discover`-Tools. - `server.py` — (in Arbeit) MCP-Server: `discover` / `get` / `set_sta` (Migration, guarded) / `verify`. ## Rollout-Reihenfolge (User-Entscheid: Pilot→Rest, Reservierungen je MAC) 1. VLAN30-DHCP-Reservierungen je MAC anlegen (MikroMCP `manage_dhcp_lease`). 2. **Pilot** 2–3 unkritische Always-on (z.B. `bad_luefter` .233 / `technik_pve` .222) umklemmen. 3. VLAN30-Reachability + HA/ioBroker-Wiederanbindung verifizieren. 4. Rest in Batches; `weihnachten_*` beim nächsten Einstecken. 5. cudy-Alt-WLAN abbauen; DNS/Inventar/`docs/ip-plan.md` nachziehen.