tobias
3b99f1f332
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>
113 lines
5.4 KiB
Python
113 lines
5.4 KiB
Python
"""Technische Konfiguration — die einzige Stelle, die vor der Installation
|
|
angepasst werden muss (siehe INSTALL.md Schritt 4).
|
|
|
|
Alles andere (WLAN-Name des Fahrzeugs, Pausenzeit, Reifendaten, ...) ist Teil
|
|
des Fahrzeugprofils (data/fahrzeugprofil.json) und über die Oberfläche
|
|
änderbar. Diese Entity-IDs sind es bewusst nicht: @state_trigger und die
|
|
Fahrzeugstatus-Abfrage brauchen sie als festen Wert, bevor überhaupt ein
|
|
Profil gelesen werden kann.
|
|
|
|
In Home Assistant unter Entwicklerwerkzeuge -> Zustände nachschlagen. Werte
|
|
lassen sich außerdem über das Setup-Menü in der Oberfläche zuordnen (siehe
|
|
entitaeten.py) - Änderungen von dort werden zur Laufzeit auf diese Variablen
|
|
angewendet (überschreiben also die hier hinterlegten Standardwerte), ohne
|
|
diese Datei anzufassen.
|
|
|
|
**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).
|
|
#
|
|
# 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 - 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
|
|
# Tankgeber).
|
|
TANK_SENSOR = ""
|
|
|
|
# Reichweite (§5.1 Übersicht) - keine Quelle mehr vorhanden.
|
|
RANGE_SENSOR = ""
|
|
|
|
# 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).
|
|
# 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.
|
|
REFRESH_BUTTON = ""
|
|
|
|
# Türen (§4.1) - keine Quelle mehr vorhanden.
|
|
TUER_SENSOREN = []
|
|
|
|
# Fenster (§4.1) - keine Quelle mehr vorhanden.
|
|
FENSTER_SENSOREN = []
|
|
|
|
# Heckklappe und Motorhaube - keine Quelle mehr vorhanden.
|
|
HECKKLAPPE_SENSOR = ""
|
|
HAUBE_SENSOR = ""
|
|
|
|
# Vom Fahrzeug selbst gemeldete Service-Fälligkeit (ergänzt die App-eigene,
|
|
# aus dem Servicebuch berechnete Prognose) - keine Quelle mehr vorhanden.
|
|
NAECHSTER_OELWECHSEL_SENSOR = ""
|
|
OELWECHSEL_STRECKE_SENSOR = ""
|
|
NAECHSTE_INSPEKTION_SENSOR = ""
|
|
INSPEKTION_STRECKE_SENSOR = ""
|
|
|
|
# Live-GPS-Position des Fahrzeugs (Übersicht -> Standort-Kachel). Breiten-/
|
|
# Längengrad als zwei eigene sensor-Entities (flespi liefert Koordinaten so,
|
|
# nicht als Attribute einer device_tracker-Entity - siehe _standort() in
|
|
# frontend_veroeffentlichung.py).
|
|
STANDORT_LAT_SENSOR = ""
|
|
STANDORT_LON_SENSOR = ""
|
|
|
|
# Update-Funktion (Einstellungen -> "Update suchen", siehe
|
|
# updateverwaltung.py): Git-Repository, in das dieses Projekt gepflegt wird -
|
|
# z. B. ein privates GitHub-Repo, genau wie für die HACS-Integration bereits
|
|
# verwendet. Leer lassen, solange es keins gibt - "Update suchen" meldet dann
|
|
# nur "keine Update-Quelle eingerichtet", ohne etwas zu tun.
|
|
UPDATE_REPO_URL = ""
|
|
UPDATE_BRANCH = "main"
|