15 Befunde aus den 18 neuen Commits, nach Schaden sortiert und mit
Datei-Zeile-Belegen. Die drei schwersten liegen im neuen Setup-Menue:
Speichern bei noch nicht geladenem Katalog ueberschreibt entitaeten.json
mit {} und loescht damit alle Zuordnungen, Zuruecksetzen wirkt bei 15 von
17 Feldern nicht, und alle vier Listenpositionen bekommen denselben Sensor,
wodurch "Sicher abgestellt" gesichert meldet, obwohl drei Tueren nie
geprueft wurden.
Jeder Befund ist als belegt oder plausibel gekennzeichnet; die belegten
sind am Code nachvollzogen, die Zuruecksetz-Regel zusaetzlich isoliert
nachgestellt.
main ist 18 Commits voraus (FMM003, Setup-Menue, iOS-Auflage). Zusammenfuehren
ist bewusst aufgeschoben. Festgehalten ist vor allem die eine Stelle, die ein
sauberer Merge nicht auffangen wuerde: profil_lesen() gibt in diesem Branch bei
fehlender Profildatei None zurueck, profil.py ist auf main unveraendert und
geht damit konfliktfrei durch - aber die dortigen Aufrufstellen pruefen das
nicht und wuerden abstuerzen statt eine verstaendliche Meldung zu schreiben.
Fünf Erweiterungen des bestehenden Setup-Popups: Live-Wert neben jedem
Such-Kandidaten, Warnhinweis bei unavailable/unknown/fehlender Entität,
Duplikat-Check mit Bestätigung vor dem Speichern, Zurücksetzen-Button je
Feld (Standardwerte-Snapshot in entitaeten.py, vor jedem Override
genommen), und ein bestätigter "Jetzt neu starten"-Knopf nach dem
Speichern, falls sich eines der drei trigger-gebundenen Felder geändert
hat (neuer Service audi_dashboard_neustart). Im Docker-Testcontainer
Feld für Feld verifiziert.
update.ps1 kopierte audi-dashboard-ios.css und www/badges/ nie, obwohl beide
von der laufenden App gebraucht werden - jedes Update seit Einfuehrung dieser
Dateien liess den deployten Stand dort veraltet zurueck. Ausserdem zwei
verwaiste *.bak-before-audit-merge-Dateien aus www/ entfernt (bereits
gitignored, nie versioniert) und installationspaket/ (generiertes,
gitignored Deployment-Bundle fuer eine frische HA-Installation) als neuen
Ignore-Eintrag ergaenzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
audi-dashboard-app.js war bereits mit dem Design-Projekt identisch, aber
audi-dashboard-ios.css war seit einer Weile nicht mehr neu gezogen worden:
Design hatte inzwischen einen Rings-Klon oben in der Desktop-Sidebar
(.navmarke) sowie einen gefuellten Pill-Stil fuer den aktiven Tab ergaenzt.
Nach Byte-Diff-Pruefung (nur additive CSS-Aenderungen) komplett uebernommen,
in Docker deployt und bei 402px/1400px verifiziert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ersetzt die veralteten Installationsschritte (manuelles Eintragen von
WLAN_SENSOR/TommiG1-Entity-IDs in einstellungen.py) durch eine Anleitung
für das neue Setup-Menü in der App und die aktuellen FMM003-Feldnamen
(ZUENDUNG_SENSOR, STANDORT_TRACKER, BATTERIE_SENSOR). AGENTS.md entsprechend
nachgeführt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Setup-Menü (Einstellungen -> Fahrzeug einrichten -> Setup): ordnet alle von
der App genutzten Sensor-Rollen echten HA-Entitäten zu, statt sie in
einstellungen.py von Hand einzutragen - durchsuchbares Dropdown je Feld,
Vorauswahl aus vorhandenen Entitäten, Schalter für "nur passende Sensoren".
Neues Modul entitaeten.py (Katalog + JSON-Override, zur Laufzeit über
setattr() auf einstellungen angewendet, kein Neustart nötig außer für die
drei trigger-gebundenen Felder).
Zusätzlich: Fahrzeug-WLAN-Erkennung und alle Entity-IDs der nicht mehr
genutzten TommiG1/HA_VAG-EU-Data-Act-Integration entfernt. Fahrterkennung
läuft jetzt über den Zündungs-/ACC-Status des neu angebundenen Teltonika
FMM003 (ersetzt die WLAN-Verbindungserkennung); Standort und 12V-
Batteriespannung kommen ebenfalls vom FMM003. Kilometerstand, Tankfüllstand,
Reichweite, Türen/Fenster/Schlösser sowie Ölwechsel-/Inspektionsdaten haben
dadurch vorerst keine Quelle mehr und zeigen "unbekannt" - die Funktionen
selbst bleiben erhalten und lassen sich über das neue Setup-Menü jederzeit
neu zuordnen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neue Kachel oberhalb von "Zuletzt" mit echter Leaflet-Mini-Karte,
öffnet per Klick eine Vollbild-Standortansicht (Kartendarstellung
wählen, auf Fahrzeug/User zentrieren, beide zeigen) mit einem
ausziehbaren myAudi-Stil-Menü: Distanz zum Gerät, Adresse (Reverse-
Geocoding via Nominatim), fährt/steht/Letzter-Parkplatz-Status,
Tankfüllstand/Reichweite, Route- und Teilen-Aktionen.
Backend: STANDORT_TRACKER-Einstellung (device_tracker-Entity) plus
_standort()-Veröffentlichung, bewusst leer gelassen bis eine echte
GPS-Quelle (FMM003/flespi) angebunden ist - Kachel zeigt bis dahin
"kein GPS-Signal". Verifiziert in audi_ha_test mit einer manuell
gesetzten Test-Position.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die iOS/Großbildschirm-Auflage setzte :host > div{height:100%}
bedingungslos, was die App auch im mobilen Layout brach, da HA die
reale Höhe durch panel_custom nicht zuverlässig durchreicht. Jetzt
bleibt die viewport-verankerte 100dvh-Höhe (mit 880px-Deckel) bei
allen Breiten erhalten; der Deckel entfällt nur noch innerhalb der
@container (min-width:860px)-Desktop-Auflage. Fix lokal in Docker und
im Claude-Design-Board (DataMetric360 Board.dc.html) verifiziert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tatsaechliche Ursache der deploy_challenge-Fehlschlaege gefunden: ein
ueberfluessiger/falscher aliases-Eintrag (alias: datametric360 ohne
.duckdns.org) in der DuckDNS-Add-on-Konfiguration, zusammen mit
accept_terms: false. Nach Entfernen von aliases und accept_terms: true lief
die Zertifikatsanfrage sofort durch. Der DNS-Server war entgegen der
vorherigen Vermutung kein Faktor - Erfolg trat auch mit dem Speedport als
DNS ein.
configuration.yaml's alter http:-Block entfernt, HA migriert SSL-Pfade und
interne/externe URL jetzt ueber die Oberflaeche (Einstellungen > System >
Netzwerk). Dabei eine HA-Eigenheit dokumentiert: Netzwerkaenderungen muessen
innerhalb 5 Minuten per Dialog bestaetigt werden, sonst automatischer
Rollback.
HA ist jetzt per HTTPS mit gueltigem Let's-Encrypt-Zertifikat erreichbar.
deploy_challenge (DNS-01) scheiterte reproduzierbar am dig-Aufruf im
DuckDNS-Add-on-Container selbst, obwohl DuckDNS den TXT-Eintrag nachweislich
korrekt setzt und dieser ueberall sonst (PC, HA-SSH-Konsole) sofort sichtbar
war - Ursache innerhalb des Containers blieb trotz gruendlicher Diagnose
ungeklaert. Entscheidung: abschalten statt weiter debuggen, da HA ohnehin
nur ueber Tailscale erreichbar ist. DuckDNS selbst (IP-Update) laeuft
zuverlaessig weiter - das ist der fuer den FMM003-Pfad relevante Teil.
configuration.yaml's http:-Block bleibt deshalb dauerhaft auskommentiert.
Portfreigabe 8883 und FMM003-Datenversand sind bestaetigt erledigt.
- Eigene CA + Server-/Client-Zertifikate erzeugt und Mosquitto konfiguriert
- Dateinamen-Endungs-Stolperstein am FMM003-Configurator dokumentiert (.pem/.pem.crt/.pem.key)
- Dual-Stack am Router bestaetigt, Portfreigabe-Risiko damit ausgeraeumt
- Klargestellt: Cloudflare ersetzt DuckDNS+Portfreigabe+Mosquitto nicht, sondern ergaenzt sie
fuer einen anderen Zweck (App-Erreichbarkeit statt Fahrzeug-MQTT)
- AGENTS.md Open-Items-Liste entsprechend abgehakt
Elf von dreizehn Phasen sind erledigt oder vorbereitet. AGENTS.md haelt
zusaetzlich die drei Fehler fest, die erst der Betrieb gegen eine echte
Home-Assistant-Instanz zutage brachte - und den verworfenen selbstgebauten
QR-Erzeuger, damit niemand den Versuch wiederholt.
Schrittweiser Plan fuer alle offenen Punkte inkl. Abnahmekriterien je
Schritt, Nachschlagereferenz und Definition of Done. Ergaenzt die
Entscheidungen vom 2026-08-11: kein Electron (Capacitor bzw. PWA) und
kein eigenes Backend (HA-API direkt).
Englischsprachiger Einstiegspunkt für Agent-Sessions: Statusübersicht der
drei Teilprojekte, Review-Befunde vom 2026-08-11, offene Punkte als
Checklisten, Karpathy-Regeln und Claude-Code-Praktiken als verbindlicher
Standard, plus Pflicht zur Aktualisierung bei Änderungen. CLAUDE.md
importiert die Datei per @AGENTS.md (Claude Code liest AGENTS.md nicht
nativ).
Paul Nothaft
tobias