Commit Graph

6 Commits

Author SHA1 Message Date
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
3426366cee chore 🔌 gitea-mcp in .mcp.json registriert + TP17 Shelly-Migrationslog (16 Geräte VLAN1→VLAN30)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 19:58:37 +02:00
2135772e04 feat 🔌 TP17 GO: 16 Shellys VLAN1→VLAN30 (Anker-Verfahren) + eco-Policy; TP17.2/TP19 angelegt
- migrate.py: anker-sicherer Runner (AP-Anker vor sta-Write, deanchor, auth, table)
- 16 Shellys migriert (Pilot+2 Wellen), 22/26 auf VLAN30, VLAN1 shelly-frei
- eco-Policy RSSI-basiert (AN >= -80, AUS < -80), provisorisch bis TP3.3
- bf.csv: 22 Shelly-Zeilen .41→.30, Section→IOT
- TP17.2 (Geräte-PW, zurückgestellt/Kosmetik) + TP19 (cudy-Teardown + VLAN1-Retirement) angelegt
- Verlorene Küchen-Shelly via HA identifiziert (Plug S Gen3, e4:b0:63:e4:1a:b8, bogus-IP 10.95.10.206 auf elektrosmog.c) → Remote-Recovery-Plan in TP19

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 17:27:56 +02:00
248b1b5e74 feat 🔌 TP17: statische Shelly-IP + in-pool-Reservierung + voller HA-MAC-Scan
- Entscheidung: alle Shellys bekommen statische IP (10.40.30.<octet>, gw/dns .30.1)
  + in-pool DHCP-Reservierung als Backup. set_sta auf static=true (Default) umgestellt
  (Ziel-IP aus Oktett), _sta_cfg-Helper.
- pool-v30 auf .100-.250 erweitert (Reservierungen jetzt in-pool, User-Konvention).
- s24 (14:33:5c:d8:2d:7c) ins inventory/bf.csv + .30.204-Reservierung.
- Voller HA-Device-Scan (alle MAC-Geräte, nicht nur configuration_url): fand
  Apple TV 4K + Philips TV (aus, VLAN40) — vor cudy-Teardown VLAN verifizieren;
  Apple TV = vmtl. Thread-Border-Router (TP17.1). Tasmota bestätigt tot (MAC nicht im Netz).
- .41.246/.247 = cudy1/cudy2 (Teardown-Ziele) dokumentiert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 07:45:08 +02:00
794082fd74 feat 🔌 shelly-mcp set_auth-Tool + Digest-Auth-Fallback (TP17 Geräte-PW)
- set_auth: setzt einheitliches Admin-PW (SHELLY_DEVICE_PW) via Shelly.SetAuth,
  realm=Geräte-ID, ha1=sha256("admin:realm:pw") pro Gerät; guarded (confirm/dry-run).
- _rpc: HTTP-Digest-Fallback (user admin) bei 401 → Geräte bleiben nach set_auth managebar.
- .env.example/README: SHELLY_DEVICE_PW dokumentiert (getrennt vom WLAN-PSK); Rollout mit PW-Schritt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 07:17:16 +02:00
e76289c8e9 feat 🔌 shelly-mcp + TP17 Shelly-Migration VLAN1→VLAN30; TP14.3 dormante Stacks bereitgestellt
TP17 (neu): shelly-mcp (eigenbau, FastMCP StreamableHTTP :3030 + Status/Health-Seite,
in .claude/launch.json) mit Tools discover/get/set_sta[guarded]/verify/reservation_plan.
Recon: 16 Shellys live, alle Gen3/4 (RPC WiFi.SetConfig, auth=off). Inventar-Fix:
s6/kueche_kuehlschrank MAC 0c:72… → real d0:cf:13:d8:18:fc.

TP14.3: 7 dormante Stacks als .new.yml bereitgestellt (nur lokal, gitignored) — SSoT
in docs/teilprojekte.md nachgezogen.

mcp/INVENTORY.md: shelly-mcp-Zeile + Richtungsentscheid „MCPs zentral, nicht Client;
MikroMCP+shelly-mcp sind pragmatische Interims, später zusammenziehen".

.gitignore: __pycache__/*.pyc.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 01:15:32 +02:00