Nachtrag zum fehlgeschlagenen Pin. Auch nach dem Rollback, mit freiem ap1 auf ch1,
blieb der DTU weg. Zurueck kam er erst, als Christoph ihm ueber die S-Miles-App die
WLAN-Zugangsdaten erneut uebergab -- danach binnen Sekunden wieder auf ap1,
dirtyvader-iot, -51 dBm, verifiziert in der Registration-Table.
Damit verschaerft sich die Lehre: ein einmal abgewiesener DTU gibt seine gespeicherte
Verbindung dauerhaft auf. Ein reject gegen dieses Geraet ist kein Experiment, sondern
ein Ausfall, dessen einziger Rueckweg Handarbeit vor Ort mit der Hersteller-App ist --
nicht per Fernzugriff behebbar. Die access-list ist fuer dieses Geraet gesperrtes
Gebiet, solange der PV-Datenpfad produktiv ist.
Nebenbefund: dass die Re-Provisionierung auf ap1 (ch1) sofort klappte, waehrend der
Wechsel auf ap2 (ch11) scheiterte, stuetzt die Kanal-These zusaetzlich.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auftrag war, den nicht abschaltbaren DTU-AP von ch1 wegzubekommen, indem man den
Client per access-list an ap2 bindet. Transaktion TP17.1-dtu-pin-ap2 eroeffnet, fuenf
reject-Regeln auf ap1s 2,4-GHz-Interfaces deployt. Der DTU flog um 14:38:48 von ap1
und kam bei ap2 nie an. Nach 2,5 Minuten zurueckgerollt, access-list ist wieder leer.
Ursache ist Christophs Verdacht und protokollseitig belegbar: SetConfig.proto kennt
channel_select (Feld 9). Der eigene AP des Geraets sendet auf ch1, und ein ESP hat ein
Radio -- AP und STA teilen zwingend den Kanal. ap2 laeuft auf ch11, dort kann das
Geraet gar nicht assoziieren. Die Sperre hat es also nicht umgeleitet, sondern
ausgesperrt. Christophs Wiederverbindungsversuch ueber S-Miles scheiterte mit genau
der Meldung, die er von Frequenz-Fehlanpassungen kennt.
Damit ist meine Empfehlung "AP-Kanal verschieben, indem man den Client bindet" fuer
dieses Geraet widerlegt und im Text durchgestrichen. Sie gilt weiter fuer frei
scannende Geraete wie die Shellys.
Zwei Merkregeln festgehalten:
- Ein reject auf AP A ist keine Umleitung auf AP B, sondern ein Rausschmiss. Ob das
Geraet woanders unterkommt, ist seine Entscheidung. Bei fixem Kanal: nirgends.
- Vor einem Pin pruefen, ob der Client den Kanal des Ziel-APs ueberhaupt benutzen
kann. Der Beleg lag vor: DTU-AP auf 2412, ap2 auf 2462. Signalstaerke ist kein
Nachweis fuer Assoziationsfaehigkeit -- meine Abnahme war zu lasch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christophs Hinweis war richtig, die Antwort steckte im Addon-Umfeld -- allerdings
nicht im Addon selbst (ha-hoymiles-wifi-addon v0.5 alias hms-mqtt-publisher ist rein
lesend und pollt nur Telemetrie), sondern in der Protokolldefinition, die die
Schwester-Bibliothek suaveolent/hoymiles-wifi offenlegt.
SetConfig.proto kennt dtu_ap_ssid (48) und dtu_ap_pass (49), dazu wifi_ssid/-password,
netmode_select, channel_select und dhcp_switch. Es gibt KEIN ap_enable. Damit ist
"AP laesst sich nicht abschalten" aus der Schnittstellendefinition ableitbar statt aus
Forenberichten.
KORREKTUR eines eigenen Fehlbefunds: ich hatte "null offene TCP-Ports" gemeldet.
Falsch, 10081 ist offen. Ursache war ein kaputter Port-Test -- timeout existiert auf
macOS nicht, jeder Aufruf lief auf command not found und wurde als geschlossen
gewertet. Merkregel festgehalten: ein Test, der bei jedem Port dasselbe Ergebnis
liefert, hat sich selbst widerlegt.
Folge: mein Gegenargument gegen die Fallback-Idee ("dann kaeme man gar nicht mehr an
die Konfiguration") ist hinfaellig -- ueber 10081 bleibt die Konfiguration auch ohne
AP erreichbar. Die Idee ist technisch sauber, Hoymiles implementiert sie nur nicht.
Gueltig bleibt: 80/443/8080/8000 sind zu, es gibt LAN-seitig keine Weboberflaeche.
Und der AP ist verschluesselt (wpa2-psk), der bekannte Fall vom offenen DTU-WLAN
trifft hier nicht zu. Einzige sinnvolle Haertung waere dtu_ap_pass, falls dort noch
das Werkspasswort steht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Am Geraet geprueft und recherchiert. Es ist kein separater DTU-Kasten, sondern der
Wechselrichter mit eingebautem DTU -- daher DTUBI, Built-In.
Abschalten: existiert nicht. Hoymiles bietet keine Funktion dafuer an, im
Herstellerumfeld wird sie von Nutzern gefordert. Christophs Recherche hat nichts
gefunden, weil es nichts zu finden gibt.
Entwarnung: der AP ist bereits verschluesselt (wpa2-psk;wpa-psk). Der bekannte Fall
"Hoymiles-DTU funkt ein offenes WLAN" trifft hier nicht zu. Ab FW 3.0.8 gibt es die
AP-Passwort-Einstellung, die offenbar gesetzt ist.
Die Fallback-Idee (AP nur wenn kein Link) ist ein Standardmuster, aber hier mit
Haken: das Geraet hat LAN-seitig null offene TCP-Ports -- geprueft, nur ICMP
antwortet, Daten kommen per MQTT-Push. Die Weboberflaeche existiert ausschliesslich
auf dem AP. Bei funktionierender STA-Verbindung waere sie damit unerreichbar, obwohl
man sie genau dann braucht.
Der Hebel, den es stattdessen gibt: ein ESP hat ein Radio, AP und STA laufen
zwangslaeufig auf demselben Kanal. Der DTU-AP sitzt auf ch1, weil seine STA-Verbindung
dort haengt. Bindet man den Wechselrichter per access-list an ap2, wandert sein AP
mit. Nicht abschaltbar, aber verschiebbar -- und dieselbe Regel erklaert den Shelly
s23: wer den Stoerer verschieben will, verschiebt den Client.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Meldung: der Luefter-Shelly muss doppelt gedrueckt werden, und der Dimmer in
der Diele UG flackert unkontrolliert seit der Migration -- mit eingeschaltetem AP
ist das Symptom weg.
KORREKTUR eines eigenen Fehlbefunds von heute Vormittag: ich hatte den aktivierten
AP auf s23 als vergessenen Anker aus TP17 eingeordnet, der abgeschaltet gehoert.
Er ist Christophs Workaround. Der als "Einzeiler" beschriebene Fix haette eine
funktionierende Reparatur zerstoert. Merkregel dazu festgehalten: ein Zustand, der
nach einem Verfahren uebrig aussieht, kann eine Reparatur sein -- vor dem Aufraeumen
fragen, wozu er da ist, nicht ob er ins Schema passt.
Leithypothese aus dem read-only-Sweep ueber alle 22 Geraete: nicht die WLAN-Config,
sondern eco_mode. Es senkt den CPU-Takt; ein Phasenanschnitt-Dimmer braucht praezises
Nulldurchgangs-Timing, und ein aktiver AP hebt die Energiesparzustaende auf -- das
erklaert genau die Beobachtung "AP an, Symptom weg". s23 ist ein SPDM-002PE01EU
(app ProDimmerx) mit eco_mode=true; s26 hat eco_mode=true bei momentary-Eingang, was
zum verschluckten ersten Tastendruck passt. Gegenprobe: s12 am selben Ort, gleiches
Modell wie s26, eco_mode=false, unauffaellig. Diskriminierender Test in vier Schritten
notiert, reversibel, ein Geraet.
Zwei Nebenfunde aus demselben Sweep:
- Die eco-Politik von 2026-07-13 ist stale und war nie konsistent: drei Geraete haben
eco an, obwohl sie unter -80 dBm liegen; zwei haben es aus, obwohl sie darueber
liegen. Die fuer "nach TP3.3" vorgemerkte zweite Evaluation hat nie stattgefunden.
- restart_required=true auf s26 und s12: dort liegt eine geschriebene, nie aktivierte
Konfigurationsaenderung, seit 21 bzw. 33 Tagen ohne Neustart.
Anker-Sweep gelaufen: s23 ist der einzige Shelly mit aktivem AP, die anderen 21 sind
sauber de-anchored.
5-GHz-Scan nachgeholt: nur drei Fremdnetze, alle <= -83 dBm, das Band ist praktisch
leer. Planungsaussage fuer die zwei neuen APs: im ETSI-Indoor-Band sind bei 40 MHz
genau zwei ueberlappungsfreie Bloecke vorhanden, und beide sind vergeben -- AP drei
und vier muessen ins DFS-Band. Dass DFS hier nutzbar ist, belegt ein Nachbar auf 5500.
DTU: bleibt wie sie ist (User). Sie gehoert zur PV, ihr AP ist deren Konfignetz, die
Messdaten kommen ohnehin ueber -iot. Als bekannter Dauersender auf ch1 dokumentiert,
nicht bekaempft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
