Claude Code Betriebshandbuch

01 Claude-Account wechseln

Auf dem apps-server läuft seit 08.09.2026 nur noch ein Account — kein Alias, kein zweites Config-Verzeichnis mehr nötig. Ein Wechsel geschieht direkt in einer laufenden Claude-Code-Sitzung.

Ablauf eines Wechsels

1. In einer laufenden Claude-Code-Sitzung /login eingeben.
2. Browser-Login-Flow durchlaufen (OAuth) — mit dem gewünschten Account anmelden.
3. Die Sitzung nutzt ab sofort den neu angemeldeten Account. Alle anderen gleichzeitig laufenden Sitzungen, die ebenfalls den normalen claude-Befehl (Standard-Config-Verzeichnis ~/.claude) nutzen, ziehen automatisch mit — sie teilen sich dieselbe Zugangsdaten-Datei.

Woran man erkennt, welcher Account gerade aktiv ist

Ohne Login-Feld im UI am schnellsten per Terminal zu prüfen:

# zeigt die hinterlegte E-Mail-Adresse des aktiven Accounts
python3 -c "import json; print(json.load(open('/home/juergen/.claude.json'))['oauthAccount']['emailAddress'])"

02 tmux-Sitzung "work" starten/anhängen

Claude-Code-Sitzungen laufen dauerhaft in einer tmux-Sitzung namens work auf dem apps-server — das erlaubt es, sich per SSH (auch vom Handy per Termux) jederzeit wieder anzuhängen, ohne dass laufende Sitzungen unterbrochen werden.

Nach einem Neustart der Maschine: ein Wort genügt

Getippt wird das im Windows Terminal direkt nach dem Anmelden am apps-server, in der normalen Eingabeaufforderung — NICHT in tmux (das wäre tmux in tmux). ~/bin liegt im PATH, darum reicht das Wort:

# vom Windows-Terminal oder Termux (Handy)
ssh juergen@apps-server
# bzw. vom Handy direkt per IP:
ssh juergen@192.168.6.86

# danach: Sitzung anlegen, alle sechs Fenster füllen und sich dranhängen
work

work ist unser eigenes Skript (/home/juergen/bin/work), kein tmux-Befehl. Es legt die Sitzung work mit allen sechs Fenstern an, tippt in jedem Fenster den Wiederanlauf der zugehörigen Claude-Sitzung und hängt dich am Ende an Fenster 0. Läuft die Sitzung schon, hängt es sich nur dran — gleichwertig zu tmux attach -t work. Es ist also immer der richtige Befehl, egal ob die Maschine gerade neu gestartet ist oder nur das Terminal zugeklappt war.

Die sechs Fenster (Stand 01.11.2026, nach dem Monatsneustart geprüft)

Stimmt eine Wiederanlaufmarke nicht mehr (etwa weil eine Sitzung neu angefangen wurde), zeigt claude agents --json im laufenden Betrieb Name und UUID jeder Sitzung; danach die Liste in ~/bin/work anpassen. Dieselbe Übersicht liegt als Textdatei auf dem Server: ~/energie/claude_sitzungen_vor_update.txt.

Falls "work" mal nicht existiert

Auch dann einfach work tippen — das Skript merkt selbst, dass keine Sitzung läuft, und legt sie an. Ein nacktes tmux new -s work gibt dagegen nur ein leeres Fenster ohne Namen, Verzeichnisse und Claude-Sitzungen.

Ein Fenster wieder schließen

Wenn eine Claude-Sitzung in einem Fenster mit /exit beendet wurde, bleibt das Fenster als leerer Bash-Prompt bestehen — tmux schließt es nicht automatisch. Drei Wege, das Fenster loszuwerden:

