User-Entscheid. minarca, node-red, hms-mqtt-publisher und openproject
zerstoert, 28 PBS-Snapshots geloescht, 0 Fehler. Gegenprobe direkt am
Datastore: keine Spur von ct/103|109|115|201 mehr.
Ergebnis: auf pve laeuft jetzt jeder existierende Gast -- 11 LXC + 2 VMs,
kein einziger stopped. Der Datastore enthaelt nur noch aktuelle Gaeste.
Merkregel mitgeschrieben: die Snapshot-Liste VOR dem pct destroy
einsammeln. pvesm list --vmid liefert danach 0, obwohl die Backups noch
liegen -- der Filter braucht die Gast-Config. Genau deshalb lief der
104er-Loeschversuch vorhin ins Leere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Entscheid: auch die Grafana-Backups loeschen. Gegenprobe direkt am
Datastore (ct/104 = 0), nicht ueber 'pvesm list --vmid' -- dessen Filter
ist nach dem destroy nicht mehr aussagekraeftig.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christoph hat 10.40.41.10/32 (alte VLAN1-NAS) entfernt und den Stand als
stable bestaetigt - kein pending offen. Vertraut wird jetzt nur noch, was
tatsaechlich proxyt: 10.40.20.40 (Caddy) plus die drei cloudflared-Origins,
die mit Schritt 6 wegfallen. Abnahme: hass/vw/gitea/n8n je 200 ueber Caddy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ursache war nicht der fehlende Eintrag, sondern der falsche Ort: HA hat die
http-Konfiguration nach .storage/http migriert ("yaml_migration_done": true,
created_at 2026-08-05). Der YAML-Block wird seither kommentarlos ignoriert -
auch ein absichtlich ungueltiger Schluessel darin erzeugt keinen Fehler.
Die Logzeile fuehrt aktiv in die Irre: "untrusted proxy 10.40.20.40" faellt
laut Quelltext nur bei aktivem use_x_forwarded_for - beide Werte kamen aber
aus .storage, wo .20.10/.126/.167 (die cloudflared-Origins) standen und
Caddy fehlte.
Fix ueber den vorgesehenen Weg: http/config/configure (setzt pending, startet
HA neu) und binnen 5 Minuten http/config/promote. stable enthaelt jetzt
10.40.20.40/32, pending ist leer, hass/vw/gitea/n8n liefern 200 ueber Caddy.
Der wirkungslose Block in configuration.yaml ist durch einen Hinweis ersetzt.
Offen und bewusst vertagt: 10.40.41.10/32 (tote VLAN1-NAS) steht weiter in
der Trusted-Liste.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SoT: CF und Caddy werden NICHT synchron gehalten - die Doppelpflege faellt
mit Schritt 5/6 weg. Heute stehen 19 Ingress-Regeln und 16 Caddy-Sites
nebeneinander und stimmen fachlich ueberein; im Zielbild haelt CF nur noch
eine Catch-all auf 10.40.20.40. Danach: Caddyfile = Name->Origin,
CF = welcher Name ist oeffentlich (4), AGH = Name->IP intern.
Nebeneffekt: die 12 internen Namen brauchen keinen oeffentlichen DNS mehr.
caddy/cf-sync.py (read-only, Exit 1 bei Drift) findet im ersten Lauf sieben
Abweichungen, alle auf CF-Seite: grafana noch im Ingress, nautobot und
gateway-dw als CNAME ohne Ingress (Quelle der 302), drei *.bf-CNAMEs auf den
zerstoerten NPM, dazu die Wildcard-Access-App, die alles maskiert.
Uebergabe korrigiert nach User-Einwand und Gegenmessung:
- Rewrites sind veraltet, nicht wertlos - Hosts leben auf VLAN20 weiter,
also Ziele umbiegen statt Namen loeschen.
- Die Redundanz existiert doch, reziprok ueber die Standorte: FM antwortet
auf 10.101.0.16/.17 (DS415+) - und beide liefern fuer nas.bf die tote
VLAN1-Adresse. Ein Rewrite-Satz nur im neuen BF-Paar erzeugt
standortabhaengig verschiedene Antworten.
- Vorratsregel auf .16 wird gestrichen statt erweitert (User-Entscheid).
- Cave: emsenhuber.net ist die Domain, bf.lan nur der DHCP-Suffix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die erste Fassung entstand vor der Caddy-Abnahme. Live erhoben, dagegen:
- adguard_bf1 (.20.16) ist ein Archiv, keine Vorlage: 24 Rewrites, davon 8
ins tote VLAN1, 9 auf den heute zerstoerten nginx-proxy-manager (LXC 128)
und 2 FritzBox-Reste. Uebernommen werden Upstreams/Filter, die Rewrites
entstehen neu aus caddy/Caddyfile.
- .20.17 ist nicht "bf2", sondern adguard_fm2 (FM-Standort) und antwortet
fuer gitea mit 10.40.41.123. BF hat heute EINEN AGH.
- Die TP5-Vorratsregeln erlauben LAN->DNS hart auf .20.16. Nach dem
DHCP-Flip wird DNS ein forward-Fluss ueber VLAN-Grenzen; ohne erweiterte
Regeln verlieren IOT/MEDIA/UNTRUSTED/GUEST/MGMT die Aufloesung, waehrend
VLAN20 weiterlaeuft und den Fehler tarnt.
Dazu neu: lease-time=1d macht Flip und Rollback traege (erst zur
Erneuerung wirksam), expliziter Rollback-Abschnitt, .36/.37 als frei
geprueft, und der Core bleibt bewusst Rueckfallebene.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Schritt 3 ist durch: Token liegt, deploy.sh gelaufen, Dienst active+enabled.
Abnahme ueber den Host-Header von einem zweiten Host (pve): 11x 200,
nautobot 302, Antwortzeiten 0,02-0,11 s.
Zwei Funde, die man sonst falsch ablegt:
- pve-mcp 400 / ha-mcp 403 / gitea-mcp 404 sind KEINE Proxy-Fehler - die
Gegenprobe direkt am Origin liefert dieselben Codes. Es sind die Antworten
der MCP-Server auf ein nacktes GET /.
- hass bleibt 400, aber die Logzeile sagt "untrusted proxy 10.40.20.40" und
nicht "not set-up for reverse proxies": use_x_forwarded_for greift also,
nur die Liste zieht nicht. Zwei volle Neustarts, Config-Check valid.
Naechster Schritt notiert; die atime taugt unter relatime nicht als Beweis.
Ist-Stand-Block mitgezogen (Projektregel).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Split-Horizon-Entscheid (AdGuard statt Core) macht aus 'ein paar
Eintraegen' eine Verschiebung der DNS-Aufloesung des ganzen Standorts in
einen Container -- heute liefert der DHCP in allen sieben VLANs den Core.
Das gehoert nicht ans Ende einer langen Sitzung (Lehre aus TP28).
Handoff enthaelt: Ausgangslage (Caddy produktiv, 16 Sites/17 Zertifikate),
den Auftrag in fuenf Schritten inkl. der IP-Kollision .30 (Nautobot) und
der Vorgabe, AGH als Paar 110/111 zu bauen statt als DNS-SPOF, sowie die
Staffelung VLAN fuer VLAN mit VLAN30 zuletzt.
Vier Fallen mitgegeben, alle in dieser Session bezahlt: Statuscode vom
oeffentlichen FQDN beweist nichts (grafana), pvesm free scheitert an
geschuetzten Snapshots stillschweigend, Startreihenfolge haengt nicht an
der VMID, und Core-Config braucht Golden Config.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Caddy in LXC 130 ist produktiv: 17 von 17 Zertifikaten per DNS-01 von
Let's Encrypt, Dienst active+enabled, Proxy gegen Host-Header verifiziert
(nautobot 302, gitea 200, pve 200, portainer 200). deploy.sh laeuft
End-to-End; Token per Fingerprint gegengeprueft -- eigenes Zone:DNS:Edit,
nicht das account-weite.
🔴 Fund beim Durchtesten: grafana war seit Langem tot und Cloudflare
Access hat es maskiert. LXC 104 stopped, konfigurativ noch auf VLAN1
(10.40.41.109), waehrend die Ingress-Zeile auf 10.40.20.109 zeigte -- eine
Adresse die es fuer Grafana nie gab. Der FQDN lieferte trotzdem 302, weil
das der Access-Login war. Exakt die Falle aus TP16.3 Paragraph 8, diesmal
in freier Wildbahn: ein toter Dienst sieht hinter Access monatelang
gesund aus.
=> Caddy-Zeile raus (16 Sites), LXC 104 zerstoert, aus dem Backup-Job.
Die 14 PBS-Snapshots bleiben bewusst stehen -- einzige Kopie etwaiger
Dashboards.
hass liefert 400: bekannter trusted_proxies-Punkt aus TP16, gehoert vor
die CNAME-Umstellung.
Split-Horizon entschieden (User): in AdGuard zusammen mit TP23 Stufe 2.
Dokumentiert, was das bedeutet -- heute liefert der DHCP in allen sieben
VLANs den Core als DNS; AGH bekommt niemand. Der Schritt verschiebt die
Aufloesung des ganzen Hauses in einen Container, deshalb als Paar
110/111 bauen. Die geloeschten Altlasten hiessen nicht zufaellig
adguard-bf1/-bf2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach der Relay-Reparatur lag weiter nichts an. tcpdump auf der VLAN40-Leitung:
jedes SSDP-Paket des MacBooks kam von Chrome (ST dial-multiscreen,
USER-AGENT Chromium), kein einziges von Sonos. Ursache war das
macOS-Local-Network-Gate - es stand auf "an" und griff nicht. Schalter
aus/ein + App-Neustart hat es gerichtet (User-bestaetigt).
Damit faellt auch die tragende Zahl des Vormittags-Handoffs: die "291 Suchen
der App in 12 Minuten" waren Chrome plus eigene Proben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die macOS-Sonos-App fand ihre Player nicht. Ursache war nicht die Firewall
(MEDIA->MAIN ist offen) und nicht der vermutete Race um den globalen
"last SSDP search source"-Slot, sondern die Flagge --ssdpUnicastAddr selbst:
multicast-relay.py Z. 630 schreibt die Quelle JEDES SSDP-Pakets an
239.255.255.250:1900 auf <addr>:1901 um (auch NOTIFY), Z. 691 verwirft
das Paket dann beim Senden auf eth1, weil 10.40.10.21 nicht im VLAN40-Netz
liegt. Der Hinweg lief damit nie.
Messung vorher: 0 Pakete via eth1 gegen 308 via eth0 in 20 min, 0x
"Received SSDP Unicast" im gesamten Journal seit 2026-08-18. Nachher:
M-SEARCH quellerhaltend in VLAN40, HTTP/1.1 200 OK von 10.40.40.193/.195
an beiden MacBook-Beinen, Drop-Log in:vlan40 out:vlan10 = 0.
- mcast-relay/multicast-relay.service: reparierte Unit jetzt im Repo
(ausgerollt auf LXC 108, Backup /root/multicast-relay.service.bak-20260825)
- CLAUDE.md: Gotcha korrigiert, Richtungsbilanz als Erstmessung, Hinweis auf
die SO_REUSEPORT-Falle auf Port 1900 und das dual-homed MacBook (.183/.82)
- docs/teilprojekte.md: Ist-Stand nachgezogen, TP33 (Fernzugriff) als Stub
- docs/teilprojekte-archiv.md: TP7.1-Aussage "--ssdpUnicastAddr ist noetig"
widerrufen
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die sieben verbliebenen Snapshots waren in PBS als protected markiert.
Auf User-Freigabe entschuetzt (pvesh set .../content/<volid> --protected 0)
und geloescht. Gegenprobe: 0 Snapshots zu allen sechs geloeschten IDs,
72 von 72 weg. VMID 130 gehoert damit ausschliesslich caddy-bf1.
Merkregel mit aufgenommen: pvesm free scheitert an geschuetzten
Snapshots mit 'cannot remove protected snapshot' -- und zwar
stillschweigend, wenn man den Fehler nicht ausliest. Wer nur die
Erfolgszaehler liest, haelt ein halb erledigtes Aufraeumen fuer fertig.
Genau so waeren hier sieben Snapshots stehen geblieben.
TP31-Abschnitt auf den Ist-Stand gezogen: Schritte 1 und 2 erledigt,
Schritt 3 wartet nur noch auf das Zone:DNS:Edit-Token.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aufgeraeumt (User-Freigabe): LXC 120/121/128/129/130/131 zerstoert --
alle stopped, onboot=0, alle konfigurativ noch auf totem VLAN1
(10.40.41.116/.117, GW .41.254). pct destroy --purge hat 120 und 128
zugleich aus dem Backup-Job entfernt. 65 von 72 PBS-Snapshots geloescht;
sieben sind PROTECTED und stehen noch -- bewusst nicht ueberschrieben.
Neu nach TP32-Systematik:
- LXC 130 caddy-bf1, VLAN20 tag=20, 10.40.20.40/24, GW/DNS .20.1,
onboot=1, startup order=10 (Core), Debian 13, 4 GB / 512 MB
- Caddy v2.11.4 mit dns.providers.cloudflare (Custom-Build)
- caddy/Caddyfile im Repo, 17 Sites: 4 oeffentlich (vw/hass/n8n/gitea),
13 intern inkl. der vier MCP-Endpunkte und drei HTTPS-Backends
- caddy/deploy.sh liest CF_DNS_API_TOKEN aus ~/.secrets und schreibt es
in die Container-Env -- nie auf stdout, nie in einer Kommandozeile
- 130 in denselben Backup-Job aufgenommen
Caddy laeuft noch NICHT: das eng geschnittene Zone:DNS:Edit-Token fehlt.
Ein Token anzulegen und im Klartext zu handhaben ist nichts, was ich
selbst tue -- der Weg ist ~/.secrets plus deploy.sh.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TP31 -- Caddy als Reverse Proxy fuer innen UND aussen, cloudflared von
sechs Containern auf einen. Anlass war Christophs Einwand, er habe den
Core unter der Praemisse gekauft, dass auch die Public-Apps darueber
laufen. Aktenlage geprueft: eine Zusage gibt es nicht, aber TP16.1
begruendet die Auswahl mit seinem Prinzip 'Router = einziger SPOF' --
und niemand hat je geprueft, ob der oeffentliche Strang ohne sechs
Container auskommt. Keine Taeuschung, eine ungepruefte Annahme.
- dst-nat-Variante geprueft und verworfen (ginge, Free-Tarif reicht),
weil Christophs Tunnel-Variante drei Risiken spart: keine angreifbare
Origin-IP, keine CF-IP-Allowlist, kein DDNS als Voraussetzung
- cloudflared auf ap1/ap2: live gemessen arm64, 95 MB Flash frei,
690 MB RAM frei. Der Core kann es nie (arm 32-bit, 2,9 MB frei)
- Kriterium fuer Infrastruktur-Container: was sich selten aendert und
wenig schreibt. Caddy nein (Config aendert staendig), AGH nein
(Query-Log frisst NAND)
TP32 -- VMID-Systematik (Hunderter = Klasse, gemeinsamer Raum fuer VMs
und LXCs) + letztes Oktett je /24, uebertragbar auf andere Standorte.
🔴 Dabei gefunden und SOFORT REPARIERT: die Startreihenfolge war falsch.
Proxmox startet erst Gaeste mit explizitem startup order=, dann den Rest
nach VMID -- drei Gaeste hatten einen, die DBs nicht. Home Assistant
startete damit vor MariaDB, MQTT und z2m25. Jetzt fuenf Stufen
(Core/Daten/Platform/Broker/Apps). Erkenntnis: VMID = Klassifikation,
startup order = Abhaengigkeit -- die Umnummerierung muss den Startlauf
gar nicht reparieren.
Doku-Korrekturen aus den Messungen:
- CLAUDE.md: 'Container NICHT auf dem Router' war nie nachgemessen
- tp16.1: 'Connector als Container ❌' galt dem TUN-Bedarf des
WARP-Connectors; cloudflared braucht kein TUN
- cf-tunnel-mapping Paragraph 16: die macvlan-Blindheit war mit einem
Shim behebbar -- der Workaround war groesser als der Fix
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Runbook ausgefuehrt. Vorbedingungen alle erfuellt, Testclient hing im
Hotspot-Netz 172.20.10.13 mit aktivem WARP -- also nicht im BF-LAN, der
einzige Aufbau der fuer Vorbedingung 2 etwas beweist.
Schnitt: nautobot.emsenhuber.net aus bf-nas (8 -> 7 Regeln), Catch-all
bleibt letzte. Rollback-Sicherung in docs/cf-backup/. Gegenprobe durch
Zuruecklesen der Config, nicht am Statuscode.
Abnahme vollstaendig, inkl. des uebersehenen Punktes: Golden Config lief
durch (Backup -> Intended -> Compliance, 104/104, 0 Drifts). Die uebrigen
fuenf bf-nas-Hostnames unveraendert.
Befund, der die Abnahmetabelle des Runbooks korrigiert: der oeffentliche
FQDN taugt nicht als Test. Er liefert vor UND nach dem Schnitt 302, weil
der von Cloudflare Access kommt, nicht vom Origin -- Access greift vor
dem Tunnel (JWT: auth_status NONE bei is_warp true). Damit auch eine
ehrlichere Erwartung: nautobot war nie ohne Access-Login oeffentlich
erreichbar, der Schnitt entfernt die zweite Tuer, nicht die erste.
Paragraph 7 des Runbooks ist ueberholt -- die HA-Degradierung ist am
selben Tag repariert, der Fall steht auf dem verbliebenen Argument.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Steht bisher nur in TP30/TP25, also nur beim Oeffnen von
teilprojekte.md sichtbar. Gehoert neben die sshpass-p-Warnung im
Tooling-Abschnitt, weil es dieselbe Klasse ist (Credential geraet
ueber ein Nebenprodukt in ein Transkript) und CLAUDE.md jede Session
gelesen wird.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kollektor am Manager (15-s-Takt, 29 Samples, 28 Clients). Von den drei
Kandidaten fallen zwei, und beide ohne Wartezeit:
- (b) DHCP-lease-time: tot. dhcp-v30 faehrt lease-time=1d, Renew bei
12h -- kann 5:05 nicht erzeugen. Eine Abfrage, keine Messung.
- (a) periodischer VAP-Re-Apply: tot. Auf genau dem VAP, der angeblich
alle 5:05 abwirft, standen drei Clients bei 16h51m Uptime, 25 von 28
ueber 6h. Dafuer braucht es die vier Zyklen nicht -- ein einziges
Sample mit 16h51m widerlegt einen 5-Minuten-Takt.
- (c) Geraet selbst: bleibt, ist aber nicht pruefbar.
Denn die zwei Fund-F-MACs sind schlicht weg: ARP status=failed, keine
Lease, nicht in der Registration-Table, HA kennt sie nicht. Merkregel
wie beim P750W -- erst pruefen ob das Geraet ueberhaupt da ist, bevor
ein periodisches Trennen als Funk-/Configfehler untersucht wird.
Nebenbefund: einziger Client mit Uptime-Ruecksetzer war der DTU
(54:F2:9F:12:51:F0) auf ap1, 43min Sitzung, bei -52 dBm. Nicht Fund F,
aber echt -- derselbe ESP-Ein-Radio-Mechanismus wie in der Transaktion
TP17.1-dtu-pin-ap2. Gehoert zur Neubewertung des Pins.
Rohdaten: docs/messdaten/tp25-fundf-20260824.log
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Vier Alt-Tunnel (openclaw/coolify/johnny2/TeilzeitCharlie) per CF-API
geloescht, User-Entscheid. Gegenprobe: 5 Tunnel, bf-* je 2 Connectoren.
Letzte VLAN1-Origins damit auch aus der CF-Config weg (Rest von TP19)
- TP25: Kanalplan fuer den dritten AP gerechnet, DFS genehmigt.
ETSI-Budget als Tabelle (Band A/B/C, 40-MHz-Bloecke duerfen keine
Bandgrenze queren). Empfehlung: neuer cAP ax auf 5180/Ce non-DFS,
ap1/ap2 nach Band B (5260/5300), 5220/Ce als Ausweichspur frei.
Band B statt C wegen CAC 60s statt 600s und gleichem 23-dBm-Deckel
- Zwei Fallen benannt: hart gepinnte Frequenz macht DFS zum SPOF
(Channel-Objekt braucht eine Liste), und die erreichte tx-power in
Band B messen BEVOR umgezogen wird -- das ist Fund B nochmal
- Platzierung: Messung widerspricht dem Aufstellen an bisheriger Stelle
(17/21 Abschnitte haben 0% Verlust). Vorschlag: cAP ax an den guten
Platz, verdraengter hAP in den Drei-Zimmer-Schatten
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TP16 -- Ursache war NICHT das erwartete QUIC-Flap: die beiden
macmini-Connectoren standen auf Exited(0), beide finishedAt auf
derselben Sekunde 2026-07-21T13:00:53, bei korrektem
restart=unless-stopped und http2. Also ein docker stop / compose down.
Fix = docker start. Abnahme: alle drei bf-Tunnel je 2 Connectoren /
8 conns, 36 Anfragen ueber 6 FQDNs beider Tunnel mit 530er=0.
- Datierung korrigiert: degradiert seit 07-21, nicht seit 08-16
(der 08-16 war der Tag der Entdeckung) -- vier Wochen unbemerkt
- Nachweisluecke festgehalten: 1 von 2 Connectoren meldet healthy,
nur die Connector-ANZAHL zeigt die Degradation -> Check nach TP11
- openclaw-Warnung korrigiert: welcher Tunnel einen Hostname bedient,
entscheidet das DNS; kein CNAME zeigt auf die vier toten Tunnel,
n8n zeigt korrekt auf bf-mm. Loeschen bleibt richtig als Hygiene
- Doku-Drift: bf-nas ist live 220c9958, nicht 70d6a4cf
- cf-tunnel-mapping.md Paragraph 15 als As-Built
TP25 -- 5-GHz-Umfeldscan am Manager: je EIN Fremdnetz pro AP, -86 bzw
-89 dBm. Band leer, Bloecke ueberlappungsfrei => beide ueblichen Gruende
fuer 20 MHz treffen nicht zu. Empfehlung: 20/40 behalten; der echte
Ausloeser ist die AP-Zahl (Band A = genau 2x40 MHz, mit zwei APs voll),
dann lautet die Wahl 20 MHz flottenweit gegen DFS akzeptieren.
TP30 -- neues Leak-Ereignis dokumentiert: list_wifi_interfaces gibt alle
Passphrasen im Klartext aus, damit sind fuenf WLAN-PSKs exponiert.
Als Falle aufgenommen. TP17.2-Stub entfernt (Verweise erklaeren den
Merge, ein Wegweiser ist nicht mehr noetig).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Entscheid: TP30 sammelt jedes Credential, das neu gesetzt werden
muss -- nicht nur Rotationen. Das Shelly-Geraetepasswort (TP17.2) ist
eine Erstvergabe und gehoert damit dorthin; ausserdem teilt es sich mit
der PSK-Rotation den Geraete-Durchgang (ein Reboot statt zwei).
- TP17.2-Volltext nach TP30 verschoben (Posten #3), Stub bleibt als
Wegweiser, damit die Nummer nicht ins Leere zeigt
- TP30-Titel/Scope geweitet: "neu setzen & rotieren", mit expliziter
Trennung Erstvergabe vs. Rotation (Prioritaet unterschiedlich,
Arbeitsaufwand identisch)
- Detailabschnitte symmetrisch als "Posten #1" / "Posten #3" benannt
- Querverweise nachgezogen: Naechster-Schritt-Block, Split-Regel,
TP17.3-Abgrenzung, Archiv-Kopfzeile TP17
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Rotationsposten (MikroTik-admin, IoT-PSK, Shelly-Geraetepasswort,
CF-Access-Token) lagen als verstreute Follow-up-Zeilen herum. Der teure
Teil jeder Rotation sind die Konsumenten (HA-Re-Auth x4, Nautobot-Stack-
Redeploy), nicht das Setzen -- einzeln gemacht zahlt man den mehrfach.
Deshalb ein Sammel-TP mit Ausloesekriterium statt Termin.
- 100 Zeilen Radius-/Etappe-1-Detail aus den Follow-ups nach TP30 verschoben
(nicht dupliziert), Follow-ups tragen jetzt einen Zeiger
- Etappe 1 (Service-Accounts ha/nautobot) ist durch; admin ist NICHT rotiert
- Stale: "nach TP17.1 sind es weniger Geraete" -- TP17.1 ist verworfen,
die Geraete bleiben WLAN-Clients, die Rechnung gilt unveraendert
- Handoff 08-24 + Naechster-Schritt-Block als ueberholt markiert
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Einstieg ist die Passwort-Rotation Etappe 2: Nautobot und die vier
HA-mikrotik-Integrationen auf die gestern angelegten Service-Accounts
umhaengen, dann erst admin rotieren. Die Vorarbeit steht komplett, und
das admin-Passwort ist zweimal in ein Transkript geraten -- derselbe
Wert, da alle vier Geraete ihn teilen.
Festgehalten sind ausserdem die beiden Messungen, die vorherige Annahmen
widerlegen (eco_mode hebt die Sendeleistung nicht an; restart_required
auf 14 Geraeten war ein Fehlalarm), der Grund fuer das Verwerfen von
TP17.1, und die Fallen, die man sonst neu erhebt -- darunter die
abweichende s-Nummerierung zwischen HA und Repo, der stale VLAN1-Sweep
in migrate.py und die Regel, nach jedem Shelly-Firmwarewechsel den AP zu
pruefen.
teilprojekte.md zeigt im Ist-Stand jetzt auf diese Uebergabe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vor dem Rotieren den Radius erhoben -- und der ist groesser als geplant:
das Admin-Konto teilen sich fuenf Konsumenten. Neben ~/.secrets und der
MikroMCP-Registry haengen der Nautobot-Stack (Portainer-Redeploy noetig)
und VIER HA-mikrotik-Integrationen mit 40 device_tracker daran. Die HA-
Eintraege melden supports_reconfigure=false, sind also nicht skriptbar.
Christophs Entscheid daraufhin: Konten trennen statt ein Passwort teilen.
Nicht das Rotieren ist das Problem, sondern dass ein einziges admin von
fuenf Stellen benutzt wird -- sonst kostet jede Rotation wieder vier
Re-Auths und einen Stack-Redeploy.
Etappe 1 ist durch, rein additiv, kein laufender Dienst beruehrt. Vorher
existierte auf allen vier Geraeten nur admin in der Gruppe full. Jetzt:
grp-ha read,api,rest-api,test -> user ha
grp-nautobot ssh,read,write,test,sensitive -> user nautobot
Passwoerter als MIKROTIK_HA_PASS / MIKROTIK_NAUTOBOT_PASS in ~/.secrets.
Angelegt ueber ein Skript, das die Werte aus der Datei liest -- bewusst
nicht ueber manage_user, dessen password-Parameter im Transkript landet.
Abnahme auf allen vier Geraeten: ha liest (am Core 59 DHCP-Leases) und
wird beim Schreiben abgewiesen; nautobot kommt per SSH rein und
exportiert. Der Export von nautobot ist byte-identisch zu dem von admin
(391/56/87/87 Zeilen) -- die GC-Compliance driftet beim Umstellen also
nicht, was das Hauptrisiko dieser Etappe war. /user wird von keiner
ComplianceRule abgedeckt, die Konten erzeugen selbst keinen Drift.
Offen: Konsumenten umhaengen (Nautobot-Stack, 4x HA), dann erst admin
rotieren -- danach beruehrt eine Rotation nur noch zwei Dateien.
Eigener Fehler protokolliert: eine Enumeration hat das ap1-Passwort im
Klartext ins Transkript geschrieben. Selber Wert wie der am 22.08.
verbrannte, also keine neue Expositionsklasse -- aber Merkregel ergaenzt,
dass Secrets-Enumeration nur Schluesselnamen ausgibt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Beide von Christoph gemeldeten Geraete sind repariert:
s23 dieleug-wohnzimmer_licht (.203, ProDimmer 2PM)
eco_mode=false, Geraete-AP abgeschaltet
-> beide Lampenausgaenge flackerfrei, Workaround entfaellt
s26 bad_luefter (.233, Gen4 2PM)
eco_mode=false + Reboot
-> Doppeldruck weg
Der diskriminierende Test lief in der im TP vorgesehenen Reihenfolge: erst
eco_mode aus bei weiter aktivem AP (nicht aussagekraeftig, beide Hypothesen
sagen dort dasselbe voraus), dann AP aus -- und genau die Konstellation, die
vorher geflackert hat, blieb stabil.
Weitere Ergebnisse aus dem Sweep ueber alle 22 erreichbaren Shellys:
- Die RSSI-basierte eco-Politik aus TP17 ist damit nicht nur stale, sondern
widerlegt. Der Flotten-Entscheid "eco flottenweit aus" haengt jetzt an
TP17.1, weil er die Sendeleistung von ~20 IoT-Geraeten anhebt und damit
ins Funkbild von TP25 greift.
- restart_required stand auf 14 von 22 Geraeten, nicht auf 2. Entwarnung:
Reboot von s26 mit Config-Vergleich davor/danach -- identisch. Kein Geraet
sitzt auf versteckten Aenderungen.
- Was das Bit gesetzt hat, ist am Geraet nicht rekonstruierbar (169 RPC-
Methoden, Config-Diff, Geraetelog -- alle drei Wege negativ). Nicht erneut
untersuchen.
- eco_mode braucht keinen Reboot; das Geraet antwortet selbst mit
restart_required=false. Eine anderslautende Warnung von mir war falsch.
- AP-Anker-Sweep erledigt: nur s23 hatte einen AP an, kein Rest im Bestand.
- Nebenbefund: alle Shellys ziehen NTP von time.cloudflare.com statt vom
Core -- statische IPs sehen DHCP-Option 42 nie. Betrifft jedes statisch
adressierte Geraet im Netz.
- inventory/bf.csv fuehrt s12 noch auf der alten .41.219.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Uebergabe docs/handoff-20260823-session.md: was die Session war (Doku-Split Punkt F
fertig, dann Shelly-/Funkmigration), womit die naechste anfangen sollte (TP17.3 --
einziger offener Punkt mit spuerbarem Alltagsschaden, von uns verursacht, blockiert
TP17.1), und die Zahlen, die niemand neu erheben muss.
Neu: docs/wifi-access-list-erklaert.md auf Christophs Wunsch ("keine ahnung von tuten
und blasen"). Von Null: was die Liste ist, wo sie unter CAPsMAN lebt, wann sie greift,
was eine Regel matchen kann -- und der eine Satz, der alle Ueberraschungen erklaert:
eine Regel kann nur nein sagen, sie kann kein Geraet irgendwo hinschicken. Dazu die
drei Anwendungsfaelle im Projekt (Signal-Boden, Messen, PSK-Wechsel ohne Flag-Day),
die Governance seit der ComplianceRule und fuenf Merkregeln aus echten Fehlgriffen.
Ausserdem: ein Duplikat von TP17.3 entfernt, das ich beim Anlegen uebersehen hatte --
der Abschnitt existierte bereits und war deutlich gruendlicher (Phasenanschnitt-
Hypothese, Gegenprobe s12, stale eco-Politik, restart_required-Fund). Die
ausfuehrliche Fassung bleibt.
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>
Audit-Trail zum fehlgeschlagenen DTU-Pin. state=rolledback, closed 2026-08-23.
access-list ist wieder leer, Snapshot-Vergleich 0 zu 0 Zeilen, keine offenen
Transaktionen mehr auf crs326-core.
Abnahme am Geraet statt am Job-Status: DTU wieder erreichbar, und die Telemetrie
fliesst -- 385,8 W, Tagesertrag 613, Zeitstempel 14:48. Die Unterbrechung hat rund
zehn Minuten gedauert.
Hinweis fuer spaetere Leser: das reason-Feld der Akte nennt noch die Annahme, ueber
ap2 wandere der DTU-AP auf ch11. Genau die ist widerlegt worden -- das Geraet hat
eine feste Kanalwahl und kann auf ch11 nicht assoziieren. Die Akte bleibt bewusst
unveraendert (sie ist ein Protokoll, kein Dokument); die Aufloesung steht im
Runbook unter "Versuch DTU an ap2 binden -- FEHLGESCHLAGEN".
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>
Nachtrag zum vorigen Commit -- diese drei Aenderungen sind dort durch einen
fehlgeschlagenen Textanker nicht mitgeschrieben worden, nur Runbook und CLAUDE.md
waren drin.
- Zwei Drucker: P750W = Etikettendrucker VLAN30 (stimmte), Brother MFC = der
eigentliche Drucker auf VLAN10, live bestaetigt 10.40.10.6 (OUI Brother,
statisch). Beide Angaben waren richtig, sie meinten verschiedene Geraete.
- s1/s2/s3 sind in HA DEAKTIVIERT, nicht fehlend -- meine Formulierung war falsch.
- Das vollstaendige 2,4-GHz-Bild (Thread 15 / ZHA 20 / Z2M 25 gegen WLAN 1+11)
samt dem einen Konflikt: ZHA ch20 auf der Unterkante von WLAN ch11.
- Der Z2M-Vorbehalt aus 2024 als das, was er ist: die schwerste offene Frage des
Zigbee-Wegs, mit Blast-Radius-Trennung als Mitigation ohne Ursachenkenntnis.
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>
Shelly.CheckForUpdate ueber die Flotte (read-only): stable ist ueberall 2.0.0,
fuer KEIN Geraet gibt es ein stabiles Update; beta waere 2.0.1-beta1 (Build
2026-08-19). Entscheidend ist der alt-Block: fuer die Gen4 liefert Shelly
alternative FUNK-Firmware ueber den normalen Update-Kanal -- S2PMG4ZB, S1PMG4ZB,
PowerStripZB, jeweils "with Zigbee". Gen3 hat keinen alt-Eintrag.
Zwei Folgerungen eingetragen:
- Frueindikator statt Pressemeldungen: eine kuenftige Thread-Variante erschiene
mit hoher Wahrscheinlichkeit genau dort als weiterer alt-Eintrag. Pollen statt
warten.
- Zigbee ist eine Option, die vorher nicht auf dem Tisch lag: erfuellt alle drei
Ziele von TP17.1 (raus aus dem WLAN, Mesh, Funkruhe), heute, mit
Hersteller-Firmware, ohne Garantieverlust und ohne UART-Backup -- und
Zigbee2MQTT laeuft bereits als LXC 112. Offene Pruefpunkte notiert, u.a. dass
Zigbee und WLAN sich 2,4 GHz teilen (Kanalplanung gegen ap1 ch1 / ap2 ch11).
Presselage korrigiert: Shellys offizielle Linie ist "wird evaluiert", nicht
"angekuendigt", Engpass ist der Flash-Platz. Die Thread-Firmware, die im Mai 2026
durch die Presse ging, ist die Dritt-Firmware.
Reihenfolge revidiert (User): PSK-Rotation und Funk-Umstellung laufen PARALLEL.
Der Passphrase-Override je MAC macht den Flag-Day ueberfluessig; die Reihenfolge
war nie technisch noetig, nur oekonomisch.
HA-Gegencheck: genau ein Shelly ist offline (s4 kueche_mikrowelle, RSSI -93),
deckungsgleich mit dem Netz-Sweep. s1/s2/s3 (weihnachten) existieren in HA gar
nicht -- sie kommen beim naechsten Einstecken mit dem alten PSK.
Drucker: NICHT stillschweigend auf VLAN10 geaendert. Das Geraet sagt VLAN30
(Reservierung 10.40.30.5 auf dhcp-v30, ARP vlan30, derzeit aus, last-seen 3d15h),
CLAUDE.md sagt seit 08-08 dasselbe. Als offener Klaerungspunkt notiert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ergebnis der read-only-Recherche-Session, hier gegengeprueft und in die kanonische
Doku uebernommen.
Der PSK in docs/teilprojekte-archiv.md (TP17) ist NOCH der live konfigurierte --
verifiziert am Manager per Fingerprint (Laenge + drei Zeichenpaare) statt im
Klartext, damit der Wert nicht ein zweites Mal in einem Transkript landet. Das ist
zugleich die Merkregel: Uebereinstimmung prueft man mit Stichproben, nicht durch
Ausgeben.
User-Entscheid: Historie belassen, im Nachtrag dokumentieren -- kein filter-repo.
Traegt, weil es genau eine getrackte Fundstelle gibt, drei Commits, Remote nur
gitea.emsenhuber.net und einen einzigen lokalen Klon; der Wert hat die eigene
Infrastruktur nie verlassen. Der wirksame Schritt ist die Rotation, und die bleibt
hinter TP17.1.
Blast radius selbst nachgemessen (crs326-core, read-only), Peer-Zahlen bestaetigt:
26 der 27 WLAN-Clients des gesamten Netzes haengen auf dirtyvader-iot (main 1,
media/untrusted/guest je 0), VLAN30 fuehrt 41 Leases/Reservierungen (5 bound).
Neben den ~26 Shellys: P750W, Airfryer, SwitchBot, Twinkly, DTUBI, SONOFF-NSPanelPro,
ein iPhone.
Damit praezisiert sich TP17.1: nach zehn migrierten Gen4 blieben grob 16 Geraete
auf dem IoT-SSID, nicht 12 -- der Funkruhe-Effekt ist real (-38 % Clients), der
PSK-Effekt nur halb. Die Reihenfolge-Entscheidung bleibt richtig, ihre Begruendung
wird ehrlicher.
Zwei Umsetzungshinweise fuers spaetere Rotations-Paket festgehalten: migrate.py hat
kein Rotate-Kommando, und ein Flag-Day ist vermeidbar ueber Passphrase-Overrides je
MAC in /interface wifi access-list -- was dem TP25-Befund "keine access-list"
nebenbei einen Zweck gibt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Entscheid 2026-08-23: das IoT-WLAN-Passwort bleibt vorerst wie es ist.
Stattdessen zuerst die Shelly Gen4 auf Matter over Thread umstellen; danach
haengen deutlich weniger Geraete am WLAN und die Rotation wird billig. Damit ist
die Rotation NACHFOLGER von TP17.1, nicht mehr eigenstaendiger Follow-up.
TP17.1 stand seit 2026-07-11 als Projektion im (inzwischen archivierten) TP17.
Es hat jetzt wieder offene Arbeit und steht deshalb nach der eigenen Split-Regel
wieder vorne in teilprojekte.md. Umsetzung liegt im HA-Projekt:
~/dev/ha-xstate/docs/shelly-gen4-thread-migration.md
Bestand live gesweept (mcp/shelly/discover.py, read-only, VLAN30): 22 von 26
erreichbar -- 12 Gen4, 8 Gen3, 2 Gen2, alle fw 2.0.0. Nicht erreichbar: s1/s2/s3
(saisonal) und s4 kueche_mikrowelle (RSSI -93).
Recherchiert und als Praemissen-Korrektur eingetragen: Shelly unterstuetzt Matter
over Thread OFFIZIELL NICHT und plant es nicht -- Gen4 kann offiziell nur Matter
over WiFi, was hier nutzlos waere (Geraet bliebe im WLAN, braeuchte den PSK
weiter). Thread nur ueber Dritt-Firmware; das brauchbare Projekt deckt 10 der 12
Geraete ab (Plug S Gen4 faellt raus), kostet Garantie + Shelly-Cloud und hat als
Rueckweg nur ein UART-Vollbackup je Geraet. Selbst bei vollem Erfolg blieben 12
Geraete im WLAN -- Gen3 hat kein 802.15.4 und kann nie folgen.
Nebeneffekt fuer TP12.1: je mehr Thread-Geraete kommen, desto oefter zahlt man
den -infra-SSID-Umweg beim Commissioning. Das ist das erste Argument fuer TP12.1,
das nicht an einem einzelnen Fuehler haengt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Getrennt nach ZUSTAND, nicht nach TP (der Vorschlag "1 MD pro Teilprojekt"
haette ~35 Dateien ergeben und genau die Querbezuege zerschnitten, die das
Dokument wertvoll machen -- Reihenfolge, Abhaengigkeiten, "TP23 haengt an TP5
in beide Richtungen"):
- docs/teilprojekte.md = Rahmen + kritischer Pfad + 16 OFFENE TPs
- docs/teilprojekte-archiv.md = 34 abgeschlossene TPs, Volltext + Inhaltsverzeichnis
Zuordnungsregel steht in beiden Dateien und in CLAUDE.md: ein TP wandert erst
dann ins Archiv, wenn nichts mehr daran zu tun ist. Wo nur ein Sub-TP offen
war, blieb dieses vorne (TP17.2 <-> TP17, TP20.1 <-> TP20).
TP25 von 393 auf ~100 Zeilen kondensiert: Stand, Offenes (Fund F, die
20-MHz-Entscheidung) und die Merkregeln bleiben vorne, die Langfassung liegt
unveraendert im Archiv (#tp25-lang) -- ein guter Teil ihres Werts steckt in den
widerlegten Erklaerungen, die zeigen, welche Wege schon abgelaufen sind.
Kein Inhalt verloren: maschinell gegengeprueft, von 2218 Originalzeilen tauchen
alle wieder auf bis auf 7 bewusste Korrekturen.
Drift, der beim Aufraeumen aufgefallen ist (dieselbe Klasse wie die 08-18-Lehre,
dass der Ist-Stand-Block zuletzt nachgezogen wird):
- Compliance im Ist-Stand war einen Tag alt: 100/100 bei 25 Rules -> live gegen
die Nautobot-API geprueft 104/104 bei 26 Rules, 0 Drifts
- VLAN-Tabelle trug immer noch "Public-IP an ap1" -> crs326-core (Rest aus
Punkt C, den vier Durchgaenge uebersehen haben, weil er in einer Tabellenzelle
steckt und nicht in einem TP-Absatz)
- die DOCSIS-Erklaerung aus dem TP6-Abschluss stand im kritischen Pfad noch als
Begruendung, obwohl TP6.1 sie am selben Tag widerlegt hat -> datierter Nachtrag
Live gegengeprueft statt abgeschrieben: crs326-branch traegt keine
192.168.88.x-Adresse mehr, damit ist der letzte offene Aufraeum-Punkt aus TP21.1
geschlossen und das TP durfte ins Archiv.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
