Vergangene Daten aus dem HA-Verlauf importierbar, Auslieferstand bereinigt

Datenaufbewahrung (recorder_snippet.yaml, neu): Home Assistant loescht
Sensor-Verlaeufe standardmaessig nach 10 Tagen - das war die stille
Obergrenze dafuer, wie weit sich ueberhaupt je etwas rekonstruieren
laesst, denn geloeschte recorder-Zeilen sind endgueltig weg. Der Block
hebt das auf 365 Tage. Die Bestaende der App selbst (fahrten.jsonl,
tankvorgaenge.jsonl, batteriespannung.jsonl, fahrzeugprofil.json) waren
davon nie betroffen, die kennen ohnehin keine Purge-Logik. Platzbedarf
an der Testinstanz gemessen statt geschaetzt: 90.858 Zeilen in 17 Tagen,
hochgerechnet grob 1,9 Mio. Zeilen und 1-1,5 GB im Jahr, davon 96 % aus
der EU-Data-Act-Integration - dafuer liegt eine auskommentierte
exclude:-Liste bei. Bewusst kein include:-Block, der wuerde jeder
anderen Integration den Verlauf nehmen und dabei kaum Platz sparen.

Historienimport (pyscript/historienimport.py, neu): neuer Dienst
audi_dashboard_historie_importieren(start, ende) liest denselben
Verlauf, den die Live-Trigger in Echtzeit sehen, und leitet rueckwirkend
dieselben Datensaetze ab - Fahrten aus dem Zuendungsverlauf (inklusive
der Pausenregel, kurze Unterbrechungen verschmelzen zu einer Fahrt),
Tankvorgaenge nach derselben Tiefststand-Logik und denselben Schwellen
wie tankerkennung.py, Tagesmin/-max der Batteriespannung. Mehrfach
ausfuehrbar: ueberschneidet sich eine Fahrt mit einer bereits erfassten,
wird sie uebersprungen statt doppelt angelegt. Erzeugte Datensaetze
tragen source: "import".

Gelesen wird ueber HAs eigene recorder-API (get_significant_states),
nicht per direktem SQL auf home-assistant_v2.db: das Schema ist
HA-intern und aendert sich zwischen Versionen, die Funktion ist die
stabile Schnittstelle. Preis dafuer ist hass_is_global: true im
pyscript-Block; ohne die Zeile laeuft alles andere unveraendert weiter,
nur der Import meldet, dass er den Verlauf nicht lesen kann.

Oberflaeche in beiden Codebasen: Knopf "Daten importieren aus Home
Assistant" unter Einstellungen -> Einrichten, dahinter ein Fenster mit
Von/Bis (Vorbelegung: letzte 30 Tage), "Importieren" als Hauptaktion und
"Abbrechen" als zweite Wahl. Das Fenster bleibt offen und zeigt das
Ergebnis, statt optimistisch zu schliessen - hier ist das Ergebnis der
Zweck des Aufrufs. Fortschritt ueber die Entitaet
pyscript.audi_dashboard_import_status, weil pyscript-Dienste sofort
zurueckkehren. In companion-app bewusst NICHT ueber die
Offline-Warteschlange: ein spaeter aus dem Nichts abgefeuerter
Importlauf waere fuer den Nutzer nicht nachvollziehbar.

Beim Testen gefunden und mitgefixt: profil.batterieverlauf_tageswert_
aktualisieren() haengte in Einfuegereihenfolge an. Solange nur die
Live-Aufzeichnung schrieb, war das dasselbe wie sortiert (sie traegt
immer den heutigen Tag ein) - der Import traegt vergangene Tage nach,
die waeren hinter den neueren gelandet und das Diagramm haette zeitlich
rueckwaerts gelaufen. Sortiert jetzt nach Datum, wie der eigene
Docstring es ohnehin versprach.

