Files

Christoph Emsenhuber 5ee0716dda Initial import from bf-network-r6.opencode — opencode migration

2026-08-26 12:44:21 +02:00

58 KiB

Raw Blame History

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

❌ TP17.1 IST VERWORFEN (User-Entscheid 2026-08-23). Dieses Runbook bleibt als Wissensspeicher stehen — es ist kein Arbeitsauftrag mehr.

Warum: der Pilot hat den Zigbee-Weg technisch vollständig bewiesen (s. Schritt 1 unten), aber gezeigt, dass das Ziel so nicht erreichbar ist — das Gerät bleibt WLAN-Client, der gemessene Funkgewinn ist klein, und WLAN abzuschalten wäre unumkehrbar (kein AP auf der Zigbee-Firmware, kein Zigbee-OTA, InstallAlt braucht IP). Der Weg ist nicht gescheitert, das Ziel war mit ihm nicht erreichbar.

✅ Rückbau am 2026-08-23 durchgeführt: ZHA-Knoten entfernt (Leave vor dem Flash), s9 zurück auf PowerStrip, Config aus dem Backup. ⚠️ Der Rückflash zog einen OFFENEN AP hoch (ap.enable=true, is_open=true) — abgeschaltet und mit dem IoT-PSK abgesichert. Merkregel: nach jedem Shelly-Firmwarewechsel den AP prüfen.

🔭 Weiter gültig ist der Frühindikator: Shelly.CheckForUpdate auf einem Gen4 auf einen …MT/Thread-alt-Eintrag beobachten. Erscheint er, ist die Rechnung neu zu machen.

📌 Was hier bleibt und Wert hat: der kartierte Firmware-Mechanismus (drei undokumentierte RPCs, Zwei-Slot-Modell), das gemessene 2,4-GHz-Bild aller vier Funknetze, die ZHA-Sturmzähler mit Baseline und Abbruchkriterium — und die Erkenntnis, dass ein ZHA-Join dieses Netz nicht destabilisiert (alle vier roten EZSP-Zähler blieben 0).

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

🔴 KORRIGIERT 2026-08-23 (Folge-Session, an allen 12 Gen4 live nachgezählt): die frühere Aussage „die zwei S4PL-00416EU (s9, s13) deckt keiner der Wege ab" ist falsch. Beide bekommen PowerStripZB angeboten, mit stable-Build 2.0.0 — nicht nur Beta. Weg (A) deckt 12 von 12 Gen4-Geräten ab, nicht 10.

Gerät	Modell	Bezeichnung	ALT-Variante	stable	beta
s9	S4PL-00416EU	wohnzimmer_sideboard	`PowerStripZB`	2.0.0	2.0.1-beta1
s13	S4PL-00416EU	arbeitszimmer_technik	`PowerStripZB`	2.0.0	2.0.1-beta1
s22	S4SW-001P16EU	kueche_steckdose3-2	`S1PMG4ZB`	2.0.0	2.0.1-beta1
s12	S4SW-002P16EU	dieleug_steckdosen	`S2PMG4ZB`	2.0.0	2.0.1-beta1
s16	S4SW-002P16EU	wohnzimmer_steckdosen	`S2PMG4ZB`	2.0.0	2.0.1-beta1
s17	S4SW-002P16EU	bad_steckdosen	`S2PMG4ZB`	2.0.0	2.0.1-beta1
s18	S4SW-002P16EU	kueche_steckdosen1	`S2PMG4ZB`	2.0.0	2.0.1-beta1
s19	S4SW-002P16EU	kueche_steckdosen3	`S2PMG4ZB`	2.0.0	2.0.1-beta1
s20	S4SW-002P16EU	kueche_steckdosen2	`S2PMG4ZB`	2.0.0	2.0.1-beta1
s21	S4SW-002P16EU	kueche_steckdosen4	`S2PMG4ZB`	2.0.0	2.0.1-beta1
s25	S4SW-002P16EU	bad_lichtschalter	`S2PMG4ZB`	2.0.0	2.0.1-beta1
s26	S4SW-002P16EU	bad_luefter	`S2PMG4ZB`	2.0.0	2.0.1-beta1

Kein Gerät bietet eine Thread-/Matter-Variante an — der Frühindikator oben (…MT-Eintrag in alt) ist damit weiterhin negativ. Weg (B) hat sich seit der Ersterhebung nicht bewegt.

🔎 Zur Rückrollbarkeit (Blocker (a)): OTA.Revert ist auf allen 12 Geräten als RPC-Methode vorhanden, und Shelly liefert beide Funkvarianten über denselben Update-Kanal mit stable-Builds — die Struktur ist symmetrisch angelegt, das Zigbee-Gerät sollte die WiFi-Variante seinerseits als alt führen. ⚠️ Bewiesen ist der Rundweg damit nicht. Er lässt sich nur am Pilotgerät beweisen, und genau das ist die Aufgabe von Schritt 1: erst zurückflashen, dann weitermachen.

💡 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) — die einzige Nachbarschaft im Haus, und sie trifft das Netz mit 52 Geräten gegen den AP mit 26 Clients. ⚠️ Aber: gemessen beißt sie nicht. PHY_CCA_FAIL_COUNT des Koordinators steht bei 4 über die gesamte Zählperiode → keine nennenswerte Kanalbelegung. Kein Handlungsbedarf, Begründung im Kapitel „Kanalwahl für ZHA" unten. (Meine erste Einschätzung „🔴 der eine Konflikt" war aus der Frequenztabelle abgeleitet, nicht gemessen.)
💡 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. ✅ Welches, ist seit dem Inventar vom 2026-08-23 entschieden: ZHA. Begründung im Kapitel „Welche Geräte sind für fehlerhaftes Routing anfällig?" unten — kurz: ZHA hat schon 24 Router (einer mehr fällt kaum ins Gewicht), Z2M hätte mit zehn Shellys mehr als doppelt so viele wie heute, und in Z2M hängt die Wandbeleuchtung an ZLL-Altgeräten — dort ist eine Routing-Störung die Lichterdisko.

⚠️ 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.

🌩️ Broadcast-/Routing-Sturm erkennen — Zähler, Baseline, Abbruchkriterium

