Christoph Emsenhuber
b8fd42b3fd
Container crashte beim ersten Deploy mit 'No module named mcp.server.fastmcp': PyPI hat mcp 2.x als aktuellste Version, FastMCP wurde dort zu MCPServer umbenannt. Repo-Code (server.py) nutzt noch v1-API. Fix: requirements.txt 'mcp[cli]>=1.0,<2' — hält den Server auf v1-kompatibel. Deploy-Ergebnis: - Container shelly-mcp auf DS923, IP 10.40.20.180 (macvlan vlan20) - Health /health: 200, psk_configured:true, iot_ssid=dirtyvader-iot - StreamableHTTP /mcp: serverInfo 'shelly-mcp 1.29.1' - Live-Sweep 10.40.30.180-250: 23 Shellys erreichbar TP30 Posten #3 (Shelly-Gerätepasswort) hochgestuft: SHELLY_DEVICE_PW ist im Zuge dieses Deploys erneut in ein Sitzungstranskript geraten (sed-Pattern 'SHELLY_DEVICE_PW=.*' hat den Wert nicht maskiert, weil der Replacement- String zu wenig greedy war — neuer Lessons-Block-Eintrag). Reihenfolge: erst Werkzeug-Härtung (Stream-Filter statt cat+sed), dann Posten #3 rotieren. CLAUDE.md hat den Lessons-Eintrag, TP30 Posten #3 hat die Hochstufungs-Begründung.
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://<ip>/rpc):
WiFi.SetConfig {"config":{"sta":{"ssid":"dirtyvader-iot","pass":"<PSK>","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 gegeninventory/bf.csv, meldet DHCP-Drift und Inventar-Lücken. Basis des MCP-discover-Tools.server.py— MCP-Server:discover/get/set_sta(WLAN→VLAN30, guarded) /set_auth(einheitliches Admin-PWSHELLY_DEVICE_PW, guarded, Digest-Auth-Fallback) /verify/reservation_plan. Go-Runbook:docs/tp17-shelly-go-runbook.md.
Rollout-Reihenfolge (User-Entscheid: Pilot→Rest, Reservierungen je MAC)
- ✅ VLAN30-DHCP-Reservierungen je MAC (liegen; s6-MAC 2026-07-11 gefixt).
- Pilot unkritischer Always-on (
set_sta) → VLAN30-Verify →set_auth(Admin-PW) → HA-Credential. - VLAN30-Reachability + HA/ioBroker-Wiederanbindung verifizieren (Entities bleiben unverändert).
- Rest in Batches; saisonale (
weihnachten_*, Twinkly, Creality) beim nächsten Einstecken. - cudy-Alt-WLAN abbauen; DNS/Inventar/
docs/ip-plan.mdnachziehen.
Status/Detail: 6/26 schon auf VLAN30, 16 morgen. Volle Runbook-Tabelle + Netz-Abgleich in
docs/tp17-shelly-go-runbook.md.