Auslieferstand bereinigt: einstellungen.py brachte zwei Entity-IDs einer
laengst abgeraeumten Testinstanz mit (testzone_fmm003_...). Beim Testen
unsichtbar, weil die Testinstanz sie ueber entitaeten.json ueberschreibt
- auf einer Neuinstallation waeren sie die wirksamen Werte gewesen. Und
schlimmer als nur wirkungslos: fahrterkennung.py registriert seinen
@state_trigger nur, wenn das Feld belegt ist, ausdruecklich als Schutz
gegen eine leere Entity-ID. Ein gesetzter, aber nicht existierender Wert
hebelt genau diesen Schutz aus. Beide Felder jetzt leer wie alle
anderen; Kopfkommentar der Datei ueberarbeitet, er behauptete noch, die
EU-Data-Act-Integration werde nicht mehr verwendet.

install.ps1 abgesichert, da die erste echte Installation auf HA OS
ansteht: die feste configuration.yaml.bak wurde bei jedem Lauf
ueberschrieben, ausgerechnet das Original war nach dem zweiten Lauf weg
- Sicherungen jetzt zeitgestempelt. Nach dem Schreiben wird die Datei
zurueckgelesen und geprueft (Laenge, genau ein Markerblock, bisheriger
Inhalt unveraendert); bei der kleinsten Abweichung rollt das Skript
automatisch zurueck. Die Sicherheitseigenschaften stehen jetzt im Kopf
der Datei, statt dass man ihnen glauben muss.

Standort-Blatt: "Teilen" war im Tagmodus unsichtbar - .standort-pille
nutzte var(--tile), das Blatt darunter var(--tile-deckend), und die
iOS-Auflage setzt im Tagmodus beide auf #FFFFFF. Gemessener Kontrast
1,00:1, weiss auf weiss. Beide Pillen folgen jetzt der Knopfsprache des
Panels (.aktion / .aktion.primaer): Umriss fuer die Nebenaktion, var(--fg)
gefuellt fuer "Route". Danach 17-21:1 Textkontrast in beiden Themes.
Nebenbei ist damit --line-strong - eine Linienfarbe - nicht laenger als
Knopffuellung im Einsatz.

Geprueft: Import zweimal ueber die echte Oberflaeche im Browser gegen
eine in die recorder-DB eingespielte Kunsthistorie (der Testcontainer
laeuft nicht, waehrend das Auto faehrt, echte Fahrten liegen dort also
nicht vor) - drei Fahrten wie erwartet, die 5-Minuten-Unterbrechung
korrekt zu einer 50-Minuten-Fahrt verschmolzen, die 30-Sekunden-Zuendung
verworfen, Strecken kilometergenau; zweiter Lauf legte 0 an und meldete
3 als vorhanden. Neuinstallation in einem Wegwerf-Container: nur
Profilvorlage und Parser, keine Fahrten-/Tank-/Batteriedatei, null
Fehler im Log. install.ps1 gegen Attrappen: -Pruefen schreibt nichts,
echter Lauf laesst automations.yaml bytegleich (SHA-256) und fremde
Bloecke stehen, Ergebnis parst als gueltiges HA-YAML, zweiter Lauf
idempotent, bei fremdem pyscript:/panel_custom: bleibt die Datei
bytegleich. tsc --noEmit sauber, companion-app-Tests 106/106, vite build
sauber, HA-Configcheck und Start ohne Fehler.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

homeassistant/pyscript/modules/einstellungen.py

@@ -13,33 +13,52 @@ entitaeten.py) - Änderungen von dort werden zur Laufzeit auf diese Variablen
 angewendet (überschreiben also die hier hinterlegten Standardwerte), ohne
 diese Datei anzufassen.
 
