Files

Christoph Emsenhuber 4a6b1b72e1 TP17.1: 2,4-GHz-Bild vollstaendig, UART-Prozedur, zwei Drucker geklaert

Alle vier Funknetze live erhoben: WLAN ap1 ch1 / ap2 ch11, Thread (OTBR) ch15,
ZHA ch20, Z2M ch25. Es sind DREI 802.15.4-Netze, nicht eines -- das war in der
bisherigen Planung nicht abgebildet.

Befund: das Band ist gut geplant bis auf ZHA ch20 (2450), das direkt auf der
Unterkante von WLAN ch11 (2451) sitzt -- ausgerechnet 52 ZHA-Geraete gegen den AP
mit 26 Clients. Thread ch15 und Z2M ch25 liegen je 2 MHz ausserhalb einer
WLAN-Bandkante, also sauber. Die Luecke 2423-2451 (ZB 16/17/18) ist unbenutzt,
aber ein Kanalwechsel muessen 52 Geraete mitmachen -- erst Energy-Scan.

Z2M-Vorbehalt aus dem 2024-Vorfall als eigenes Kapitel: die Fehlerklasse ist
benennbar (Broadcast-/Routing-Sturm, trifft ZHA genauso), der Root Cause aber
nicht mehr rekonstruierbar. Mitigation ohne Ursachenkenntnis = Blast Radius
trennen: die zehn neuen Router komplett in EIN Zigbee-Netz, und zwar nicht in
das, das Licht und Fernbedienungen traegt. Dazu einzeln joinen, Backup vorher,
keine Gruppen-Bindings, Abbruchkriterium vorher festlegen.

UART-Prozedur konkret dokumentiert: J6-Pinout (TXD GPIO16, RXD GPIO17, 3V3, GPIO0
als BOOT, GND), GPIO0 beim Einschalten LOW, Versorgung vom Adapter statt Netz,
Geraet muss aus der Wand. Kein Reset-Knopf. Faellt einmal je Geraet an, danach
alles OTA. Recovery = dasselbe rueckwaerts mit dem 8-MB-Image.

Zwei Korrekturen von Christoph uebernommen:
- Es gibt ZWEI Drucker. P750W = Etikettendrucker auf VLAN30 (stimmte), der
  eigentliche Brother MFC haengt auf VLAN10 -- live bestaetigt 10.40.10.6, OUI
  Brother, statisch. Auch in CLAUDE.md eingetragen, samt der Folge fuer TP5: der
  MFC steht im selben VLAN wie die Macs, die forward-Kette greift dort nicht.
- s1/s2/s3 (weihnachten) sind in HA DEAKTIVIERT, nicht fehlend. Meine Formulierung
  "existieren gar nicht" war falsch -- deaktivierte Entities haben keinen Zustand.

Entity-Bruch entschaerft: der Umbau behaelt die Entity-Namen (User-Entscheid).
Damit faellt der teuerste Posten der Abwaegung weg, fuer Zigbee wie fuer Thread.
Zwei Fallen dazu notiert (alte entity_id erst nach Entfernen frei; unique_id und
Statistiken sind trotzdem neu).

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

2026-08-23 10:04:12 +02:00

19 KiB

Raw Blame History

TP17.1 — Shelly Gen4 raus aus dem WLAN (Thread oder Zigbee) · Runbook

Status 2026-08-23: 🔜 entscheidungsreif, nicht startbereit. Schritt 0 ist eine Abwägung, kein Flash. Steuerung/Scope: teilprojekte.md → TP17.1. Kein Netz-Eingriff bisher, alle Zahlen hier sind read-only erhoben.

📌 Wohnort dieses Arbeitspakets: das Netz-Projekt (User-Entscheid 2026-08-23). Eine erste Fassung lag kurzzeitig im HA-Projekt (ha-xstate) — sie ist dort entfernt, damit es keine zweite Wahrheit gibt. HA ist Betroffener, nicht Eigentümer: die Entities brechen, aber die Entscheidung ist eine Funk- und Netzentscheidung.

Das Ziel (Christophs Begründung, dreiteilig)

Die PSK-Rotation wird billiger. Jedes Gerät, das den Funk wechselt, fällt aus der Rechnung.
Mesh-Stabilität — netzgespeiste Geräte sind immer Router-Knoten, nie Sleepy End Devices.
Ruhe im WLAN. 26 der 27 WLAN-Clients des ganzen Netzes hängen auf dirtyvader-iot.

