Scan auf beiden APs durchgefuehrt (User hat die Client-Unterbrechung freigegeben).
Neuer Gotcha, auch in CLAUDE.md: /interface wifi scan geht am CAP NICHT, nur am
Manager gegen cap-wifiN. Der Gegentest schliesst device-mode und Policy aus --
/tool fetch meldet auf demselben Geraet explizit "not allowed by device-mode",
waehrend der Scan nur "not allowed" sagt, und die Gruppe full hat test und sniff.
Ein CAP besitzt sein Radio nicht.
Ergebnis: kein einziges Fremdnetz ueber -81 dBm. Die Nachbarschaft ist fuer eine
Wohnlage bemerkenswert ruhig.
Die zwei lautesten Stoerer im Band sind eigene Geraete, und keines davon ist ein AP:
- Shelly s23 (dieleug-wohnzimmer_licht) sendet einen eigenen Access Point auf ch11
mit -51 dBm. WiFi.GetConfig bestaetigt ap.enable=true. Das ist ein uebrig
gebliebener Anker aus dem TP17-Migrationsverfahren, bei dem das De-Anchoring nicht
angekommen ist -- das Geraet funkt seither doppelt, als Client auf ch1 und als AP
auf ch11. Fix waere ein Einzeiler, nicht ausgefuehrt weil nicht beauftragt. Die
anderen 21 Anker sind nie gegengeprueft worden.
- Hoymiles-DTU sendet ebenfalls einen Konfig-AP, auf ch1 mit -59 dBm.
Fuer die Zigbee-Frage: das Fenster 2426-2448 ist nur schwach belegt, ZB18 bleibt
valide -- aber ohne Handlungsdruck, CCA=4 gilt weiter. ZHA bleibt auf 20.
Neue Randbedingung durch die zwei kommenden APs: 2,4 GHz hat drei ueberlappungsfreie
Kanaele. Funken vier APs dort, ist ch6 belegt und ZB18 faellt aus. Empfehlung, die
beides loest: die neuen APs als 5-GHz-Schwerpunkt fahren -- haelt ch6 frei, vermeidet
Selbststoerung und legt Kapazitaet dorthin, wo sie laut TP25 fehlt.
Homematic/HmIP nachgetragen (User-Hinweis): 37 Geraete an der CCU, classic und HmIP
gemischt, beide auf 868 MHz -- ausserhalb dieser Rechnung. Eigener Ausfallmodus ist
der 1-Prozent-Duty-Cycle, das Gegenstueck zum Broadcast-Sturm. Relevant fuer TP29,
dessen Aktor genau die HmIP-HEATING-Geraete waeren.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei Fragen von Christoph beantwortet, alle mit Messung statt Schaetzung.
1) Woran erkennt man einen Broadcast-/Routing-Sturm: die EZSP-Zaehler des
Koordinators, mit einer echten Baseline von heute. BROADCAST_TABLE_FULL,
ALLOCATE_PACKET_BUFFER_FAILURE, PHY_TO_MAC_QUEUE_LIMIT_REACHED und
TYPE_NWK_RETRY_OVERFLOW stehen alle auf 0 -- jede Abweichung davon ist der Alarm.
Normallage sonst: Retry-Quote ~15 Prozent, Broadcast-zu-Unicast 6,7:1. Dazu ein
vorab festgelegtes Abbruchkriterium fuer den Testjoin, damit im Moment nicht
diskutiert werden muss.
2) Welche Geraete sind fuer fehlerhaftes Routing anfaellig -- beide Netze
durchgesehen. ZHA: 3 Aqara lumi.weather als Kanarienvogel (klassisches
Aqara-an-Hue-Problem, 14 Hue-Router im Netz), 3 GLEDOPTO mit dokumentierter
Router-Schwaeche. Z2M: 6 Busch-Jaeger ZLL-Altgeraete, die die Wandbeleuchtung
tragen, plus 4 Tuya-Geraete, eines davon ohne saubere Definition.
Daraus die Netzwahl fuer den Test: ZHA, nicht Z2M -- Proportion (24 vs 7 Router),
Blast Radius (in Z2M haengt das Licht an den Altgeraeten) und Messbarkeit.
3) ZHA-Kanal: bleibt auf 20. Korrektur meines eigenen Befundes -- ich hatte ch20
als den Konflikt im Haus markiert, weil 2450 auf der Unterkante von WLAN ch11
liegt. PHY_CCA_FAIL_COUNT steht bei 4 ueber die gesamte Zaehlperiode, die Adjazenz
beisst also nicht. Ein Wechsel muessten 52 Geraete mitmachen, und wer nicht folgt,
ist verwaist -- Risiko ohne belegten Nutzen. Falls doch je gewechselt wird: 18,
und erst nach einem Scan der Nachbar-WLANs, weil die Luecke genau WLAN-Kanal 6 ist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
User-Entscheid: das Arbeitspaket wird im Netz-Projekt gesteuert, nicht im
HA-Projekt. HA ist Betroffener (Entity-Bruch), nicht Eigentuemer -- die
Entscheidung ist eine Funk- und Netzentscheidung.
Aus der Uebergabe wird docs/tp17.1-shelly-gen4-funkmigration-runbook.md, auf den
heutigen Stand gebracht: die drei Wege (Zigbee offiziell / Thread abwarten /
Thread per Dritt-Firmware) als Vergleichstabelle, die Geraetebefunde, die
Zigbee-Kanalplanung gegen ap1 ch1 und ap2 ch11 als Rechenschritt, und die
Verzahnung mit der parallel laufenden PSK-Rotation inkl. der s1/s2/s3-Falle.
Titel geaendert: "Thread ODER Zigbee". Der reine Thread-Zuschnitt haette den
einzigen heute verfuegbaren Weg ausgeschlossen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