1. Am einfachsten: im leeren Bash-Prompt einfach nochmal exit eintippen — die Shell beendet sich, tmux entfernt das Fenster danach von selbst.
2. Per Tastenkombination, ohne erst reinzuwechseln: Strg+B dann 3 (zum Fenster wechseln), dann Strg+B dann & (fragt kill window #3? (y/n), mit Y bestätigen).
3. Von einem beliebigen anderen Fenster aus per Befehl, ohne überhaupt hinzuwechseln: tmux kill-window -t work:3 (Fensternummer anpassen).

03 tmux-Tastenkombinationen

Präfix-Taste ist der Standard Strg+B (nicht umbelegt, siehe ~/.tmux.conf). Erst Präfix drücken und loslassen, danach die zweite Taste.

Zwei Namen pro Reiter — nicht verwechseln

Jeder Reiter zeigt zwei unabhängige Namen, die leicht durcheinandergehen:

Wenn hier im Handbuch oder im Chat von "Prüfung" oder "Datenauswertung" die Rede ist, ist immer der rechte Sitzungsname gemeint — im tmux-Fensternamen links steht meist trotzdem einfach nur claude, solange er nicht manuell umbenannt wurde.

04 Claude-Befehle

Die wichtigsten Befehle im täglichen Betrieb — sowohl auf der Shell (vor dem Start) als auch als Slash-Befehl innerhalb einer laufenden Sitzung.

Auf der Shell

Innerhalb einer Sitzung (Slash-Befehle)

Vordergrund oder Hintergrund — und wie man eine Sitzung zurückholt

Warum es zählt: Im Vordergrund fragt Claude Code vor einem Eingriff nach und wartet auf Bestätigung. In einem Hintergrundauftrag ist niemand da, der bestätigt — dort gelten andere Schreibrechte, und niemand sieht die Rückfrage.

Damit es gar nicht passiert: Es gibt genau zwei Türen in den Hintergrund, und keine davon ist der Start — ein Schrägstrich-Befehl aus einer laufenden Sitzung heraus, oder die Flotten-/Agentenübersicht. Im Daemon-Protokoll ~/.claude/daemon.log stehen sie als (slash) bzw. (fleet). Weder ~/bin/work noch ~/.claude/settings.json enthalten eine Hintergrund-Einstellung. Im Fenster also nur claude tippen, oder claude --resume <Name>.

Dasselbe als zweiseitige Anleitung zum Ausdrucken: /home/juergen/energie/doku/Anleitungen/Claude-Sitzung_in_den_Vordergrund_holen.pdf

Statuszeile unten in der Sitzung

Ganz unten rechts zeigt Claude Code eine kleine /rc-Anzeige — das steht für Remote Control (ob diese Sitzung gerade fernsteuerbar/verbunden ist, z. B. für Remote-Control-Zugriffe von einem anderen Gerät). /rc active ist der normale Zustand, kein Fehler. Falls dort mal /rc failed steht: meist harmlos (z. B. kurzzeitiger Verbindungsaufbau) — einfach weiterarbeiten, die Sitzung selbst läuft davon unabhängig normal weiter.

05 Subdomains & Zugänge

Welche öffentliche Subdomain zu welchem Dienst gehört, wie sie geschützt ist, und der direkte lokale Link zum jeweiligen Dienst (nur im LAN erreichbar, ohne den Umweg über die öffentliche Domain).

Nur intern erreichbar, keine öffentliche Subdomain

06 Projekt-TODO (Tibber/EVCC/DESS)

Aktueller Stand der offenen Punkte im Energie-Projekt. Damit nichts verloren geht, wenn mal jemand (Claude oder der Nutzer) etwas vergisst, hält der Abschnitt "Revisionsverlauf" unten die letzten zehn Stände fest — bei jeder inhaltlichen Änderung hier oben wird der bisherige Stand dorthin verschoben, der älteste fliegt dann raus, sobald mehr als zehn gesammelt wären.

Lesekopf am Stromzähler — Stand 04.11.2026 abends: er läuft

Der Zähler EFR SGM-D4-A920N ist entschlüsselt: er sendet unaufgefordert jede Sekunde, Bezug 1-0:1.8.0 und Einspeisung 1-0:2.8.0, ohne PIN. Einheit steht im Telegramm selbst (62 1E = Wh, 52 FF = Faktor 0,1). Gemessen am 02.11. um 20:02: Bezug 97,26 kWh, Einspeisung 7,94 kWh — das waren die Prüfzahlen. Am 04.11.2026 um 21:58 ist der Kopf geflasht, im WLAN und in Home Assistant eingebunden — gemessen um 22:05: Bezug 119,7022 kWh, Einspeisung 7,9524 kWh, WLAN-Pegel −74 dBm. Die Gegenrechnung trägt: +22,3 kWh Bezug in 49 Stunden sind 455 W Dauerlast, die Einspeisung stand im November praktisch still. Einzelheiten im Gedächtnis unter project_lesekopf_stromzaehler.

• Erledigt am 04.11.2026, 21:58 Der Lesekopf läuft — und das Modul war nie zerstört. Die Annahme vom 02.11. („beim Umflashen zerstört“) war falsch. Der Zeitfresser am 04.11. war eine Verwechslung: die sechs Drähte hingen an der runden Trägerplatine statt am ESP01s-Modul — darum antwortete nichts, und alle Messwerte des Abends (3 mV, 600 mV an „IO0/IO2“) betrafen die Infrarot-Elektronik, nicht den Chip. ⚠ Lehre für die Anleitung: ein Blatt, das ein Teil ausbauen lässt, muss im gleichen Satz sagen, woran weitergearbeitet wird — „zieh X heraus“ ohne „und arbeite an X weiter“ lädt genau zu dieser Verwechslung ein. Mit dem Modul am Kabel lief alles in einem Zug: Chip erkannt (MAC d8:bf:c0:1d:7f:ba), Erase 1,766 s, 387.088 B bei 0x0 in 25,1 s, File-MD5 = Flash-MD5 = 2f741cf2…, „Hash of data verified“ — lokal gegengeprüft. ⚠ Lehre zur Fehlermeldung: „Flash ID: 0“ und „Failed to communicate with the flash chip“ sind kein Beweis für einen defekten Flash — die Kennungsabfrage kann scheitern, während Erase und Write samt Prüfsumme fehlerfrei durchlaufen. Erst die Prüfsumme nach dem Schreiben entscheidet, nicht die Kennung davor. Danach in HA als ESPHome-Gerät eingebunden (Host 192.168.6.103, Port 6053, kein Schlüssel nötig). Ein OTA-Update dauert rund sechs Minuten (Kompilieren, Hochladen, Neustart); die Sensoren stehen dabei auf unavailable — das ist der Vorgang, keine Störung.
• 04.11.2026, 22:12 — behoben, Wirkung noch offen Der Kopf hat die WLAN-Zugangsdaten nach dem ersten Update vergessen. Der Nutzer musste sie über das Notfall-Portal neu eingeben. Zwei belegte Ursachen in der yaml, beide am 04.11. geändert (Sicherung lesekopf.yaml.bak_20261104_vor_wlan_fix): (1) Eingaben aus dem Notfall-Portal lagen im RTC-Speicher, der einen Softwareneustart übersteht, aber keine Stromtrennung — jetzt esp8266: restore_from_flash: true (Standard ist false). (2) fast_connect: true war gesetzt; die Option ist laut ESPHome-Doku für Batteriegeräte aus dem Deep Sleep gedacht und verbindet mit dem ersten Netz, das der ESP sieht, „even if that network is very far away“ — bei −74 dBm am Zähler die falsche Wahl, darum entfernt. Ursache: die Großschreibung der SSID — vom Nutzer selbst gefunden. Das Netz heißt Condor, in secrets.yaml stand condor; SSIDs unterscheiden Groß- und Kleinschreibung, der Kopf suchte also ein Netz, das es nicht gibt. Am 04.11. um 22:21 in secrets.yaml behoben. ⚠ In der laufenden Firmware steht noch condor — Secrets werden beim Bauen eingesetzt, es fehlt also noch ein Neubau mit OTA; Probe danach: Strom trennen. Meine beiden vorherigen Verdächtigen waren nicht die Ursache (restore_from_flash und das entfernte fast_connect bleiben dennoch richtig) — und ich hatte die korrigierte Datei irrtümlich wieder zurückgedreht, wiederhergestellt aus secrets.yaml.bak_20261104_vor_ssid_fix. Auch nach dem zweiten Update musste der Nutzer sie über das Notfall-Portal eingeben („nein ich wars wlan eingegeben“). Nächster Schritt: SSID und Passwort im Device Builder unter Secrets neu eintragen — das macht der Nutzer selbst, Zugangsdaten gehen nicht über den Chat. Danach neu bauen, per OTA einspielen, und als Probe den Strom trennen: kommt der Kopf dann von allein, ist es erledigt. Der tägliche Schmerz ist schon weg — mit restore_from_flash übersteht eine Portal-Eingabe jetzt auch einen Stromausfall.
• 04.11.2026 — Termin 2027.1.0 Die Statusseite auf http://192.168.6.103/ läuft auf web_server Version 1, und die ist abgekündigt. ESPHome warnt beim Bauen: entfernt in 2027.1.0. Version 1 ist hier trotzdem richtig, aber nicht aus dem Grund, den ich zuerst genannt hatte: auch Version 1 lädt CSS und JavaScript von oi.esphome.io aus dem Internet nach (am 04.11. im Seitenquelltext nachgesehen) — autark ist sie also nicht, der Browser braucht Netz. Ihr einziger Vorteil ist die Größe; Version 2 und 3 mit local: true sprängen den 1-MB-Flash. Vor 2027.1 entscheiden: Version 2 ohne local, Seite weglassen (HA ist der eigentliche Weg) oder eine eigene Seite auf dem apps-server, Port 8085 ist frei.
• 04.11.2026 — neu aufzusetzen Das Energie-Dashboard ist falsch konfiguriert und wird neu gemacht. Gefunden beim Versuch, den Lesekopf einzutragen. Als Netzbezug steht dort sensor.evcc_go_e_charge_total_import — „Geladen (Gesamt)", 4592,673 kWh: das ist der Gesamtzähler der Wallbox, also nur das Autoladen, nicht der Hausbezug. Eine Einspeisung ist gar nicht eingetragen (null), obwohl sie seit dem Smart Meter am 26.10. getrennt zählt und vergütet wird. Der Nutzer dazu: „das war ja so sowieso quatsch". Hinein gehören …zaehlerstand_bezug und …zaehlerstand_einspeisung — der Zähler, nach dem EDIS abrechnet, ist die genaueste Quelle im Haus; die Wallbox wandert zu „Einzelne Geräte". Zu klären: was der Solar-Template-Sensor summiert, und der Vergütungssatz (~7,66 ct). ⚠ Zwei Fallen: /config/.storage/energy nicht von Hand bearbeiten (HA hält die Daten im Speicher und schreibt sie zurück) — richtig ist die Oberfläche oder energy/save_prefs; und mehrere Netzbezugs-Quellen werden ADDIERT, der Lesekopf „zusätzlich" neben die Wallbox würde das Autoladen doppelt zählen. Kein Zeitdruck: HA sammelt die Langzeitstatistik für beide Zählerstände schon jetzt (state_class: total_increasing), unabhängig vom Dashboard — es gehen keine Messwerte verloren.
• 02.11.2026 — wartet auf den Netzbetreiber PIN für den Zähler über das EDIS-Portal holen, sobald der neue Zähler dort eingetragen ist. Am 02.11. war er sieben Tage nach dem Einbau noch nicht im Portal. Mit PIN und eingeschaltetem InF on (am Zähler selbst über die optische Taste) sendet er zusätzlich Wirkleistung in W, gesamt und je Phase, Spannung und Strom je Phase sowie die Netzfrequenz — damit gibt es die Netzleistung am Zähler selbst als unabhängige Gegenprobe zu Victron und EVCC. Danach die Zusatzwerte in lesekopf.yaml ergänzen; das geht dann über Funk — am 04.11. erprobt, OTA läuft (Port 8266).

Belegarchiv ~/belege — Stand 03.11.2026 abends: beide Umzüge durch, Gegenprobe geschlossen

Nicht mein Inhalt, aber meine Zahlen: ich prüfe nur, dass bei den Umzügen nichts verlorengeht — Dateizahlen und Prüfsummen, ohne hineinzusehen. Beide Seiten sind eingezogen und der Bestand ist entdoppelt: 39.511 Belegdateien, 6,68 GiB, 36.395 verschiedene Inhalte (morgens waren es 49.123 Dateien und 8,21 GiB). Gegengerechnet, nicht nachgesprochen: es fehlt kein einziger Beleg — siehe unten. Zugriffsregel, von Jürgen am 03.11. entschieden: Bucher liest, Kosten schreibt (einzige schreibende Hand); beide Sitzungen sind unterrichtet. Einzelheiten im Gedächtnis unter project_claude_code_umzug_apps_server, die ausführliche Fassung in /home/juergen/belege/LIESMICH.md.

• Erledigt am 03.11.2026 abends Die Gegenprobe nach Kostens Umzug ist gezogen: kein Beleg fehlt. Nicht die Dateizahlen verglichen, sondern die Menge der Inhalte (sha256) von morgens gegen abends: 36.981 → 36.395, also 589 Inhalte verschwunden und 3 neu (die drei HVB-Umsatzlisten). Zu den 589 gehörten morgens 695 Pfade — davon 693 macOS-Metadateien (.DS_Store, ._*), die Kosten gelöscht hat; die zwei übrigen sind meine eigenen Dateien (dieses LIESMICH, das ich heute geändert habe, und meine Bestandsliste vom Morgen). ⚠ Und der Grund, warum die Zahl erst nicht aufging: Kosten meldete „kein Inhalt verloren, 36.983 vorher und nachher“ — das gilt nur dem Entdoppeln, und dort stimmt es, denn Entdoppeln entfernt nur Pfade. Das Löschen der Metadateien war ein zweiter Schritt, und der entfernt sehr wohl Inhalte: jede .DS_Store ist ein eigener. Ich hatte die 36.983 zuerst als Endstand ins LIESMICH geschrieben und musste es berichtigen. Eine Kennzahl, die in Klammern beim ersten von zwei Schritten steht, gilt auch nur für diesen. Dass die Probe überhaupt möglich war, liegt allein an den Listen vom Vormittag — ohne Vorzustand wäre hinterher nichts zu beweisen gewesen. Neue Grundlage, beide chmod 600 in ~/belege: bestand_archiv_2026-11-03_abend.tsv (sha256 beginnt f2524869c857a121) und pruefsummen_archiv_2026-11-03_abend.txt (363792f04c06ace5) — sie listen diesmal nur den Bestand, nicht sich selbst. ⚠ Stolperstein beim Bauen: ! -name 'LIESMICH.md*' schloss auch sechs LIESMICH-Dateien in Unterordnern aus, die zum Bestand gehören — richtig ist ! -path './LIESMICH.md*'. Aufgefallen nur, weil die Zahl um 6 nicht stimmte.
• Erledigt am 03.11.2026 durch die Sitzung Kosten Das Archiv ist entdoppelt — 49.126 → 40.099 Dateien, 9.027 Pfade weg, und der Dateisystemmüll dazu (587 .DS_Store und ._*) → 39.515. Vorher lagen alle Dubletten noch da: Bucher hatte beim Einzug mit Absicht nicht entdoppelt, und das war richtig — der Bearbeitungsstand steckt in den Ordnernamen (klar 4.990, unklar 2.813, kein_beleg 29). Entdoppelt hat dann die Sitzung, die auch die Inhalte führt. Kostens Einzug brauchte dabei gar keinen Umzug: von 32.889 Belegdateien seines Baums lagen 32.887 inhaltsgleich schon im Archiv; seine Kopien sind aufgelöst, je Datei vorher der Zwilling über die Prüfsumme nachgewiesen. Neu hereingekommen sind genau drei Dateien — die drei mehrjährigen HVB-Umsatzlisten. Damit trägt die Vorabmessung vom Vormittag: Kosten bringt kaum Neues mit. Gemeinsame Regel aus Buchers eigener Lehre: wer verschiebt, protokolliert das Verschieben genauso wie das Löschen.
• Erledigt am 03.11.2026 — Ablageregel Mehrjährige Dateien bekommen keinen Jahresordner, sondern die Spanne in den Dateinamen. Die Sitzung kosten hat das als Anfrage herausgegeben (richtig gekennzeichnet, kein Auftrag), Jürgen hat es fürs LIESMICH freigegeben. Sein Wortlaut: „mehrjärige ja ohne jahresornder. wenn möglich z.b. 2018-20 in den Dateinamen“. Grundordnung bleibt unterlagen/auszuege/<Konto>/<Jahr>/; was über Jahre läuft, liegt direkt unter dem Konto neben den Jahresordnern — so die drei HVB-Umsatzlisten (…_2018-24.csv, …_2019-24.csv, …_2019-23.csv), alle drei Pfade nachgesehen. Nicht in Jahresscheiben zerlegen — das wäre eine Änderung am Original. Die Spannen hat Kosten gemessen (erste und letzte Buchungszeile), nicht aus den alten Namen übernommen. Bei Kosten steht die Regel in dessen eigener Regeldatei, im LIESMICH des Archivs als Beschreibung des Bestands — keine Sitzung hat die Regeldatei der anderen angefasst.

Heizung — Luft im Dachheizkörper, Stand 03.11.2026

Die Stube wurde nicht warm. Zwei Ursachen gleichzeitig, beide gemessen: die Sonne fiel weg (PV 20,6 kWh am 26.10., seit dem 28. unter 9) und der Küchenheizkörper war vom 29.10. bis 02.11. abgedreht — sein Kopf hing in diesen Tagen an seinem eigenen heißen Winkel (24,0–24,5 gegen Sollwert 24,0), statt wie sonst am FRITZ 440. Jürgen hat ihn am 03.11. wieder verbunden und auf 24,5 gestellt; der Bezugspunkt manualtemp bleibt bei 22,0. Die Wärmepumpe selbst ist nicht der Engpass — sie liefert 38,6 kWh am 02.11. gegen 30,0 am 25.10. und drosselt dabei auf 18 % Verdichterdrehzahl bei Minimum 8. Einzelheiten im Gedächtnis unter project_waermepumpe_bosch.

• 03.11.2026 — wartet auf dich, du warst nicht zu Hause Luft aus dem Dachheizkörper holen: es blubbert. Entlüftet wurde schon, es kam nur Wasser — und das hat einen einfachen Grund: bei laufender Pumpe wird die Luft mitgeschleppt, sie sammelt sich erst im stehenden Wasser am Hochpunkt, und das ist der Dachheizkörper 8 m über dem Gerät. ⚠ Beim Warmwasserlauf geht es nicht — gemessen: PC1 läuft durch, 633 Warmwasser-Minuten mit im Mittel 518 l/h, nie unter 304. Und ein natürliches Fenster gibt es gar nicht: PC1 hat in zwei Wochen 13 Minuten gestanden. Zwei Wege: (a) Heizung 30–60 min abschalten, warten, dann entlüften, Druck auf 1,5–1,6 bar nachfüllen, Pumpe 15–30 min laufen lassen — 2 bis 4 Runden über mehrere Tage sind normal; (b) der bequemere Weg, und er geht: Jürgen kann den Dachheizkörper unten an Vor- und Rücklauf absperren (03.11. bestätigt). Dann steht das Wasser in ihm allein, während der Rest weiterläuft; nach wenigen Minuten ist die Luft an der Entlüftungsschraube. ⚠ Die Umdrehungen am Rücklauf zählen — dort sitzt oft die hydraulische Voreinstellung, und die muss genau so zurück. Reihenfolge beim Öffnen: erst Rücklauf, dann Vorlauf. Zwei bis drei Mal wiederholen, weil beim Wiederauffüllen Luft aus dem Rohr darüber nachkommen kann. Geprüft und ausgeschlossen: der Anlagendruck (10 Tage 1,2–1,6 bar, normale thermische Schwankung; bei 8 m bleiben oben 0,5–0,8 bar Überdruck — die Anlage zieht keine Luft). Ein Entlüftungsprogramm ist über das Gateway nicht erreichbar. Wenn es nach drei bis vier Runden weiter blubbert, ist es Sache des Heizungsbauers; dann beachten, ob es direkt nach einer Warmwasserladung am lautesten ist — das deutet auf die Umschaltung des Dreiwegeventils als Eintragsweg.
• 03.11.2026 — deine Entscheidung Pumpendruck steht auf 300 mbar und hat im Raum nichts gebracht. Sauber gemessen, weil der Verdichter über den Wechsel um 08:28 durchlief und die Drehzahl konstant 24 % blieb: geschätzter Durchfluss 631 → 685 l/h, aber Vorlauf 39,3 → 39,1, Rücklauf 37,0 → 36,9, Stube 23,1 → 23,1. 300 ist die dokumentierte Obergrenze und genau der Wert, bei dem du am 30.09. Strömungsgeräusche gehört hast. Fürs Entlüften ist er aber nützlich — höhere Geschwindigkeit schwemmt Blasen mit. Also erst nach dem Entlüften entscheiden, ob er auf 250 zurückgeht.

Lademasken — Stand 07.11.2026: kWh statt Prozent, Handstopp vom Knopf, und eine Stelle entscheidet

Nachgemessen am 21.10.: beide Dienste nachbar-laden (Port 8089) und haus-laden (Port 8091) sind active, antworten intern mit HTTP 200, und von außen gehen laden.askai.de und charge.askai.de mit 302 auf die Authelia-Anmeldung. Im Betrieb ist nichts offen. Der Umbau ruht auf der Entscheidung vom 17.10.: „Unsere Lademaske machen wir weiter wenn die zum leaf endgültig passt.“ Die Einzelheiten zu jedem Punkt stehen auf der Seite Nachbar laden.

• 05.11.2026, 09:00 — gefunden Die Hausmaske hat die Nachtladung nicht angestoßen — sie konnte es nie. Gemeldet: „unsere Maske sollte heute nacht laden hat sie aber nicht. das auto ist fats leer. und ich brauche es heute.“ Auto bei 6 %, angesteckt seit 04.11. 17:52, geladen 0,01 kWh. Die Ursache stand im Dateikopf von haus_fenster.py, wörtlich: „Es steuert NICHT. Kein smartCostLimit, kein Modus, kein Phasenwechsel.“ Das Programm rechnet das Fenster aus und legt den Plan ab, die Maske zeigt ihn — und niemand öffnet das Tor. Dazu passend gemessen: EVCC-Modus stand auf off. Belegt aus haus_fenster.log: um 00:15 noch „heute 00:15-01:30 · durchgehender Block“, um 00:30 dann „Frist zu knapp: 4 von 5 Viertelstunden“. ⚠ Zweite Schicht: die Frist stand auf 01:30 und das Fenster lag 00:15–01:30 — fünf Viertelstunden, die auf die Minute passten; ab der zweiten war es rechnerisch unmöglich. Zwei weitere Funde: das Ziel-SoC kam nie in EVCC an (Maske 30 %, EVCC limitSoc: 0, wirksam also 100 %) — und der Start-SoC zieht nicht nach. Jürgen dazu: „der soc war gestern 10% da vw noch nicht aktuell war. es war dann später bei den 6 %. das hat sich dann nicht neu gesetzt.“ Kostete 1,7 kWh Planmenge.
• Soforthilfe am 05.11.2026, 09:05 Von Hand geladen, auf „Jetzt sofort laden“ und „bis 30% ist okay ich warte auf bessere preise“. Erst das Limit (limitsoc/30, sonst wäre es bis voll gelaufen), dann /api/jetzt auf 8091. Gemessen: 11,47 kW bei drei Phasen — vorher stand phasesActive: 1, das wären 3,7 kW und dreimal so lange gewesen. ⚠ Das Limit 30 % bleibt stehen, bis es jemand ändert. Nebenbei ein Beleg für die Entscheidung vom 18.10. („alles läuft jetzt über dess“): während der Ladung meldete die Maske idle_maintain_targetsoc, eingefroren, Hausakku blieb bei 26 % und nahm sogar 317 W auf — DESS hält den Akku allein, die abgeschalteten Sperr-Automationen braucht es dafür nachweislich nicht.
• Gebaut am 05.11.2026, 09:15 Die Hausmaske schaltet jetzt selbst — übernommen von Dietrich, ohne die Preisgrenze. Jürgens Weg, nicht meiner: „über nimm das doch von dietrich und mach das nicht neu. nur eben ohne die preisgrenze“. „Preisgrenze“ ist belegt, nicht geraten: im Quelltext heißt number.evcc_go_e_smart_cost_limit genau so; die 0,34-Marge heißt dort Budget und war auf der Hausseite ohnehin nie drin. Übernommen wurde also Dietrichs Tor — die Preisgrenze bleibt unangetastet und behält damit einen Schreiber. Vier Teile: (a) tor() setzt now + Phasen frei und schließt mit off — Dietrich setzt smart, was ohne Preisgrenze gar nicht laden würde; (b) ein Merker haus_tor.json, weil Dietrichs Schutz „ist == now → nie übersteuern“ hier nicht greifen kann (now ist unser eigenes Ziel) — geschlossen wird nur, was dieses Programm selbst geöffnet hat, ein now von Hand bleibt stehen; (c) limit_soc() schreibt das Ziel-SoC als EVCCs Limit, nur solange etwas steckt (das Limit gehört dem Ladepunkt, nicht dem Auto); (d) der Start-SoC zieht nach, aber nur solange nichts geladen ist — ab dem ersten Strom ist der eingetragene Wert der Nullpunkt, auf dem geladen_seit() aufbaut, und würde er mitten in einer Ladung wandern, zählte dieselbe Ladung zweimal. Dazu geht das Tor auch an den drei Ausstiegen ohne Plan zu. Atomar geschrieben (tmp + os.replace), weil Cron die Datei alle 15 Minuten startet. Geprüft: beide Dateien ast.parse · Tor trocken in allen vier Merker-Lagen (ohne Merker zumachen → nichts, die Handladung bleibt) · Fenstergrenzen gegen den echten Plan 193 auf die Minute (11:44 zu, 11:45 auf, 12:59 auf, 13:00 zu) · Ladelimit setzt und erkennt Gleichstand · Erfolgspfad trocken durchlaufen, Merkdatei danach nicht angelegt · beide Masken HTTP 200 nach dem Neustart. ⚠ Der erste echte Schaltvorgang fehlt noch: das Sofortladen von heute morgen gilt bis 15:04, und suchen() steigt solange vorn aus — das Fenster 11:45–13:00 fällt damit aus. Wer es vorher sehen will, drückt „Sofortladen beenden“. Sicherungen haus_fenster.py.bak_20261105_vor_steuerung und nachbar_laden.py.bak_20261105_vor_steuerung.
• 05.11.2026 — berichtigt Zwei Stellen in der Dokumentation logen, beide eine Falle für den nächsten Leser. (1) Der Dateikopf von haus_fenster.py sagte „Es steuert NICHT“ — jetzt mit Datum berichtigt; die zwei alten Gründe bleiben stehen, denn sie begründen den Merker und die Leaf-Prüfung. (2) jetzt_setzen() in nachbar_laden.py begründete den Netzbezug mit automation.hausakku_schutz_auch_bei_evcc_schnellladen — die ist seit dem 18.10. aus, heute hält DESS Slot 0. Wer darauf baut, baut auf etwas, das es nicht mehr gibt.
• Gebaut am 01.11.2026, 22:20 Auch die HA-Automation „Nachbar: Ladung vorbereiten (Chip erkannt)“ schaltet die Grundladung nur noch bedingt ein — das Aufflackern beim Anstecken ist damit an beiden Stellen weg. Auf „dann mach die chip-automation jetzt“. Aktion 5 (always_charge → on) steckt jetzt in einem if-Block mit derselben Bedingung wie begruessung_traegt() im Programm: Hausakku über sensor.minpv_grenze (80 %) oder EVCCs Preisgrenze lädt gerade, und immer über dem Boden von 20 %. Die Push-Nachricht lügt nicht mehr: statt immer „Grundladung 6 A einphasig läuft“ steht dort sonst „KEINE Grundladung: Hausakku 25 % unter der Schutzgrenze 80 %“. Geschrieben über die Config-API, danach ausdrücklich automation.reload (Dateistand ist nicht Laufzeitstand); Sicherung ha_sicherungen/automation_nachbar_ladung_vorbereiten.bak_20261101.json. Gegengeprüft: echter Zustand → False mit passendem Text, Proben 85 % → True, 79/25/15 % → False, Automation nach dem Reload on, Aktionskette unverändert achtgliedrig. ⚠ Am echten Anstecken noch nicht erprobt — zu sehen wären dann: keine 1,4 kW, kein Wechsel von always_charge, in Dietrichs Maske der Leuchten-Hinweis. Alles andere (einphasig, 6/16 A, Modus smart, Preisdeckel 0,38, Sicherung der Vorwerte) unberührt.
• 01.11.2026 — Hintergrund Warum das nötig war. Jürgen am 01.11.: „bitte in die todo. machen wir nacher wegen des neustarts.“ Sie schaltet beim Anstecken selbst always_charge auf on — und der Hausakku-Schutz nimmt es sofort wieder weg, solange der Akku unter sensor.minpv_grenze (80 %) steht. Gemessen am 29.10.: 17:41:33 an → 17:41:35 aus → 17:42:00 Modus off. Das Programm lässt die Begrüßungsladung seit dem 29.10. in diesem Fall ganz aus; von der Automation bleibt aber ein Aufflackern von rund einer Minute: das Auto meldet „Ladung gestartet“ und gleich darauf „beendet“, im Auto landen rund 20 Wh. Zu ändern ist nur das Einschalten von „Dauerhaft laden“ — einphasig, 6/16 A, Preisdeckel 0,38 und die Sicherung der Vorwerte bleiben unangetastet.
• Gebaut am 29.10.2026, 22:10 Die Begrüßungsladung wird nur noch versucht, wenn sie durchläuft. Anlass war der echte Vorgang vom 29.10.: angesteckt 17:41, geflossen sind 19 Wh in 90 Sekunden, zweimal an und aus. Ursache sind nicht unsere Fünfzehn Minuten, sondern zwei Hausakku-Schutzautomationen, deren Bedingungen jetzt im Programm gespiegelt sind (aus der HA-Config-API gelesen): begruessung_traegt() lässt sie nur laufen, wenn der Hausakku über sensor.minpv_grenze liegt oder EVCCs Preisgrenze gerade lädt; Jürgens Boden von 20 % bleibt darunter. Sonst steht in Dietrichs Maske: „Dein Chip ist erkannt — das zeigt dir die Wallbox mit ihrer Leuchte. Geladen wird in den günstigen Stunden.“ Jürgen dazu: „Dann ist das so das die Ladung nicht läuft dann macht es keinen sinn das die an und aus geht.“ ⚠ Am echten Vorgang noch nicht erprobt — seither hat der Leaf nicht ohne Plan angesteckt. Sicherung nachbar_fenster.py.bak_20261029_vor_begruessung_bedingt.
• Gebaut am 29.10.2026, 19:00 „Seit dem Anstecken“ und die Ladungen je Monat — in beiden Masken. Die Kopfzeile nennt Ansteckzeit, Zahl der Ladungen, kWh und €; ein Tipp auf einen Monat klappt dessen Einzelladungen auf (Dietrich mit seinem Preis, die Hausmaske mit dem echten Viertelstundenpreis aus dess_ist.csv). Die Ansteckmarke hält jetzt eine Gnadenfrist von 180 s aus (eine einzelne Fehlmeldung von EVCC darf weder die Anzeige noch ein angenommenes Fenster wegwerfen) und merkt sich, welches Auto hängt; der Name wird nachgetragen, sobald EVCC ihn meldet. Am echten Vorgang bestätigt: Abstecken 12:38 → Marke gefallen 12:41, Anstecken 17:41 → neue Marke.
• Gebaut am 27.10.2026, 19:00 Dietrichs Ladung lief über die Hochrechnung hinaus — drei Bausteine gebaut. Gemeldet: „85 - 100 % aber das Laden stoppte nicht … es fehlt also auch ein stop taste.“ Nachgerechnet aus Protokoll und Abrechnung: geplant 12,6 kWh, geflossen 14,317 kWh (deckungsgleich mit EVCCs chargedEnergy 14315 Wh). ⚠ Das Fenster war nicht das teure — es war das billigste weit und breit (die ganze Nacht liegt bei 0,40–0,42, der Abend bis 0,49); der Anstieg 0,227 → 0,315 ist der echte Preisverlauf. Drei Ursachen, keine davon „auf das Auto warten“: (1) ohne Fahrzeug-SoC rechnet die Maske nur aus der Eingabe; (2) freigegeben werden ganze Viertelstunden, geschlossen wird erst unter 0,1 kWh offen — um 15:15 fehlten 0,43 kWh, hinein liefen 2,03, also waren bis 2,75 kWh Überschuss eingebaut; (3) EVCCs limitEnergy stand auf 0, es gab nichts, was bei einer kWh-Zahl abschaltet (das Auto zog in der letzten Scheibe noch 8,1 kW, war also nicht voll). ⚠ Und der Notausgang war keiner: die Eingabe von 95 % ist ein neuer Auftrag — sie setzt den Nullpunkt neu, es standen wieder 8,4 kWh offen und Plan 123 plante sie ein; dass nichts mehr lief, lag allein am Preis über Budget. Gebaut, auf die Entscheidung „beides zusammen“: (a) EVCC-Energiegrenze = Sitzungszähler + offener Rest, direkt an EVCCs API, weil die HA-Anbindung nur limit_soc kennt; sie gehört dem Ladepunkt, darum nur beim Leaf gesetzt und nur gelöscht, was wir selbst geschrieben haben (beide Richtungen live gegengeprüft). (b) Minutenbremse nachbar_fenster.py --wacht im Cron mit flock: sie plant nicht, sie bremst — Auflösung 0,18 kWh je Minute statt 2,75 kWh, und sie schweigt, wenn nichts zu tun war. (c) Knopf „Ladung beenden“ mit Marke nachbar_stopp.json: der Stopp hält bis zum Abstecken oder bis Stand und Ziel neu eingetragen werden — ohne die Marke hätte der nächste Lauf die 1,4-kW-Grundladung wieder eingeschaltet. (d) Mitlaufender Zähler statt Prognosesumme: neue Zeile „abgerechnet“, kWh und € aus derselben Quelle und demselben Zeitraum (Abrechnung, seit der Eingabe; EVCCs connectedDuration stand auf 0, der Ansteckzeitpunkt wird nicht geraten). Live-Beweis der Kette: Energiegrenze 22.68 kWh im Protokoll, limitEnergy 22.678 in EVCC — 14,315 Sitzung + 8,363 offen.
• 28.10.2026, 08:30 — gefunden und behoben Dietrichs Maske antwortete mit 500 Too many open files — eine einzige Zeile. Die Startseite kam noch, die Daten nicht. Gemessen: 1023 offene Dateizeiger von 1024, davon 1019 auf nachbar_ladungen.db; der Hausprozess hatte 4. Nach Neustart: 21 Abfragen → 21 neue Zeiger, also genau einer je /api/stand. Eingegrenzt: monat() +10 bei 10 Aufrufen, rechnung_seit() und verlauf() +0. Ursache: with sqlite3.connect(…) as v: — dieses with schließt die Verbindung nicht, es beendet nur die Transaktion. monat() läuft bei jeder Standabfrage, eine Nacht mit offener Seite reicht. Behoben mit closing(); Gegenprobe: 25 Abfragen, Zeiger bleibt bei 5. ⚠ Zweiter Fall desselben Fehlers — beim Austausch-Dienst standen 1019 Zeiger auf austausch.db. Merksatz fürs nächste Programm, das je Anfrage eine Datenbank öffnet.
• Gebaut am 28.10.2026, 09:10 „Günstigstes wäre“ statt „Geladen wird“ — die Maske verspricht nichts mehr, was sie nicht freigibt. Die Suche legt neu fenster_h ab (die Zeit, die die gewählten Viertelstunden wirklich decken), der Server reicht wird_geladen durch — nur der Wahrheitswert, kein Einkaufspreis. Liegt der Einkauf über Budget, heißt es „Günstigstes wäre“, „Dafür nötig“ und, wenn der Plan zu kurz ist, „Reicht aber nur für 0,25 h von 0,5 h“; der Preis trägt die Folge bei sich: 0,40 €/kWh — dafür wird nicht geladen. Geprüft mit node --check (die erste Fassung erklärte die Variable erst nach ihrer Verwendung — im Browser wäre die halbe Seite leer geblieben) und drei durchgespielten Fällen.
• Gebaut am 27.10.2026, 20:20 Grundladung läuft jetzt über EVCC — und drei Textfehler in Dietrichs Maske behoben. Auf „Grundladung umstellen“ und zwei Bildschirmfotos („da steht ziemlicher Unsinn“). (1) grundladung() liest und schreibt am Ladepunkt statt über HA; der HA-Schalter bleibt unangetastet als Anzeige, die MinPV-Automation liest ihn weiter. Live bewiesen bei Modus off, also genau im vorher blinden Fall: von Hand on gesetzt, grundladung(False) schaltete zurück, EVCC las off. Gleicher Fehler im Stoppknopf mitgenommen: der schrieb den HA-Schalter eine Zeile nachdem er den Modus ausgeschaltet hatte — und tu() fängt nur Ausnahmen, also stand „Grundladung aus“ in der Erfolgsliste, obwohl nichts geschaltet wurde. (2) Nach dem Speichern stand der Hinweis zweimal da (grün als Antwort, beige im Kasten) — und das Wort „Gespeichert.“ fehlte ganz. (3) „bis 29.10. 00:00 Uhr“ war richtig gerechnet, aber falsch geschrieben: Mitternacht gehört zum Tag davor, es heißt jetzt „bis morgen 24:00 Uhr“, und der Satz sagt auch wofür die nächsten Preise gelten („morgen Mittag … für übermorgen“); ist dieser Mittag vorbei, keine Zusage für die Vergangenheit mehr. Dazu Umlaute statt guenstiger/naechsten in einem Text, den der Nachbar liest.
• 27.10.2026, 20:25 — wartet auf dich Das Fenster, das keines ist: die Maske zeigt „Geladen wird morgen 15:00-15:15“ zu 0,40 €/kWh — und lädt trotzdem nicht. Belegt aus dem Lauf 20:21: Schnitt 0.363 ÜBER Budget 0.340 → Grenze 0.000. Die Dauer passt auch nicht: angezeigt 0,5 h, gefunden wurde eine Viertelstunde von zwei. Drei Anzeigen sagen etwas anderes als der Hinweis darunter. Vorschlag: bei „über Budget“ nicht „Geladen wird“ schreiben, sondern „Günstigstes Fenster wäre …“, und den Preis als das kennzeichnen, was er ist — der Preis, zu dem nicht geladen wird. Deine Entscheidung.
• 27.10.2026, 20:05 — berichtigt Der Grundladung-Schalter ist NICHT defekt — die HA-Anbindung nimmt ihn weg, solange der Modus off ist. Diese Fassung ersetzt meinen Eintrag von 19:05 („seit dem 26.10. unlesbar“): der Befund dass ins Leere geschrieben wurde, bleibt richtig — die Deutung war falsch, und meine Zeiten darin waren UTC statt Ortszeit, dieselbe Falle, die im Gedächtnis steht. Belegt aus HAs Historie, in Ortszeit: 26.10. 17:36:00 Modus → off = Grundladung → unavailable; 27.10. 08:52:24 Modus → smart = wieder off lesbar; 27.10. 15:26:03 Modus → off = wieder unavailable. Dreimal dieselbe Sekunde, keine Ausnahme — bei ausgeschaltetem Ladepunkt gibt es kein „dauerhaft laden“, die Anbindung blendet den Schalter dann aus. Mein Satz „durchgehend unlesbar, über 26 Stunden“ war falsch: am 27.10. war er von 08:52 bis 15:26 lesbar, und die Befehle um 14:09 kamen an. ⚠ Die echte Folge steht im eigenen Code: im Hauptweg von suchen() läuft tor() (Zeile 1789, setzt den Modus) vor grundladung() (Zeile 1797) — der Modus geht aus, der Schalter verschwindet, der Befehl danach geht ins Leere. An den fünf anderen Stellen ist die Reihenfolge umgekehrt und richtig. Schaden heute nicht eingetreten, aber möglich: bliebe EVCCs alwaysCharge auf on hängen, würde beim nächsten smart ohne Rücksicht auf die Preisgrenze geladen. Schreibweg jetzt geprüft (EVCC 0.318.0): lesen aus /api/state → loadpoints[0].alwaysCharge (auch bei Modus off vorhanden), schreiben mit POST /api/loadpoints/1/alwayscharge/<on|off> → HTTP 200; Probe off→on→off am Zustand gegengelesen, Ladeleistung durchweg 0, Unsinnspfad daneben 404, und die gespeicherte Fahrzeugvorgabe von db:9 blieb unberührt. ⚠ Wartet auf dich: grundladung() auf diesen Weg umstellen — dann ist der Modus gleichgültig und die Reihenfolgenfalle weg; HAs Schalter bleibt als Anzeige für die MinPV-Automation, die ihn nur liest.
• 27.10.2026 — wartet auf dich Der Plan von 15:26 steht noch: 8,4 kWh, morgen 15:00–15:15, Dietrich mit 0,41 €/kWh — für ein Auto, das voll ist. Entweder „Ladung beenden“ drücken oder abstecken. Mit Chip D kann das Programm das Auto nicht erkennen, und das ist konstruktionsbedingt: EVCC ordnet das Fahrzeug über die Karte zu (vehicleDetectionActive ist false), und sensor.nachbar_akkukapazitaet liest die capacity des Fahrzeugs mit dem Titel „Leaf E 75kWh“ — die 75 hängen an der Karte. Der ID.3 pro steht in EVCC richtig mit 59 kWh, mit ihm wären aus 85 → 100 % 9,9 statt 12,6 kWh geworden. Auf derselben Karte ruht die Schreibsperre der Maske — eine zweite Erkennung soll es nicht geben. ⚠ Selbst 12,6 war zu wenig: 14,32 kWh sind auf 59 kWh rund 22 % Akku statt 15 %, die eingetragenen 85 % stimmten also nicht. Beim Leaf ist das nicht zu verbessern (kein SoC); für die eigenen Autos liefert EVCC dagegen einen echten SoC — ob die Hausmaske ihn als Start-SoC übernehmen soll, ist nicht entschieden.
• Dietrichs Maske bequemer machen — Vorschlag vom 18.10., gebaut ist nichts: (a) Fenster ohne Datum, 24 h ab dem Eintragen, eine Alternative jenseits der 24 h wird angeboten statt heimlich genommen; (b) Hinweis „gegen 13:30 kommen die Preise für morgen“, die Zeit aus preise_ankunft.log gezogen, nicht eingetippt. Entschieden am 23.10.2026: 2 ct/kWh auf die Restmenge — Jürgen: „Wenn ich bei Dietrich fast am Minus liege würde es auch nutzen ab 2 Cent.“ Und: die 48-h-Frist gilt NUR für Dietrich, „damit er unseren Ladeplatz wieder frei macht“. Gemessener Rahmen: der Preisblick endet immer mit dem Folgetag — kürzester Fall ~10 h (kurz vor 13:30), längster ~34,5 h; „bis 48 h“ ist nicht zu versprechen.
• Erledigt am 05.11.2026 Fenstersuche fürs Hausauto — und der Satz hier war ungenau. Er sagte „fehlt ganz“; richtig ist: die Suche gab es seit dem 16.10., es fehlte die Tat. Genau das kostete die Nacht zum 05.11. Jetzt gebaut (siehe oben), und die Bedingung von damals ist eingehalten: angefasst wird das Tor nur, solange der Leaf nicht steckt — zwei Schreiber auf einem Feld waren der Fehler vom 12.10. Die Preisgrenze bleibt Dietrichs, sie hat weiter nur einen Schreiber.
• Kristinas Anmeldung für charge.askai.de — nachgeprüft am 21.10.: in users_database.yml stehen nur juergen und dietrich. Ihr Argon2-Hash muss interaktiv erzeugt werden (docker exec -it authelia authelia crypto hash generate argon2), nie über --password — das stünde in der Prozessliste. Danach der Benutzerblock mit Gruppe haus.
• Zwei kleine Dateien werden noch unatomar geschrieben — nachbar_eilig.json und haus_jetzt.json; am 21.10. im Quelltext nachgeprüft, gilt weiter. Klein und selten, aber derselbe Fehlertyp wie bei den Stand-Dateien; der fertige Helfer nachbar_fenster.json_ablegen() liegt daneben.
• Die HA-Kachel schreibt die Frist nicht mehr mit, zeigt es aber nicht an — die drei Felder sind seit dem 17.10. nur noch Anzeige und ab übermorgen verlustbehaftet (jedes Datum wird beim Mitschreiben zu „morgen“). Wer an der Kachel dreht, ändert die Frist nicht. Beabsichtigt, aber eine Falle, solange es dort nicht steht. Vorschlag steht aus.
• Testdaten stecken noch in der Abrechnungssumme — die Probelauf-Scheiben vom 12.10. (1,371 kWh) und 16.10. (0,022 kWh): „wir löschen das wenn der leaf kommt.“ ⚠ Die vier Scheiben vom 17.10. sind echt (zusammen 10,1 kWh, die ersten Ladungen über den Plan) — die bleiben.
• Fensterlogik fürs Hausauto — am 23.10.2026 beschlossen UND GEBAUT. Nach der Ziel-SoC-Eingabe schlägt die Maske vor der Zeiteingabe das günstigste Fenster innerhalb des bekannten Preisblicks vor und sagt dazu, wie weit dieser Blick reicht; drei Knöpfe: bestätigen · anderes Fenster · sofort laden. Drei Regeln: (1) Sofortladen wird nie verschoben. (2) Ein angelaufener Plan wird festgehalten — keine Pause für einen Cent (Durchziehen-Regel vom 17.10.). (3) Ein noch nicht angelaufener Plan darf innerhalb der Frist wandern, wenn neue Preise ein günstigeres Fenster zeigen — das kostet nichts, weil nichts unterbrochen wird. Kein Geld-Schwellenwert dabei, nur eine Rauschsperre von 0,1 ct/kWh: Jürgens Grund war nicht der Cent, sondern „nicht wegen 1 cent ständiges on off. Man bekommt dann auch immer eine push Nachricht vom auto.“ — und ein nicht angelaufener Plan erzeugt kein On/Off. Die Frist ist beim Hausauto wählbar und darf länger als 48 h sein („Das Auto steht da sowieso“). Dass ein Fenster für 75 kWh nicht reicht, ist eingeplant — dann sind es mehrere.
  Gebaut am 23.10.2026, alles mit Gegenprobe: die Schwellen als benannte Konstanten (0,4 ct RAUSCHEN_EUR, 1 ct VERSCHIEBEN_EUR) · die Verschiebe-Regel in festhalten(), jetzt von beiden Suchen benutzt · ein eigenes Plangedächtnis für die Hausuche · Frist 48 h vorbelegt, bei Dietrich gekappt (bei der Eingabe und beim Lesen) · eine eigene Fristzeile je Maske · der Plan verfällt bei einem Fahrzeugwechsel · Knopf „Plan zurücksetzen“ bei der Eingabe.
  ⚠ Noch offen davon: die 2 ct, ab denen Dietrich über die 24 h hinaus wartet — und der Vorschlag vor der Zeiteingabe existiert schon seit dem 16.10. in nachbar_laden.vorschau(), dort also nicht daneben bauen.
  Im Feld noch nicht erprobt — Test mit beiden Masken war für den Abend des 23.10. verabredet.
• IDEEN, ausdrücklich nicht gebaut (Jürgen, 23.10.2026: „Aber dass sind ideen. Jetzt muss es erst einmal wieder zuverlässug laufen“): erst laden, wenn der Strom bei 16 ct steht — oder wenigstens bis 30 % ab 26 ct und dann auf billiger warten. Beides braucht zuerst Zahlen: wie oft diese Preise überhaupt vorkommen, ist aus price_log_db auszuzählen und nicht zu schätzen („ich kenne die Zahlen nicht aktuell war der Preis imemr sehr hoch“).
• Der Hausakku-Schutz ist seit dem 23.10.2026 wieder scharf — aber nur der Einfrier-Weg über DESS. Der Mindest-SoC-Weg und die Notbremse bleiben aus (PV-Drosselung). ⚠ Im Feld nicht erprobt: beim nächsten Schnellladen ist dreierlei zu erwarten — kein „Slot 0 gesichert“ mehr im Logbuch, der Merker input_boolean.dess_eingefroren geht an, die DC-Batterieleistung bleibt bei −5 bis −85 W, und die Freigabe läuft beim Ende einmal. Einzelheiten auf Dynamic ESS.
• Die cloudfreie DESS-Freigabe fehlt noch. Heute geht der Rückweg über den Moduskniff off → auto_vrm, der VRM und Internet braucht und bis zu 70 Sekunden dauert. Jürgens Idee vom 23.10.: Slot 0 beim Beenden aus Slot 1 fortschreiben, also örtlich und ohne Cloud. Was fehlt: acht sensor.dess_slot1_* — die acht für Slot 0 stehen in keiner YAML, sie kamen per MQTT-Discovery.
• Wie oft ein DESS-Fenster in die billigen Stunden fällt, ist ungezählt. dess_plan.py schreibt den Fahrplan seit dem 23.10. stündlich mit (dess_plan.csv); nach einigen Tagen lässt sich an Zahlen sagen, ob sich das Anhängen einer Autoladung an ein DESS-Fenster überhaupt lohnt.
• Die zweite 02:30 des 25.10. ist über die Maske nicht eingebbar — datetime-local kennt kein fold. Betrifft nur die Vorschau, nicht die Steuerung. Einmal im Jahr, eine Stunde.
• 07.11.2026, 17:00 — gefunden Das Prozentlimit der Hausmaske war eine Platzpatrone. Jürgen hat das Fahrzeug in EVCC neu als „ID.3 Pro" ohne API angelegt (db:13, Merkmal Offline, 59 kWh), weil EVCCs socBasedPlanning() am Fahrzeugtyp hängt und limitEnergy bei einem WeConnect-Profil grundsätzlich ignoriert. Das Wegnehmen der VW-Zugangsdaten hätte nicht gereicht. Folge: EVCC meldet dauerhaft vehicleSoc = 0 — die Maske setzte limitSoc = 30, effectiveLimitSoc stand auf 30, erreicht wurde es nie. Gestoppt hat die kWh-Grenze der Wallbox bei 2.029,6 von 2.000 Wh, also neun Sekunden Überlauf bei 11,4 kW. Damit ist der dwo-Test endlich positiv — zwei Versuche am Vormittag waren von mir falsch aufgebaut (Limit gesetzt, als der Sitzungszähler schon darüber stand; die Box setzt ein überschrittenes Limit nicht rückwirkend durch).
• 07.11.2026, 17:09 — gefunden Der Stopp-Knopf der Hausmaske schrieb in die Dateien der Nachbarmaske. Auf der Platte lag nachbar_stopp.json mit {"zeit":"2026-11-07T17:09:53+01:00","wh":1967.0} — die 1.967 Wh waren der Sitzungszähler von Jürgens ID.3. Zwei Folgen, beide gemessen: Dietrichs Maske hielt einen Handstopp, den er nie gedrückt hatte, und Jürgens eigener Plan lief weiter (haus_fenster.log legte um 17:15 „Plan 233" an). Nebenbei beantwortet die Datei, wer EVCC um 17:09:53 auf off gestellt hat — das HA-Logbuch konnte es nicht sagen, weil alle Skripte mit Jürgens Token schreiben und dort aussehen wie sein Fingertipp. Lehre: nicht nur HA befragen, auch die eigenen Markendateien.
• 07.11.2026, 17:20 — gefunden Eine Automation löschte die Mengengrenze bei jedem Auto, alle fünf Minuten. automation.evcc_fahrzeug_ladelimit_setzen prüfte drei Fahrzeugnamen, von denen keiner mehr traf — unter anderem „Nachbar", während der Leaf in EVCC längst Leaf E 75kWh heißt. Belegt an Dietrichs Protokoll vom 30.10.: von 01:15 bis 03:45 schreibt jeder Viertelstundenlauf erneut „Energiegrenze 4.22 kWh" — die Maske schreibt diesen Satz nur bei Abweichung, musste also jedes Mal neu setzen. Dietrichs kWh-Grenze hat seit ihrem Bau am 27.10. nie länger als fünf Minuten gehalten. Verloren hat er dadurch nichts: 18 Viertelstunden, 10,412 kWh, jede Ladung unter der geplanten Menge, beendet jeweils vom Auto oder vom zufallenden Tor. In einer anderen Automation stand die Warnung „wird er in EVCC umbenannt, müssen BEIDE nachgezogen werden" — es waren drei, und die dritte war vergessen.
• 07.11.2026, abends — gebaut Fünf Umbauten an den Masken. (a) Die Hausmaske rechnet in kWh statt Prozent — limitEnergy = Sitzungszähler + offen, denn EVCC prüft gegen chargedEnergy, und das zählt ab dem Anstecken; übernommen von Dietrich samt Merker, Freigabe bei erreichtem Ziel und Freigabe bei fremdem Auto. (b) Handstopp: „Stop ist stop sollte auch einen Plan stoppen. Man muss dann neu planen." Meine erste Fassung erriet die Hand am Modus — das löste ohne Hand aus (mein eigener Code beim Ablauf von „Jetzt", Dietrichs bedingungslose Chip-Automation, ein 53 Sekunden langes unavailable beim EVCC-Neustart) und ist wieder heraus; der Stopp kommt jetzt vom Knopf. (c) Regel „nur eigenes Auto mit Chip": beide Masken fragen positiv statt negativ — vorher zählte auch „kein Auto am Kabel" als eigenes. Öffnen braucht ein eigenes Auto, Schließen und Aufräumen darf immer. (d) Ein Auftrag gilt für eine Steckverbindung, erkannt am Rücksprung des Sitzungszählers; Jürgen: „wenn wieder angesteckt wird muss man wieder mit dem chip freischalten" — der Griff zum Chip ist der neue Auftrag. (e) Härtung: ein stummes Home Assistant erfindet keinen Auftrag mehr (vorher still 10 → 90 % = 67,2 kWh), der Viertelstundenlauf bricht nicht mehr ohne Protokollzeile ab, except OSError verschluckt keinen fehlgeschlagenen POST mehr, und ein Grenz-Merker ohne Grenze räumt sich selbst weg (Dietrichs stand acht Tage auf 7,801).
• 07.11.2026, 21:25 — gebaut Schritt 0 und 1 der Trennung (Vorschlag und Begründung: Hausladen und Nachbarladen trennen). Schritt 0: die Gast-Automation ist off mit initial_state: false — sie hat keine Aufgabe mehr, weil der Gast auf Jürgens Wort ins Hausladen gehört („Ich lege dann die kwh des Autos in evcc an", Kapazität kommt aus EVCC). Geprüft: kein Skript und keine andere Automation liest input_number.evcc_gast_ziel_kwh. Schritt 1: ladepunkt.py beantwortet als einzige Stelle, wem der Ladepunkt gehört — haus, nachbar oder niemand, aus Stecken und Chipkennung; die Kartenliste steht nur noch dort, und python3 ladepunkt.py ist ein Selbsttest. Mit dran hängen jetzt auch „Jetzt laden" (wies vorher nur Dietrichs Karte ab — ohne jedes Auto am Kabel hätte die Taste geschaltet) und das Speichern der Eingaben. Beim Zusammenlegen fiel ein eigener Fehler auf: meine sein_auto() von zwei Stunden vorher verglich mit KARTE, und KARTE ist in nachbar_fenster.py nie definiert — beim Öffnen des Tors hätte das abgebrochen, ein Syntaxtest findet das nicht. Genau dafür gibt es jetzt eine Stelle statt dreier.
• 07.11.2026 — offen Schritt 2 bis 5 der Trennung: eigene Zählerzeile je Maske (belegt nötig — am 07.11. um 17:00:01 überschrieb der Hauslauf Dietrichs Nullpunkt mit Jürgens 23 %), eigene Eingabefelder, Ansteckmarke zum Kabel, zuletzt das Programm teilen. Dazu drei Kleinigkeiten: derselbe Eintrag hebt den Handstopp nicht auf (Abweichung ab 0,5 % nötig), obwohl der Hinweistext „trag Ladestand und Ziel neu ein" sagt — entweder die Regel oder der Text muss weichen; der Gast-Zweig rechnete den Sitzungszähler nicht mit (mit der Abschaltung gegenstandslos, aber zu prüfen, wenn der Gast zum ersten Mal lädt); und in der letzten Viertelstunde einer Ladung steht manchmal ein anderer Preis als zugesagt (belegt 30.10.: 0,46 und 0,35 bei derselben Zusage) — in der Testphase ohne Bedeutung, Dietrich hat noch kein Auto.

Hausakku — Zellabgleich und Volladung, Stand 25.10.2026

Am 25.10. wurde die Kapazität im BMS von 628 auf 672 Ah gestellt und zweimal vollgeladen. Der obere Anker fiel um 16:16:25 — auf vier Sekunden genau mit Ablauf des RCV-Timers, damit ist der Mechanismus an der eigenen Anlage belegt: „BMS resets to 100 % only if Vbat ≥ SOC100%Vol at this point“. Der Zähler sprang dabei um 44 Ah — genau der vorhergesagte Versatz. Die Spreizung in der Erhaltung fiel von 16 auf 8 mV, am Abend bei gleichem Strom (2 A) von 27 auf 5 mV. Einzelheiten im Gedächtnis unter project_hausakku_soc_kalibrierung.md.

• Erledigt am 26.10.2026 Rückstellung umgebaut — an beiden Stellen. Auch akku/ladefenster_wacht.py stellt den Mindest-SoC nicht mehr zurück (Auftrag „ja nimm sie da auch raus“); dort bleibt als einziger Schreibzugriff DESS = 1, der Mindest-SoC wird nur noch gelesen und im Protokoll angezeigt. Sicherung ladefenster_wacht.py.bak_20261026_vor_minsoc_ausbau. Im Zustandsautomaten des Reiters ist das Schreiben auf acsystem/0/Settings/Ess/MinimumSocLimit entfallen; zurückgestellt werden nur noch DESS = 1 und das Ladefenster auf Day = −7. Das Lernen des Ruhewerts bleibt als reine Anzeige. Eingespielt per PUT /flow/<id> — nicht POST, das erzeugt einen zweiten Reiter. Ursprünglicher Auftrag: Der Node-RED-Reiter „Hausakku Abgleich“ (Ekrano, https://192.168.6.19:1881/abgleich) stellt am Ende eines Laufs Mindest-SoC, DESS-Modus und Ladefenster zurück. Der Mindest-SoC gehört heraus, nur DESS und Fenster bleiben. Zwei Gründe: (1) Beim Autoladen heben die HA-Automationen den Mindest-SoC an, um den Hausakku zu sperren — eine Rückstellung mitten in einer EV-Sitzung würde den Akku freigeben, bis der HA-Wachhund binnen fünf Minuten nachzieht. Zwei Schreiber auf einem Feld, derselbe Fehlertyp wie am 12.10. (2) Er wird gar nicht gebraucht: am 25.10. hat das Ladefenster von 95 % aus geladen, während der Mindest-SoC auf 94 stand und keine Rolle spielte. Er kann auf seinem Ruhewert bleiben.
• Rückstellung aus der Python-Wache entfernen — akku/ladefenster_wacht.py stellt ebenfalls zurück. In der Nacht 25./26.10. schreiben beide dieselben Werte, das ist folgenlos; nach dem ersten erfolgreichen Node-RED-Lauf gehört es dort heraus.
• ⚠ Das Ladefenster ist seit dem 26.10. 01:19 aus (Day = −7, vom Node-RED-Reiter selbst gesetzt, um 09:12 und nach dem Venus-Update nachgemessen). Die Falle bleibt beschrieben, weil sie bei jedem Lauf wiederkommt: Schedule/Charge/0/Day = 7 heißt täglich, Start 19:00, Dauer 8 h, Ziel-SoC 100. Mit eingeschaltetem DESS läuft es ins Leere, weil DESS die Arbitrierung gewinnt (control_priority 0 gegen 20) — aber an jedem Abend, an dem DESS aus ist, würde um 19:00 ungeplant vollgeladen. Abschalten geht über Day = −7.
• RCV-Zeit wieder senken, sobald die Erhaltungsspreizung stehen bleibt. Reihe jetzt vollständig: 24./25.10. 16 mV → 25.10. mittags 8 mV (4,0 h RCV) → Nacht 25./26.10. 7,6 mV (6,0 h RCV). Der Anker fiel um 01:13:04 nach 6,01 h Absorption, das BMS senkte sein Soll selbst von 55,20 auf 53,60 V. Die zwei zusätzlichen Stunden brachten 0,4 mV — das liegt im Rauschen (der Reiter rechnete aus seiner eigenen Probenreihe 6,4 mV), und während der Absorption stand die Spreizung ab 20:31 fünf Stunden auf 3–4 mV, ohne weiter zu fallen. Damit ist die Grenze nicht die Zeit, sondern der Unterschied der Zellen selbst — die RCV-Zeit kann zurück auf 1–2 h, denn der Anker hängt am Ablauf des Timers, nicht am Abgleich. Zum Abwägen: jede Haltestunde kostet rund 0,9 kWh Hausbezug, die sechs Stunden also 5,4 kWh für 0,4 mV. Entscheidung liegt beim Nutzer. Balanciert wird nur in der Absorption (erst über 3,45 V je Zelle), die Absorptionsdauer ist also die einzige Balancierzeit.
• Offene Probe: begrenzt die Absorptionszeit des Multi überhaupt? Alle drei Multis melden State = 252 „External control“ und TimeInAbsorption = 0, obwohl vier Stunden Absorptionsspannung anlagen — das Ekrano-Handbuch 12.3 sagt, bei ESS und verwalteter Batterie sei die interne Ladealgorithmik deaktiviert. Dann wäre die Kopplung „Multi immer 0,5 h länger als das BMS“ gegenstandslos. Probe: BMS-RCV länger als die Multi-Zeit stellen und sehen, was an deren Ablauf passiert. Am 25.10. nicht möglich, weil der Nutzer aus Sicherheitsgründen beide mitgezogen hat (BMS 6,0 h, Multi 6,5 h) — richtig so, die Probe kostet an einem Abend ohne Bedarf nichts.
• Volladung mit einer Autoladung verbinden — Idee des Nutzers vom 25.10.: während des Fensters wird der Hausakku ohnehin oben gehalten und das Haus läuft am Netz, das Auto kostet dann keine Akkuzyklen. Nicht während des Bulk — die Lasten hängen hinter dem Multi (18 kW), und der Bulk zog am 25.10. 7,6 kW in den Akku. In der Absorption ist Platz, der Akku nimmt dort fast nichts. Der Bulk dauerte von 95 % aus nur 12 Minuten.
• Was eine Volladung wirklich kostet — am 25.10. gemessen, weil die erste Schätzung falsch war: in den Akku gingen in 3,75 h Absorption nur 0,25 kWh. Teuer ist nicht die Absorption, sondern dass der Akku das Haus nicht versorgt: rund 0,9 kW Hauslast über die ganze Fensterdauer. Balancierzeit kostet also etwa 0,9 kWh je Stunde, nicht 0,06. Kostenformel: 8,4 kWh × Preis(Startstunde) + 0,9 kW × Σ Preis(übrige Stunden).
• Erledigt am 25.10.: Settings/DynamicEss/BatteryCapacity auf 34,41 kWh (vorher 32,16 = 628 Ah). Sie zieht nicht von selbst nach, obwohl battery/512/InstalledCapacity über CAN auf 672 gewechselt ist — muss bei jeder Kapazitätsänderung von Hand mit, nur über dbus/MQTT, in VRM gibt es den Wert nicht.
• BMS-Einstellungen aus dem Vergleich mit der Off-Grid Garage, weiter offen: Charge OTP und Discharge OTP 70 → 55 °C (OTPR 60 → 50), Charge UTPR 2 → 5 °C, Cell OVPR 3,400 → 3,440 V. Einzelheiten im PDF upload/JK-BMS Volladen und Einstellungen 2026-10-24.pdf. Nicht ändern: Re-Bulk SOC bleibt 1 % (kürzeste Erhaltung = meiste Ankergelegenheiten), SCP Delay bleibt 5 µs.

Smart Meter, Venus 3.85 und Opportunitätslasten — Stand 26.10.2026

Am 26.10. wurde der Smart Meter eingebaut (Stromausfall zwischen 07:39 und 07:57:32, im eigenen Protokoll als fehlender Netzwert um 08:00:01 sichtbar). Damit ist der Wendepunkt da: Bezug und Einspeisung zählen ab heute getrennt. Einspeisung bringt die 7,66 ct, die in DESS als Verkaufspreis stehen, Bezug kostete am Morgen 23–36 ct. Jede Rechnung nach dem Muster „hebt sich eh 1:1 auf“ ist ab jetzt falsch. Danach hat der Nutzer Venus OS von 3.81 auf 3.85 aktualisiert.

• Gebaut am 26.10.2026 „Wer schreibt wohin“ — die Übersicht steht: docs.mttec.de/schreiber/ Anlass war der Satz des Nutzers: „aber ehrlich gesagt weiß ich es nicht mehr. wir haben zu viel geändert. wir müssen das mal sauber durchgehen.“ Erzeugt von ~/energie/schreiber_karte.py, nach Hebeln statt nach Dateien: die Zeile ist das Register, nicht die Automation — quer zu Was gebaut wurde. Erster Lauf: 40 Stellwerte, 14 davon mit mehr als einem Schreiber, 22 Automationen, 8 eigene Programme, 12 Node-RED-Schreibknoten. Die Seite prüft sich selbst: Automations-Aktionen werden rekursiv durchsucht (choose, if, repeat), jedes Programm trägt ein Prüfmuster, das gegen die Datei gehalten wird, und eine Drift-Suche meldet schreibende Programme, die noch niemand eingeordnet hat. Dazu ein eigener Fehler, der jetzt als Begründung im Code steht: der erste Lauf meldete den Node-RED-Reiter als Schreiber des Mindest-SoC — ein Pfad im Quelltext ist kein Schreibzugriff, der Reiter liest ihn in einem Knoten und schreibt in einem anderen.
• Erledigt am 26.10.2026, 23:42 — Stufe 1 Das Auto-Laden-Kapitel im HA-Dashboard ist zurückgebaut: sechs Reiter raus, nur noch Energiefluss und Bosch WP. Weg sind „Übersicht“, „Sofort laden“, „Ladeplan“, „Automatik“, „Hausakku Laden“ und „Auto Laden (alt)“. Der Nutzer: „alste logik und unsere 2 apps decken das ab oder?“ und „Haus akku laden ist alter schrott. Das lösen wir ja über diesen Termin im Ekrano udn ess.“ — geprüft, es trägt: dess_akku_einfrieren_wachhund erkennt Schnellladen mit ODER an drei Dingen, darunter die EVCC-Betriebsart now; von den neun Automationen am Merker evcc_schnell_netz liest jede ihn nur, geschaltet wurde er allein von drei Skripten der gelöschten Reiter. Weg über lovelace/config/save (wirkt ohne HA-Neustart), Sicherung in ~/energie/backups/. Gegenprobe: beide Masken 200, alle sechs Schutzautomationen on. Die Programmierung ist absichtlich unberührt geblieben — siehe den nächsten Punkt.
• Erledigt am 27.10.2026, 09:40 — Stufe 2 Die elf verwaisten Objekte sind weg. Fünf Skripte (scripts.yaml enthielt genau diese fünf und ist jetzt ein {} mit Begründung im Kopf), drei Bestätigungs-Merker, drei Template-Sensoren. Niemand rief sie mehr auf — geprüft gegen automations.yaml, configuration.yaml, das neue Dashboard, Node-RED und alle .py unter ~/energie; der einzige Treffer außerhalb war ein Kommentar in einem Sensor, der selbst wegfiel. Der Weg, der sich bewährt hat: an einer Kopie schneiden, Zeilenbereiche vorher mit Stichproben prüfen und von unten nach oben löschen; dann YAML-Diff als Beweis (genau 3 Merker und 3 Sensoren weg, alle übrigen Abschnitte identisch); Sicherungen auf dem HA und md5 beidseitig verglichen; check_config → valid vor den drei Reloads (kein Neustart nötig); zuletzt die Registry-Karteileichen über config/entity_registry/remove (1660 → 1652), sonst bräuchte es keine fünf Minuten bis zur nächsten unavailable-Leiche. Gegenprobe: 11 von 11 weg, 0 unavailable Skripte oder Merker, alle sechs Schutzautomationen on, beide Masken 200, sensor.ladeempfehlung 0,3152. ⚠ Präzisierung zu yaml.safe_load: es scheitert an HAs !include — ein add_multi_constructor("") auf einem eigenen Loader löst das.
• Erledigt am 27.10.2026, 10:45 — Stufe 3 Die Schnelllade-Merker sind weg — damit ist das Auto-Laden-Kapitel in HA vollständig zurückgebaut. Auf die Frage „wofür solld er sein?“: evcc_schnell_netz war der Absichtsschalter „ich will jetzt 11 kW aus dem Netz“ vom Reiter „Sofort laden“ — EVCC-Ladepunkt aus und go-e direkt auf 16 A/3-phasig, Netzsollwert 11 kW alle 15 s aufgefrischt, Mindest-SoC anheben, Dashboard auf „Laden jetzt stoppen“ reduziert. Abgelöst am 10.09.2026, als auffiel, dass der ganze Hausakku-Schutz an dieser einen Stelle hing: startete EVCC von sich aus, kamen die 11 kW aus dem Hausakku. Seitdem erkennen die Schutzautomationen ein Schnellladen an EVCCs eigenen Signalen (mode = now, Preisladen). Umgebaut: 9 Automationen, mit vorher im Code festgelegten Regeln („Merker off“ fällt weg, weil ohne Schreiber immer wahr; „Merker on“ fällt als ODER-Zweig weg, weil nie wahr; Jinja wird true/false) und Trockenlauf vor dem Schnitt. dess_akku_freigeben behält 4 von 5 Auslösern, victron_ess_status_abfragen 2 von 3 — keine Automation ohne Auslöser, das prüft das Skript ausdrücklich. Entfernt: 9 Helfer, sieben davon schon vorher unreferenziert (Zeitwerte standen noch auf dem 11.09.). ⚠ Zwei Fallen unterwegs: der Abschnitt input_datetime: enthielt nur diese Helfer und wäre leer zurückgeblieben (Kopfzeile mit entfernt; die UI-Helfer in .storage sind unberührt, wanne_ladezeit lebt — daran hängt der Auslöser der Wannenladung); und die erste Skriptfassung hätte zwei Automationen nicht geschrieben, weil der Merker in ihrer description stand — im Fließtext zur Geschichte, nicht in der Logik. Die Beschreibungen bleiben jetzt und bekommen einen Nachtrag. Gegenproben: Sicherungen mit md5-Vergleich, YAML-Diff (alle übrigen Abschnitte unverändert), check_config valid, keine funktionale Referenz mehr, 22 Automationen — 18 on, 4 aus und zwar genau die vorher schon abgeschalteten, 0 unavailable bei Helfern/Skripten, beide Masken 200, Fault-Datei 0 Bytes.
• Was von der Lade-Bedienung bleibt — zum Nachlesen, falls etwas fehlt. Gesteuert wird jetzt über EVCC selbst und die zwei eigenen Masken (8089 Nachbar, 8091 Haus); geschützt wird der Hausakku über das DESS-Einfrieren, erkannt an mode = now oder Preisladen. Nicht mehr vorhanden: ein Bedienweg, der gleichzeitig den Mindest-SoC anhebt — der dafür zuständige hausakku_schutz_evcc_schnellladen steht seit dem 23.10. absichtlich aus, weil er die PV drosselte und still versagte.
• 27.10.2026 — Beobachtungsposten Bitaxe läuft seit 27.10. 09:35 auf 1200 mV / 550 MHz / 62 °C — vom Nutzer selbst gesetzt, nachdem der Lauf mit 1150/525/60 25,6 h fehlerfrei durchging (26.10. 07:58 bis 27.10. 09:35, aus dem Statistik-Ringpuffer gemessen; der Umschaltzeitpunkt steht als Spannungssprung 1144 → 1195 mV in den Daten). Ausgangsmessung 09:50: coreVoltageActual 1195 mV (nicht gekippt), 2244 GH/s bei 41 W, overheat_mode 0. Warum beobachten: 1200 mV ist der Wert, bei dem der alte Bestwert nur 321 min war. Kommt der Lauf deutlich über 5–6 h, ist die Zuordnung „1200 mV ⇒ Fehler nach ~5 h“ widerlegt. Nichts verstellen, nur messen.
• Erledigt am 26.10.2026, 23:00 Die Cron-Zeile für die neue Seite steht — 06:35, fünf Minuten vor bestandsaufnahme.py. Crontab von 69 auf 74 Zeilen, Sicherung ~/energie/crontab.bak_20261026_vor_schreiber_karte; Seite danach neu erzeugt (Stand 22:58), der rote Kasten ist weg. Der Weg dahin ist die eigentliche Lehre: zwei Versuche wurden mit [Unauthorized Persistence] abgelehnt, obwohl in den Mitschnitten elf gleichartige Crontab-Schreibaufrufe stehen, die vom 23. bis 25.10. alle durchgingen. Ich schloss daraus auf einen wackelnden Prüfer — falsch. Der Nutzer rief /auto-mode-setup auf („ich musste den auto mode anpassen“), danach ging derselbe Befehl beim ersten Versuch durch. Die Entscheidung hängt am autoMode-Block in ~/.claude/settings.json, nicht an permissions (das ist leer). Regel fürs nächste Mal: bei „ging doch sonst“ nicht auf Zufall schließen, sondern fragen, welche Einstellung sich dazwischen geändert hat — und die Zeitstempel der Einstellungsdateien ansehen, nicht nur ihren Inhalt.
• Berichtigt am 26.10.2026, 23:10 — mein Fehler Fund 1 war falsch: die Rückstellung in akku/volladen_beobachter.py ist KEINE Doppelung und bleibt drin. Der Nutzer hatte den Ausbau schon freigegeben („ja nimm sie da auch raus“) — ich habe vor dem Schnitt geprüft, und es wäre eine Falle geworden. Der Beleg steht in der Wachhund-Konfiguration: er holt den Mindest-SoC nur zurück, wenn input_boolean.ev_minsoc_erhoeht fünf Minuten on ist — das ist der Merker der Auto-Automationen, und ein Volladungslauf setzt ihn nicht (er schreibt direkt per MQTT). Zum Volladen steht der Mindest-SoC aber auf 100. Ohne Stufe C bliebe er dort stehen und der Hausakku gäbe nichts mehr ab, bis es jemand von Hand merkt — genau der Fehler vom 24.10., nur mit dem anderen Register. Also ist dieses Skript der einzige Rücksteller nach einem Volladungslauf. Der Ruhewert-Nachführer (Punkt 3 derselben Stufe) schreibt den Mindest-SoC ohnehin nicht, er merkt ihn nur in input_number.ev_mindest_soc_vorher. Hinweis auf der Übersicht berichtigt. Lehre: „mehrere Schreiber“ ist ein Anlass zum Hinsehen, kein Befund — ich hatte die Zahl 3 gemeldet, ohne die Bedingungen des Wachhunds gelesen zu haben.
• Was statt Fund 1 wirklich aufzuräumen ist: die hartkodierte 20. Sowohl der Volladen-Beobachter als auch früher der Reiter und ladefenster_wacht.py tragen 20 als Zahl im Quelltext, während der Wachhund den gemerkten Ruhewert aus input_number.ev_mindest_soc_vorher nimmt (steht derzeit auch auf 20). Vorschlag: Stufe C liest diesen Merkwert und fällt nur auf 20 zurück, wenn er unbrauchbar ist — eine Quelle der Wahrheit statt zwei. Entscheidung offen.
• Erledigt am 27.10.2026, 10:15 Fund 2 behoben: die Wannenladung prüft jetzt den Einfrier-Merker. Der Fund hat die Prüfung gehalten (diesmal Aktion für Aktion gelesen, bevor etwas geändert wurde): einzige Bedingung war die Speichertemperatur, und die Variable einfrieren sah nur auf Preis und DESS-Modus node_red. Am Ende setzt die Automation DynamicEss/Mode → 1 und leert input_text.dess_slot0_sicherung. Lädt das Auto samstags gleichzeitig, sichert sie also die Einfrier-Werte des Wachhunds statt des echten DESS-Plans und gibt den Akku am Ende frei, während noch geladen wird — der Wachhund zieht im Minutentakt nach, die Lücke ist kurz, aber da. Jetzt endet einfrieren auf and not is_state('input_boolean.dess_eingefroren','on'): ist schon eingefroren, lässt die Wanne DESS in Ruhe — ihr Ziel ist dann ohnehin erfüllt, der Akku ist gesperrt. Die Warmwasserladung selbst hängt nicht an einfrieren und läuft unverändert; die Push-Meldung hat einen dritten Fall bekommen. Gegenproben: Sicherung auf dem HA, Auslöser/Bedingungen/Modus unverändert, check_config valid, Automation on, Vorlage live gerendert (einfrieren=False, Preis 30,2 ct über der 25er-Grenze). Die Begründung steht in der description der Automation — dort, wo heute zweimal der entscheidende Beleg stand.
• Erledigt am 27.10.2026, 10:10 Fund 3 behoben: nachbar_fenster.py liest den Mindest-SoC nur noch am Gerät. Das max() über beide Quellen ist weg, die Konstante für die number.-Entität ebenfalls. Was der Fehler angerichtet hätte: am 22.10. zeigte jenes Register 73 %, während der Akku bis 48 % durchlief — der Schutzcheck hätte „Hausakku am Mindest-SoC, gibt nichts ab“ gemeldet, genau als er abgab. Beleg und Datum stehen jetzt als Kommentar im Code, dazu ein ⚠-Satz im Docstring. Gegenprobe live: akku_gesichert() → Hausakku 44 % frei; beide Quellen stehen heute auf 20, der Fehler war also latent. Nebenbefund: die Masken laufen als systemd-Dienste mit Restart=always, nicht per Cron — die Notiz dazu im Gedächtnis war veraltet. Darum genügt für den nötigen Neustart ein pkill als juergen, kein sudo: neue PIDs, beide Dienste active, beide Ports 200, Ausfall unter 10 Sekunden.
• Beobachtungsposten: SG-Ready-Trockenkontakt für die Bosch über GX Opportunity Loads. Victron kündigt in der Präsentation „GX Opportunity Loads“ drei Erweiterungen an: eine Node-RED-Palette für eigene Geräte, Wärmepumpensteuerung über SG-Ready-Trockenkontakt und eine EEBUS-Anbindung. Der SG-Ready-Weg ist für uns der interessante, weil der EEBUS-Weg erprobt und gescheitert ist (Störung A91/1240, am 22.09.2026 im Bosch-Menü getrennt) und weil der PV-Kontakt hpin4opt an der Bosch bis heute fehlt. Nichts zu tun, nur verfolgen — es ist angekündigt, nicht vorhanden.
• Opportunitätslasten sind die Alternative zu DESS, nicht die Ergänzung. Victron wörtlich: „Users can choose the one strategy that best fits their system and needs.“ Der Nutzer am 26.10.: „geht aber mit DESS nicht, jedenfalls muss ich es vorher deaktivieren.“ DESS optimiert über Preis und Prognose, Opportunitätslasten über den PV-Überschuss im Augenblick — ausdrücklich gedacht für Inselanlagen, Nulleinspeisung und Festpreis. Unterstützt werden heute nur die Victron-Ladestation und sechs geprüfte Shelly-Modelle; die go-e ist nicht dabei, und ein zweiter Regler auf ihren Parametern würde gegen EVCC arbeiten. Am Gerät steht die Funktion aus: Settings/Services/OpportunityLoads = 0. Bewertung: nicht einschalten — wir speisen ein und bekommen 7,66 ct, ab Ende November läuft Tibber, also ist die preisgeführte Strategie die richtige.
• Geklärt am 26.10.2026 Die zwei abgeschalteten Wärmepumpen-Automationen sind Entwürfe — absichtlich aus. Beim Aufräumen der Karteileichen gezählt: von den 22 verbliebenen Automationen sind 18 an und 4 aus. Zwei stehen dokumentiert aus (hausakku_schutz_evcc_schnellladen und die Notbremse, Begründung vom 23.10.). Die anderen zwei sind wp_pv_modus_ueberschuss und wp_ww_im_pv_betrieb; der Nutzer wusste es sofort: „ich denk das hat was mit dem PV Schalter bei der Bosch zu tun. mher heizen oder extra warmes wasser bei PV überschuss.“ — genau so ist es. Die erste schaltet den PV-Kontakt text.boiler_hpin4opt bei SoC ≥ 95 % und mindestens 1 kW Einspeisung, die zweite hängt die Warmwasserladung an einen bereits laufenden Kompressor an. Beide am 26./27.09.2026 gebaut und gleich deaktiviert; der Beleg steht in ihrem eigenen description-Feld: „ENTWURF, deaktiviert.“ Was vor dem Einschalten zu klären bleibt: die 2-K-Heizungsanhebung lief am 01.10. ins Leere, weil die Stube ohne Raumfühler regelt — der Warmwasserteil ist dagegen belegt (pvenabledhw lädt bis 62 °C ohne Heizstab). Neu dafür spricht die Preislage: seit dem Smart Meter bringt Einspeisung nur 7,66 ct, Überschuss selbst zu verheizen ist damit erstmals sicher besser. Bei der nächsten Wärmepumpen-Runde entscheiden.
• Geklärt am 26.10.2026 — kein Handlungsbedarf Die 26 „fehlenden“ Automationen in HA sind Karteileichen einer gewollten Löschung. Nach dem HA-Update des Nutzers am 25.10. abends standen 26 von 48 Automationen auf unavailable, alle mit restored: True und echter id — der komplette EV-Block. Grund: sie wurden am 18.10.2026 auf Auftrag entfernt („und ha durchgehen das der alte kram raus ist. Autoladen und hausakku Laden kann raus“); die Sicherungen auf dem HA tragen den Grund im Namen: automations.yaml.bak_20261018_vor_loeschen_alte_ladelogik (48 ids), …_vor_loeschen_schnellnetz_ev (30 ids), heute 22 ids — 48 → 30 → 22, genau die Differenz von 26. Der Zeitstempel 22:51:43 ist nur der Neustart: HA legt gelöschte Entitäten aus seiner Registrierung als restored wieder an. Nichts wiederherzustellen. Aufgeräumt am 26.10.2026 um 13:06 auf Auftrag „ja räum die karteileichen auf“: alle 26 Registrierungseinträge per WebSocket config/entity_registry/remove entfernt, kein Neustart nötig. Vorher dreifach abgesichert — jeder Kandidat unavailable und restored, keine seiner ids unter den 22 aktiven (Treffer 0), und jede der 22 aktiven ids hat eine lebende Entität (Fehlende 0); dazu alle 26 entity_id gegen ganz /config gegrept: 0 Verweise. Sicherungen core.entity_registry.bak_20261026_vor_karteileichen und core.restore_state.bak_20261026_vor_karteileichen. Ergebnis live: Registrierung 1692 → 1666, automation.* 48 → 22 (18 an, 4 aus). Die 112 weiteren restored-Karteileichen im System (größtenteils FritzBox-DECT-Entitäten) bleiben bewusst stehen — bei denen ist offen, ob die Integration sie nur gerade nicht anbietet.
• Venus 3.85 hat nichts verstellt — geprüft, nicht vermutet. Vorher/nachher je eine vollständige Aufnahme (ekrano/zustand_vor_venus_385_20261026.txt und …nach_…): 19 Dienste vorher, 19 nachher, keiner fehlt, keiner neu; alle Einstellungen identisch (drei Steuerpfade 20,0 / 1 / 0, aktive Grenze 20,0, State 252 auf allen drei Multis, DESS 1, Kapazität 34,41, Ladefenster Day −7, DVCC 157 A, BMS 55,20 V / 240 A, installiert 672 Ah). Der Node-RED-Reiter hat den Neustart überlebt, die Laufzeile kam aus der Datei zurück. In HA kamen neun Victron-Entitäten wieder (unavailable 23 → 14). Merkposten bestätigt: vor jedem GX-Update den Zustand aufnehmen.
• Der Miner hing nicht am gestützten Zweig. Der apps-server lief durch (22 Tage Laufzeit), das Haus trug der Akku (SoC 93 → 87 % über den Morgen) — der Bitaxe war trotzdem weg. Nebenbei entstand damit der beste Messpunkt der Fehlersuche: 21,8 h ohne Reglerfehler bei Standardwerten 1150 mV / 525 MHz, beendet vom Zählerwechsel und nicht vom Fehler — das Vierfache des alten Bestwerts von 321 min. Solange der Lauf steht, nichts verstellen.

Sofort — noch offen

• Die Hausdienste ziehen von mttec.de auf askai.de — DNS steht seit dem 12.11.2026. Der Grund ist nicht technisch: Jürgen am 09.11. — „mttec ist firma und askai privat". Dazu zieht mttec.de gerade um (Sitzung webserver). Jürgen hat am 12.11. vier Namen als CNAME auf ztxweeuwwq3tzjoc.myfritz.net.: ha, evcc, docs, solar — TTL 7200, nachgeprüft, alle vier lösen auf 79.140.124.43. brc ist bewusst weggelassen („brc habe ich weggelassen das brauche ich nicht mehr“): auf dem apps-server ist davon nichts übrig — am 29.09. und erneut am 12.11. gesucht, kein Verzeichnis, keine nginx-Site, kein Dienst, kein Cron, kein Container. Der alte CNAME brc.mttec.de bei Publicomp und der Vhost auf der .55 bleiben offen, beides nicht dieser Bereich. auth.askai.de, laden und charge standen schon. Jetzt ich: Apache-Vhosts und certbot-Befehl je Name schreiben, dann Authelia nachziehen. Gemessen am 09.11.: die sechs mttec-Namen haben bei den autoritativen Nameservern null Einträge — von außen ist schon jetzt nichts erreichbar, es kann also nichts ausfallen. Lokal fast nichts zu tun: das nginx hört auf Ports (server_name _), nur drei Stellen tragen einen Namen fest (Autheliás Regel evcc.mttec.de, der Portal-Eintrag mttec.de, die 401-Weiterleitung). SSL: certbot je Name auf der .55, KEIN Wildcard — „Wildcard bei Hetzner ist NICHT belegt" steht seit dem 12.10. im Gedächtnis; ich hatte es am 09.11. trotzdem erst falsch empfohlen. Arbeitsteilung wie am 12.10.: Jürgen macht DNS in der Console, ich schreibe Vhosts und certbot-Befehl, Jürgen setzt ein. Einzelheiten im Gedächtnis unter reference_fritzbox_heimnetz.
• Danach: die Todo-Adresse wandert mit — aus docs.mttec.de/claude-code/#todo wird docs.askai.de/claude-code/#todo. Steht in der stehenden Regel, in MEMORY.md, in reference_projekt_todo und in mehreren Seiten unter /var/www/docs/. Nicht vergessen, sonst zeigt die eigene Regel auf einen toten Namen.
• ⚠ Die 157-A-Ladestromgrenze des Hausakkus ist seit dem 05.11.2026 aufgehoben — und niemand weiß, von wem. Verlauf der Entität number.multi_rs_6000_3p_ess_maximaler_ladestrom (DVCC SystemSetup/MaxChargeCurrent, Einheit DC-Ampere), selbst gemessen: bis 04.11. 19:11 157, dann 230, dann 240, am 05.11. 12:04 auf −1, also keine Grenze. Bei diesen drei Änderungen sind context_user_id und context_domain im HA-Logbuch leer — es war kein Dienstaufruf, die Änderung kam von der Victron-Seite (Ekrano-GUI, Fernkonsole, VRM oder Node-RED). Jürgens Probe-Umschalten am 07.11. (50, dann wieder −1) trägt dagegen seine Benutzerkennung. Warum das zählt: die 157 A waren am 08.09.2026 als dauerhafte Grenze eingestellt, 0,25 C der 628-Ah-Zellen — und der Software-Deckel in den Schnellladen-Automationen wurde deswegen wieder entfernt. Es gibt jetzt gar keinen Nutzer-Deckel mehr. Der Akku lädt am BMS-Anschlag von 240 A: gemessen 13.312 W am 07.11. und 13.436 W am 05.11.; 13,4 kW bei rund 55,6 V sind genau diese 240 A. Das erklärt auch den Vorfall vom 07.11. vormittags (9.430 W ungedeckter Netzbezug in den Akku). Nichts verändert — das ist Jürgens Entscheidung, am Ekrano wird ohne seinen Auftrag nichts angefasst.
• number.multi_rs_6000_3p_ess_maximale_ladeleistung steht auf 8.000 W und ist messbar wirkungslos — es ist nicht dasselbe Feld wie die 50 A, die Jürgen beim Einschalten sah (das war das Ampere-Feld, Logbuch 17:22:46 → 50, 17:23:19 → −1; am Watt-Feld kein Eintrag). Das Register ist CGwacs/MaxChargePower; bei eingestellten 8.000 W lud der Akku mit 13.312 W. Zwei unabhängige Gründe: der Multi RS ignoriert den settings-Zweig für ESS-Steuerung (eigene Messung, schon im Gedächtnis), und ein Victron-Community-Bericht nennt das Register seit Venus OS 3.5x als ignoriert. Niemand schreibt die 8.000 — kein Skript, keine der 24 aktiven Automationen, Wert seit 01.10. unverändert. Folge: das geplante Umstellen auf −1 bringt nichts; der Hebel, der wirkt, ist das Ampere-Feld, und das steht offen (Punkt darüber). Der Name „ESS maximaler Ladestrom" führt übrigens in die Irre — es ist ein DVCC-Feld.
• Die 80-Prozent-Warnung ist so nicht baubar — am 12.09. geklärt, Ursache gefunden. VW führt zwei Zielladestände: einen Standardwert und zusätzlich ortsabhängige für jeden „Ladeort". EVCC liest nur den Standardwert (vehicleLimitSoc). Steht für „Zuhause" 100 %, lädt das Auto auf 100, während EVCC 90 anzeigt — genau so am 12.09. beobachtet. Eine Warnung gegen diesen Wert würde also gegen etwas prüfen, wonach das Auto gar nicht lädt. Neu zu entscheiden, wie sie stattdessen aussehen soll.
• Zielladestand vor dem Anstecken setzen — offener Test, sobald das Auto wieder unter 90 % ist: Limit setzen, während nicht geladen wird, dabei die Ladeorte in der App prüfen, dann erst anstecken. Damit unterscheidbar, ob der Wert nur beim Sitzungsbeginn übernommen wird oder ob der Ladeort ihn generell aushebelt. An öffentlichen Säulen schaltet das Auto korrekt ab, es kann es also.
• Nachbar-Planung läuft über SoC — zu prüfen, ob sein Fahrzeug dieselbe Schwäche hat. Sonst plant der Ladeplan auf einem Wert, der um Prozentpunkte danebenliegt. Konstruktionsregel aus dem 12.09.: wo wir wählen können, in kWh rechnen statt in Prozent — der Energiezähler ist physikalisch und war an dem Tag die einzige verlässliche Quelle.
• car=4 als schnelleres Ladeende-Signal — erledigt sich. Am 12.09. widerlegt: In 60 h meldete der go-e sechs Mal fälschlich „Ladung beendet", jedes Mal exakt 30 s, einmal sogar während durchgehend 1,43 kW flossen. binary_sensor.evcc_go_e_charging machte keinen dieser Aussetzer mit und reagiert trotzdem in einer Sekunde. Nicht bauen.

Neu aus den Tests vom 11. und 12.09.

• Wiederanlauf-Lücke gemessen. Nach einem Ladestopp bleibt der go-e mit alw=true und 16 A freigegeben. Läuft die Ladung wieder an, geht es sofort mit voller Leistung los, während der Wechselrichter noch umschaltet: Am 12.09. um 13:53:50 lieferte der Hausakku in der ersten Messung 5.476 W ins Auto, 15 Sekunden später war es vorbei. Rund 0,02 kWh, vernachlässigbar — aber es begründet die zwei Minuten Haltezeit im Wachhund.
• VW-Ladestand kann aus dem Cache kommen. EVCC interpoliert zwischen den Abfragen anhand der geladenen Energie; eine zwischengespeicherte Antwort überschreibt die Hochrechnung. Am 12.09. sprang der gemeldete Wert um 14:01:17 von 96,98 auf 90,0 — einziger Rücksprung unter 114 Messpunkten. Energiezähler (10,28 kWh) und Fahrzeuganzeige (100 %) belegen, dass die Hochrechnung recht hatte.
• DESS reagiert auf unser Schnellladen. Der Soll-SoC sprang um 18:28:56 von 0 auf 100 — 50 Sekunden nach dem Start, als die 11,8 kW am Netz anlagen — und fiel erst um 18:47:28 von allein zurück. In den fünf Minuten nach dem Ladeende hielt DESS den Hausakku fest und das Haus lief mit rund 350 W am Netz (etwa 0,03 kWh, ohne Belang). Bei einer längeren Sitzung mitten am Tag könnte das mehr ausmachen. Noch nicht entschieden, ob wir etwas dagegen tun.
• EVCC-Feldnamen für den Ladestrom. chargeCurrent gibt es nicht; richtig sind offeredCurrent (Sollwert, den EVCC dem go-e vorgibt und im PV-Modus laufend nachführt), maxCurrent (unsere Drosselung) und chargeCurrents (gemessen je Phase). Der Umweg über den go-e ist dafür nicht nötig.

Offen aus der Runde vom 10.09.

• Nachbar-Abrechnung — eigenes Thema, vom Nutzer angemeldet: fester Preis 0,35 €/kWh, kein Laden wenn der Netzpreis darüber liegt. Er soll die Preise nicht sehen, aber eine Warnung bekommen. Dazu eine Eingabemaske für seine Daten oder Eingabe durch den Nutzer mit sofortigem PV-Start. Wichtig: EVCCs sessionPrice taugt dafür nicht — es bepreist nur den Netzanteil (PV-Ladung ergab 0,0011 €/kWh). Gebraucht wird die Menge, nicht EVCCs Preis.
• Reiter „Automatik" ist weiterhin ein Platzhalter. EVCC kennt seit dem 10.09. Preise (48 h) und Solarprognose (3 Tage), steuert aber bewusst nichts.
• Hausakku-Plan rechnet noch nach dem Mittelwert bei aufgerundeter Slotzahl — dieselbe Bauart wie der EV-Plan vor der Korrektur vom 10.09. Vom Nutzer zurückgestellt.
• Preishorizont in HA fest auf 30 Stunden verdrahtet (vier Stellen), während EVCC 48 h führt.
• Deadline in der Vergangenheit meldet nur „nicht schaffbar", ohne den Grund zu nennen.

Großes, noch nicht begonnenes Vorhaben

• Preisautomatik-Redesign bauen — Design (design_preisautomatik_v3_2026-09-08.md) ist von beiden Peers fertig abgestimmt, der eigentliche Bau (automatische Keep-Logik für Hausakku+Auto zusammen, ausgelöst durch Preis) hat noch nicht angefangen. Kein Zeitdruck, bewusst vertagt.

Nachrangig / geparkt

• E.DIS-Niedertarif-Bonus als Preis-Korrektur — designed, nicht gebaut. Hat bis Q4 2026 ohnehin keine Wirkung (Sommerhalbjahr = keine Zeitdifferenzierung bei E.DIS).
• Notladen-Eskalationslogik bei anhaltend hohem Preis (Deadline-Ansatz) — Design steht, nicht gebaut, gehört vermutlich ins Redesign.
• Zweitquelle-Gegencheck für E.DIS-Werte — offen, evtl. gar nicht nötig (14a-atlas.de gilt schon als verifiziert).
• Alte Claude-Desktop-Notizen (21 Dateien, siehe Reference-Memory: BRC, Wärmepumpe, JTL-Wawi, Proxmox, PV-Installation, SEO u. a.) — Entscheidung 08.09.2026: bewusst nicht systematisch durchgehen. Nur merken, dass sie da sind — bei Bedarf gezielt nachschauen, wenn ein konkretes altes Thema wieder gebraucht wird.

Wartet auf dich/extern

• EU-Data-Act-Freigabe für den „ID.3 pro S" — am 12.09. vollständig aufgeklärt, beide Peers unabhängig, dazu Quellcode, Log und Datenbank. Der Portal-Zugang stimmt (per Screenshot belegt: VIN des pro S im Portal, Rolle „Primary user") — eine erste Vermutung, es liege am falschen VW-Konto, war falsch. Die Ursache ist die falsche Funktion: Benutzt wurde bisher „Data File → Request file", ein einmaliger Datenexport als ZIP, ausdrücklich nur einmal je 24 Stunden. EVCC braucht laut eigenem Vorlagentext etwas anderes: „link the vehicle and enable a continuous data request (every 15 minutes) — without this activation the portal returns no data". Gesucht ist also die fortlaufende Datenanfrage, vermutlich unter den Menüpunkten „EU Data Act" oder „Data Clusters". Schritt 2 wird regelmäßig übersehen und ist genau die Ursache der Meldung subscription not configured (EVCC fragt je Fahrzeug-Identnummer nach der laufenden Datenanfrage; 404 → diese Meldung). Danach kann es laut Community 2 bis über 24 Stunden dauern, bis Daten fließen, und die Datenpakete müssen echten Inhalt haben. Belege: 436 Fehlerzeilen seit 01.09., kein einziger Erfolg, nur eine Fahrzeugkennung im Log — während der „pro" gleichzeitig Daten liefert.

Alte Einzel-Bugs, vermutlich gegenstandslos

Betrafen die mittlerweile deaktivierten 16 alten Automationen, werden beim Redesign ohnehin neu gebaut, kein isolierter Fix mehr nötig:

• EV-Ownership-Bug (evcc_schnellwahl_auto_laden)
• EVCC-PV-Start-Enable-Lücke (Kickstart-Automation-Idee) — reine, nicht abgestimmte Idee
• DESS direkt preisgesteuert aus HA schalten — technisch möglich, nicht gebaut

Heute erledigt — 11.09.2026

• Fahrzeugtausch-Test bestanden (18:27–18:42, ID.3 pro, 3,26 kWh aus dem Netz). Bewiesen: Mindest-SoC = Stand + 1 — Hausakku-SoC blieb über die vollen 15 Minuten auf 98 %, Akkuleistung zwischen −127 und +26 W (Vortag: 12 kW aus dem Akku, 96 → 95 %). Drosselung 10 A → 16 A — 7.020 W beim Start, nach 30 s 11.400 W, am go-e mit amp=16 bestätigt. Übergabe ans Netz in 41 s.
• Rückstellung am Sitzungsende erstmals live bewiesen — zur geplanten Endzeit fiel in einem einzigen 10-Sekunden-Intervall alles zurück: MinSoC 99 → 20 (alle vier Entitäten, auch die drei einzelnen Wechselrichter), Modus off, Marker ev_minsoc_erhoeht gelöscht. Das war das letzte nie im Echtbetrieb gelaufene Glied der Kette.
• Automatische Fahrzeugwahl und Start-SoC bestätigt — beim Anstecken sprang der Ladeplan von allein auf „ID.3 pro (59 kWh)", ev_ladeplan_start_soc übernahm 84 % vom Auto.
• sensor.dess_netzbezug_plan gebaut — DESS-Planung im 15-Minuten-Raster aus VRM, zeigt Fenster, in denen DESS gleichzeitig den Akku lädt und Netz bezieht. Zwei eigene Fehler dabei gefunden und behoben (Index- statt Zeitstempel-Verknüpfung; Zirkelschluss in der Netzbezugsformel), live gegen die VRM-API gegengerechnet.
• VRM-Ereignisprotokoll ausgewertet — Ergebnis: es protokolliert nur VRM-Eingriffe, MQTT-Änderungen tauchen nicht auf, DESS protokolliert eigene Entscheidungen nie. Kein API-Zugang. Damit belegt: vor dem Netzbezug-Vorfall am 01.09. hat niemand eine Einstellung geändert.
• DESS-Bericht 01.07.–11.09. geprüft — Saldo −152,98 €, DESS war nur 36,9 % der Zeit an. Per API abrufbar (dynamic-ess-report&type=descriptive).
• Werkzeuge für die Buchhaltung installiert (vom Nutzer ausgeführt): Tesseract 5.5 mit deutscher Sprachdatei, WeasyPrint 67 für PDF aus HTML, img2pdf für Fotos und Scans, hyphen-de für die Silbentrennung. Alles an echten Beispielen geprüft.

Revisionsverlauf

07 Künftige Kapitel

Dieses Dokument wächst mit der Zeit — sobald sich neue wiederkehrende Abläufe etablieren, kommen hier weitere Kapitel dazu (z. B. Peer-Sitzungen koordinieren, Memory-System-Konventionen, Cron-/Wakeup-Nutzung).