⚠️ Punkt 1 trägt nur teilweise. Kandidaten sind 10 Geräte; danach blieben grob 16 auf dem IoT-SSID. Die Rotation wird kleiner, nicht überflüssig — und Gen3 kann nie folgen, dort fehlt 802.15.4. (Seit 2026-08-23 ist das ohnehin entschärft: Rotation und Funkmigration laufen parallel, s.u.)

Bestand (live 2026-08-23, `mcp/shelly/discover.py`, read-only)

22 von 26 Shellys erreichbar auf VLAN30, alle auf Firmware 2.0.0:

Gen	Anzahl	Modelle
Gen4	12	9× `S4SW-002P16EU` (2PM) · 1× `S4SW-001P16EU` (1PM) · 2× `S4PL-00416EU` (Power Strip)
Gen3	8	`S3PL-00112EU`, `S3PL-30116EU`
Gen2	2	`SPDM-002PE01EU`, `SNDC-0D4P10WW`

Die 12 Gen4: s25 bad_lichtschalter .205 · s20 kueche_steckdosen2 .206 · s21 kueche_steckdosen4 .207 · s12 dieleug_steckdosen .219 · s16 wohnzimmer_steckdosen .223 · s17 bad_steckdosen .224 · s18 kueche_steckdosen1 .225 · s19 kueche_steckdosen3 .226 · s26 bad_luefter .233 (alle 2PM) · s22 kueche_steckdose3-2 .202 (1PM) · s9 wohnzimmer_sideboard .216 und s13 arbeitszimmer_technik .220 (Power Strip).

Nicht erreichbar (4): s1/s2/s3 (weihnachten_*, saisonal ausgesteckt — die HA-Entities sind deaktiviert, nicht gelöscht, deshalb tauchen sie in keiner Zustandssuche auf; Christoph 2026-08-23) und s4 kueche_mikrowelle — der einzige, den auch HA als unavailable führt. Hängt hinter Metall bei RSSI −93 dBm, Generation unbekannt. Falls Gen4: bester Pilot überhaupt, denn 802.15.4 kommt dorthin, wo 2,4-GHz-WLAN scheitert.

🔴 Die Firmware-Lage — der Kern der Entscheidung

Direkt an den Geräten erhoben (Shelly.CheckForUpdate, read-only, 2026-08-23):

	Befund
Stable	2.0.0 überall — für kein Gerät ein stabiles Update
Beta	`2.0.1-beta1`, Build 2026-08-19, für alle inkl. Gen3
Alt-Varianten (nur Gen4)	`S2PMG4ZB` · `S1PMG4ZB` · `PowerStripZB` — jeweils „with Zigbee"
Gen3	kein `alt`-Eintrag → Alternativfunk ist Gen4-only

Thread gibt es von Shelly heute nicht. Die offizielle Linie ist „wird evaluiert" (Stand Juli 2026, genannter Engpass: Flash-Platz), kein Release-Datum. Was im Mai 2026 als „Thread für Gen4" durch die Presse ging, war die Dritt-Firmware.

🎯 Der wichtigste Nebenbefund: Shelly liefert alternative Funk-Firmware über den normalen Update-Kanal, nicht über einen Bastelpfad. Eine Thread-Variante erschiene mit hoher Wahrscheinlichkeit genau dort als weiterer alt-Eintrag. ⇒ Frühindikator statt Warten auf Pressemeldungen: Shelly.CheckForUpdate auf einem Gen4 pollen und auf einen …MT/Thread-Eintrag warten.

Die drei Wege im Vergleich

Weg	Deckt ab	Preis	Reife
(A) Zigbee, offiziell — heute verfügbar	10 der 12 (2PM, 1PM, Power Strip)	Entity-Bruch (Shelly-Integration → Z2M); 2,4-GHz-Kanalplanung nötig	Hersteller-Firmware, offizieller Kanal, keine Garantie-/Cloud-Frage
(B) Thread, offiziell — warten	offen	nur Wartezeit	existiert nicht; „wird evaluiert", Flash-Platz als Engpass
(C) Thread, Dritt-Firmware — heute möglich	10 der 12 via hencou (die automatous-io-Variante deckt hier 0 ab)	Garantie + Cloud + offizielle OTA weg; Rückweg nur mit UART-Vollbackup je Gerät; PM-Kalibrierung Platzhalter; Test-VID	nur Shelly 1 Gen4 auf echter Hardware verifiziert, andere Profile ungetestet

