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>
Christophs Anstoss vom 2026-08-23 festgehalten, damit er die separate Doku-Session
erreicht statt im Sitzungskontext zu verfallen.
Empfehlung mit Zahlen: nach ZUSTAND splitten (offen / Archiv), nicht 1 MD pro TP.
1071 der 2205 Zeilen sind abgeschlossene TPs, TP25 allein 393. Ein Schnitt pro TP
waeren ~35 Dateien und wuerde das Versprechen aus CLAUDE.md brechen ("kein anderer
Kontext noetig") -- er zerstoert die teuerste Eigenschaft der Datei, um ihr
billigstes Problem zu loesen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christophs Einwand beim TP6-Abschluss war berechtigt, und er kippt die Erklaerung,
die ich einen Tag lang vertreten habe.
ABNAHME (gleiche NAS-Last, gleicher Messclient, Kontrolle inklusive):
Priorisierung aus 40,8 ms avg / 53,4 max
Priorisierung an 11,0 ms avg / 14,6 max -73 %
Die Last war echt, nicht behauptet: wan-up-total fuhr 9,0 Mbit (max-limit greift
exakt), wan-up-bulk 8,87 Mbit mit 1581 Drops, vlan100 tx 9,0 Mbps. Die Kontrolle
mit abgeschalteter Markierung war noetig, um auszuschliessen, dass die Verbesserung
bloss daher kommt, dass Bulk und Ping jetzt von verschiedenen Hosts stammen.
KORREKTUR AN TP6: dort steht, die 30 ms entstuenden im DOCSIS-Uplink und seien
unabaenderlich. Das ist widerlegt. Der Fehler lag in der METHODE dieser Messung:
Bulk und Messverkehr kamen vom SELBEN Host, also gab es fuer CAKEs triple-isolate
nichts zu trennen -- alles lag in derselben Klasse, und Shapen allein aendert keine
Reihenfolge. Was CAKE nicht schaffte, schafft explizite Klassentrennung.
TP6 traegt jetzt einen Warnhinweis und ist als Messprotokoll zu lesen, nicht als
Ursachenanalyse. Weiter gueltig bleibt: CAKE als EINE Queue ueber allem brachte
nichts (dreimal gemessen), und Interface-HTB ist auf diesem Geraet tot.
GEBAUT (Template [11a], via GC):
2x mangle postrouting (VOR src-nat -- nur dort ist die LAN-Quelle sichtbar):
NAS 10.40.20.10 -> bulkup, alles andere -> restup
wan-up-total (parent=global, max-limit=9M)
wan-up-rest priority=1 limit-at=6M
wan-up-bulk priority=8 limit-at=1M
Drei Entscheidungen, begruendet im Template:
- Prioritaet statt Cap: ein Limit haette die NAS auch nachts gebremst und
Bandbreite verschenkt (DSM drosselt nicht, User-bestaetigt). limit-at=1M
sorgt dafuer, dass der Sync nie ganz verhungert.
- src-address=10.40.20.10, NICHT VLAN20: dort haengen auch HA, Nautobot, pve.
- parent=global, nicht vlan100: Interface-HTB ist hier wirkungslos.
GOVERNANCE: ComplianceRule ip-firewall-mangle angelegt (ingest-mangle-rule.py),
config_ordered=True -- die NAS-Regel muss vor dem Catch-all stehen, sonst waere die
Priorisierung STILL wirkungslos. 26 Rules x 4 Geraete = 104 Checks, 104/104 gruen.
Formatfalle nebenbei: priority=8 ist Default und wird von /export weggelassen --
explizit im Template erzeugt es Dauer-Drift, bei dem das Geraet recht hat.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Abschluss wie entschieden. CAKE-Queue vom Geraet entfernt, Template-Abschnitt [11]
bleibt als BEGRUENDET LEER stehen: er traegt jetzt die Messreihe und die zwei
Fallen, damit der naechste QoS-Gedanke nicht bei null anfaengt.
ohne CAKE 42,4 ms | 88 % 43,3 | 73 % 44,0 | 52 % der Linerate 44,6 (idle 12,9)
Die ComplianceRule `queue` BLEIBT und bewacht den Abschnitt weiter -- als leer.
Das ist derselbe Gedanke wie bei wifi-access-list: ein leerer Soll-Zustand ist
eine Aussage, kein fehlender Eintrag. 100/100 compliant, keine Drifts.
NEU: TP6.1 -- Saettigung vermeiden statt Bufferbloat bekaempfen.
Christophs Einwand beim Abschluss ("dann koennten wir zumindest den Sync von der
NAS zurueckhalten") trifft eine echte Luecke im TP6-Urteil: die 30 ms Zusatzlatenz
sind nicht wegzushapen, aber sie treten NUR unter Saettigung auf -- im Leerlauf
misst dieselbe Strecke 12,9 ms. Ein NAS-Sync, der bei laufendem Call zurueckweicht,
haelt die Leitung aus der Saettigung. Das ist eine groessere Verbesserung, als
Bufferbloat-Bekaempfung hier je gebracht haette.
Entwurf steht als TP6.1, bewusst NICHT gebaut:
- Global-HTB (in TP6 als wirksam bewiesen) + zwei Prioritaetsklassen
- Prioritaet statt hartem Cap: nimmt dem Sync die Bandbreite nur, solange
jemand anders sie braucht
- src-address=10.40.20.10, NICHT ganz VLAN20 -- dort haengen auch HA, Nautobot
und pve, die nicht pauschal hinten anstehen sollen
- Vorbedingung: /ip firewall mangle steht unter KEINER ComplianceRule
- Abnahme misst den Call, nicht die Queue
- und zuerst pruefen, ob der Fall ueberhaupt auftritt oder DSM schon drosselt
Kritischer Pfad: LEER. deny-by-default steht, Golden Config steht, WLAN steht,
VLAN1 ist weg, TP6 ist beantwortet statt offengelassen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Korrigiert den Befund von heute Nacht. Der stand so nicht richtig da.
WAS FALSCH WAR: "der CRS326 fuehrt keine Software-Queue". Die These stuetzte sich
auf zwei eigene Testfehler und ist widerlegt. ipv4-fast-path-active=no und
fasttrack-packets=0 belegen sogar, dass die CPU jedes Paket im Slow Path sieht --
die Hardware war nie die Grenze.
WAS RICHTIG IST (MikroTik-Doku, woertlich): "Interface HTB will not work correctly
when the out-interface is hardware offloaded and the bridge Fast Path is not
active." Das war die Ursache der wirkungslosen Queue auf parent=vlan100. Ueber
parent=global + mangle mark-packet funktioniert CAKE einwandfrei:
6.040.563 Bytes gezaehlt
cake-bandwidth=7000000 -> Durchsatz faellt 9,3 auf 7,78 Mbit
Sie zaehlt UND drosselt. Es scheitert nicht am Bau.
Die zweite "Gegenprobe" von heute Nacht war ebenfalls untauglich: Simple Queue auf
10.40.0.0/16 laeuft im Postrouting NACH src-nat, wo die Quelle laengst die WAN-IP
ist. Sie konnte nie matchen und bewies nichts.
DER BEFUND, DER TP6 BEENDET -- A/B, gleicher Client, Minuten auseinander:
ohne CAKE 42,4 ms
CAKE 8,5 Mbit (88 %) 43,3 ms
CAKE 7 Mbit (73 %) 44,0 ms
CAKE 5 Mbit (52 %) 44,6 ms (idle 12,9 ms)
Selbst bei halber Linerate keine Verbesserung -- und dort MUSS die Warteschlange im
Router liegen. Die ~30 ms entstehen stromabwaerts im Arris/DOCSIS-Uplink, wo
Request/Grant-Scheduling auf MAC-Layer sitzt und gar keine Queue ist. Das kann kein
Shaper im Router beheben. Die max-Werte steigen mit haerterer Drosselung
(53 -> 94 -> 148 ms): die eigene Queue waechst, die DOCSIS-Latenz bleibt.
EMPFEHLUNG: TP6 schliessen. Nicht mangels Nutzen, sondern weil das Werkzeug nicht an
die Ursache reicht -- ein staerkeres Ergebnis als das "marginal" von 2026-06-16.
Weder hw-offload opfern noch Chip-QoS ist noetig; der Global-HTB-Weg braucht beides
nicht. Es lohnt nur nicht.
Am Geraet steht weiterhin die wirkungslose Interface-Queue (qos-wan-up), in der SoT
und compliant, aber ohne Funktion -- markiert, gehoert beim Abschluss entfernt.
Alle Testaenderungen liefen als Transaktion, alle zurueckgebaut, 100/100 compliant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Entscheidung dieser Sitzung war "bauen statt schliessen". Gebaut ist es. Das
Ergebnis stellt TP6 aber neu: die Queue steht, ist compliant, und tut nichts.
DREI BELEGE AM GERAET, unabhaengig voneinander:
/queue tree nach 6 MB echtem Client-Upload -> 0 Bytes
Simple Queue auf 10.40.0.0/16 (Gegenprobe) -> 0 Bytes
Upload gegen cake-bandwidth=8.5Mbps -> 9,48 Mbit
Der dritte ist der harte. Ein Zaehler auf 0 laesst sich als Anzeigeproblem
wegerklaeren, ein Durchsatz UEBER dem gesetzten Limit nicht.
URSACHE (sehr wahrscheinlich, nicht abschliessend bewiesen): CRS326 mit
Marvell-98DX3236. Bridge faehrt hw-offload, alle Ports only-hardware-queue,
Bridge-Interface no-queue. Der Switch-Chip serialisiert, nicht die CPU. Dass
l3-hw-offloading=no ist, widerspricht dem nicht: die CPU routet (Firewall zaehlt
32,9 Mio Pakete), aber sie serialisiert nicht.
WAS BESTAND HAT -- die ComplianceRule `queue`:
- nautobot/ingest-queue-rule.py (idempotent, Dry-Run default)
- match_config = "/queue type\n/queue tree"; /queue interface bewusst NICHT,
das traegt nur die Default-Portzuordnung und hat mit QoS nichts zu tun
- Wirksamkeit bewiesen, nicht behauptet: erst 99/100 mit exakt der fehlenden
Queue als `missing`, nach dem Deploy 100/100, 0 Drifts
- Zaehler jetzt 25 Rules x 4 Geraete = 100 Checks
Damit ist dieselbe blinde Stelle zu, die TP26 fuer /ip firewall filter geschlossen
hat -- und zwar VOR der Queue, wie Runbook 4.1 es verlangt.
ZWEI DESIGN-ENTSCHEIDUNGEN, die im Template begruendet stehen:
- nur die Senderichtung: der Download liegt mit +23..28 ms UNTER der
3-Schwelle und ist nach demselben Kriterium Fall A
- parent=vlan100 statt target=10.40.0.0/16: eine Simple Queue aufs LAN-Supernetz
haette Inter-VLAN (NAS <-> MAIN, geroutet ueber dieselbe CPU) mitgedrosselt
VIER SACKGASSEN, dokumentiert in ref_crs326_keine_software_queue:
1. active-queue=queue-tree heisst nur "verdrahtet", nicht "wirksam"
2. parent=global OHNE packet-mark faengt per Definition nichts
3. target=0.0.0.0/0 wird stillschweigend zu target="" verworfen
4. router-eigener Verkehr durchlaeuft die Queues nicht -- Test-Pings vom Router
beweisen nichts, es braucht einen echten LAN-Client
Zwei davon sahen wie Hardware-Befunde aus und waren eigene Testfehler.
FORMATFALLE: RouterOS exportiert 8.5Mbps statt 8500000 und schiebt eine eigene
Hinweiszeile vor die Tree-Zeile, wodurch der Backup-Normalisierer /queue tree
nicht abflacht. Template baut beides nach -> 100/100.
Alle Testaenderungen liefen als Config-Transaktion und sind zurueckgebaut; keine
Akte offen. Die wirkungslose Queue bleibt vorerst am Geraet und in der SoT --
dokumentiert, nicht als aktives QoS misszuverstehen -- bis ueber die drei Wege
entschieden ist (hw-offload opfern / Chip-QoS ohne CAKE / TP6 schliessen).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
/interface wifi access-list stand unter KEINER ComplianceRule. Eintraege dort
erzeugten keinen Drift und liessen sich nicht als Config-Transaktion fuehren --
gc-transaktion.py verlangt eine ComplianceRule als --scope. Seit dem 22.8. ist
das nicht mehr theoretisch: docs/tp25-pin-s22.sh schreibt bei jedem Messrundgang
Regeln dorthin, und TP25 Fund E (signal-range-Boden) wuerde dauerhaft genau in
diesem blinden Fleck landen.
- nautobot/ingest-wifi-access-list-rule.py (idempotent, Dry-Run default)
- Template-Abschnitt [6c], bewusst NUR Kommentare: der Soll-Zustand ist LEER,
und das ist die Aussage. Die intended config gewinnt keine wirksame Zeile.
Nach bf-golden-config gepusht (51c11f0), Repo-Sync SUCCESS.
ZWEI KORREKTUREN AN DER AUFGABENSTELLUNG:
1. Der Zaehler geht auf 96, nicht auf 94. Die Regeln gelten PLATTFORMWEIT, nicht
geraetespezifisch -- 92 Checks waren exakt 23 Rules x 4 Geraete, jetzt sind es
24 x 4. Die Annahme "2 geraete-relevante Checks" war falsch.
2. Vor Beginn stand bereits ein Drift in der Anzeige (bridge-vlan auf
crs326-core, ether3 als Trunk), obwohl der Sideboard-Rollback am 08-22
gelandet war. Das Geraet war live korrekt -- die Compliance vergleicht gegen
das letzte BACKUP, und das war aelter als der Rollback. Mit dem Refresh weg.
WIRKSAMKEIT BEWIESEN, nicht behauptet (TP22-Regel "Job-Status ist kein
Wirksamkeitsnachweis"):
96/96 compliant, 0 Drifts
-> Test-Eintrag mit nicht existierender MAC (kein echter Client betroffen)
-> 95/96, extra = exakt diese Zeile bei crs326-core | wifi-access-list
-> Eintrag entfernt -> 96/96, 0 Drifts
Zusaetzlich: gc-transaktion.py akzeptiert --scope wifi-access-list.
Ausserdem geprueft: 4 Compliance-Datensaetze (einer je Geraet), und der
[6c]-Block steht wirklich in der intended config von crs326-core.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TP25 hat den Pfad seit dem 08-20 blockiert und ist im Kern durch -- die
Terrasse ist repariert, Fund E abgestuft. Der TP25-Header und der Abschnitt
"Kritischer Pfad" sagten beide noch das Gegenteil und sind nachgezogen.
Neu: docs/handoff-20260822-naechste-schritte.md -- fuenf zugeschnittene
Sessions, jede mit frischem Kontext arbeitsfaehig:
1. TP6 bauen ODER begruendet schliessen. Diese Session MISST NICHT, sie
entscheidet: formal Fall B (+28..47 ms), aber durch sechs Lastphasen mit
laufendem Videocall kein einziger Problem-Klick. Wenn gebaut wird, erst
/queue ins GC-Template plus ComplianceRule, dann die Queue, dann A/B.
2. Admin-Passwort der vier MikroTik rotieren. Vorbedingung ist erledigt --
kein sshpass -p mehr im Repo.
3. TP25 abschliessen: Fund F messen (am MANAGER, die AP-Tabellen sind unter
CAPsMAN leer) + Entscheidung 5 GHz auf 20 MHz.
4. ComplianceRule fuer /interface wifi access-list -- seit tp25-pin-s22.sh
nicht mehr theoretisch.
5. Der Rest ohne Rangfolge (TP12.1 mit zwingender Reihenfolge v6-Firewall
VOR Adressen, TP16.3, TP24, TP20.1, ...).
Dazu eine Werkzeugtabelle, damit niemand neu baut, was schon existiert, und
die drei Fallen dieser Sitzung, die wiederkommen werden: dynamische
cap-wifiN-Nummern, abgewiesene Verbindungsversuche die wie Funkloecher aussehen,
und dreimal Anzeige-statt-Wirkung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Erster Lauf mit beiden Ping-Strecken (23:30-23:41, per Stopp-Knopf beendet).
TERRASSE, die Frage des Aufbaus:
2026-08-21, ap2 tief: 43 % Verlust, laengste Luecke 20,4 s, -72 dBm
2026-08-22, ap2 auf 2,5 m: 9 % Verlust, laengste Luecke 1,0 s, -69,0 dBm
Gleiches Geraet, gleiche Rolle. 1,0 s liegt unter der Hoerbarkeitsschwelle im
Videocall. Der Dead Spot, der TP25 seit dem 08-20 getragen hat, ist weg.
STRUKTURBEFUND: die Referenz hat in 17 von 21 Raumabschnitten 0 % Verlust --
die Alltagsabdeckung ist ueberall in Ordnung. Der Gegen-AP traegt dagegen fast
nirgends: Schlafzimmer -84,6/38 %, Bad -82,3/24 %, Kueche -82,0/23 %, Terrasse
-78,7/19 %. Faellt ein AP aus, ist die halbe Wohnung "verbunden, aber tot".
Ein dritter AP kaufte damit REDUNDANZ, keine Abdeckung -- nach Christophs
eigener Randbedingung derzeit nicht begruendet.
KORREKTUR zum 22:43-Lauf: "die Kueche ist ein Loch fuer beide APs" gilt nur
fuer die aeusserste Ecke. Hier hat die Referenz in der Kueche 1 % Verlust bei
-71 dBm. Der Unterschied ist der Weg -- der Vorlauf ging ausdruecklich allen
Waenden entlang in die totesten Winkel. Beide Aussagen gelten, sie messen
verschiedene Orte.
Fund E weiter abgestuft: der Sticky-Client vom 08-20 reproduzierte sich nicht
(Treppe: sauberer Wechsel ap2/5G -> ap1/5G, 0 % ueber 57 s). Nicht umsetzen,
bevor ein Sticky-Fall erneut gemessen ist. Ein Lauf widerlegt Fund B nicht,
er zeigt nur, dass es nicht der Normalfall ist.
WERKZEUG: die Auswertung wies die groesste Sonden-Luecke auf der Treppe als
"⚠️ eher Ruhezustand" aus (4,6 s). Das war unser eigener Eingriff -- um
23:35:10 wechselte der Pin, das S22 war 23:35:12-16 abgemeldet. Ein Artefakt
als "Geraet war erreichbar, wollte nur nicht" zu beschriften ist doppelt
falsch. Pin-Wechsel werden jetzt erkannt und als solche benannt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Auswertung liest jetzt beide Geraete und stellt sie je Raum untereinander:
REFERENZ (iPhone, frei) was du an dieser Stelle wirklich hast
SONDE (S22, Gegen-AP) was die Rueckfallebene noch leisten koennte
Damit faellt der Terrassen-Vergleich beim naechsten Lauf von selbst raus, und
die Lesart wird eindeutig: gute Referenz + schlechte Sonde = alles haengt an
EINEM AP; beide schlecht = echtes Loch ohne Rueckfallebene (der Kuechenfall).
Rueckwaertskompatibel: Laeufe ohne walk-ping-iphone.csv/beide-telefone.csv
laufen einspaltig weiter und liefern fuer den Lauf vom 22.8. Ziffer fuer Ziffer
dieselben Zahlen wie vorher. Das Geraet heisst dort "Geraet" -- welches es war,
steht in den Dateien nicht, also wird es auch nicht behauptet.
Drei Fehler, die der Abnahmetest zutage foerderte und die alle den naechsten
Rundgang gekostet haetten:
1. Die Gegen-AP-Automatik war nach dem Start AUS. Wer den Klick vergisst, geht
die ganze Runde mit beiden Telefonen auf DEMSELBEN AP -- im Test genau so
passiert. tp25-runde.sh schaltet sie jetzt scharf; /auto nimmt dafuer ?an=1
(ein Toggle waere falsch: bei schon laufender Konsole haette der Start sie
ausgeschaltet).
2. "Funk da, aber keine einzige Ping-Antwort" erschien als "—", also wie eine
Datenluecke. Beim Test lag das iPhone gesperrt auf dem Tisch: angemeldet mit
-47 dBm und trotzdem stumm. Wer das als Luecke liest, sucht danach ein
Funkloch, das es nicht gibt. Jetzt: "keine Antwort" + "⚠️ Display gesperrt?".
3. Der Aufraeumer meldete "AP-Pin geloest", und danach standen die Regeln
trotzdem am Core. Wettlauf: er loeste den Pin, waehrend die Konsole noch
lief, und deren Automatik setzte ihn binnen zwei Sekunden wieder. Das
Telefon waere nach JEDER Runde gepinnt geblieben. Jetzt erst Konsole toeten,
dann Pin loesen.
Zuletzt: tp25-pin-s22.sh laeuft auf sshpass -e. Damit steht das Router-Passwort
in keiner Kommandozeile mehr -- `grep -rn "sshpass -p" docs/ nautobot/` findet
nur noch die Erwaehnung in teilprojekte.md. Die Rotation kann jetzt kommen.
Abnahme (mehrere echte Laeufe): Automatik meldet EIN, beide Telefone stehen auf
verschiedenen APs, beide werden gepingt, ein Klick auf Stopp beendet alles,
Pin danach "off", kein Prozess uebrig.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Maengel aus dem Rundgang vom 22.8. behoben.
1. STOPP-KNOPF. Die Konsole nannte "⏹ Aufzeichnung stoppen", es gab ihn nicht.
Christoph drueckte "Call beendet" und den Not-Aus -- beide schreiben nur
Marken -- und die Messung lief weiter, waehrend der Core sein Telefon mit
5 Pings/s bearbeitete. Jetzt legt der Knopf stop.flag ab, und die
Warteschleife des Messskripts bricht darauf ab.
2. ZWEITES TELEFON. Der Beobachter las immer schon beide Geraete, hielt die
Zahlen aber nur im Speicher fuer die Anzeige. Da das S22 per Automatik
immer auf dem GEGEN-AP sitzt, fehlte damit ausgerechnet die Strecke, die
die Alltagsabdeckung zeigt -- der Terrassen-Vergleich war nicht zu fuehren.
Jetzt: zweiter Ping (walk-ping-iphone.csv) und beide-telefone.csv im
2-s-Takt mit iface + Signal je Geraet.
Beim Testen kamen zwei Fehler ans Licht, die den naechsten Lauf gekostet
haetten:
- `PINGER=$(ping_lauf ...)` blockiert. Die Kommandosubstitution wartet, bis die
stdout-Pipe schliesst, und der Hintergrundjob darin haelt sie offen. Das
Skript stand in dieser Zeile, der zweite Ping wurde nie gestartet -- und es
sah von aussen aus wie ein normal laufender Lauf. Die Funktion laeuft in der
aktuellen Shell, also liefert $! danach die richtige PID.
- `kill $SAMPLER` traf nur den Wrapper. Dessen Subshell samt SSH-Sitzung wurde
dabei verwaist und lief weiter: nach dem Stopp hielt der Core stumm eine
Sampler-Sitzung offen. Wer den Vater zuerst killt, verliert den Zugriff auf
die Kinder -- jetzt killbaum(), Kinder zuerst.
Mitgenommen von der Rotationsliste: tp6-monitor-core.sh und der Ping in
tp25-walk-messung.sh laufen jetzt ueber `sshpass -e` statt `-p`. Damit steht
das Router-Passwort in keiner Kommandozeile mehr. `pgrep -fl "sshpass -p"`
ist leer. Offen bleibt tp25-pin-s22.sh.
Abnahme: Lauf gestartet, beide Ziele gepingt (10.40.10.178 + .196), ein Klick
auf den Stopp-Knopf, danach kein Prozess und keine SSH-Sitzung mehr uebrig,
Pin geloest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Erster Lauf mit der Gegen-AP-Automatik: iPhone frei roamend, S22 automatisch
auf den jeweils anderen AP gezwungen. Gemessen wird damit nicht die
Alltagsabdeckung, sondern die RUECKFALLEBENE. Christoph ist bewusst allen
Waenden entlang in die totesten Winkel gegangen -- Worst Case je Raum.
Messguete: 22 von 784 Funkproben nicht angemeldet (2,8 %). Die befuerchteten
Abweisungs-Artefakte des Pins sind praktisch ausgeblieben, die Verluste sind
echte Funkschwaeche.
HAUPTBEFUND: In der Kueche fallen BEIDE APs gleichzeitig aus, unabhaengig
voneinander belegt.
S22 auf ap2: 57 % Verlust ueber 2 min, laengste Totzeit 24 s, dabei
durchgehend ANGEMELDET bei -79..-87 dBm und staendig
zwischen 5 und 2,4 GHz springend -- "verbunden, aber tot".
iPhone auf ap1: 22:51:37 "disconnected, connection lost" bei -76 dBm,
89 Sekunden komplett weg, wieder da erst beim Verlassen
des Raums.
Es gibt dort also keine Rueckfallebene. Das ist schlimmer als alles vom 08-21.
Terrasse: Anzeichen einer Verbesserung nach dem Anheben von ap2 (kein
Verbindungsabbruch statt 43 % Verlust am 08-21), aber NICHT bewiesen -- der
Ping lief nur auf das S22, und das war dort auf ap1 gezwungen. Belegt ist
dagegen Fund C: vier Bandwechsel in 49 s auf ap2, nach der Hoehenaenderung,
mit aktivem 802.11k/v und FT.
Folge fuer Fund E: ein signal-range-Boden steuert auf den besseren AP -- den
gibt es in den Problemraeumen nicht (ap2 liefert im UG -80..-86). Fund E hilft
auf der Treppe, nicht gegen den Dead Spot. Bleibt richtig, ist aber nicht mehr
die Antwort.
Zwei Werkzeugmaengel, die der Lauf aufdeckte und die noch offen sind:
kein Stopp-Knopf (die Aufzeichnung lief nach dem Ende weiter, der Core pingte
mit 5/s), und die iPhone-Zeitreihe wird nicht mitgeschrieben -- nachtraeglich
liess sich nur das Roaming-Log am Manager sichern.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs/tp25-runde.sh startet Konsole und Messung zusammen, friert die AP-Karte
ein, sagt die vom Interface GELESENE Adresse fuers Telefon an und loest beim
Beenden den Pin. Grund: beide Einzelteile hatten als Standard-Laufverzeichnis
einen Pfad in ein Sitzungs-Scratchpad -- wer sie ohne die passende
Umgebungsvariable startete, mass in ein totes Verzeichnis und merkte es erst
bei der Auswertung.
Der Probelauf hat dabei sofort einen Fehler in der eigenen Anzeige aufgedeckt:
die Seite meldete "✅ beide angemeldet, auf verschiedenen APs", waehrend beide
Telefone auf ap2 hingen. Das Kriterium prueft "beide angemeldet" -- nicht, ob
sie auf VERSCHIEDENEN APs sitzen. Das ist ein gruenes Licht fuer einen
Messpunkt, den es nicht gibt: Piep, weitergehen, kein Gegen-AP gemessen.
Wieder dieselbe Klasse wie der 14-h-Ausfall -- Anzeige geprueft statt Wirkung.
Jetzt vier Zustaende, gegen sechs Faelle geprueft (inkl. "gleicher AP, anderes
Band" -> zaehlt NICHT):
bereit verschiedene APs -> Piep, weitergehen
wird nachgezogen gleicher AP, Automatik -> warten
kein Gegen-AP gleicher AP, ohne Auto -> Warnung statt gruen
S22 sucht S22 nicht angemeldet -> stehenbleiben
teilprojekte.md: Passwort-Rotation als offener Follow-up eingetragen (User:
"machen wir, aber erst spaeter") -- inkl. der noch offenen sshpass -p in
tp6-monitor-core.sh und tp25-pin-s22.sh, die vorher nachgezogen gehoeren.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beim Bauen der Gegen-AP-Automatik fiel auf, dass die feste AP-Tabelle in
server.py und tp25-gehweg-auswertung.py nicht zum Live-Zustand passt: heute
sind cap-wifi1/2 = ap2 und cap-wifi3/4 = ap1. Der Manager vergibt die Nummern
dynamisch beim Anmelden der CAPs; ap1 hat sich beim Rueckbau auf ether15 neu
angemeldet.
Der erste Schluss daraus war voreilig ("die alten Auswertungen sind
falsch beschriftet"). Die Gegenprobe widerlegt ihn: mit der HEUTIGEN Karte
haette Technik OG am 08-21 von ap1 mit -43 dBm versorgt worden sein -- in dem
Raum, in dem ap2 steht. Die alte Tabelle war zu ihrer Zeit also richtig und
ist erst durch das Umstecken falsch geworden.
Konsequenz, und das ist der eigentliche Fix: eine live nachgeschlagene Karte
auf alte Daten anzuwenden ist nicht die Loesung, sondern derselbe Fehler mit
umgekehrtem Vorzeichen. Die Zuordnung gehoert zum Messzeitpunkt.
- tp25-walk-messung.sh friert sie als ap-map.txt im Laufverzeichnis ein.
- tp25-gehweg-auswertung.py nimmt ausschliesslich diese Datei. Fehlt sie
(alle Laeufe vor heute), bleiben die rohen cap-wifiN stehen, mit lauter
Warnung -- unbeschriftet ist ehrlicher als falsch beschriftet.
teilprojekte.md: TP25 um den Werkzeug-Fund, den neuen Messaufbau (eine Runde
statt zwei) und den Pausenstand ergaenzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Mit dem Gating der Call-Buttons wurde der Hinweis "Erst den Treiber starten
lassen" zur Sackgasse: ohne Treiber gibt es keinen Start-Button mehr. Er sagt
jetzt, was ohne Treiber SEHR WOHL geht (Raeume, AP-Pin) und wie man die
Ping-Aufzeichnung dazuholt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christophs Einwand, und er hat recht: wer in ap2-Zone losgeht und das S22
auf ap2 pinnt, misst dort dasselbe, was das frei roamende iPhone ohnehin
liefert. Der Erkenntnisgewinn liegt beim ANDEREN AP.
Die Konsole liest deshalb beide Telefone mit und zwingt das S22 automatisch
auf den Gegen-AP des iPhones. Pro Standort gibt es damit zwei Messpunkte
statt einem, ohne den Weg zweimal zu gehen. Ein kurzer Doppelton meldet
"beide angemeldet, verschiedene APs" -- das ist das Signal zum Weitergehen.
Drei Zustaende statt zwei, weil zwei hier luegen wuerden:
bereit beide haengen -> Piep, weiter
sucht S22 versucht den Gegen-AP -> stehenbleiben
unerreichbar nach 45 s: der Gegen-AP traegt hier NICHT. Das ist das
Messergebnis, kein Defekt -- Marker UNERREICHBAR=apX, kein
Dauer-Alarm, weitergehen.
Ausserdem:
- Raumkacheln sind zurueck. Sie hingen am TP6-Treiber-Zustand und waren ohne
laufenden Call-Treiber unsichtbar -- ausgerechnet beim Kartieren.
- Die Call-Buttons (Start / Not-Aus fuer die Saettigungs-Flows) erscheinen nur
noch MIT Treiber. Ohne einen haette der Start-Klick nichts gemessen; der
Not-Aus haette nichts zu stoppen gehabt. 🚶/📍 brauchen keinen Treiber und
bleiben immer da.
Zwei Fehler beim Bauen, beide mit Merkwert:
1. `(:while (true) do={...})` -- die Klammern beenden die RouterOS-Sitzung
wortlos. Mit stderr auf DEVNULL sah man nur, dass alle 3 s ein neuer ssh
startet, und sonst nichts. stderr geht jetzt in beobachter.log.
2. `for zeile in proc.stdout` liest blockweise vor: bei einer Zeile alle 2 s
waeren die ersten Daten nach etwa einer Stunde gekommen. iter(readline, "").
Und eine Sicherheitskorrektur: `sshpass -p` schreibt das Router-Passwort in
die Kommandozeile -- sichtbar in ps und in jedem argv-Trace. Beim Debuggen ist
es am 2026-08-22 genau so im Klartext gelandet. Der Beobachter nutzt jetzt
`sshpass -e` (Passwort nur in der Umgebung des Kindprozesses). tp6-monitor-core.sh
und tp25-pin-s22.sh haben dieselbe Schwaeche und sind noch NICHT umgestellt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TP25: das S22 laesst sich jetzt per access-list am Manager auf EINEN AP
festnageln (docs/tp25-pin-s22.sh, Umschalter in der Klick-Konsole). Damit
werden Einzel-AP-Abdeckungskarten messbar, statt dass der Client mitten im
Weg wechselt. Gepinnt wird der Standort, nicht das Band -- Band-Ping-Pong
(Fund C) bleibt damit ein echter Befund und wird nicht wegkonfiguriert.
Beim Bauen fielen drei Fehler auf, die alle dieselbe Form haben: eine
Konstante, die einmal richtig war.
1. Die AP-Zuordnung war VERTAUSCHT. server.py und tp25-gehweg-auswertung.py
fuehren cap-wifi1/2 als ap1 -- live ist es ap2 (belegt ueber cap=,
configuration= und Kanal). Baender stimmten, Identitaet nicht. Die
cap-wifiN-Nummern vergibt der Manager dynamisch in der Anmeldereihenfolge
der CAPs, jede feste Tabelle dazu wartet auf den naechsten AP-Reboot.
server.py liest sie jetzt vom Geraet; die Auswertung ist NOCH NICHT
angefasst -- offen ist, ob die Funde vom 08-21 mit vertauschten AP-Namen
notiert sind.
2. Das Laufverzeichnis war beim Serverstart eingefroren. Die Konsole laeuft
als Dauer-Preview, der Messlauf legt spaeter ein neues Verzeichnis an --
Marker waeren in den Lauf von gestern gewandert, waehrend der Sampler ins
neue schreibt. tp25-walk-messung.sh hinterlaesst jetzt einen Zeiger.
3. Das Startbanner nannte eine hartkodierte IP (10.40.10.183 = MacBook Air).
Auf dem Mac mini ist es 10.40.10.82, und genau die falsche Adresse ging
ans Telefon: "geht nicht" bei einem Server, der sauber auf 0.0.0.0 lauschte.
Es werden jetzt die real gefundenen Interface-Adressen gedruckt.
Ausserdem, aus dem Test heraus:
- Ein vom Pin ABGEWIESENER Verbindungsversuch ist in den Ping-Daten nicht von
einem Funkloch zu unterscheiden, und der Manager protokolliert ihn auf
info-Ebene nicht. Android quittiert ihn mit "Verbindung fehlgeschlagen" und
waehlt das Netz ab -- danach misst der Rest des Rundgangs Stille. Die Konsole
schlaegt deshalb mit Vollbanner, Ton und Vibration Alarm, sobald das gepinnte
Geraet nirgends haengt.
- Die Konsole laeuft diesmal auf dem S22 selbst, also auf genau dem Geraet, das
der Pin gleich vom WLAN wirft. Die Anweisung zum Wiederverbinden erscheint
deshalb clientseitig VOR dem Abbruch.
- ThreadingHTTPServer: der Pin braucht ~8 s ueber SSH und haette sonst die
ganze Seite blockiert, Not-Aus inklusive.
Governance: /interface wifi access-list steht unter KEINER ComplianceRule --
der Change erzeugt keinen Drift und laesst sich nicht als Transaktion fuehren.
Fuer eine Messung vertretbar; relevant wird es, wenn Fund E (signal-range)
dauerhaft dort landet.
teilprojekte.md: die beiden Hinweise auf die offene Transaktion
TEST-ether3-trunk-ap1-sideboard nachgezogen -- sie ist seit 08-22
zurueckgerollt, crs326-core ist transaktionsfrei.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Entscheid 2026-08-22: es wird kein ESP32 als ESPHome-BT-Proxy
angeschafft. ble_proxy bleibt an, ist aber wirkungslos -- HA hat keine
connectable BLE-Quelle (Shellys: slots=0 auf allen dreien, gemessen) und
bekommt keine. Konsequenz, die beim naechsten Thread-Geraet zaehlt: der Weg
ist wieder die temporaere -infra-SSID. Runbook entsprechend von "Plan B" auf
Standardweg umgeschrieben, Blocker-Abschnitt als erledigt markiert (aber mit
dem Hinweis, dass Regel 3 jederzeit wieder greifen kann).
Neuer Nebenbefund unter TP12.1, bewusst als thread-, nicht ipv6-Thema
markiert: die Knoten @1:a (Diele OG/Treppenauge), @1:f und @1:10 flappen seit
Stunden (Resolving address is unreachable -> offline grace period expired),
waehrend die uebrigen ~20 stabil sind -- also kein Fabric-Problem. Vor jeder
Diagnose die Sonderlage von heute abziehen: OTBR-Neustart um 17:33 und ap1
zwischenzeitlich vom Netz. Erst pruefen, ob es danach noch besteht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
TEST-infra-ssid-matter-pairing (Scope wifi-provisioning, Frist 2026-08-29):
cfg-infra als Slave-VAP in beide ap2-Provisioning-Zeilen. Nicht ap1, weil der
gerade auf ether11 (VLAN10-Access) haengt und kein CAP ist.
Zweck ist TP12.1: das iPhone fuer EIN Matter-Commissioning auf denselben
L2-Link wie der OTBR bringen, damit dessen RA (On-Link-Prefix + Route in den
Thread-OMR-Prefix) beim Telefon ankommt. Danach zurueckbauen -- ein WLAN nach
INFRA soll nicht stehen bleiben.
Zwei Dinge fuer die Ablage:
- Provisioning-Zeilen aendern reicht nicht, der CAP muss re-provisioniert
werden (/interface wifi capsman remote-cap provision). Das ist eine Aktion,
keine Config, also kein Nautobot-Weg noetig.
- Danach zeigt der MANAGER running=false fuer alle cap-*-Interfaces, waehrend
am CAP wifi13/wifi18 sauber DBR laufen. Beim Interface-Zustand ist der CAP
die Wahrheit, nicht der Manager -- Gegenstueck zur bekannten Regel, dass die
Registration-Table am Manager zu lesen ist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TEST-ether3-trunk-ap1-sideboard ist zurueckgerollt und geschlossen: ether3
faellt aus allen tagged-Listen und ist in VLAN40 wieder untagged (Sideboard-
Access-Port). Am Geraet gegengeprueft, Snapshot-Diff leer. crs326-core ist
damit transaktionsfrei.
TP25 Fund (G): ap1 am Sideboard richtet das Wohnzimmer nicht und kostet das
Schlafzimmer (-61 -> -83 dBm). Die Idee "ap1 ersetzt den Sideboard-Switch" ist
damit entschieden -- nein, Platzierung vor eingespartem Geraet. ap2 haengt
jetzt auf 2,5 m, Terrasse subjektiv besser, Nachmessung steht aus.
Korrektur im selben Zug: die erste Fassung von (G) behauptete, der Steering-
Fall entfalle mit dem Rollback. Falsch -- es entfaellt nur die konkrete
Auspraegung. Fund B und C wurden am 08-20 mit ap1 auf ether15 gemessen, also
in genau der Stellung, in die wir zurueckgebaut haben; der Defekt ist
platzierungsunabhaengig und verlagert sich nur. Fund E bleibt die Massnahme
und ist jetzt oberster offener Punkt.
TP12.1 neu (unter TP12, kein Duplikat daneben): Matter/Thread-Commissioning
scheitert an fehlendem IPv6-Routing zwischen VLAN10 und VLAN20 -- nicht an der
Firewall. Der Kostenpunkt des TP ist aber nicht die Adressvergabe, sondern
dass /ipv6 firewall filter leer ist: heute harmlos, ab der ersten Adresse ein
Loch an TP5 vorbei. Reihenfolge deshalb zwingend v6-Firewall vor Adressen.
Runbook + Kommandodateien fuer die temporaere dirtyvader-infra-SSID
(cfg-infra existiert bereits, haengt nur in keiner provisioning-Zeile).
Vorbereitet, nicht deployt.
Repo-lokalen projektstatus-Skill geloescht: er war seit 11. Juli stale
(harte Themenblöcke, kritischer Pfad von TP14.3) und wurde nicht geladen --
aktiv ist der globale.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Uebergabedokument nach dem Muster des TP6-Handovers, das sich bewaehrt hat. Sein
Wert liegt in zwei Dingen, die eine frische Session nicht selbst herausfinden
kann: die offene Config-Transaktion mit Frist, und die acht Messfallen, die in
dieser Session je einen Fehlbefund produziert haben.
Der Statusstand: TP6 gemessen und nachrangig, TP25 auf dem kritischen Pfad, und
auf crs326-core ist TEST-ether3-trunk-ap1-sideboard offen (Frist 2026-09-04) --
die Compliance ist deshalb absichtlich nicht 92/92.
Inhaltlich neu ist die Umdeutung des Abend-Befunds. Nach dem ap1-Umzug ans
Sideboard verlieren die Schlafraeume rund 20 dB und fallen auf ap2/2,4 GHz
zurueck. Laut Christophs Massangaben liegen sie aber 2 bzw. 4 m Luftlinie von
ap1, waehrend ap2 4-6 m entfernt ist und zwei zusaetzliche Mauern dazwischen hat.
Ein Client, der so am ferneren AP klebt, hat kein Abdeckungs-, sondern ein
Steering-Problem -- und damit ist das die erste Stelle im Haus, an der Fund E
(signal-range-Boden) wirklich das richtige Werkzeug ist. Auf der Terrasse waere
er falsch gewesen, weil es dort keine Alternative gibt. Der Test dafuer steht im
Handover und ist die naechste Messung.
Ebenfalls korrigiert: der Platz, an dem das Telefon auf der Terrasse
normalerweise steht, ist mit -46 bis -66 dBm gut. Der Dead Spot ist der Teil
dahinter.
TP29 haelt Christophs Idee fest, Anwesenheit ueber BLE (Shellys), WLAN und
mmWave-Radar zu erkennen, um ohne Komfortverlust zu heizen. Der Entwurfsgedanke
sind die komplementaeren Schwaechen der drei Quellen -- BLE braucht ein
getragenes Geraet, WLAN erkennt nur Menschen mit Telefon, Radar auch die
stillsitzende Person, kostet aber einen Sensor je Raum. Nicht auf dem kritischen
Pfad.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ein iPhone mit gesperrtem Display beantwortet ICMP nicht. In der Verlustspalte
sieht das exakt aus wie ein Funkloch, und heute haette es fast zu einem falschen
Befund gefuehrt: 58 Sekunden Ping-Luecke auf der Terrasse -- bei -53 dBm, 275 Mbps
PHY-Rate und weiterlaufenden 3 kbit/s Hintergrundverkehr. Das Geraet war
erreichbar, es wollte nur nicht antworten.
Die Auswertung markiert solche Luecken jetzt (gutes Durchschnittssignal plus hohe
PHY-Rate) und sagt dazu, dass sie NICHT als Funkloch zu lesen sind. Bewertet wird
der Durchschnitt des Abschnitts, nicht sein Minimum -- ein einzelner schwacher
Sample beim Durchgehen darf den Befund nicht kippen.
Dazu die Rohdaten des Gangs mit ap1 am Sideboard.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Port trug keines der sieben VLANs, deshalb war ap1 nach dem Umpatchen tot.
Sieben set-Zeilen ueber gc-manual-plan.py, und der erste Deploy zeigte gleich zwei
bekannte Fallen von ihrer praktischen Seite:
Der Plan meldete Failed, und der Teilzustand war real -- sechs VLANs hatten ether3
bekommen, VLAN 40 nicht. Der Grund ist sauber: ether3 war dort UNTAGGED-Mitglied,
und ein Port kann in derselben VLAN nicht zugleich tagged und untagged sein.
Nachtrag deployt (untagged=ether2,ether4,ether5), diesmal mit --assert, und der
hat den Effekt am Geraet nachgewiesen statt dem Job zu glauben.
Ergebnis: ap1 antwortet in 447 us und traegt wieder 12 Clients (ap2: 16).
Die Aenderung bleibt bewusst UNCOMMITTED: sie steht am Geraet, nicht in der SoT,
und die Compliance meldet den Drift auf bridge-vlan. Genau so soll es sein,
solange offen ist, ob ap1 am Sideboard bleibt. Faellt die Entscheidung, wird
entweder das Template nachgezogen (commit) oder aus dem Snapshot zurueckgebaut.
Ein Bugfix im neuen Werkzeug faellt dabei gleich mit an: der Feature-Name steht
bei depth=1 nicht ausgeschrieben in rule.feature, dort kommt nur eine URL.
Verwendbar ist rule.display. Ohne das meldete status JEDEN Drift als "ausserhalb
des Scopes" -- also ausgerechnet die Zuordnung falsch, fuer die es gebaut wurde.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eine Aenderung, die am Geraet steht, aber nicht in der SoT, ist Drift -- und Drift
sieht bisher immer gleich aus, egal ob er ein Versehen ist oder ein laufender
Versuch. Wer testen wollte, hatte die Wahl zwischen "Compliance kaputt" und "gar
nicht testen".
gc-transaktion.py macht die Absicht sichtbar, ohne die Governance aufzuweichen:
der Change geht weiterhin ausschliesslich ueber Golden Config, die Compliance
meldet den Drift weiterhin -- neu ist, dass `status` ihn zuordnen kann,
"erwartet (offene Transaktion)" statt "unerklaert". Und dass er ein Ablaufdatum
hat.
Drei Regeln erzwingt das Werkzeug: --expires ist Pflicht (eine unbefristete
Ausnahme ist undokumentierter Drift mit besserem Gewissen), der Scope ist eine
ComplianceRule und kein Freibrief (Drift ausserhalb wird ausdruecklich als nicht
abgedeckt gemeldet), und es gibt genau eine offene Transaktion je Geraet -- sonst
ist beim Rollback nicht mehr entscheidbar, wohin zurueck. Der Commit wird
verweigert, solange der Scope noch driftet: dann waere die SoT gar nicht
nachgezogen worden.
Zwei bewusste Grenzen: der Rollback pusht nicht selbst, sondern schreibt einen
Vorschlag zum Pruefen (add-Zeilen aus einem /export legen neu an, statt zu
aendern), und der Snapshot enthaelt nur den Scope-Abschnitt. Der Vollexport
enthielt Firewall, Adressen, Benutzerliste und Skriptquellen -- nichts davon
braucht der Rueckbau, und die Akten liegen im Git.
Erste Akte ist der ether3-Trunk: ap1 haengt testweise am Sideboard auf core
ether3, und dieser Port traegt bisher keines der sieben VLANs. Deploy steht noch
aus -- er wurde in dieser Session vom Berechtigungs-Klassifikator blockiert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei User-Korrekturen (2026-08-21) an der Erklaerung des Terrassen-Dead-Spots:
"Technik OG" ist kein eigener Raum, sondern ein virtueller Bereich im
Arbeitszimmer -- es gibt dort keine bauliche Trennung. Die bisherige Erklaerung
zaehlte drei Waende und war damit falsch.
Zwischen ap2 und Terrasse liegen zwei Mauern der Diele OG und teilweise die
PV-Anlage an der Mauer. Module und Unterkonstruktion sind eine leitende Flaeche,
also ein Schirm und keine daempfende Wand. Das erklaert, warum es auf der
Terrasse nicht knapp, sondern kaputt ist -- und sagt zugleich voraus, dass mehr
Sendeleistung oder ein schmalerer Kanal dort wenig ausrichten werden.
Daraus folgt die neue Reihenfolge: ap2 testweise an den Kandidatenplatz haengen,
an dem spaeter ohnehin ein Decken-AP sitzen wuerde (kein Config-Change noetig, ap2
ist ein CAP und provisioniert sich am neuen Platz selbst). Bleibt die Terrasse
dabei schlecht, ist das OG die falsche Seite: dann ist das Wohnzimmer der
Kandidat, das unterhalb der Terrasse liegt -- ein AP dort strahlt an der PV-Anlage
vorbei statt durch sie hindurch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Statusblock war im Commit davor haengengeblieben (Anker im Skript verfehlt,
Assertion geworfen, Doku committet, Status nicht). Genau der Fehler, vor dem
Spielregel 4 der TP6-Uebergabe warnt: neuer Inhalt geschrieben, alter Status
stehen geblieben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zweiter Gehweg-Durchgang, diesmal methodisch sauber: Ping vom Core statt vom
Laptop, Konsole auf dem iPhone (Wake Lock haelt es wach, sonst misst man
Ruhezustand), Raumwechsel per Klick markiert.
Das Ergebnis ist eindeutig und macht die Roaming-Geschichte klein. Im ganzen Haus
null Paketverlust -- Technik UG und OG, Diele, Kinder-, Schlaf- und
Arbeitszimmer, Treppe, alle 0 %, und die Uebergaben ap1<->ap2 auf der Treppe
kosten 0,2 s. Auf der Terrasse dagegen 43 % Verlust ueber 162 Sekunden, am Stueck
fehlen 20,4 Sekunden, bei -72 dBm. Dort ist ein Call nicht gestoert, sondern weg.
Die Topologie erklaert es vollstaendig: ap2 steht in Technik OG, das nur ueber
das Arbeitszimmer zugaenglich ist -- zur Terrasse liegen Technik OG,
Arbeitszimmer, Diele OG und die Aussenwand dazwischen.
Das dreht die Massnahmen um. Ein signal-range-Boden (Fund E) wuerde die Terrasse
VERSCHLECHTERN, weil es dort keinen besseren AP gibt, auf den er steuern koennte
-- er wuerde nur rauswerfen. Stattdessen: 5 GHz auf 20 MHz (+3 dB, ein Wort im
Template), dann ap2 von Technik OG in die Diele OG umhaengen, die an Terrasse,
Arbeitszimmer und Treppe grenzt. Kein neuer AP noetig, damit ist auch die
User-Randbedingung erfuellt.
Konsole nachgezogen: Marker werden URL-dekodiert und behalten ihre Gross- und
Kleinschreibung (aus "RAUM=Diele OG" wurde "RAUM%3DDIELE%20OG"), Diele OG ist
ergaenzt, und das Raumraster steht jetzt oben -- ohne JavaScript laedt die Seite
nach jedem Klick neu, und dann muss der naechste Raum ohne Scrollen erreichbar
sein.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pingt der messende Laptop das Telefon an, laeuft der Weg ueber zwei
Funkstrecken -- Laptop -> AP -> Core -> AP -> Telefon. Fehlt dann ein Paket, ist
nicht entscheidbar, welches der beiden Geraete weg war, und genau diese
Trennschaerfe ist der ganze Zweck der Messung. Vom Core aus ist die Strecke bis
zum AP durchgehend Kabel.
Ausloeser war unfreiwillig: das MacBook ist mitten in einem Lauf vom Dock ans
WLAN gewechselt und hat dabei die IP gewechselt -- die Konsole war ploetzlich
nicht mehr erreichbar, und der Ping haette ab da zwei Funkstrecken gemessen.
Das Ping-Protokoll ist jetzt eine CSV (ts_local,seq,ms; leeres ms = Verlust), die
Auswertung liest beide Formate, damit die Laeufe von gestern lesbar bleiben.
RouterOS-Dauern kommen als "3ms441us" oder "529us" und werden entsprechend
geparst.
Eine Falle steckt im Skript-Kommentar: tr puffert blockweise, sobald die Ausgabe
in eine Pipe geht -- die ersten ~130 Zeilen haengen im Puffer und die Datei
bleibt scheinbar leer. Das \r kommt deshalb im Shell-Loop weg, nicht per tr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