Der Vorfall von 2024 war unsichtbar, weil niemand hingesehen hat, bevor es zu spät war. Das ist lösbar: der EZSP-Koordinator führt Zähler mit, die einen Sturm beschreiben, bevor er als „Lichterdisko" auffällt. Hier die Baseline vom 2026-08-23 (ZHA, read-only aus den Diagnostics) — gegen die wird nach jedem Join verglichen.

Die Zähler, auf die es ankommt

Zähler	Baseline (kumuliert)	Bedeutung, wenn er steigt
🔴 `BROADCAST_TABLE_FULL`	0	Der eine Zähler, der einen Sturm beweist. Broadcasts kommen schneller, als der Stack sie nachhalten kann. Alles > 0 ist ein Alarm.
🔴 `ALLOCATE_PACKET_BUFFER_FAILURE`	0	Koordinator hat keine Puffer mehr → genau der Zustand „nichts mehr steuerbar".
🔴 `PHY_TO_MAC_QUEUE_LIMIT_REACHED`	0	Das Radio kommt mit dem Senden nicht nach.
🔴 `TYPE_NWK_RETRY_OVERFLOW`	0	Netzwerk-Retries laufen über.
🟠 `ROUTE_DISCOVERY_INITIATED`	65	Routen-Thrash. Ein paar pro Tag sind normal, ein Sprung um Dutzende in Minuten nicht.
🟠 `NEIGHBOR_STALE` / `NEIGHBOR_REMOVED`	372 / 0	Topologie-Unruhe. `REMOVED > 0` heißt: Router verschwinden aus der Nachbarschaftstabelle.
🟠 `MAC_TX_UNICAST_RETRY` / `…_FAILED`	1.086 / 341	Retry-Quote ≈ 15 %, Fehlerquote ≈ 5 % bei 6.222 Erfolgen. Das ist die Normallage dieses Netzes — Verdopplung = Warnsignal.
🟠 `PHY_CCA_FAIL_COUNT`	4	Kanal war belegt, als gesendet werden sollte = Funkstörung (WLAN oder Zigbee).
🟠 `NWK_FRAME_COUNTER_FAILURE`	25	Replay/Rejoin-Schleifen — ein Gerät, das immer wieder neu beitritt.
ℹ️ `MAC_RX_BROADCAST` vs `MAC_RX_UNICAST`	124.282 vs 18.620	Verhältnis 6,7 : 1. Das ist die Normallage (Link-Status alle 15 s je Router). Das Verhältnis ist die Kennzahl, nicht der Absolutwert — wandert es Richtung 20:1, läuft ein Sturm an.

📌 Ablesen: ZHA-Config-Entry → Diagnostics → data.application_state.counters.ezsp_counters. _last_reset_value = Langzeitsumme, _raw_value = seit dem letzten Reset. Für Z2M (hier 2.6.2) ist das Gegenstück zigbee2mqtt/bridge/health — es liefert je Gerät leave_count, network_address_changes und Fehlerzähler; network_address_changes > 0 ist dort das Äquivalent zu „Topologie unruhig".

Was man als Mensch sieht, bevor die Zähler gelesen werden

Kommandos brauchen Sekunden statt sofort — oder kommen doppelt an (Licht geht an und gleich wieder aus).
Geräte fallen in Wellen auf unavailable, nicht einzeln.
Lichter schalten von selbst — ein Broadcast, der im Netz kreist und mehrfach zugestellt wird. Das ist die „Lichterdisko".
Im HA-Log häufen sich Failed to send request … device did not respond.

🔑 Merkregel: der Unterschied zwischen „ein Gerät zickt" und „das Netz kippt" ist die Gleichzeitigkeit. Ein einzelnes stummes Gerät ist ein Gerät. Drei Geräte gleichzeitig, die vorher liefen, sind das Netz.

Abbruchkriterium für den Test — vorher festlegen, nicht im Moment entscheiden

Rückbau des Testgeräts, sobald EINES davon eintritt:

BROADCAST_TABLE_FULL, ALLOCATE_PACKET_BUFFER_FAILURE, PHY_TO_MAC_QUEUE_LIMIT_REACHED oder TYPE_NWK_RETRY_OVERFLOW verlässt die Null.
Retry-Quote verdoppelt sich gegenüber der Baseline (≈15 % → >30 %).
Ein Referenzgerät, das vorher prompt reagierte, braucht wiederholt >2 s.
Zwei oder mehr Geräte gehen gleichzeitig auf unavailable.

Nicht „das pendelt sich schon ein" — genau diese Hoffnung hat 2024 den Neuaufbau gekostet.

🧭 Welche Geräte sind für fehlerhaftes Routing anfällig? (Inventar 2026-08-23)

Beide Netze vollständig durchgesehen. Die Risiken sind konkret benennbar — und sie sind in beiden Netzen vorhanden, nur unterschiedlich.

ZHA — 52 Geräte, davon 24 Router

Klasse	Geräte	Einschätzung
Philips/Signify Hue	14 Router (LCT012 ×3, LST002 ×2, LCL006 ×2, 5060931P7 ×4, 4090331P9 ×2, 915005997801)	Als Router gutmütig und stabil. Aber: siehe Aqara-Zeile.
IKEA	Signal Repeater ×2, STARKVIND, VINDSTYRKA, Driver 30W ×2, Floor lamp	unauffällig; die Repeater sind explizit als Router gedacht
🟠 GLEDOPTO	GL-SD-001, GL-C-006, GL-C-008 (3 Router)	Dokumentierte Schwäche als Router (ältere Firmware-Stände, Kind-Tabellen). Im Auge behalten.
🟠 Sunricher	HK-LN-DIM-A	meist unauffällig
🔴 LUMI / Aqara	`lumi.weather` ×3 (End Devices)	Der klassische Instabilitätsherd. Aqara-End-Devices halten sich nicht an die übliche Rejoin-Mechanik und fallen weg, wenn sie an einem Nicht-Aqara-Router hängen — Hue-Router sind der meistdokumentierte Fall, und davon stehen hier 14.

⇒ 🐤 Die drei lumi.weather sind der Kanarienvogel. Sie reagieren als Erste, wenn sich die Topologie ändert. Vor und nach dem Shelly-Join gezielt auf ihr last_seen schauen — nicht auf den Durchschnitt des Netzes.

Z2M — 15 Geräte, davon 7 Router