Die zwei S4PL-00416EU (s9, s13) deckt keiner der Wege ab — sie bleiben im WLAN.

💡 Empfehlung, falls gefragt: (A) prüfen, bevor (C) erwogen wird. Zigbee erfüllt alle drei Ziele oben — heute, mit Hersteller-Firmware, ohne Garantieverlust, ohne UART-Backup. Zigbee2MQTT läuft bereits als LXC 112 (10.40.20.106, z2m25). Was vorher zu klären ist:

(a) Rückrollbarkeit: Ist der Wechsel des Funkstacks so zurückrollbar wie ein normales Update? Das ist ein anderer Vorgang als ein Versionssprung — vor dem ersten Gerät klären.
(b) Kanalplanung: ✅ erledigt, s. eigenes Kapitel unten. Kurzfassung: Thread 15, ZHA 20, Z2M 25, WLAN 1 + 11. Sauber bis auf ZHA ch20, das auf der Unterkante von WLAN ch11 sitzt.
(c) Entity-Bruch: ✅ entschärft (User-Entscheid 2026-08-23) — „wir werden so umbauen, dass die Entitäten ihren Namen behalten." Der Umbau benennt die neuen Entities auf die alten entity_ids zurück, damit Automationen, Dashboards und die FSM-Configs unverändert bleiben. ⚠️ Zwei Fallen dabei: (1) die alte entity_id ist erst frei, wenn die alte Integration das Gerät losgelassen hat — sonst hängt HA ein _2 an; also erst entfernen, dann neu anlernen, dann umbenennen. (2) Der Name überlebt, die History nicht zwangsläufig — der Recorder keyt auf entity_id, das passt, aber unique_id und Device-Zuordnung sind neu. Energie-Dashboard-Statistiken brauchen ggf. einen Fix-Lauf. ⇒ Damit fällt der teuerste Posten der ganzen Abwägung weg. Er gilt für Weg (A) und (C) gleich.

📻 Das 2,4-GHz-Bild — alle vier Netze, live erhoben 2026-08-23

Das ist der Rechenschritt, der bei „einfach auf Zigbee umstellen" gern übersprungen wird. Es gibt hier drei 802.15.4-Netze neben dem WLAN, nicht eines:

Netz	Kanal	Mitte	belegt ca.	Geräte	Quelle
WLAN ap1	1	2412	2401–2423	—	CAPsMAN
Thread (OTBR)	15	2425	2424–2426	~30 Matter-Knoten	`ha_manage_radio thread`
ZHA	20	2450	2449–2451	52 Geräte	ZHA-Diagnostics, EZSP/bellows
WLAN ap2	11	2462	2451–2473	26 Clients	CAPsMAN
Z2M (`z2m25`)	25	2475	2474–2476	—	`configuration.yaml`, zstack

