From a4833efcdbdbc33dd9912b7313cc92b75522a7b0 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 23 Aug 2026 14:53:31 +0200 Subject: [PATCH] DTU erholt sich nicht selbst -- Re-Provisionierung war noetig 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 --- docs/tp17.1-shelly-gen4-funkmigration-runbook.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md index 8542fcd..8425a53 100644 --- a/docs/tp17.1-shelly-gen4-funkmigration-runbook.md +++ b/docs/tp17.1-shelly-gen4-funkmigration-runbook.md @@ -459,6 +459,18 @@ Wechselrichter, mit der bekannten Falle, dass `SetConfig` den *ganzen* Satz übe 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. + ### 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