tobias
99cef7c393
BUG "Fahrzeug faehrt" aenderte sich nie. standortZustand() leitete den
Fahrzustand aus TRIPS[0].status === "offen" ab - zwei Fehler
uebereinander, die sich gegenseitig verstaerkt haben.
Erstens heisst "offen" nicht "unterwegs", sondern "Daten noch
unvollstaendig": _fahrt_beenden() legt die Fahrt mit diesem Status an,
wenn sie ENDET, und das Kilometerstand-Screening fuellt sie spaeter. Eine
Fahrt, die nie eine Strecke bekam - etwa weil damals kein KM_SENSOR
zugeordnet war -, bleibt fuer immer "offen". Zweitens ist TRIPS[0] die
AELTESTE Fahrt, nicht die neueste: fahrten_veroeffentlichen() reicht
profil.fahrten_lesen() unveraendert in Dateireihenfolge weiter, und die
ist aufsteigend. Zusammen hat die aelteste jemals unvollstaendig
gebliebene Fahrt das Fahrzeug dauerhaft als fahrend angezeigt; an der
Testinstanz war das eine seit 18 Tagen beendete Fahrt.
Nicht den Index geflickt, sondern die Quelle korrigiert: das Backend
veroeffentlicht jetzt "zuendung" im Fahrzeugstatus, gelesen aus dem
ohnehin zugeordneten ZUENDUNG_SENSOR - demselben Signal, das auch
fahrterkennung.py als massgeblich nimmt. Anzeige und Erfassung koennen
dadurch gar nicht mehr auseinanderlaufen. Ohne zugeordneten Sensor
(null) steht "Fahrzustand unbekannt" statt einer Behauptung.
companion-app hatte denselben Fehler spiegelverkehrt: liveZustandLesen()
las "zuendung" (gab es nie) und "lat"/"lon" (das Backend liefert
standort_lat/standort_lon), und der Typ Fahrzeug kannte keines dieser
Felder. Die Live-Ansicht meldete deshalb dauerhaft "Das Fahrzeug steht"
und zeigte nie eine Position. Felder in Fahrzeugstatus/Fahrzeug und im
Adapter ergaenzt, damit der Typ diese Fehlerklasse kuenftig faengt -
wovor sein eigener Kopfkommentar seit einem frueheren Vorfall warnt.
BUG "Standortzugriff verweigert" war irrefuehrend. Die Zeile steht
direkt unter dem Fahrzeugnamen, wo sonst der Abstand zum Auto steht,
handelt aber vom Standort DIESES Geraets - sie las sich, als sei der
Standort des Autos nicht abrufbar. Jetzt "GPS offline" wie gewuenscht.
Die verweigerte Freigabe behaelt eine eigene Meldung ("GPS-Freigabe
fehlt"): sie ist der einzige Fall mit anderer Abhilfe, und "GPS offline"
wuerde dort zur Signalsuche statt zum Freigabeschalter schicken.
VERSIONIERUNG: die Zahl, die alle fuer "die Version" hielten, ist keine.
Der Integer in audi-dashboard-version.json ist ein Cache-Brecher, den
install.ps1/update.ps1 bei jedem Deploy mit UtcNow neu setzen -
unabhaengig davon, ob sich Code geaendert hat. Zwei Builds derselben
Quelle bekommen verschiedene Zahlen. Er kann die Frage "ist das derselbe
Stand?" grundsaetzlich nicht beantworten.
Deshalb beide Aufgaben getrennt: neue Datei VERSION im Projektstamm
(2026.08.23.1) als Identitaet, von Hand erhoeht; der Integer bleibt
unveraendert der Cache-Brecher. VERSION fliesst in beide Seiten - als
zweites Feld "app" in audi-dashboard-version.json (alle drei
Deploy-Skripte uebernehmen es jetzt; sie haben die Datei bisher komplett
ueberschrieben und haetten es still zerstoert) und ueber vite define als
__APP_VERSION__ in den Companion-Build. Das Backend veroeffentlicht
pyscript.audi_dashboard_app_version, die App vergleicht und meldet eine
Abweichung in der Hinweisleiste - deren erklaerter Grundsatz "nie eine
stille Veraltung" genau dieser Fall ist, nur dass hier nicht die Anzeige
veraltet, sondern die App selbst.
Bewusst nur Gleichheitsvergleich, nie groesser/kleiner: die Version ist
eine Kennung, keine Zahl; Sortieren waere scheingenau und wuerde bei
einem Formatwechsel still falsch antworten. Fehlt eine der beiden
Seiten, wird nicht verglichen und nichts gemeldet - ein aelteres Backend
oder ein Start ohne Netz darf keinen Fehlalarm ausloesen. Der
vite-Build bricht dagegen hart ab, wenn VERSION fehlt, statt eine App zu
erzeugen, die ihre eigene Veraltung nicht erkennen kann. Das Panel
braucht nichts davon: es laedt bei jedem Seitenaufruf neu.
Geprueft: Backend meldet zuendung: False und app_version 2026.08.23.1 im
Testcontainer, Panel zeigt statt "Fahrzeug faehrt" jetzt "Geparkt seit
13 Tg. 13 Std." und statt der alten Meldung "GPS-Freigabe fehlt";
VERSION landet nachweislich im Build (im Bundle gegriffen) und der Build
bricht ohne die Datei ab (gegengeprueft); tsc sauber, Tests 112/112,
vite build sauber, HA-Start ohne Fehler.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.9 KiB
Versionierung — warum es zwei Zahlen gibt
Kurzfassung für den Alltag: Wenn du etwas an der Oberfläche änderst, erhöhe
VERSION. Alles Weitere erledigen die Bau- und Installationsskripte.
Die zwei Zahlen tun verschiedene Dinge
Sie sahen sich lange zum Verwechseln ähnlich, deshalb hier ausdrücklich getrennt:
VERSION (Repo-Wurzel) |
version in audi-dashboard-version.json |
|
|---|---|---|
| Zweck | Identität: welcher Stand ist das? | Cache-Bruch: hol die Dateien neu |
| Format | 2026.08.23.1 (Datum + laufende Nummer) |
Unix-Sekunden, z. B. 1787016000 |
| Wer setzt sie | du, von Hand, wenn sich etwas ändert | install.ps1 / update.ps1 bei jedem Deploy |
| Vergleichbar zwischen Panel und iOS-App | ja, darum geht es | nein, jede Installation hat eine andere |
Die Unix-Zahl taugt bewusst nicht als Versionsvergleich: sie wird bei jeder Installation neu gesetzt, ohne dass sich am Code etwas geändert hätte. Sie sagt dem Browser nur „lade neu", nicht „das ist Stand X".
Warum das überhaupt nötig wurde
Das Panel und die iOS-App werden völlig unterschiedlich ausgeliefert:
- Panel: holt bei jedem Seitenaufruf
audi-dashboard-version.jsonmitcache: "no-store"und lädt seine Dateien neu, sobald die Zahl sich geändert hat. Es ist damit nach einem Deploy sofort aktuell, ohne Zutun. - iOS-App: eine Capacitor-Hülle mit fest gebündelten Dateien. Sie bleibt auf dem Stand, der beim Signieren in Xcode eingebaut wurde — unbegrenzt.
Die Paritätsregel in AGENTS.md sichert, dass beide Codebasen in derselben
Sitzung geändert werden. Über das, was läuft, sagte bisher nichts etwas: die
iOS-App konnte wochenlang hinterherhinken, ohne dass es irgendwo sichtbar wurde.
VERSION schließt genau diese Lücke — nicht, indem es die Abweichung
verhindert (das kann keine Zahl), sondern indem es sie sichtbar macht.
Wie die Zahl durchs System läuft
VERSION (2026.08.23.1)
│
├─► homeassistant/www/audi-dashboard-version.json { "app": "2026.08.23.1" }
│ │
│ └─► Backend liest die Datei und veröffentlicht sie als
│ pyscript.audi_dashboard_app_version
│ │
│ └─► die iOS-App vergleicht sie mit ihrer eigenen,
│ einkompilierten Zahl und zeigt bei Abweichung
│ einen Hinweis in der Hinweisleiste
│
└─► companion-app: von vite beim Bauen als __APP_VERSION__ eingesetzt
Der Vergleich läuft also immer in eine Richtung: das Backend sagt, welcher Stand ausgeliefert wurde; die App sagt, welchen sie hat. Stimmen sie nicht überein, ist die App zu alt (oder, seltener, das Backend).
Was du tun musst
Bei einer Änderung an der Oberfläche oder am Backend:
VERSIONerhöhen — bei mehreren Änderungen am selben Tag die laufende Nummer:2026.08.23.1→2026.08.23.2, am nächsten Tag2026.08.24.1.- Panel deployen wie bisher (
update.ps1). Das Skript trägt die neueVERSIONinaudi-dashboard-version.jsonein und setzt die Cache-Zahl frisch. - iOS-App neu bauen (
npm run build), damit sie dieselbe Zahl einkompiliert bekommt.
Vergisst du Schritt 3, ist das kein stiller Fehler mehr: die App meldet selbst, dass sie älter ist als der Server.
Bei einer reinen Neuinstallation ohne Codeänderung: nichts tun. VERSION
bleibt, wie sie ist; nur die Cache-Zahl wird neu gesetzt.
Ausblick: OTA-Updates
Sobald @capgo/capacitor-updater eingebaut ist (geprüft: MPL-2.0, passt zu
Capacitor 8, Selbst-Hosting ohne fremde Cloud möglich), holt sich die iOS-App
den neuen Stand selbst — dann entfällt Schritt 3 für alles, was nur
JavaScript/CSS betrifft. Xcode wird dann nur noch für echte native Änderungen
gebraucht. Der Vergleich aus dieser Datei bleibt dabei unverändert nützlich: er
ist genau das Signal, an dem die App erkennt, dass ein neues Bündel bereitliegt.