Klasse	Geräte	Einschätzung
🔴 Busch-Jaeger ZLL	6× „Zigbee Light Link power supply/relay/dimmer/wall-switch", sw 1.2.0	Zigbee-Light-Link-Altbestand. ZLL-Stacks sind älter als Zigbee 3.0, mit knappen Routing-/Kind-Tabellen — und das ist die Wandbeleuchtung (Küche, Wohnzimmer ×2, Kinderzimmer, Klo, Schlafzimmer). ⇒ Genau die Geräte, aus denen eine „Lichterdisko" besteht.
🔴 Tuya-Familie	Tongou Smart circuit breaker (Router) · Mini human breathe sensor · 24G mmWave · Soil sensor · `_TZE284_7zazvlyn` „Automatically generated definition"	Tuya ist die unberechenbarste Klasse; das letzte Gerät ist nicht einmal sauber unterstützt (Auto-Definition) — sein Verhalten ist unbekannt.
🟠 Aqara	Presence sensor FP300	dieselbe Familie wie oben, End Device
ℹ️ COOLO / IKEA	Soil moisture, TRADFRI on/off	unauffällig

🎯 Damit ist die Netzwahl für den Test entschieden — und zwar gegen die Intuition:

Das Testgerät gehört in ZHA, nicht in Z2M. Drei Gründe:

Proportion. ZHA hat 24 Router — einer mehr ändert die Topologie kaum. Z2M hat 7; zehn Shellys würden den Router-Bestand dort mehr als verdoppeln. Genau solche abrupten Topologiewechsel erzeugen die Route-Thrash-Phase, die man fürchtet.

Blast Radius. In Z2M hängt die Wandbeleuchtung an ZLL-Altgeräten. Ein Routing-Problem dort ist die Lichterdisko. In ZHA hängen Lampen, die sich zur Not einzeln schalten lassen.

Messbarkeit. Für ZHA gibt es die Zählertabelle oben mit einer echten Baseline. Für Z2M gibt es bridge/health, aber keine vergleichbar feinen Funkzähler.

⚠️ Der Preis dieser Wahl: die drei Aqara-lumi.weather sitzen in ZHA und könnten sich auf den neuen, unerprobten Shelly-Router umhängen. Das ist beherrschbar (beobachten, notfalls den Shelly wieder entfernen) — und es ist der Grund, warum der Test ein Gerät umfasst und nicht drei.

📡 Kanalwahl für ZHA — gemessen, nicht geschätzt

🔄 Korrektur meines eigenen Befundes von vorhin. Ich hatte ZHA ch20 als „🔴 der eine Konflikt im Haus" markiert, weil 2450 MHz auf der Unterkante von WLAN ch11 (2451) liegt. Die Zähler des Koordinators widersprechen dem: PHY_CCA_FAIL_COUNT steht bei 4 über die gesamte Zählperiode (gegen 6.222 erfolgreiche Sendungen). Wäre die WLAN-Nachbarschaft ein echtes Problem, stünde dort eine drei- bis vierstellige Zahl. Die Adjazenz existiert auf dem Papier und beißt nicht.

Empfehlung: ZHA bleibt vorerst auf Kanal 20.

Ein Kanalwechsel müssten 52 Geräte mitmachen. Schlafende und ältere Router folgen dem nwk_update_id-Broadcast nicht zuverlässig und bleiben auf dem alten Kanal zurück — sie sind dann verwaist und müssen einzeln neu angelernt werden. Das ist exakt die Fehlerklasse von 2024, ausgelöst durch die Maßnahme, die sie verhindern sollte.
Der Nutzen ist nach der CCA-Messung nicht belegt. Ein Risiko ohne belegten Nutzen ist kein Trade.

Falls doch einmal gewechselt wird — dann auf 18:

Kandidat	Mitte	Abstand zu Thread (2425)	Abstand zu WLAN ch11 (2451)	Urteil
16	2430	3 MHz	19 MHz	zu nah an Thread
17	2435	8 MHz	14 MHz	brauchbar
18	2440	13 MHz	9 MHz	✅ am besten zentriert in der Lücke 2426–2451
19	2445	18 MHz	4 MHz	zu nah am WLAN

✅ Vorbedingung erfüllt: die Nachbar-WLANs sind am 2026-08-23 gemessen (Kapitel unten). Ergebnis: das Fenster 2426–2448 ist nur schwach belegt (alles ≤ −81 dBm) — ZB18 ist valide. Der Handlungsdruck fehlt trotzdem (CCA = 4). 🔴 Neue Randbedingung: funken die zwei neuen APs ebenfalls auf 2,4 GHz, ist ch6 belegt und ZB18 fällt aus — dann sind 20 und 25 die einzig richtigen Plätze. Details und die Empfehlung dazu im Scan-Kapitel.

📡 WLAN-Umfeldscan 2,4 GHz — durchgeführt 2026-08-23 (beide APs)

🔴 Gotcha zuerst, er kostet sonst eine halbe Stunde: /interface wifi scan geht am CAP NICHT. Auf ap1 direkt (SSH, User in Gruppe full) antwortet das Gerät failure: not allowed (/interface/wifi/scan). Das ist weder device-mode noch eine Policy-Lücke — der Gegentest beweist es: /tool fetch meldet auf demselben Gerät explizit „not allowed by device-mode", und die Gruppe full hat test und sniff. Ursache ist der CAPsMAN-Zustand: ein CAP besitzt sein Radio nicht. Der Scan läuft am Manager gegen die cap-wifiN-Schnittstelle und funktioniert dort einwandfrei. Reiht sich ein in „unter CAPsMAN führt der Manager die Tabellen". (Zuordnung am Messtag über radio-mac bestimmt, nicht angenommen: ap1 = cap-wifi3 (5 GHz) / cap-wifi4 (2,4 GHz), ap2 = cap-wifi1 / cap-wifi2.)

Fremdnetze — die Nachbarschaft ist leise

WLAN-Kanal	Belegung ca.	Fremd-APs	stärkstes Fremdsignal
1 (2412)	2401–2423	dahoam is dahoam −89, FRITZ!Box 6690 TM −87	−87
3 / 4 (2417/2427)	2406–2438	meins.w −81/−93, Drei_H288A −81	−81
6 (2437)	2426–2448	Liwest_9d44 −90, meins.liwest −88/−90, Liwest3422 −90	−88
8 (2447)	2436–2458	meins.w −92, verstecktes Netz −84	−84
11 (2462)	2451–2473	FRITZ!Box 7490 −81, LiwestBB93 −96, LiwestF0DA −90, LiwestEDBA −92, MIKENET2 −91	−81

