Christophs strukturelle Frage hat TP17.1 gekippt: "zigbee sollte die
antwort auf die vielen radios auf -iot geben. nutzt aber wenig wenn man
das wifi nicht abdrehen kann bzw. es nicht mehr aktivieren kann ohne
reset."
Der Pilot hat den Weg technisch vollstaendig bewiesen -- und gezeigt, dass
das Ziel so nicht erreichbar ist. Das Geraet bleibt WLAN-Client; der
gemessene Funkgewinn ist klein (12 von 26 IoT-Clients, je 150-200 KB rx /
0,6-3 MB tx in sechs Stunden); und WLAN abzuschalten waere unumkehrbar,
weil die Zigbee-Firmware keinen AP hat, Shelly kein Zigbee-OTA macht und
InstallAlt eine IP braucht. Der Weg ist nicht gescheitert, das Ziel war
mit ihm nicht erreichbar. Das Runbook bleibt als Wissensspeicher.
Rueckbau: ZHA-Knoten entfernt -- Leave VOR dem Flash, damit kein
Geisterrouter im 52-Geraete-Mesh bleibt. s9 zurueck auf PowerStrip, Config
aus dem Backup. Alle vier roten EZSP-Zaehler blieben 0, Retry-Quote fiel
im Delta auf 8,9 %.
Neue Merkregel: der Rueckflash zog einen OFFENEN AP hoch (ap.enable=true,
is_open=true). Abgeschaltet und mit dem IoT-PSK abgesichert. Nach jedem
Shelly-Firmwarewechsel den AP pruefen.
eco_mode flottenweit aus (User: "der rotz macht nur probleme"): 13 Geraete
umgestellt, null Fehler, 9 standen schon so. Jetzt eco=false auf allen 22
erreichbaren Shellys ausser s24, das es nicht unterstuetzt. Dafuer
migrate.py um ein eco-Kommando ergaenzt -- mit Retry je Geraet, weil ein
Timeout an einem schwachen Link den Sweep sonst abreisst.
Die Gegenmessung widerlegt meine eigene Warnung: eco aus hebt die
Sendeleistung NICHT messbar an. 13 geaenderte Geraete im Mittel -0,9 dB,
Kontrollgruppe von 13 unveraenderten +0,0 dB bei gleicher Streuung. Die
TP17-Aussage, eco senke Takt UND Sendeleistung, stimmt nur zur Haelfte.
Vorbedingung der Passwort-Rotation geprueft: alle vier Skripte laufen
laengst auf sshpass -e, die gegenteilige Notiz war veraltet. Uebrig war
CLAUDE.md, das sshpass -p weiterhin aktiv als Reboot-Weg empfahl -- genau
das Muster, das den Leak verursacht hat. Auf sshpass -e korrigiert.
TP17.2 aus "zurueckgestellt" aktiviert und an die PSK-Rotation gekoppelt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ZHA-Backup zuerst (is_complete true, Kanal 20, PAN 5B5A) -- das ist der
Punkt, der 2024 gefehlt hat. Dann permit_join + StartNetworkSteering:
network_state joined nach 10 Sekunden.
Abnahme nach Runbook-Kriterium erfuellt. ZHA hat vier switch-Entities
angelegt. Gegenprobe quer ueber beide Wege: turn_on ueber ZHA gesendet,
Ergebnis ueber die WLAN-RPC des Shelly gelesen -- switch:0 output=True,
2.1 W. Der Zigbee-Befehl hat das physische Relais geschaltet. Danach
wieder aus, Ausgangszustand hergestellt.
Zaehlervergleich vor/nach dem Join: alle vier roten Zaehler unveraendert
0. NEIGHBOR_ADDED +1 (genau der neue Router), NEIGHBOR_REMOVED weiterhin
0. Broadcast:Unicast im Delta 1,8:1 gegen eine Normallage von 6,7:1 --
unicast-lastiger Interview-Traffic, das Gegenteil einer Sturmsignatur.
Erhoeht und vor dem zweiten Geraet erneut zu lesen: Retry-Quote im Delta
44 % (Normallage ~15 %) und PHY_CCA_FAIL_COUNT 7 -> 19.
Der Pilot ist damit noch nicht fertig -- Schritt 2 (HA-Seite) steht:
alte Shelly-Entities entfernen, bevor umbenannt wird, sonst haengt HA
ein _2 an; vier Ziel-entity_ids notiert; zwei Gruppen-Helper (sonos
wohnzimmer, tv) referenzieren s9 und brechen sonst; Ausgangsnamen und
initial_state aus dem Backup zurueckschreiben; Energie-Statistiken
brauchen einen Fix-Lauf.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christoph hat Weg (A) gewaehlt (Zigbee, Hersteller-Firmware) und als Pilot
s9 wohnzimmer_sideboard bestimmt -- nach dem Kriterium physische
Zugaenglichkeit. Das ist das bessere Kriterium: von den 12 Gen4 sind nur s9
und s13 Steckerleisten, die anderen zehn Unterputz. s13 scheidet aus (NAS
und Drucker haengen dort).
Ergebnis: s9 laeuft auf slot=0, app=PowerStripZB, ver 2.0.0.
Korrekturen am Runbook, alle live am Geraet erhoben:
- Deckung ist 12 von 12 Gen4, nicht 10. Die frueher als "von keinem Weg
abgedeckt" gefuehrten S4PL-00416EU (s9, s13) bekommen PowerStripZB
angeboten, mit stable-Build.
- s4 kueche_mikrowelle ist ein S3PL-00112EU = Gen3. Der im Runbook erhoffte
beste Pilot existiert nicht; das Geraet bleibt bei -93 dBm im WLAN.
- Der Wechsel ist KEIN Modus-Umschalter, wie die Shelly-Support-Seite
beschreibt, sondern ein Firmware-Wechsel im Zwei-Slot-Modell. Auf der
WiFi-Firmware existiert kein Zigbee.*-Namespace. Drei undokumentierte
RPCs aus dem UI-JS extrahiert: Shelly.InstallAlt, Shelly.SetAlternative,
Shelly.ListAlternatives -- nur die erste ist hier nutzbar.
- Blocker (a) Rueckrollbarkeit ist geschlossen: die Zigbee-Firmware bietet
PowerStrip ("with Matter", stable) ihrerseits als alt an, ueber das Netz.
WLAN und statische IP ueberleben den Wechsel, das Geraet bleibt unter
10.40.30.216 erreichbar. Eine frueher in derselben Session geaeusserte
Einschaetzung, der Rueckweg sei physisch und die Unterputz-Module damit
Einbahnstrassen, war falsch.
Verloren gehen: Matter komplett, der AP, alle Ausgangsnamen und
initial_state. Vollbackup vor dem Flash liegt vor.
Beobachtung fuer die Serie: der erste InstallAlt brach bei 2 % ab; nach
eco_mode=false lief derselbe Aufruf glatt durch. n=1, keine bewiesene
Kausalitaet -- aber eco_mode=false vor dem Flash kostet nichts.
Offen: s9 ist noch keinem Zigbee-Netz beigetreten (network_state failed),
die vier Ausgaenge sind derzeit nicht aus HA steuerbar. Vor dem Join in ZHA
fehlt das ZHA-Backup.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
get-config read-only ueber Port 10081 abgefragt (hoymiles-wifi 0.5.6, isoliertes venv,
nur lesende Kommandos, Passwortfelder in der Ausgabe redigiert).
channel_select = 0. Damit ist Christophs These "Kanalwahl fix eingebrannt" widerlegt,
und zwar an der Quelle statt durch Indizien. Seine Beobachtung war trotzdem richtig,
nur die Ursache eine andere.
Die tragfaehige Erklaerung: das Geraet sucht nicht. Es haelt an dem AP fest, mit dem es
provisioniert wurde, und gibt auf, wenn der es abweist, statt sich einen anderen zu
suchen -- genau das beobachtete Verhalten. Nicht der Kanal ist starr, sondern die
AP-Bindung. Typisch fuer einfache ESP-Firmware ohne Roaming-Logik.
Folge, die eine Option wiederbelebt: ap1s eigenen Kanal umzulegen wirkt. Ohne
channel_select folgt der DTU dem AP, an dem er haengt -- der Stoerer wandert mit, ohne
dass das Geraet je abgewiesen wird oder neu provisioniert werden muss. Das ist der
einzige risikoarme Weg, ihn von ch1 wegzubekommen, und er faellt beim Kanalplan fuer
die zwei neuen APs ohnehin an.
Die access-list bleibt gesperrt -- nicht wegen des Kanals, sondern wegen der
Aufgeben-Eigenschaft.
Nebenbefund mit Vorsicht notiert: dtu_ap_pass und lock_password liefern nur 1 Zeichen
zurueck, mit hoher Wahrscheinlichkeit ein maskierter Platzhalter. Daraus wird
ausdruecklich KEINE Passwortschwaeche abgeleitet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
