TIMMERFLOTTE angelernt, -infra wieder deaktiviert
Der Workaround aus TP12.1 ist durchgespielt: dirtyvader-infra temporaer auf ap2, iPhone auf VLAN20, TIMMERFLOTTE per Companion-App angelernt (25,44 C / 53,1 % rF / Batterie 100 %, Technik UG). SSID danach wieder vom Funk; cfg-infra/dp-infra/sec-infra bleiben auf User-Wunsch inaktiv am Manager stehen, damit das naechste Thread-Geraet ein Zweizeiler ist. Beide Akten geschlossen, crs326-core transaktionsfrei. TP12.1 bleibt offen: der Workaround umgeht das fehlende IPv6-Routing, er behebt es nicht. Neuer Gotcha in CLAUDE.md, an dem ich mich heute selbst verrannt habe: slave-configurations zu setzen bewirkt am Funk nichts ohne remote-cap provision -- und zwar in BEIDE Richtungen, auch beim Entfernen. Schlimmer: beim Rueckbau wird der Interface-Kommentar geleert, waehrend der VAP weitersendet. Ich habe auf comment~"dirtyvader-infra" geprueft, nichts gefunden und "weg" gemeldet -- tatsaechlich liefen wifi13/wifi18 mit vlan=20 weiter. Richtige Abnahme ist datapath.vlan-id am CAP. Also wieder: Wirkung messen, nicht Anzeige. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -646,6 +646,14 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
|
||||
beides aus. `cfg-infra` / SSID `dirtyvader-infra` (`dp-infra`, VLAN20, `sec-infra` mit PSK) existiert am
|
||||
Manager **bereits**, ist nur in **keiner** `provisioning`-Zeile als Slave hinterlegt. Runbook:
|
||||
[`docs/matter-pairing-infra-ssid-runbook.md`](matter-pairing-infra-ssid-runbook.md).
|
||||
- ✅ **2026-08-22 durchgefuehrt und wieder zurueckgebaut.** `dirtyvader-infra` temporaer auf ap2
|
||||
(Transaktion `TEST-infra-ssid-matter-pairing`, Scope `wifi-provisioning`), iPhone dort hinein,
|
||||
**TIMMERFLOTTE per Companion-App angelernt** — liefert 25,44 °C / 53,1 % rF / Batterie 100 %
|
||||
(Bereich Technik UG). Danach SSID deaktiviert; `cfg-infra`/`dp-infra`/`sec-infra` bleiben auf
|
||||
User-Wunsch **inaktiv am Manager stehen**, damit der Weg beim naechsten Thread-Geraet ein
|
||||
Zweizeiler ist. Beide Akten geschlossen, `crs326-core` transaktionsfrei.
|
||||
⇒ **Der Workaround ist damit bewiesen** — und TP12.1 bleibt trotzdem offen: er umgeht das
|
||||
fehlende IPv6-Routing, er behebt es nicht.
|
||||
- ✅ **Der Weg, der das Problem dauerhaft erledigt:** Matter-Server-Option **`ble_proxy: true`** (ab HA
|
||||
2026.06, hier 2026.8.3). Dann kommissioniert **HA selbst** über seinen Bluetooth-Stack; das Telefon ist
|
||||
raus und die VLAN-Grenze wird nie berührt. Braucht eine **connectable** BLE-Quelle — Shelly-Proxies sind
|
||||
|
||||
@@ -8,7 +8,8 @@
|
||||
"reason": "dirtyvader-infra temporaer auf ap2: iPhone fuer Matter-Commissioning auf VLAN20 (TP12.1)",
|
||||
"started": "2026-08-22",
|
||||
"expires": "2026-08-29",
|
||||
"state": "open",
|
||||
"state": "rolledback",
|
||||
"snapshot": "docs/transaktionen/TEST-infra-ssid-matter-pairing.snapshot.rsc",
|
||||
"device_backup": ""
|
||||
"device_backup": "",
|
||||
"closed": "2026-08-22"
|
||||
}
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
# TATSAECHLICH DEPLOYT am 2026-08-22 (Plan 1469f0f7-fc52-47e1-bd65-a83ac709d89c, Completed).
|
||||
# Danach ZWINGEND: /interface wifi capsman remote-cap provision [find where identity="ap2"]
|
||||
# Ohne die Re-Provisionierung bleiben die VAPs am CAP bestehen und senden weiter.
|
||||
# Rueckbau: dirtyvader-infra wieder von ap2 nehmen. Stand vor dem Change (live gelesen 2026-08-22).
|
||||
/interface wifi provisioning set [find where comment="ap2 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest
|
||||
/interface wifi provisioning set [find where comment="ap2 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest
|
||||
@@ -1,3 +1,18 @@
|
||||
# Rueckbau: dirtyvader-infra wieder von ap2 nehmen. Stand vor dem Change (live gelesen 2026-08-22).
|
||||
/interface wifi provisioning set [find where comment="ap2 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest
|
||||
/interface wifi provisioning set [find where comment="ap2 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest
|
||||
# Rueckbau-VORSCHLAG fuer TEST-infra-ssid-matter-pairing (crs326-core, Scope wifi-provisioning)
|
||||
# Aus dem Snapshot vom 2026-08-22. NICHT ungeprueft deployen:
|
||||
# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird,
|
||||
# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen.
|
||||
|
||||
/interface wifi provisioning
|
||||
add action=create-dynamic-enabled comment="ap1 5GHz" master-configuration=\
|
||||
cfg-main-5g-ap1 radio-mac=D0:EA:11:4D:40:E5 slave-configurations=\
|
||||
cfg-media,cfg-untrusted,cfg-guest
|
||||
add action=create-dynamic-enabled comment="ap1 2.4GHz" master-configuration=\
|
||||
cfg-main-2g-ap1 radio-mac=D0:EA:11:4D:40:E6 slave-configurations=\
|
||||
cfg-iot,cfg-media,cfg-untrusted,cfg-guest
|
||||
add action=create-dynamic-enabled comment="ap2 5GHz" master-configuration=\
|
||||
cfg-main-5g-ap2 radio-mac=D0:EA:11:4D:40:3E slave-configurations=\
|
||||
cfg-media,cfg-untrusted,cfg-guest
|
||||
add action=create-dynamic-enabled comment="ap2 2.4GHz" master-configuration=\
|
||||
cfg-main-2g-ap2 radio-mac=D0:EA:11:4D:40:3F slave-configurations=\
|
||||
cfg-iot,cfg-media,cfg-untrusted,cfg-guest
|
||||
|
||||
Reference in New Issue
Block a user