⇒ Kein einziges Fremdnetz über −81 dBm. Die 2,4-GHz-Umgebung ist für eine Wohnlage bemerkenswert ruhig — die eigenen APs sind mit Abstand die lautesten Sender im Band.

🔴 Zwei laute Sender sind aber die eigenen — und keiner davon ist ein AP

Sender	Kanal	Signal	Was es ist
`AC:15:18:7B:62:21` SSID `AC15187B6220`	11 (2462)	−51 (von ap1)	Shelly s23 (`dieleug-wohnzimmer_licht`, Pro Dimmer 2PM, `10.40.30.203`) sendet einen eigenen Access Point
`54:F2:9F:12:51:F1` SSID `DTUBI-92337823`	1 (2412)	−59 (von ap2)	Hoymiles-DTU (Solar-Datenlogger, VLAN30) sendet ebenfalls einen eigenen AP

🎯 Der Shelly-Fund ist ein Rückstand aus TP17 und live bestätigt: WiFi.GetConfig liefert ap.enable = true, SSID AC15187B6220, WPA2. Das ist ein übrig gebliebener „Anker" aus dem Migrationsverfahren von 2026-07-13 — dort wurde je Gerät vor dem STA-Write die geräteeigene AP-Funktion als Notanker aktiviert und nach dem Verify wieder abgeschaltet. Bei s23 ist das De-Anchoring nicht angekommen. Das Gerät funkt seither doppelt: als Client auf ch1 (dirtyvader-iot an ap1, RSSI −56) und als AP auf ch11.

~~Fix ist ein Einzeiler~~ ⏸️ Nicht ausgeführt — und das war Glück, s. Korrektur unten.