-2026-08-12: Die HACS-Integration TommiG1/HA_VAG-EU-Data-Act (bisherige
-Quelle für Kilometerstand, Tankfüllstand, Türen/Fenster/Schlösser,
-Ölwechsel-/Inspektionsdaten) wird nicht mehr verwendet - die zugehörigen
-Entity-IDs sind deshalb unten bewusst leer. Neue Datenquelle ist der
-Teltonika FMM003 (GPS-Tracker mit CAN-Anbindung, siehe AGENTS.md Abschnitt
-B); er liefert Standort, Zündungsstatus und Batteriespannung, aber keinen
-Tankfüllstand, keine Tür-/Fenster-/Schlossdaten und keine Ölwechsel-/
-Inspektionstermine - die entsprechenden Kacheln zeigen deshalb bis auf
-Weiteres "unbekannt" statt eines falschen Werts (siehe zustand_oder_none()
-in frontend_veroeffentlichung.py). Bleibt ein Wert leer ("") oder passt eine
-Entity-ID nicht zur tatsächlichen Integration, liefert zustand_oder_none()
-für das jeweilige Feld None statt abzustürzen.
+**Im Auslieferstand sind alle Felder hier leer.** Das ist Absicht, kein
+unfertiger Zustand: welche Entity-IDs richtig sind, hängt an der jeweiligen
+Instanz und ihren Integrationen. Die Zuordnung passiert nach der Installation
+im Setup-Menü der App (Einstellungen -> Fahrzeug einrichten -> Setup), das
+sie nach data/entitaeten.json schreibt; diese Datei bleibt dabei unangetastet.
+
+Ein leeres Feld ist der sichere Zustand: die betroffene Kachel zeigt
+"unbekannt" statt eines falschen Werts (siehe zustand_oder_none() in
+frontend_veroeffentlichung.py), und die trigger-gebundenen Felder
+(ZUENDUNG_SENSOR, KM_SENSOR, TANK_SENSOR) registrieren gar keinen Trigger,
+statt einen gegen eine nicht existierende Entität zu registrieren. Eine
+gesetzte, aber falsche Entity-ID ist deshalb schlechter als eine leere.
+
+Zwei typische Quellen auf dieser Instanz: der Teltonika FMM003 (GPS-Tracker
+mit CAN-Anbindung, über flespi angebunden - Standort, Zündungsstatus,
+Bordnetzspannung, CAN-Werte wie Kilometerstand und Tankfüllstand) und eine
+EU-Data-Act-Integration des Herstellers (Kilometerstand, Tankfüllstand,
+Türen/Fenster/Schlösser, Reifendrücke, Ölwechsel-/Inspektionstermine). Welche
+davon welche Rolle bedient, entscheidet das Setup-Menü - nicht diese Datei.
 """
 
 # Fahrterkennung (§7.1): Start/Ende einer Fahrt wird über den Zündungs-/ACC-
 # Status des FMM003 erkannt (on = Fahrt läuft), nicht mehr über die WLAN-
 # Verbindung des iPhones zum Fahrzeug (siehe fahrterkennung.py).
-ZUENDUNG_SENSOR = "binary_sensor.testzone_fmm003_engine_ignition_or_acc_status"
+#
+# Leer im Auslieferstand, wie alle Felder hier. Bis 2026-08-23 stand hier die
+# Entity-ID einer längst abgeräumten Testinstanz
+# ("binary_sensor.testzone_fmm003_..."). Auf einer frischen Installation
+# zeigte sie ins Leere - und richtete dabei mehr an, als nur nutzlos zu sein:
+# fahrterkennung.py registriert seinen @state_trigger nur, WENN dieses Feld
+# belegt ist ("if einstellungen.ZUENDUNG_SENSOR:", ausdrücklich als Schutz
+# gegen eine leere Entity-ID gebaut). Ein gesetzter, aber nicht existierender
+# Wert hebelt genau diesen Schutz aus. Dasselbe galt für BATTERIE_SENSOR
+# weiter unten. Zuordnung gehört ins Setup-Menü, nicht in den Auslieferstand.
+ZUENDUNG_SENSOR = ""
 
-# Kilometerstand - bisher aus der TommiG1-Integration, aktuell keine Quelle
-# vorhanden. Der FMM003 liefert unter sensor.testzone_fmm003_total_calculated_mileage
-# einen selbst berechneten Wert, der aber auf einer anderen Zählbasis beruht
-# als der echte Fahrzeug-Kilometerstand (GPS-Streckenberechnung statt
-# Tacho) - bewusst NICHT automatisch übernommen, um Reifenzähler,
-# Ölwechsel-Prognose und Fahrtabschluss-Screening nicht mit einem
-# inkonsistenten Basiswert zu verfälschen. Bei Bedarf über das Setup-Menü
-# gezielt zuordnen.
+# Kilometerstand - für Fahrtabschluss-Screening, Reifenzähler und
+# Ölwechsel-Prognose.
+#
+# Beim FMM003 hier NICHT den selbst berechneten Gesamtkilometerstand
+# (*_total_calculated_mileage) zuordnen: der beruht auf GPS-Streckenrechnung
+# statt auf dem Tacho und damit auf einer anderen Zählbasis als der echte
+# Fahrzeug-Kilometerstand. Wer ihn einträgt, verfälscht alle drei genannten
+# Auswertungen mit einem inkonsistenten Basiswert. Der vom CAN gelesene Wert
+# (*_total_vehicle_mileage_read_from_can) bzw. der Kilometerstand der
+# EU-Data-Act-Integration ist der richtige.
 KM_SENSOR = ""
 
 # Tankfüllstand (Prozent) - keine Quelle mehr vorhanden (der FMM003 ist kein
@@ -49,11 +68,12 @@ TANK_SENSOR = ""
 # Reichweite (§5.1 Übersicht) - keine Quelle mehr vorhanden.
 RANGE_SENSOR = ""
 
-# 12V-Batteriespannung (Mein Audi -> Zustand). Vom FMM003 geliefert -
-# external_power_voltage ist die vom Gerät gemessene Bordnetzspannung des
-# Fahrzeugs, NICHT battery_voltage (das ist die interne Pufferbatterie des
+# 12V-Batteriespannung (Mein Audi -> Zustand). Beim FMM003 ist das
+# external_power_voltage - die vom Gerät gemessene Bordnetzspannung des
+# Fahrzeugs -, NICHT battery_voltage (das ist die interne Pufferbatterie des
 # Trackers selbst und hat mit der Fahrzeugbatterie nichts zu tun).
-BATTERIE_SENSOR = "sensor.testzone_fmm003_external_power_voltage"
+# Leer im Auslieferstand, siehe ZUENDUNG_SENSOR oben.
+BATTERIE_SENSOR = ""
 
 # Knopf für eine sofortige Neuabfrage beim Fahrzeug - kam aus der
 # TommiG1-Integration, keine Entsprechung beim FMM003 vorhanden.

homeassistant/pyscript/modules/profil.py

@@ -282,6 +282,13 @@ def batterieverlauf_tageswert_aktualisieren(datum, ts, spannung):
             break
     else:
         verlauf.append({"datum": datum, "min": spannung, "min_ts": ts, "max": spannung, "max_ts": ts})
+    # Nach Datum sortiert schreiben, nicht in Einfügereihenfolge. Solange nur
+    # die Live-Aufzeichnung schrieb, war beides dasselbe (sie trägt immer den
+    # heutigen Tag ein, also stets den jüngsten). Der nachträgliche Import
+    # (historienimport.py) trägt dagegen vergangene Tage ein - ohne diese
+    # Zeile stünden sie hinter den neueren, und das Diagramm im Frontend, das
+    # die Datei in Dateireihenfolge zeichnet, liefe zeitlich rückwärts.
+    verlauf.sort(key=lambda e: e.get("datum") or "")
     _zeilen_schreiben(BATTERIEVERLAUF_PFAD, verlauf)