ZHA-Koordinator: SONOFF Dongle-M, angebunden über Netz (socket://10.40.30.137:6638), PAN 23386, tx_power=8. Zwei weitere ZHA-Einträge (Dongle Plus V2, Dongle-M_10E8) stehen auf ignore — das ist Absicht, sonst griffe ZHA nach dem Z2M-Stick.
Z2M-Koordinator: ITead Sonoff Zigbee 3.0 USB Dongle Plus, adapter: zstack.

🎯 Befund: das Band ist gut geplant — mit genau einer Ausnahme.

Thread ch15 (2425) liegt 2 MHz über der Oberkante von WLAN ch1. Knapp, aber sauber.
Z2M ch25 (2475) liegt 2 MHz über der Oberkante von WLAN ch11. Ebenso sauber — das ist die klassisch richtige Wahl.
🔴 ZHA ch20 (2450) liegt direkt auf der Unterkante von WLAN ch11 (2451). Das ist die einzige echte Nachbarschaft im Haus — und sie trifft ausgerechnet das Netz mit 52 Geräten gegen den AP mit 26 Clients.
💡 Die Lücke zwischen WLAN ch1 und ch11 (2423–2451) ist unbenutzt. Dort liegen ZB 16/17/18 (2430/2435/2440) — mitten im Freiraum, nichts sendet da. ⚠️ Trotzdem nicht blind umziehen: einen Kanalwechsel müssen 52 Geräte mitmachen; schlafende und ältere Router folgen dem nwk_update_id-Broadcast nicht zuverlässig und bleiben zurück. Das ist dieselbe Fehlerklasse wie der Vorfall von 2024 (s.u.). Erst Energy-Scan in ZHA fahren, dann entscheiden — nicht umgekehrt.

Wohin kämen die Shelly-Zigbee-Geräte?

Sie wären netzgespeiste Router, keine End Devices — sie verändern also die Routing-Topologie des Netzes, dem sie beitreten. Drei Optionen, und die Wahl ist eine Blast-Radius-Frage:

	Wirkung
In ZHA (52 Geräte, ch20)	dichteres Mesh dort, wo die Fernbedienungen hängen — aber das ist das Netz, das die Automationen trägt, und es sitzt auf dem einzigen kontendierten Kanal
In Z2M (ch25, sauberer Kanal)	technisch der bessere Kanal — aber genau das Netz, mit dem 2024 die Installation zusammenbrach (s.u.)
Getrennt halten	10 Router in ein Netz, das andere unangetastet lassen ⇒ wenn es schiefgeht, läuft die andere Hälfte des Hauses weiter

🔑 Empfehlung: die Trennung als Sicherheitsnetz nutzen, die es faktisch schon gibt. Zwei unabhängige Zigbee-Netze sind ein Vorteil, kein Zufall — die Shellys gehören komplett in eines, und zwar in das, das nicht die Beleuchtung und die Fernbedienungen trägt. Dann kann eine Routing-Störung durch die neuen Router keine „Lichterdisko" mehr auslösen, weil die Lichter gar nicht in diesem Netz hängen.

⚠️ Christophs Z2M-Vorbehalt — ernst zu nehmen, und benennbar

Erfahrung (2024): „mir hats vor 2 jahren die ganze installation gekillt. nichts mehr steuerbar, musste alles resetten und neu aufbauen. Lichterdisko war das damals."

Das ist kein diffuses Unbehagen, sondern eine bekannte Fehlerklasse. „Alles unsteuerbar + Lichter feuern von selbst" ist das Bild eines Zigbee-Broadcast-/Routing-Sturms: das Netz sättigt sich mit Broadcasts, Routing-Tabellen thrashen, Kommandos kommen mehrfach oder gar nicht an. Typische Auslöser sind Gruppen-/Binding-Schleifen, ein einzelnes fehlerhaftes Router-Gerät (billige Bulbs sind berüchtigt), oder schlicht zu viele Broadcasts auf einem überlasteten Kanal. Nicht ursächlich ist üblicherweise „Z2M als Software" — dieselbe Klasse trifft ZHA genauso.

⚠️ Der Root Cause von damals ist heute nicht mehr rekonstruierbar (Netz wurde neu aufgebaut, keine Logs). Deshalb ist die ehrliche Aussage: wir wissen nicht, ob es wiederkommt — aber wir können die Bedingungen ungünstig machen:

Blast Radius trennen (s.o.) — die wirksamste Maßnahme, weil sie ohne Ursachenkenntnis wirkt.
Nicht im Batch beitreten lassen. 10 neue Router auf einmal ändern die Topologie schlagartig. Einzeln, mit ein paar Tagen Abstand — und dazwischen schauen, ob Kommandos noch prompt ankommen.
Vorher einen Rückweg festhalten: Z2M/ZHA-Backup (coordinator_backup.json bzw. ZHA-Backup) vor dem ersten Join. Genau das hat 2024 gefehlt — der Wiederaufbau war nötig, weil es kein Netz-Backup gab, nicht weil die Geräte kaputt waren.
Keine Gruppen-Bindings für die Shellys anlegen, solange sie neu sind. Direktes Binding ist der Pfad, auf dem Schleifen entstehen; über HA gesteuert passiert das nicht.
Ein Abbruchkriterium vorher festlegen: wenn nach einem Join die Latenz eines bekannten Geräts spürbar steigt, das Gerät wieder entfernen — nicht „wird sich schon einpendeln".

📌 Und die nüchterne Gegenrechnung: 10 zusätzliche Router machen ein Zigbee-Mesh normalerweise stabiler, nicht instabiler — das ist der Regelfall. Der Vorfall von 2024 ist ein Grund für Vorsicht und Backups, kein Grund, den Weg auszuschließen.

🔌 UART-Backup: was das praktisch heißt (nur für Weg C nötig)

Kurzantwort: ja, einmal physisch ans Gerät — aber es ist keine Taste, und es ist genau einmal.

Der J6-Header (7-polig, 1,27 mm Raster, auf der Rückseite der Platine):

Pin	Funktion	GPIO
2	TXD → RXD des Adapters	GPIO16
3	RXD ← TXD des Adapters	GPIO17
4	3,3 V — Versorgung vom Adapter	—
6	BOOT — muss beim Einschalten LOW sein	GPIO0
7	GND	—

Der Ablauf je Gerät: Modul stromlos machen und ausbauen → Gehäuse öffnen → fünf Pins an einen USB-UART-Adapter (3,3 V, kein 5 V!) → GPIO0 beim Anlegen der Versorgung auf LOW ziehen → esptool.py read_flash über die vollen 8 MB → das Image wegsichern → dann erst flashen.

⚡ Nicht am Netz. Die Versorgung kommt beim Flashen vom Adapter, nicht von 230 V — das Gerät muss also aus der Wand.
🔘 Kein Reset-Knopf. Der ESP32-C6 geht über die Strapping-Leitung in den Download-Modus. Viele Adapter schalten das per DTR/RTS automatisch; ob das an diesem J6 durchgeschleift ist, steht nicht in der Doku — am ersten Gerät ausprobieren, sonst GPIO0 von Hand nach GND brücken.
✅ Danach nie wieder UART. Alle weiteren Updates laufen OTA (Matter-OTA, Dashboard-Upload). Der Aufwand fällt einmal je Gerät an, nicht bei jedem Update.
🔁 Recovery = dasselbe Prozedere rückwärts, mit dem gesicherten 8-MB-Image. Bricht dabei der Strom weg, während der Bootloader geschrieben wird, ist das Gerät nur noch per UART zu retten — ein zweites Mal öffnen, kein Weg über die Luft.
⚠️ Der Weg ohne UART existiert (Paket über die Shelly-Web-UI hochladen), kann aber kein Backup erzeugen und ist damit praktisch einseitig.

🎯 Konsequenz für die Wegwahl: die Frage „wie viele Module sitzen Unterputz hinter einem Schalter" entscheidet über den Aufwand von Weg (C) mehr als alles andere. Weg (A) Zigbee braucht davon nichts — das ist ein normales Update über den Hersteller-Kanal.

Vorbedingungen aus dem Netz (stehen bereits, nur für den Thread-Weg relevant)

✅ Thread-Border-Router läuft, ~30 Matter-Knoten produktiv (OTBR auf demselben Host wie HA).
✅ Commissioning-Pfad erprobt: temporäre SSID dirtyvader-infra (VLAN20) nach matter-pairing-infra-ssid-runbook.md — am 2026-08-22 mit dem TIMMERFLOTTE bewiesen. cfg-infra/dp-infra/sec-infra stehen dauerhaft am Manager.
🔴 Nötig ist der Umweg, weil TP12.1 offen ist: zwischen VLAN10 (iPhone) und VLAN20 (Border Router) wird kein IPv6 geroutet → Commissioning-Etappe 2 bricht ab. Und ble_proxy ist wirkungslos, seit der ESP32-BT-Proxy ausgeschlossen wurde (User 2026-08-22). ⇒ Jedes weitere Thread-Gerät zahlt diesen Umweg erneut — das stärkste Argument für TP12.1.
⚠️ Firewall ist deny-by-default — ein neuer Dienst über eine VLAN-Grenze braucht eine explizite Regel. Für den Zigbee-Weg heißt das: der Pfad Gerät → Z2M (10.40.20.106) läuft über den Zigbee-Koordinator, nicht über IP — es entsteht kein neuer VLAN-Übergang. Ein Punkt weniger.

Ablauf

Schritt 0 — entscheiden, nicht flashen. Weg (A), (B) oder (C). Grundlage ist die Tabelle oben. Das ist Christophs Abwägung; sie hängt an Garantie, Rückweg und daran, wie lange er auf (B) warten will.

Schritt 1 — Pilot mit genau EINEM Gerät. Kandidat: s26 bad_luefter oder s12 dieleug_steckdosen — beide 2PM Gen4, funktional unkritisch, keine Verbrauchsmessung im Energie-Dashboard. Nicht mit einem Küchengerät anfangen (Kühl-/Tiefkühlschrank hängen dort). Bei Weg (C) vorher UART-Vollbackup, sonst gibt es keinen Rückweg.

Schritt 2 — HA-Seite bilanzieren, bevor das zweite Gerät drankommt. Welche entity_ids sind neu, was zeigt noch auf die alten? grep über die HA-Automationen und die FSM-Configs im ha-xstate-Repo (machines/*.json). Erst wenn der Pilot in HA vollständig verdrahtet ist, war er erfolgreich.

Schritt 3 — Wellen zu 3–4 Geräten, nach Raum gruppiert, gleiches Abnahmekriterium.

Schritt 4 — Zahl zurückmelden: wie viele Geräte sind aus dirtyvader-iot verschwunden. Diese Zahl macht die PSK-Rotation planbar.

Abnahmekriterium

Pro Gerät ein frischer Knoten im Zielnetz UND eine funktionierende HA-Entity — nicht die Anzeige in einer Tabelle. Im Netz-Projekt hat genau diese Verwechslung einmal 14 Stunden gekostet: die Registration-Table zeigte 25 zufriedene Clients, während keiner davon eine IP bekam.

Verzahnung mit der PSK-Rotation (parallel, nicht nacheinander)

User-Entscheid 2026-08-23: beides läuft gleichzeitig. Möglich macht das der Passphrase-Override je MAC in /interface wifi access-list (RouterOS 7): neuer PSK aufs Profil, noch nicht migrierte Geräte übergangsweise per MAC mit dem alten weiter, danach Liste leeren — kein Flag-Day.

🔑 Die eine Regel, die die Parallelität kostenlos macht: ein Gerät, das ohnehin den Funk wechselt, bekommt den neuen PSK gar nicht — nur einen Übergangseintrag, und verschwindet später ganz.

⚠️ Nicht vergessen: s1/s2/s3 sind ausgesteckt und in HA nicht eingebunden. Sie kommen beim nächsten Einstecken mit dem alten PSK zurück — sie gehören auf die Override-Liste, sonst stehen sie im Dezember im AP-Mode.

Offene Fragen für die erste Sitzung

Ist s4 kueche_mikrowelle ein Gen4? Falls ja → bester Pilot, größter Gewinn (−93 dBm heute).
Wie viele der 10 Kandidaten sind physisch zugänglich? Unterputz-Module hinter Schaltern zu öffnen ist bei Weg (C) Pflicht (UART), bei Weg (A) nicht.
Bei Weg (A): welcher Zigbee-Kanal, gemessen gegen ap1 ch1 / ap2 ch11 — und was sagt der bestehende Z2M-Koordinator dazu, der schon IKEA-Geräte trägt?
✅ Geklärt (Christoph 2026-08-23): es sind ZWEI Drucker. Der P750W ist der Etikettendrucker und hängt korrekt auf VLAN30 (10.40.30.5). Der eigentliche Drucker ist ein Brother MFC auf VLAN10 — live bestätigt: 10.40.10.6, MAC 30:05:5C:78:86:20 (OUI = Brother Industries), ARP-Status delay = aktiv, keine DHCP-Reservierung (statisch konfiguriert). Beide Angaben waren richtig, sie meinten verschiedene Geräte. 📌 Für TP5 relevant: die Merkregel „Drucker fällt mit udp/161 SNMP aus, nicht mit 631" (ref_printer_snmp_before_ipp) betrifft den VLAN-übergreifenden Fall. Der MFC steht im selben VLAN wie die Macs — dort greift die forward-Kette gar nicht.

Verweise

Steuerung: teilprojekte.md → TP17.1, TP12.1 (IPv6/Matter), Follow-up PSK-Rotation
Migrationshistorie der Shellys (VLAN1 → VLAN30, 26 Geräte, 0 Fehler) inkl. Anker-Verfahren gegen den AP-Mode-Fallstrick: teilprojekte-archiv.md → TP17
Werkzeug: mcp/shelly/ — discover.py (read-only), migrate.py (Dry-Run default). ⚠️ Kein Rotate-Kommando vorhanden, es bräuchte eine Variante über denselben set_sta-Pfad.
HA-Seite: ~/dev/ha-xstate (FSM-Configs machines/*.json)

19 KiB Raw Blame History Unescape Escape