GNSS-Rollen vorbereitet, "Geparkt seit" von der Zuendung (2026.9.1.5/.6)

GNSS-STRECKENROLLEN, NOCH OHNE VERBRAUCHER

11806 steht seit dem 01.09. auf GNSS. Zwei neue Sensorrollen angelegt, damit
nach der ersten echten Fahrt nur noch gemessen und nicht mehr zugeordnet
werden muss: GNSS_KM_SENSOR (total_calculated_mileage, der robustere fuer eine
Fahrtstrecke - ein verlorener Datensatz verfaelscht die Differenz nicht) und
GNSS_TEILSTRECKE_SENSOR (segment_mileage, zeigt WO Strecke fehlt, taugt als
Gegenprobe). Kein Code liest sie; die Zuordnung aendert nichts.

KM_SENSOR bleibt der Anker - er ist der Tacho des Fahrzeugs und driftet nicht.
Der alte Warnhinweis dort zeigt jetzt auf die neue Rolle statt ins Leere.

"GEPARKT SEIT" KOMMT VON DER ZUENDUNG

Die Anzeige rechnete "jetzt minus ts_end der juengsten Fahrt". Das ist keine
Aussage ueber das Parken, sondern ueber die Fahrterkennung: am 01.09. stand
dort "Geparkt seit 2 Tg. 16 Std.", waehrend am Vorabend 7 km gefahren wurden -
die Fahrt fehlte im Bestand, weil trip_status festhing.

Der Koordinator merkt sich jetzt den Zeitpunkt, zu dem die Zuendung zuletzt
ausging, in der Zeit des Geraets. Er liegt im Laufzeit-Store neben
fahrt_start_ts und ueberlebt einen Neustart. Kein Rueckfall auf die
Fahrtenliste: null heisst unbekannt und wird auch so angezeigt - ausdrueckliche
Ansage des Eigentuemers, eine falsche Zahl ist schlechter als keine.

Beim Ausliefern fiel derselbe Neustart-Fehler auf wie bei der Phantomfahrt:
der Zuhoerer las die Registrierung der Entitaet als Wechsel und stempelte den
Parkbeginn bei jedem Neustart neu. if alt is None: return behebt es. Merkposten
fuer dieses Projekt: jeder neue Zustandszuhoerer braucht diese Pruefung.

VERIFIZIERT in audi_ha_test: Neustart laesst 09:34:15 unveraendert; Zuendung an
-> null; Zuendung aus mit Geraetezeit von vor 40 Minuten -> 09:04:57 statt
jetzt. Companion-App gleichgezogen, tsc --noEmit sauber, 165/165 Tests gruen.

NOTIERT, NICHT GEBAUT: der GNSS-Zaehler driftet im Stand. Die 0,034 km waren
GPS-Rauschen, nicht Aufloesung - der Dongle lag unbewegt. Die GNSS-Zuwaechse
brauchen deshalb ein Bewegungstor, bevor sie summiert werden duerfen.

Co-Authored-By: Claude Opus 5 <[email protected]>

custom_components/audi_dashboard/einstellungen.py

@@ -52,7 +52,7 @@ class Sensorzuordnung:
     # Ölwechsel-Prognose.
     #
     # Beim FMM003 hier NICHT den selbst berechneten Gesamtkilometerstand
-    # (*_total_calculated_mileage) zuordnen: der beruht auf GPS-Strecken-
+    # (*_total_calculated_mileage) zuordnen - dafür gibt es GNSS_KM_SENSOR
     # rechnung 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
@@ -60,6 +60,37 @@ class Sensorzuordnung:
     # Kilometerstand der EU-Data-Act-Integration ist der richtige.
     KM_SENSOR: str = ""
 
