849 lines
58 KiB
Markdown
849 lines
58 KiB
Markdown
# 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`](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)
|
||
|
||
1. **Die PSK-Rotation wird billiger.** Jedes Gerät, das den Funk wechselt, fällt aus der Rechnung.
|
||
2. **Mesh-Stabilität** — netzgespeiste Geräte sind immer Router-Knoten, nie Sleepy End Devices.
|
||
3. **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](https://github.com/hencou/shelly_gen4_matter_module) *(die [automatous-io](https://github.com/automatous-io/shelly-1-gen4-matter-thread)-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_id`s
|
||
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:
|
||
|
||
1. **Blast Radius trennen** (s.o.) — die wirksamste Maßnahme, weil sie ohne Ursachenkenntnis wirkt.
|
||
2. **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.
|
||
3. **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.
|
||
4. **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.
|
||
5. **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:**
|
||
1. `BROADCAST_TABLE_FULL`, `ALLOCATE_PACKET_BUFFER_FAILURE`, `PHY_TO_MAC_QUEUE_LIMIT_REACHED` oder
|
||
`TYPE_NWK_RETRY_OVERFLOW` **verlässt die Null**.
|
||
2. Retry-Quote **verdoppelt** sich gegenüber der Baseline (≈15 % → >30 %).
|
||
3. Ein Referenzgerät, das vorher prompt reagierte, braucht **wiederholt >2 s**.
|
||
4. 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:
|
||
> 1. **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.
|
||
> 2. **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.
|
||
> 3. **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`](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 **B**uilt-**I**n"). 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`](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:**
|
||
1. **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".
|
||
2. **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`](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](https://support.shelly.cloud/en/support/solutions/articles/103000360571-adding-shelly-devices-to-a-zigbee-network)
|
||
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."
|
||
|
||
1. **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).
|
||
2. **Ziel-`entity_id`s** (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`
|
||
3. 🔴 **Zwei Gruppen-Helper referenzieren `s9` in ihrer Config und brechen sonst:**
|
||
**`sonos wohnzimmer`** (`01KFN557CED9WWDSKMVF1MW4CQ`) und **`tv`** (`01KFN57B9V1D30J39VH75V0GA9`).
|
||
4. **Ausgangsnamen und `initial_state=restore_last`** aus dem Backup wieder setzen (der Flash hat sie
|
||
auf `None`/`off` zurückgesetzt).
|
||
5. **Energie-Dashboard:** 2,2 / 0,4 / 16,4 / 14,4 kWh hängen an den alten `unique_id`s — 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_id`s 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
|
||
|
||
1. ✅ **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`.
|
||
2. 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.
|
||
3. 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.)*
|
||
4. ✅ **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`](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](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`)
|