🔴🔴 KORREKTUR am selben Tag — ich habe diesen Fund falsch eingeordnet. Der AP auf s23 ist kein vergessener Anker, sondern Christophs WORKAROUND: das Gerät (Pro Dimmer 2PM, „Diele UG/Licht") flackert unkontrolliert, seit die Migration daran gearbeitet hat — und mit eingeschaltetem AP ist das Symptom weg. Der Fix, den ich oben als „Einzeiler" beschrieben habe, hätte also eine funktionierende Reparatur zerstört. ap.enable auf s23 bleibt an, bis die Ursache behoben ist. ➡️ Eigenes Teilprojekt dafür: TP17.3 in teilprojekte.md — Leithypothese ist eco_mode (gedrosselter CPU-Takt vs. Nulldurchgangs-Timing eines Phasenanschnitt-Dimmers; ein aktiver AP hebt die Energiesparzustände auf und erklärt damit genau die Beobachtung). 📌 Merkregel, die das kostet: ein Zustand, der nach einem Verfahren „übrig" aussieht, kann eine Reparatur sein. Vor dem Aufräumen fragen, wozu er da ist — nicht, ob er ins Schema passt. ⇒ Der Anker-Sweep bleibt trotzdem sinnvoll und ist am 2026-08-23 gelaufen: s23 ist der einzige Shelly mit aktivem AP, alle anderen 21 sind sauber de-anchored. Die Sorge war unbegründet, der Einzelfall ist erklärt.

☀️ Die DTU: abschalten geht nicht — und das ist jetzt am PROTOKOLL belegt, nicht am Forum (2026-08-23). Es ist kein separater DTU-Kasten, sondern der Wechselrichter mit eingebautem DTU („DTU Built-In"). Hostname DTUBI-414392337823, 10.40.30.8, MAC 54:F2:9F:12:51:F0; der AP läuft auf …:F1 (STA-MAC + 1, übliches ESP-Muster).

🔴 Korrektur eines eigenen Fehlbefunds vom selben Tag: ich hatte „null offene TCP-Ports" gemeldet. Falsch — 10081 ist offen. Ursache war ein kaputter Port-Test: timeout gibt es auf macOS nicht, jeder Aufruf lief auf command not found und wurde als „zu" gewertet. Merkregel: ein Test, der bei jedem Port dasselbe Ergebnis liefert, hat sich selbst widerlegt — ein leeres Ergebnis ist kein Befund, sondern ein Verdacht auf einen kaputten Test. (Gültig bleibt: 80/443/8080/8000 sind zu — dieser Teil lief ohne timeout. Es gibt LAN-seitig also keine Weboberfläche, wohl aber ein vollwertiges Konfigurationsprotokoll.)
🔌 Was auf 10081 läuft: das proprietäre Hoymiles-Protokoll (Protobuf). Das HA-Addon ha-hoymiles-wifi-addon v0.5 (DennisOSRM/hms-mqtt-publisher, Rust) pollt darüber alle 30,5 s und schiebt die Telemetrie in den MQTT-Broker — es ist rein lesend.

🎯 Die Antwort steckt in der Protokolldefinition, nicht im Addon. Die Schwester-Bibliothek suaveolent/hoymiles-wifi legt den vollen Befehlssatz offen: get-real-data, get-config, network-info, app-information-data, get-version-info, get-alarm-list — und schreibend set-power-limit, turn-on/off-inverter, restart-dtu, identify-dtu, firmware-update, set-wifi. In SetConfig.proto stehen die relevanten Felder:

Feld	Nr.	Bedeutung
`dtu_ap_ssid`	48	SSID des geräteeigenen APs
`dtu_ap_pass`	49	Passwort des geräteeigenen APs
`wifi_ssid` / `wifi_password`	15 / 16	das WLAN, in das sich der Wechselrichter einbucht
`netmode_select` · `channel_select` · `dhcp_switch`	8 · 9 · 25	Netzmodus, Kanalwahl, DHCP
🔴 Und entscheidend: es gibt KEIN `ap_enable`. Das Protokoll kennt SSID und Passwort des APs —
aber keinen Schalter, ihn abzuschalten. Damit ist „geht nicht" kein Forumsgerücht mehr, sondern
aus der Schnittstellendefinition ableitbar.

✅ Entwarnung: der AP ist verschlüsselt — der Scan meldet security=wpa2-psk;wpa-psk. Der bekannte Fall „Hoymiles-DTU funkt ein offenes WLAN" trifft hier nicht zu. 💡 Die einzige sinnvolle Härtung, die das Protokoll hergibt: dtu_ap_pass auf ein eigenes Passwort setzen, falls dort noch das Werkspasswort vom Geräteaufkleber steht.
⚠️ Wenn jemand das je anfasst, zwei Fallen: (a) SetConfig überträgt den ganzen Konfigurationssatz — wer ein Feld ändern will, muss vorher get-config lesen und alles andere unverändert zurückschreiben, sonst überschreibt man Felder mit Leerwerten. (b) Ein falsch gesetztes wifi_ssid/wifi_password kappt die STA-Verbindung. Rettung wäre dann ausgerechnet der AP — der nicht abschaltbare AP ist die Rückfallebene. Das ist das beste Argument, ihn zu lassen.
💡 Zu Christophs Entwurfsidee („AP nur, wenn kein Link"): das Muster ist Standard (Captive-Portal-/WiFiManager-Fallback; Tasmota, ESPHome und viele ESP-Firmwares machen es so). Dass Hoymiles es nicht tut, ist eine Herstellerentscheidung, kein technisches Hindernis — und mit dem Protokoll auf 10081 wäre es sogar unproblematisch, weil die Konfiguration auch ohne AP erreichbar bliebe. (Mein früheres Gegenargument „dann käme man gar nicht mehr an die Konfiguration" beruhte auf dem falschen Port-Befund und ist damit hinfällig.)
🎯 ~~Der Hebel, den es praktisch gibt: den AP-Kanal verschieben.~~ 🔴 WIDERLEGT am 2026-08-23 — s. Fehlschlag unten. Ein ESP hat ein Radio — AP und STA laufen zwangsläufig auf demselben Kanal. Der DTU-AP sitzt auf ch1, weil seine STA-Verbindung an einem AP auf ch1 hängt. Bindet man den Wechselrichter per access-list an ap2 (ch11), wandert sein AP mit. Werkzeug wie in TP25 (tp25-pin-s22.sh); seit 2026-08-23 steht wifi-access-list unter einer ComplianceRule, ist also transaktionsfähig. 📌 Dieselbe Regel erklärt den Shelly s23: wer den Störer verschieben will, verschiebt den Client, nicht den AP.
🔴 Nicht auf Verdacht am Gerät herumprobieren: die PV-Datenstrecke ist produktiv.

🔴 Versuch „DTU an ap2 binden" — FEHLGESCHLAGEN und zurückgerollt (2026-08-23)

Auftrag: den nicht abschaltbaren DTU-AP von ch1 wegbekommen, indem man den Client an ap2 (ch11) bindet — die Idee „verschieben statt abschalten" aus dem Absatz oben.

Ablauf: Transaktion TP17.1-dtu-pin-ap2 (Scope wifi-access-list) eröffnet, fünf action=reject-Regeln für 54:F2:9F:12:51:F0 auf ap1s 2,4-GHz-Interfaces per ConfigPlan deployt. Der DTU flog um 14:38:48 von cap-wifi4-virtual1 (disconnected, access-list changed, signal strength -51) — und kam nie bei ap2 an. Nach 2,5 Minuten zurückgerollt; auch danach blieb er weg.

🎯 Die Ursache ist Christophs Verdacht, und sie ist am Protokoll belegbar: der DTU hat eine feste Kanalwahl. SetConfig.proto kennt channel_select (Feld 9) und netmode_select (8). Zwei Beobachtungen bestätigen es:

Sein eigener AP sendet auf ch1 — und ein ESP hat ein Radio, AP und STA teilen zwingend den Kanal. Der AP auf 2412 heißt: das Radio steht auf Kanal 1.
Christophs Wiederverbinden über die S-Miles-App scheiterte mit „Verbindung fehlgeschlagen" — das Symptom, das er von Frequenz-Fehlanpassungen kennt.

⇒ ap2 läuft auf ch11. Der DTU kann dort gar nicht assoziieren. Die Sperre auf ap1 hat ihn deshalb nicht umgeleitet, sondern schlicht ausgesperrt.

🔴 Damit ist die Empfehlung „AP-Kanal verschieben, indem man den Client bindet" für dieses Gerät WIDERLEGT. Sie gilt weiter für Geräte, die frei scannen (z.B. die Shellys) — nicht für ein Gerät mit fixierter Kanalwahl. Wer den DTU-AP wirklich von ch1 wegbekommen will, hat nur zwei Wege: (a) channel_select per SetConfig über Port 10081 ändern — ein Schreibvorgang am produktiven Wechselrichter, mit der bekannten Falle, dass SetConfig den ganzen Satz überträgt; oder (b) ap1 selbst auf einen anderen Kanal legen — dann folgt der DTU-AP dorthin, wo ap1 ist. (b) ist der ungefährlichere Weg und wird mit dem Kanalplan für die zwei neuen APs ohnehin neu gestellt.

📌 Zwei Merkregeln, die das gekostet hat:

Ein reject auf AP A ist keine Umleitung auf AP B. Es ist ein Rausschmiss — ob das Gerät woanders unterkommt, ist seine Entscheidung, nicht unsere. Bei Geräten mit fixem Kanal, fixem BSSID oder trägem Rescan ist die Antwort: nirgends. Das ist dieselbe Klasse wie die TP25-Falle „ein abgewiesener Verbindungsversuch ist von einem Funkloch nicht zu unterscheiden".
Vor einem Pin prüfen, ob das Ziel überhaupt erreichbar ist — also ob der Client den Kanal des Ziel-APs benutzen kann. Der Beleg lag die ganze Zeit vor: der DTU-AP sendete auf 2412, ap2 läuft auf 2462. Das war vor dem Eingriff sichtbar und hätte ihn verhindert. ⚠️ Und die Abnahme war zu lasch: „ap2 hört den DTU mit −59 dBm" belegt nur, dass ein Pfad existiert — nicht, dass der Client diesen Kanal benutzen darf. Signalstärke ist kein Nachweis für Assoziationsfähigkeit.

🔴🔴 Nachtrag, und er verschärft die Merkregel: das Gerät hat sich NICHT selbst erholt. Auch nachdem die Sperre entfernt war und ap1 wieder frei auf ch1 sendete, blieb der DTU weg. Zurück kam er erst, als Christoph ihm über die S-Miles-App die WLAN-Zugangsdaten erneut übergab — „als wäre es ein neues WLAN". Danach war er binnen Sekunden wieder auf cap-wifi4-virtual1 (ap1, dirtyvader-iot, −51 dBm). ⇒ Ein einmal abgewiesener DTU gibt seine gespeicherte Verbindung dauerhaft auf. Ein reject gegen dieses Gerät ist damit kein Experiment, sondern ein Ausfall mit Handarbeit als einzigem Rückweg — und zwar Handarbeit, die nur jemand vor Ort mit der Hersteller-App leisten kann, nicht per Fernzugriff. Für den produktiven PV-Datenpfad heißt das: die access-list ist für dieses Gerät gesperrtes Gebiet. 📌 Nebenbefund: dass die Re-Provisionierung auf ap1 (ch1) sofort funktionierte, während der Wechsel zu ap2 (ch11) scheiterte, stützt die Kanal-These zusätzlich — widerlegt sie jedenfalls nicht.

🔬 Auflösung: `get-config` gelesen — es gibt KEINE feste Kanalwahl (2026-08-23)

Read-only über Port 10081 abgefragt (hoymiles-wifi 0.5.6 in einem isolierten venv, nur get-config; Passwortfelder in der Ausgabe redigiert). Die 62 Felder der Antwort sagen:

Feld	Wert	Bedeutung
`channel_select`	`0`	🎯 kein fixer Kanal — 0 = automatisch
`netmode_select`	`1`	Netzmodus WLAN
`wifi_ssid`	`dirtyvader-iot`	✔ erwartet
`dtu_ap_ssid`	`DTUBI-92337823`	✔ der störende AP
`dtu_ap_pass` / `lock_password`	gesetzt, aber nur 1 Zeichen zurückgeliefert	⚠️ mit hoher Wahrscheinlichkeit ein maskierter Platzhalter, kein echtes Ein-Zeichen-Passwort — daraus KEINE Schwäche ableiten
`server_domain_name` · `serverport`	`dataeu.hoymiles.com` · `10081`	spricht weiterhin mit der Hoymiles-Cloud
`wifi_ip_addr`	`10.40.30.8`	✔

🔴 Damit ist Christophs These „die Kanalwahl ist fix eingebrannt" widerlegt — und zwar an der Quelle, nicht durch Indizien. Seine Beobachtung war trotzdem richtig, nur die Ursache eine andere.

✅ Die tragfähige Erklärung ist stattdessen: das Gerät sucht nicht. Es hält an dem AP fest, mit dem es provisioniert wurde, und wenn der es abweist, gibt es auf statt sich einen anderen zu suchen — exakt das beobachtete Verhalten (kam auch nach entfernter Sperre nicht zurück, brauchte eine Re-Provisionierung). Das ist typisch für einfache ESP-Firmware ohne Roaming-Logik. Nicht der Kanal ist starr, sondern die AP-Bindung.

🎯 Und das macht eine Option wieder lebendig, die ich vorschnell mitbeerdigt hatte: ap1s eigenen Kanal umzulegen wirkt. Ohne channel_select folgt der DTU dem AP, an dem er hängt — wandert ap1 auf einen anderen Kanal, wandert der DTU-AP mit, ohne dass das Gerät je abgewiesen wird oder neu provisioniert werden muss. Das ist der einzige risikoarme Weg, den Störer von ch1 wegzubekommen — und er fällt beim Kanalplan für die zwei neuen APs ohnehin an. ⚠️ Weiterhin gesperrt bleibt die access-list: nicht wegen des Kanals, sondern wegen der Aufgeben-Eigenschaft. Ein reject gegen dieses Gerät kostet einen Vor-Ort-Einsatz.

Was das für die Zigbee-Kanalfrage heißt

Das Fenster 2426–2448 (WLAN ch4–8), in dem ZB 16/17/18 liegen, ist belegt, aber nur schwach — alles dort ≤ −81 dBm. ZB18 (2440) bleibt damit eine valide Option, die Messung widerlegt sie nicht.
Handlungsdruck entsteht dadurch trotzdem nicht. PHY_CCA_FAIL_COUNT = 4 gilt weiter; das ist die Aussage über den Ort, der zählt (der Koordinator), während der Scan die Orte der APs beschreibt. ZHA bleibt auf 20.

📻 Nachtrag: Homematic / HmIP — 868 MHz, damit außerhalb dieser Rechnung

Christophs Ergänzung 2026-08-23. Live nachgesehen: Integration homematicip_local an der CCU ccu.emsenhuber.net (RaspberryMatic, Technik UG, 10.40.20.232) mit 37 Geräten im Mischbetrieb — Homematic classic (BidCoS-RF, z.B. HM-LC-Sw1-FM „WC Lüfter", zentrale HM-RCV-50) und HmIP (u.a. HmIP-HEATING je Raum = die Heizungssteuerung).

✅ Für die Kanalplanung ist das eine Entlastung: beide Funkstandards liegen im 868-MHz-Band (SRD860), nicht bei 2,4 GHz. Homematic stört Zigbee, Thread und WLAN nicht — und wird von ihnen nicht gestört. Es ändert an der Tabelle oben nichts.

⚠️ Aber es ist ein fünftes Funkökosystem im Haus (WLAN 2,4 · WLAN 5 · Zigbee ×2 · Thread · Homematic) — und es hat seinen eigenen Ausfallmodus, der dem Broadcast-Sturm entspricht: das 868-MHz-Band ist gesetzlich auf 1 % Duty Cycle begrenzt. Wird das überschritten, stellt die Zentrale das Senden minutenlang ein — Symptom: „Befehle kommen nicht an, aber alles ist online". 🔎 Merkregel: bei Homematic-Aussetzern zuerst den Duty Cycle der CCU ansehen, nicht die Funkabdeckung. Ausgelöst wird er typischerweise durch zu häufige Sollwert-Schreibvorgänge — also durch Automationen, nicht durch Geräte.

📌 Bezug zu TP29 (Anwesenheitserkennung fürs Energiesparen): die HmIP-HEATING-Geräte sind der Aktor, den TP29 ansteuern würde. Wer dort präsenzabhängig regelt, schreibt Sollwerte — und läuft damit genau in die Duty-Cycle-Grenze. Das gehört in TP29s Entwurf, bevor die erste Automation scharf geht.

🆕 Und was die zwei neuen APs damit zu tun haben

Sehr viel — das ist der Punkt, an dem die AP-Frage und die Zigbee-Frage dieselbe Frage werden.

2,4 GHz hat drei überlappungsfreie Kanäle: 1, 6, 11. Heute belegt das Haus zwei davon (ap1 = 1, ap2 = 11) und lässt ch6 frei — genau das Fenster, in dem ZB 16/17/18 liegen.

🔴 Kommen zwei APs dazu und funken alle vier auf 2,4 GHz, ist ch6 belegt. Damit fällt ein ZHA-Umzug auf 18 aus, und ZB20 (zwischen 6 und 11) sowie ZB25 (über 11) sind dann die einzigen richtigen Plätze — also exakt die heutige Belegung. Die aktuelle Konfiguration wäre dann nicht nur vertretbar, sondern die einzig sinnvolle.

💡 Empfehlung für den AP-Aufbau, die beides löst: 2,4 GHz nicht auf allen vier APs betreiben. Vier 2,4-GHz-Zellen auf drei Kanälen stören sich zwangsläufig selbst, und die Reichweite von 2,4 GHz ist so groß, dass zwei Zellen die Wohnung ohnehin abdecken — die IoT-Geräte hängen heute an zwei APs und kommen zurecht. Die beiden neuen APs also als 5-GHz-Schwerpunkt betreiben (2,4 GHz aus oder stark reduziert). Das

hält ch6 frei und damit die Zigbee-Option offen,
vermeidet Selbststörung im vollsten Band,
und legt die neue Kapazität dorthin, wo sie tatsächlich fehlt: 5 GHz an den Rändern (TP25: die Redundanz ist der Schwachpunkt, nicht die Abdeckung).

5 GHz — gemessen 2026-08-23, das Band ist praktisch leer

Kanal	Fremdnetz	Signal
5180 (ch36)	dahoam is dahoam-5G	−89
5200 (ch40)	LiwestBB93-5G	−88
5500 (ch100, DFS)	meins.liwest	−83

⇒ Drei Fremdnetze, alle ≤ −83 dBm. 5 GHz ist hier faktisch unbelegt — die neue Kapazität hat also Platz, und der Vorschlag „neue APs als 5-GHz-Schwerpunkt" ist damit auch messtechnisch gedeckt.

🔴 Aber die Kanäle werden knapp, und das ist die Planungsaussage: unter ETSI gibt es im Indoor-Band 5180–5240 bei 40 MHz genau zwei überlappungsfreie Blöcke — `5180/Ce` (ap1) und `5220/Ce` (ap2). Beide sind vergeben. Ein dritter und vierter AP muss auf 5 GHz also ins DFS-Band (5500–5700) ausweichen — dort liegen laut TP25-Analyse 11 zusätzliche Kanäle, in ETSI ohne `/I`-Leistungsbeschränkung. ✅ Und DFS ist in dieser Lage nachweislich nutzbar: der Nachbar `meins.liwest` funkt auf 5500. ⚠️ Preis bleibt die CAC-Wartezeit beim Start und ein erzwungener Kanalwechsel im Radar-Fall (30 min Sperre). Der TP25-Vorbehalt dagegen („bei Abbruch-Symptomatik unangenehm") ist seit dem Terrassen-Fix vom 08-22 schwächer geworden — die Abwägung gehört neu geführt, wenn die zwei APs bleiben.

🔌 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. ▶️ DURCHGEFÜHRT 2026-08-23 (Folge-Session) — Flash-Teil ✅

🔀 Christophs Gerätewahl weicht bewusst vom Vorschlag ab: s9 wohnzimmer_sideboard statt s26/s12. Begründung: „auf diese steckerleiste habe ich zugriff. die meisten sind aber unterputz." Das ist das bessere Kriterium — von den 12 Gen4 sind nur s9 und s13 Steckerleisten, die anderen zehn sind Unterputz-Module. s13 scheidet aus, dort hängt das NAS (28 W, live) und der Drucker. Auf s9 hängen Apple TV / VU+ / Sonos Arc+Amp / TV — beim Flash alle vier aus, also kein Ausfall. (Der Preis: s9 hat Verbrauchsmessung — 2,2 / 0,4 / 16,4 / 14,4 kWh — das Energie-Dashboard braucht später einen Fix-Lauf. Die Zugänglichkeit wog schwerer.)

🎯 Der Mechanismus, live kartiert — drei UNDOKUMENTIERTE RPCs

Die offizielle API-Doku kennt für alt-Varianten keinen Parameter, und die Support-Seite beschreibt einen Modus-Umschalter („Settings → Switch to Matter/Zigbee", zurück per 5 s Knopfdruck). Für unsere Modelle stimmt das nicht — auf der WiFi-Firmware gibt es keinen Zigbee.*-Namespace (404 No handler). Es ist ein Firmware-Wechsel im Zwei-Slot-Modell. Aus dem JS der Geräte-UI extrahiert:

RPC	Wirkung
`Shelly.InstallAlt {app, stage}`	lädt die Alternativ-Firmware in den inaktiven Slot und rebootet hinein
`Shelly.SetAlternative {name}`	schaltet den Slot um — ⚠️ auf unseren Geräten nicht vorhanden
`Shelly.ListAlternatives`	404 auf beiden Builds — hier nutzlos

Was der Flash gekostet und was er erhalten hat

Warntext der Geräte-UI, wörtlich: „Switching to Zigbee resets all settings (except Wi-Fi). AP will be disabled — access only via previously configured IP." Live bestätigt:


✅ Überlebt	WLAN exakt: `dirtyvader-iot`, statisch `10.40.30.216` — das Gerät bleibt über IP erreichbar · `eco_mode`
❌ Weg	`Matter.` komplett · der AP · alle Ausgangsnamen* (`apple tv`/`vuplus`/`sonos arc + amp`/`tv` → `None`) · `initial_state` `restore_last` → `off` · `input:*`
🆕 Neu	`Zigbee.*`: `StartNetworkSteering`, `GetStatus`, `Get/SetConfig`, `ReadAttr`, `WriteAttr`, `SendCommand`; `zigbee.enable=true`

📦 Vollbackup vor dem Flash liegt im Scratchpad (s9-backup-*.json: Config, Status, Components, Schedule, Webhook, KVS) — daraus werden Namen und initial_state wiederhergestellt.

✅ Blocker (a) „Rückrollbarkeit" ist geschlossen

Die Zigbee-Firmware bietet ihrerseits alt: {"PowerStrip": …"with Matter", stable 2.0.0} an. Der Rückweg ist `Shelly.InstallAlt {app:"PowerStrip", stage:"stable"} über das Netz — kein 5-Sekunden-Knopf, kein Öffnen von Unterputz-Dosen. (Eine frühere Einschätzung in dieser Session, der Rückweg sei physisch und die zehn Unterputz-Module damit faktisch Einbahnstraßen, war falsch — sie stammte aus der Support-Seite, nicht vom Gerät.) ⚠️ Bewiesen ist bisher das Angebot, nicht der vollzogene Rundweg.

🟠 Eine Beobachtung, die für die Serie zählt

Der erste InstallAlt brach reproduzierbar bei 2 % ab (result: null, kein Fehler, kein Reboot). Nach eco_mode=false auf s9 lief derselbe Aufruf glatt bis 100 % durch (3,92 MB, Update succeeded (OK)). n = 1, keine bewiesene Kausalität — aber eco_mode senkt die Sendeleistung, und das Gerät war während des ersten Versuchs wiederholt nicht erreichbar. ⇒ Empfehlung für die restlichen elf: eco_mode=false VOR dem Flash (fällt ohnehin unter den Flotten-Entscheid aus TP17.3) — es kostet nichts und beseitigt eine plausible Fehlerquelle.

✅ ZHA-Join DURCH (2026-08-23) — mit Vorher/Nachher-Messung

Reihenfolge eingehalten: ZHA-Backup zuerst (ha_manage_radio zigbee network_backup, is_complete: true, Kanal 20, PAN 5B5A, Koordinator SONOFF Dongle-M, EZSP 13 / bellows 1.0.0). ⚠️ Das Backup enthält den Netzwerkschlüssel im Klartext — es liegt in HA, keine lokale Kopie. Dann permit_join 240 s + Zigbee.StartNetworkSteering am Gerät → network_state: joined nach 10 s.

Abnahme nach Runbook-Kriterium erfüllt — frischer Knoten UND funktionierende Entity: ZHA hat vier Entities angelegt (switch.shelly_power_strip_schalter, …_2, …_3, …_4). Gegenprobe quer über beide Wege: switch.turn_on über ZHA gesendet, das Ergebnis über die WLAN-RPC des Shelly gelesen → switch:0 output=True, 2.1 W. Der Zigbee-Befehl hat das physische Relais geschaltet. (Zuordnung damit belegt: Entity 1 → switch:0 = „apple tv". Danach wieder aus — Ausgangszustand hergestellt.)

Zählervergleich vor/nach dem Join (kumuliert). Alle vier roten Zähler unverändert 0: BROADCAST_TABLE_FULL, ALLOCATE_PACKET_BUFFER_FAILURE, PHY_TO_MAC_QUEUE_LIMIT_REACHED, TYPE_NWK_RETRY_OVERFLOW. NEIGHBOR_ADDED +1 (genau der neue Router), NEIGHBOR_REMOVED weiterhin 0 — nichts wurde verdrängt. 🔑 Broadcast : Unicast im Delta = 1,8 : 1, also weit unter der Normallage von 6,7 : 1 — der Join war unicast-lastig (Interview), das Gegenteil einer Sturmsignatur. 🟠 Zwei Werte sind erhöht und gehören nach dem Einschwingen erneut gelesen, bevor Gerät zwei drankommt: Retry-Quote im Delta 44 % (Normallage ~15 %) und PHY_CCA_FAIL_COUNT 7 → 19. Beides ist für einen Join mit vollem Interview erwartbar — aber es ist genau die Kennzahl, deren Verdopplung das Runbook als Warnsignal führt. Nicht ungeprüft weitermachen.

⏳ Offen am Pilotgerät — Schritt 2 (HA-Seite bilanzieren)

Der Pilot ist noch nicht fertig: „erst wenn der Pilot in HA vollständig verdrahtet ist, war er erfolgreich."

Die alten Shelly-Entities leben alle noch (67 Treffer auf s9) — die Shelly-Integration erreicht das Gerät weiter über WLAN und liefert RSSI/Uptime/Cloud, nur die switch.* sind weg. ⇒ Erst das alte Gerät aus der Shelly-Integration entfernen, sonst hängt HA beim Umbenennen ein _2 an (Falle aus dem Entity-Bruch-Kapitel oben).
Ziel-entity_ids (aus den erhaltenen Sensor-Namen ableitbar): switch.shelly_s9_0_wohnzimmer_apple_tv · …_s9_1_wohnzimmer_vuplus · …_s9_2_wohnzimmer_sonos_arc_amp · …_s9_3_wohnzimmer_tv
🔴 Zwei Gruppen-Helper referenzieren s9 in ihrer Config und brechen sonst: sonos wohnzimmer (01KFN557CED9WWDSKMVF1MW4CQ) und tv (01KFN57B9V1D30J39VH75V0GA9).
Ausgangsnamen und initial_state=restore_last aus dem Backup wieder setzen (der Flash hat sie auf None/off zurückgesetzt).
Energie-Dashboard: 2,2 / 0,4 / 16,4 / 14,4 kWh hängen an den alten unique_ids — Fix-Lauf nötig.

Bei Weg (C) wäre vorher ein UART-Vollbackup nötig gewesen, sonst gäbe 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

✅ Geklärt 2026-08-23, negativ: s4 kueche_mikrowelle ist ein S3PL-00112EU = Gen3 (Modell aus mcp/shelly/migration-log.jsonl, Gerät selbst offline hinter Metall). Es gibt für Gen3 keine Alternativfunk-Firmware. Der erhoffte beste Pilot existiert nicht — das Gerät bleibt bei −93 dBm im WLAN und ist damit auch nach TP17.1 der Härtefall. Pilot bleibt s26 oder s12.
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? (Z2M z2m25 auf 10.40.20.106:8080 ist erreichbar, HTTP 200 — geprüft 2026-08-23.)
✅ 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)

58 KiB Raw Blame History Unescape Escape