+    # Der geräteeigene Kilometerzähler, wenn er auf GNSS rechnet
+    # (Trip \ Odometer -> Calculation Source = GNSS). Er löst am 01.09.2026
+    # nachgemessen auf **einen Meter** auf (0,034 km direkt nach dem
+    # Zurücksetzen), während der vom CAN gelesene Fahrzeug-Kilometerstand nur
+    # ganze Kilometer hergibt - über die gesamte Aufzeichnung 147 Schritte von
+    # exakt 1,0 km, kein einziger feinerer.
+    #
+    # Gedacht als FEINAUFLÖSUNG, nicht als Ersatz: KM_SENSOR bleibt der Anker,
+    # weil er der Tacho des Fahrzeugs ist und nicht driftet. Dieser hier liefert
+    # die Nachkommastelle dazwischen und verliert Strecke, wo kein GNSS-Empfang
+    # ist. Beides zusammen ergibt eine Strecke auf 100 m genau, die trotzdem am
+    # Fahrzeugwert hängt.
+    #
+    # NOCH OHNE VERBRAUCHER: die Rolle ist angelegt, damit nach der ersten
+    # echten GNSS-Fahrt nur noch gemessen und nicht mehr zugeordnet werden muss.
+    # Solange sie niemand liest, ändert eine Zuordnung nichts.
+    GNSS_KM_SENSOR: str = ""
+
+    # Die Strecke seit dem letzten Datensatz, ebenfalls vom Gerät gerechnet
+    # (Trip \ Odometer -> Mode = "Between records"; steht die Einstellung auf
+    # "Continuous", zählt das Feld stattdessen die laufende Fahrt und die Rolle
+    # ist unbrauchbar - vor dem Zuordnen also nachsehen).
+    #
+    # Wozu zusätzlich zu GNSS_KM_SENSOR: der Gesamtzähler ist die robustere
+    # Quelle für eine Fahrtstrecke, weil ein verlorener Datensatz die Differenz
+    # nicht verfälscht - er zählt weiter. Die Teilstrecken taugen dafür nur,
+    # wenn keiner fehlt. Umgekehrt zeigen sie, WO Strecke verloren ging, und
+    # sind damit die bessere Gegenprobe. Auch diese Rolle hat noch keinen
+    # Verbraucher.
+    GNSS_TEILSTRECKE_SENSOR: str = ""
+
     # Das Trip-Signal des Geräts: es beginnt erst, wenn Zündung UND Bewegung
     # UND "Start Speed" zusammenkommen, und endet erst nach dem
     # "Ignition OFF Timeout" des Geräts. Damit bringt es die Pausentoleranz
@@ -185,6 +216,16 @@ SCHLUESSEL: set[str] = set(STANDARDWERTE)
 # "Nur passende Sensoren anzeigen") - eine fehlende oder leere Liste bedeutet
 # "keine Einschränkung" bzw. "diese Rolle hat üblicherweise keine Einheit".
 FELDER: list[dict] = [
+    {"key": "GNSS_KM_SENSOR", "label": "Kilometerzähler (GNSS)", "gruppe": "fahrterkennung",
+     "hinweis": "Der geräteeigene Zähler, auf einen Meter genau. Verfeinert die Fahrtstrecke; der Kilometerstand oben bleibt der maßgebliche Wert.",
+     "domains": ["sensor"], "device_classes": ["distance"], "units": ["km"], "liste": False, "pflicht": False,
+     "beispiel": "total_calculated_mileage",
+     "stichworte": ["gnss", "gps", "calculated", "mileage", "kilometer"]},
+    {"key": "GNSS_TEILSTRECKE_SENSOR", "label": "Teilstrecke je Datensatz (GNSS)", "gruppe": "fahrterkennung",
+     "hinweis": "Strecke seit dem letzten Datensatz - Gegenprobe zum Kilometerzähler und Hinweis darauf, wo Strecke fehlt.",
+     "domains": ["sensor"], "device_classes": ["distance"], "units": ["km"], "liste": False, "pflicht": False,
+     "beispiel": "segment_mileage",
+     "stichworte": ["segment", "teilstrecke", "abschnitt", "mileage"]},
     {"key": "TRIP_SENSOR", "label": "Trip-Status", "gruppe": "fahrterkennung",
      "hinweis": "on = Fahrt läuft. Das gefilterte Fahrtsignal des Geräts - erkennt Fahrtbeginn und -ende. Ohne Zuordnung übernimmt die Zündung diese Aufgabe.",
      "domains": ["binary_sensor"], "device_classes": [], "units": [], "liste": False, "pflicht": False,