tobias
d8b12da36d
Das Backend liegt jetzt als custom_components/audi_dashboard/ vor - eine normale Home-Assistant-Integration mit Config-Flow, einer sensor-Plattform und 18 Diensten. Damit ist die App über HACS installierbar; bis das Repo auf GitHub gespiegelt ist (HACS spricht ausschließlich mit GitHub), installiert homeassistant/installationspaket/install.ps1 denselben Ordner ohne HACS. Fünf Installationsschritte entfallen ersatzlos: der pyscript:-Block, der panel_custom:-Block, das Kopieren der Oberfläche nach www/, das langlebige Zugriffstoken (der Verlauf wird direkt über die recorder-API gelesen) und "pip install pypdf" (steht in manifest.json). Das Fahrzeugprofil legt die Integration beim ersten Start aus ihrer Vorlage an. Drei alte Schwächen sind dabei mit erledigt: - Die Nutzlast landet nicht mehr in der Recorder-Datenbank (_unrecorded_attributes - das kann nur eine echte Entität). - Eine laufende Fahrt überlebt einen Neustart (Store statt Arbeitsspeicher); fiel sie während eines Ausfalls ins Ende, schließt nach_neustart_fortsetzen() sie beim letzten aufgezeichneten Zeitpunkt. - Sensor-Zuordnungen wirken sofort - die Zustandsbeobachter werden neu gebunden, der Neustart-Hinweis und der Neustart-Dienst sind weg. Namensvertrag geändert, beide Oberflächen mitgezogen: pyscript.audi_dashboard_x -> sensor.audi_dashboard_x, pyscript.audi_dashboard_y -> audi_dashboard.y. Eine Companion-App vom alten Stand findet nach dem Umstieg nichts mehr und muss neu gebaut werden; das Panel liegt in der Integration und kann nicht driften. Der selbstgebaute Updater entfällt - HACS ist die Update-Mechanik, die Home Assistant kennt. Die Versionierung schrumpft auf eine Quelle: manifest.json. Geprüft am laufenden Testcontainer (Container byteweise identisch mit dem Repo): alle 18 Dienste, Panel, Config-Entry neu laden, Historienimport, echter Shell-Beleg in-process, Neuinstallation im Wegwerf-Container blank mit automatisch nachinstalliertem pypdf. Companion-App: tsc sauber, 112/112 Tests, beide Rauchtests gegen das laufende Backend grün. Belegparser 8/8. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.7 KiB
testumgebung/ — Wegwerf-Home-Assistant für Entwicklung und Tests
Setzt eine vollständige Home-Assistant-Instanz in Docker auf, in der die
Integration dieses Projekts echt läuft: eigene Entitäten, echte Dienstaufrufe,
nachgebildete Fahrzeugsensoren. Gedacht als Ziel für die Abnahmekriterien aus
../UMSETZUNGSPLAN.md (Phasen 1, 6, 9).
Die ursprüngliche Testinstanz aus der Entwicklung des HA-Panels war eine Wegwerfinstanz ohne Skript und ist verloren gegangen — deshalb liegt der Aufbau hier als ausführbares Skript statt als Anleitung.
Aufsetzen
./aufsetzen.sh
Das Skript ist mehrfach ausführbar (löscht einen vorhandenen Container vorher).
Es lädt das offizielle Image, startet den Container auf Port 18123, legt per
API einen Testnutzer an, erzeugt ein langlebiges Zugriffstoken, kopiert
../custom_components/audi_dashboard hinein, startet neu und legt den
Konfigurationseintrag über die API an.
Seit dem Umbau zur eigenen Integration (2026-08-23) fällt dabei einiges weg,
was vorher nötig war: pyscript herunterladen und einrichten, das Backend nach
pyscript/ und die Oberfläche nach www/ kopieren, ein Fahrzeugprofil aus der
Vorlage anlegen, den Belegleser ablegen und ein Zugriffstoken in eine Datei
schreiben. Alles davon macht die Integration jetzt selbst.
Am Ende schreibt es das Token nach ../companion-app/.env.local
(Variable VITE_TEST_TOKEN, gitignored) — von dort holen es die
authentifizierten Tests.
Zugang: http://localhost:18123 · Benutzer test · Passwort testtest123
Was nachgebildet wird
konfiguration.yaml bildet zwei Datenquellen als Template-Sensoren nach, damit
das Backend echte Werte sieht. Steuerbar zur Laufzeit über Helfer — damit
lassen sich die Erkennungsabläufe (Fahrt, Tanken, Reifen) wirklich auslösen:
| Helfer | Steuert | Wofür |
|---|---|---|
input_boolean.test_zuendung |
binary_sensor.testzone_fmm003_engine_ignition_or_acc_status |
Fahrterkennung (Start/Ende, einstellungen.ZUENDUNG_SENSOR) |
input_number.test_kilometerstand |
sensor.audi_rs_4_avant_mileage |
Reifenzähler, Fahrtabschluss-Screening (nur bei manueller Zuordnung über das Setup-Menü, KM_SENSOR ist per Default leer) |
input_number.test_tankfuellstand |
sensor.audi_rs_4_avant_fuel_level |
automatische Tankerkennung (nur bei manueller Zuordnung, TANK_SENSOR ist per Default leer) |
input_number.test_reichweite |
sensor.audi_rs_4_avant_range_primary |
Übersichtsanzeige (nur bei manueller Zuordnung, RANGE_SENSOR ist per Default leer) |
input_boolean.test_tuer_vl |
Tür vorne links | „sicher abgestellt" (nur bei manueller Zuordnung) |
input_boolean.test_fenster_vl |
Fenster vorne links | „sicher abgestellt" (nur bei manueller Zuordnung) |
Die Kilometerstand-/Tankfüllstand-/Reichweite- und Tür-/Fenster-Sensoren
bilden die Entitäten der abgelösten HACS-Integration TommiG1/HA_VAG-EU-Data-Act
nach (siehe custom_components/audi_dashboard/einstellungen.py) — für den Standardbetrieb ohne Bedeutung, aber
weiterhin nützlich, um die manuelle Zuordnung über das Setup-Menü zu testen.
(Türschloss- und Haubenschloss-Erkennung wurden 2026-08-16 ersatzlos aus der
App entfernt, siehe AGENTS.md.)
Beispiel — Fahrt auslösen (Zündung/ACC an, dann aus):
T=$(grep VITE_TEST_TOKEN ../companion-app/.env.local | cut -d= -f2)
curl -X POST -H "Authorization: Bearer $T" -H "Content-Type: application/json" \
-d '{"entity_id":"input_boolean.test_zuendung"}' \
http://localhost:18123/api/services/input_boolean/turn_on
Aufräumen
docker rm -f audi_ha_test
Die Konfiguration liegt außerhalb des Repos unter dem im Skript gesetzten
ZIEL-Pfad; es werden keine echten Fahrzeugdaten verwendet, sondern
fahrzeugprofil.example.json.