Christoph Emsenhuber
4a6b1b72e1
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>
306 lines
19 KiB
Markdown
306 lines
19 KiB
Markdown
# 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`](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)
|
||
|
||
1. **Die PSK-Rotation wird billiger.** Jedes Gerät, das den Funk wechselt, fällt aus der Rechnung.
|
||
2. **Mesh-Stabilität** — netzgespeiste Geräte sind immer Router-Knoten, nie Sleepy End Devices.
|
||
3. **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](https://github.com/hencou/shelly_gen4_matter_module) *(die [automatous-io](https://github.com/automatous-io/shelly-1-gen4-matter-thread)-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_id`s
|
||
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:
|
||
|
||
1. **Blast Radius trennen** (s.o.) — die wirksamste Maßnahme, weil sie ohne Ursachenkenntnis wirkt.
|
||
2. **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.
|
||
3. **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.
|
||
4. **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.
|
||
5. **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`](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_id`s 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
|
||
|
||
1. Ist **`s4 kueche_mikrowelle`** ein Gen4? Falls ja → bester Pilot, größter Gewinn (−93 dBm heute).
|
||
2. 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.
|
||
3. 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?
|
||
4. ✅ **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`](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](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`)
|