tobias
fb251154c7
Zwei getrennte Themen in einem Commit, beide in derselben Sitzung entstanden:
1. Ölwechsel/Inspektion wurden komplett ausgeblendet ("kein Eintrag im
Servicebuch"), sobald kein Servicebucheintrag vorlag - selbst wenn der
zugeordnete Sensor eine gültige Fälligkeit meldete. In beiden Frontends
prüfte die Anzeige nur den Servicebuch-Zweig, bevor sie die
Fahrzeugmeldung überhaupt las. Jetzt steht die Fahrzeugmeldung für sich;
fehlt zusätzlich ein Servicebucheintrag, übernimmt eine neue,
fahrtenlog-basierte Prognose (kmProTagAusFahrten()/meldungsPrognose())
die Hochrechnung statt der Servicebuch-Rate - deckelt auf die vom
Fahrzeug selbst gemeldete Zeitgrenze, falls zu wenig gefahren wird.
2. install.ps1 als Update-Weg wird von Windows Smart App Control blockiert,
ohne Umgehungsmöglichkeit. Die Integration lädt sich jetzt auf
Tastendruck selbst von Gitea (aktualisierung.py), verifiziert das
Manifest vor jedem Tausch und tauscht per os.rename mit automatischem
Rollback bei Fehlern - install.ps1 bleibt nur noch für die
Erstinstallation nötig. Zugangstoken über einen neuen OptionsFlow in
entry.options, nie in configuration.yaml.
Nebenbei: mehrere seit der HACS-Ausschluss-Entscheidung liegen gebliebene
falsche HACS-Referenzen in Code-Kommentaren und einem UI-Text korrigiert.
Details, Sicherheitsbegründung und Verifikationsstand in AGENTS.md,
Abschnitte I und J.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
47 lines
2.0 KiB
TypeScript
47 lines
2.0 KiB
TypeScript
import { readFileSync } from "node:fs"
|
|
import { fileURLToPath } from "node:url"
|
|
|
|
import { defineConfig } from "vite"
|
|
import react from "@vitejs/plugin-react"
|
|
|
|
// Die App-Version kommt aus der manifest.json der Integration — derselben
|
|
// Zahl, die Home Assistant als Version der Integration führt und die das
|
|
// Backend über sensor.audi_dashboard_app_version meldet (siehe
|
|
// VERSIONIERUNG.md). Sie wird hier fest einkompiliert, damit die fertige App
|
|
// weiß, aus welchem Stand sie gebaut wurde, und das gegen den vom Backend
|
|
// gemeldeten Stand halten kann.
|
|
//
|
|
// Bis 2026-08-23 stand die Zahl in einer eigenen Datei VERSION im
|
|
// Projektstamm. Die ist mit dem Umbau zur Integration überflüssig geworden:
|
|
// Home Assistant selbst verlangt ein version-Feld in jeder manifest.json,
|
|
// unabhängig von HACS (das für dieses private Repository ohnehin dauerhaft
|
|
// ausscheidet, siehe AGENTS.md Abschnitt H). Zwei Quellen für dieselbe
|
|
// Angabe wären eine Quelle zu viel — sie hätten irgendwann
|
|
// auseinandergelegen, und der Vergleich, den diese Zahl trägt, wäre still
|
|
// falsch geworden.
|
|
//
|
|
// Absichtlich hart: fehlt die Datei oder das Feld, soll der Build abbrechen
|
|
// statt still eine App ohne Versionsangabe zu erzeugen — die könnte ihre
|
|
// eigene Veraltung nicht mehr erkennen, und genau das ist der Zweck der
|
|
// ganzen Mechanik.
|
|
const manifestPfad = fileURLToPath(
|
|
new URL("../custom_components/audi_dashboard/manifest.json", import.meta.url),
|
|
)
|
|
const appVersion: string = JSON.parse(readFileSync(manifestPfad, "utf8")).version
|
|
if (!appVersion) throw new Error(`Kein "version"-Feld in ${manifestPfad}`)
|
|
|
|
// Basispfad relativ: die App wird sowohl unter einer eigenen Domain als auch
|
|
// aus einem Unterordner heraus ausgeliefert (Home Assistant: /local/dm360/),
|
|
// und in der Capacitor-Hülle direkt vom Dateisystem.
|
|
export default defineConfig({
|
|
base: "./",
|
|
plugins: [react()],
|
|
define: { __APP_VERSION__: JSON.stringify(appVersion) },
|
|
server: { port: 5173 },
|
|
build: {
|
|
outDir: "dist",
|
|
target: "es2022",
|
|
sourcemap: true,
|
|
},
|
|
})
|