Files

Christoph Emsenhuber 2f183190ed TP17.1 verworfen + s9 zurueckgebaut, eco_mode flottenweit aus

Christophs strukturelle Frage hat TP17.1 gekippt: "zigbee sollte die
antwort auf die vielen radios auf -iot geben. nutzt aber wenig wenn man
das wifi nicht abdrehen kann bzw. es nicht mehr aktivieren kann ohne
reset."

Der Pilot hat den Weg technisch vollstaendig bewiesen -- und gezeigt, dass
das Ziel so nicht erreichbar ist. Das Geraet bleibt WLAN-Client; der
gemessene Funkgewinn ist klein (12 von 26 IoT-Clients, je 150-200 KB rx /
0,6-3 MB tx in sechs Stunden); und WLAN abzuschalten waere unumkehrbar,
weil die Zigbee-Firmware keinen AP hat, Shelly kein Zigbee-OTA macht und
InstallAlt eine IP braucht. Der Weg ist nicht gescheitert, das Ziel war
mit ihm nicht erreichbar. Das Runbook bleibt als Wissensspeicher.

Rueckbau: ZHA-Knoten entfernt -- Leave VOR dem Flash, damit kein
Geisterrouter im 52-Geraete-Mesh bleibt. s9 zurueck auf PowerStrip, Config
aus dem Backup. Alle vier roten EZSP-Zaehler blieben 0, Retry-Quote fiel
im Delta auf 8,9 %.

Neue Merkregel: der Rueckflash zog einen OFFENEN AP hoch (ap.enable=true,
is_open=true). Abgeschaltet und mit dem IoT-PSK abgesichert. Nach jedem
Shelly-Firmwarewechsel den AP pruefen.

eco_mode flottenweit aus (User: "der rotz macht nur probleme"): 13 Geraete
umgestellt, null Fehler, 9 standen schon so. Jetzt eco=false auf allen 22
erreichbaren Shellys ausser s24, das es nicht unterstuetzt. Dafuer
migrate.py um ein eco-Kommando ergaenzt -- mit Retry je Geraet, weil ein
Timeout an einem schwachen Link den Sweep sonst abreisst.

Die Gegenmessung widerlegt meine eigene Warnung: eco aus hebt die
Sendeleistung NICHT messbar an. 13 geaenderte Geraete im Mittel -0,9 dB,
Kontrollgruppe von 13 unveraenderten +0,0 dB bei gleicher Streuung. Die
TP17-Aussage, eco senke Takt UND Sendeleistung, stimmt nur zur Haelfte.

Vorbedingung der Passwort-Rotation geprueft: alle vier Skripte laufen
laengst auf sshpass -e, die gegenteilige Notiz war veraltet. Uebrig war
CLAUDE.md, das sshpass -p weiterhin aktiv als Reboot-Weg empfahl -- genau
das Muster, das den Leak verursacht hat. Auf sshpass -e korrigiert.

TP17.2 aus "zurueckgestellt" aktiviert und an die PSK-Rotation gekoppelt.

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

2026-08-23 21:12:46 +02:00

.env.example

feat 🔌 shelly-mcp set_auth-Tool + Digest-Auth-Fallback (TP17 Geräte-PW)

2026-07-11 07:17:16 +02:00

discover.py

feat 🔌 shelly-mcp + TP17 Shelly-Migration VLAN1→VLAN30; TP14.3 dormante Stacks bereitgestellt

2026-07-11 01:15:32 +02:00

migrate.py

TP17.1 verworfen + s9 zurueckgebaut, eco_mode flottenweit aus

2026-08-23 21:12:46 +02:00

migration-log.jsonl

chore 🔌 gitea-mcp in .mcp.json registriert + TP17 Shelly-Migrationslog (16 Geräte VLAN1→VLAN30)

2026-07-13 19:58:37 +02:00

README.md

feat 🔌 shelly-mcp set_auth-Tool + Digest-Auth-Fallback (TP17 Geräte-PW)

2026-07-11 07:17:16 +02:00

server.py

feat 🔌 TP17: statische Shelly-IP + in-pool-Reservierung + voller HA-MAC-Scan

2026-07-11 07:45:08 +02:00

README.md

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 gegen inventory/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-PW SHELLY_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.md nachziehen.

Status/Detail: 6/26 schon auf VLAN30, 16 morgen. Volle Runbook-Tabelle + Netz-Abgleich in docs/tp17-shelly-go-runbook.md.