Regler stellt den Schlaf-Timeout des Dongles (2026.9.3.10)

Der Regler "Fahrt beenden" ist jetzt eine Zahl fuer zwei Dinge: unsere eigene
Wartezeit bis zum Fahrtende und der Schlaf-Timeout des FMM003 (103). So lange
bleibt der Dongle wach und wartet darauf, dass es gleich weitergeht; danach
schlaeft er. Die 180 s Ignition OFF Delay laufen davor und bleiben unsichtbar -
sie werden nur von der Fahrtdauer abgezogen. Der Regler geht deshalb von 1 bis
60 in Einerschritten; das Geraet kennt kein Timeout 0.

flespi.py liest und schreibt die Geraete-Konfiguration. Drei Annahmen sind an
der echten API gefallen und stehen als Messung im Modulkopf: der Wert liegt in
current (nicht value), die Einstellung heisst sleep_mode mit dem Wert eine Ebene
tiefer unter mode, und ein PUT braucht {"properties": ..., "address": ...}.

Die eigene Auftrags-Warteschlange ist wieder entfallen. Sie war fuer "das Geraet
schlaeft" gebaut - das gilt aber nur fuer das Geraet, nicht fuer die
Schnittstelle: die vollstaendige Konfiguration kam herein, waehrend das Fahrzeug
seit dem Vortag stand. flespi puffert selbst (pending + address=connection), ein
zweites Auftragsbuch waere eine zweite Warteschlange fuer dieselbe Aufgabe.

Gegengelesen wird nach jedem Schreiben; als Erfolg zaehlt current ODER pending -
letzteres ist bei stehendem Fahrzeug der Normalfall.

Live gegen den echten Account belegt: Token sieht genau ein Geraet, 127
Einstellungen bei parkendem Fahrzeug gelesen, Regler 15 geschrieben und als
pending bestaetigt (Nachbarfelder unveraendert), zweiter Neustart ohne erneute
Anfrage.

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

companion-app/src/api/index.ts

@@ -351,6 +351,16 @@ export class DataMetricApi {
     return this.rest.dienstAufrufen(DIENST_DOMAIN, "zugang_setzen", { dienst, token });
   }
 
+  /** Liest die Konfiguration des Dongles - und schreibt dabei eine vorgemerkte
+     Aenderung, falls eine offen ist (siehe flespi.py).
+
+     Wie zugangSetzen bewusst NICHT ueber die Warteschlange: der Abruf gelingt
+     nur bei laufender Zuendung, und Stunden spaeter aus dem Funkloch nachgeholt
+     traefe er das Geraet garantiert im Schlaf an. */
+  dongleLesen(): Promise<unknown> {
+    return this.rest.dienstAufrufen(DIENST_DOMAIN, "dongle_lesen", {});
+  }
+
   historieImportieren(start: string, ende: string): Promise<unknown> {
     return this.rest.dienstAufrufen(DIENST_DOMAIN, "historie_importieren", {
       start,

companion-app/src/api/types.ts

@@ -234,12 +234,50 @@ export interface ZugangAngabe {
   rest: string | null;
 }
 
+/** Was am Dongle steht und was noch aussteht (flespi.py).
+
+    `aktiv` ist false, solange kein flespi-Token hinterlegt ist - dann gibt es
+    nichts zu zeigen. `stand` traegt seinen eigenen Zeitstempel: eine Angabe von
+    gestern soll nicht wie eine frische aussehen. Was noch zum Geraet unterwegs
+    ist, steht je Wert in `offen` - flespi haelt es vor, wir nicht. */
+export interface DongleWert {
+  schluessel: string;
+  /** Die Nummer im flespi-Configurator - danach sucht man dort. */
+  nummer: string;
+  titel: string;
+  einheit: string;
+  geraet: unknown;
+  /** Was noch zum Gerät unterwegs ist (flespis `pending`) - null, wenn nichts
+      aussteht. */
+  offen: unknown;
+  /** Unser eigener Wert, sofern es einen zu vergleichen gibt. */
+  unser: number | null;
+  abweichung: boolean;
+}
+
+export interface DongleStand {
+  geraet?: number;
+  gelesen_am: string;
+  anzahl?: number;
+  werte?: DongleWert[];
+  abweichungen?: number;
+  /** Wie viele der gezeigten Werte noch zum Gerät unterwegs sind. */
+  offen?: number;
+  fehler: string | null;
+}
+
+export interface DongleAngabe {
+  aktiv: boolean;
+  stand: DongleStand | null;
+}
+
 /** Nutzlast von sensor.audi_dashboard_app_version. */
 export interface AppVersionAngabe {
   app: string | null;
   buendel: Buendelangabe | null;
   integration_update: IntegrationUpdateAngabe | null;
   zugaenge?: ZugangAngabe[];
+  dongle?: DongleAngabe;
 }
 
 /* -------------------------------------------------- Entitäts-Verzeichnis */