Alle Referenzen in Doku und Code aktualisiert (REVERSE_PROXY.md,
INTERNET_ZUGRIFF_EINRICHTEN.md, COMPANION_APP_ARCHITECTURE.md, AGENTS.md,
UMSETZUNGSPLAN.md, companion-app/src/api/umgebung.ts-Kommentar). Dabei den
.app-spezifischen HSTS-Preload-Hinweis in COMPANION_APP_ARCHITECTURE.md §5.4
korrigiert - gilt für .de nicht, Force-SSL in Nginx Proxy Manager deckt das
weiterhin ab. UMSETZUNGSPLAN.md Phase 12 zusätzlich mit einem
Aktualisierungshinweis versehen (zwei-Hostnamen-Plan und pyscript-Namen dort
waren ohnehin schon überholt, jetzt klar auf REVERSE_PROXY.md/
INTERNET_ZUGRIFF_EINRICHTEN.md als maßgeblich verwiesen).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
REVERSE_PROXY.md verwies auf INTERNET_ZUGRIFF_EINRICHTEN.md, das nie
geschrieben wurde - jetzt vorhanden (Cloudflare-Konto, Nameserver-Umstellung,
Cloudflared/NPM-Add-ons, Pfad-Freigabeliste eintragen, Prüfung).
Dabei einen echten Fehler in der Freigabeliste gefunden: sie ging noch von
einem companion-app-Web-Build unter /local/dm360/ aus (Planungsstand
2026-08-11) - das wurde nie gebaut, die App ist nativ/sideload-only. Ersetzt
durch den tatsächlichen Fernbedarf: das OTA-Bündel unter
/audi_dashboard_static/app/* (@capgo/capacitor-updater). Damit genügt auch
ein einziger Hostname statt der ursprünglich erwogenen App-/API-Trennung.
COMPANION_APP_ARCHITECTURE.md §5 und AGENTS.md entsprechend nachgezogen.
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
Owner-Entscheidung: der Mehraufwand einer VPS-Bridge steht in keinem Verhaeltnis zum
zusaetzlichen Schutz, da TLS-Zwang plus Pflicht-Client-Zertifikat den Port bereits
praktisch unangreifbar macht.
"Custom server" ist im Configurator des Besitzers nicht auswählbar. Ein zweiter unabhängiger
Praxisbericht (mdworld.nl) bestätigt "AWS IoT Custom" + eigener Server als funktionierenden Weg
und deckt zwei kritische Stolpersteine auf: umgekehrte Zertifikatsketten-Reihenfolge und ein
Topic-Namensschema mit %imei%.
Configurator-Hilfetext (Screenshot) bestätigt einen vierten, in der offiziellen Doku nicht
beschriebenen Wert für eigene Broker. Ein Community-Thread bestätigt den Ansatz praktisch, zeigt
aber auch einen ungelösten FMM003-spezifischen Fehlerbericht - TCP/Codec8 bleibt der Rückfallplan.
Bei all-inkl angelegt, ohne Webseite und ohne Postfach darauf. Geplante
Adresse der App: https://datametric360.app
Offen bleibt der eigentliche Schritt: die Nameserver muessen bei all-inkl
auf Cloudflare umgestellt werden, sonst kann der Tunnel darunter keinen
Hostnamen veroeffentlichen. Die Alternative, die DNS bei all-inkl zu
belassen, gibt es nur im Business-Tarif fuer 200 USD/Monat. Da auf der
Domain nichts liegt, ist die Umstellung folgenlos.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der FMM003 beherrscht Codec JSON - damit entfällt der einzige Grund, aus
dem Traccar überhaupt vorgesehen war: das Entschlüsseln des binären
Codec8-Protokolls.
Recherchiert und bestätigt: Codec JSON ist ein Datenprotokoll, kein
Transportweg; der zugehörige Transport ist MQTT, nicht ein HTTP-Webhook.
Ein eigener Broker ist vorgesehen (IP, Port, optional Anmeldung), TLS ist
dabei Pflicht. Home Assistant bringt beides von Haus aus mit: das
Mosquitto-Add-on und die MQTT-Integration samt json_attributes_topic.
Damit entfallen ersatzlos: das Traccar-Add-on, dessen H2-Datenbank samt
Sicherung, das Position Forwarding an einen HA-Webhook, der offene rohe
TCP-Port und die Alternative eines selbst geschriebenen Codec8-Decoders.
Übrig bleibt FMM003 -> MQTT/TLS -> Mosquitto -> MQTT-Integration.
Neu zu klären und in §5 aufgenommen: wie das Fahrzeug den Broker von außen
erreicht (Portfreigabe 8883 oder VPS-Broker mit Mosquitto-Bridge - Cloudflare
Tunnel hilft hier nicht, der ist auf HTTP zugeschnitten), sowie die
TLS-Zertifikate. Die Zuordnungstabelle der Fahrzeugwerte kann erst nach dem
Mitschnitt einer echten MQTT-Nachricht entstehen - die Feldnamen werden nicht
geraten.
Der bisherige Traccar-Abschnitt bleibt als Entscheidungsprotokoll stehen,
deutlich als überholt markiert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei zusammengehörige Teile in einem Repository:
- homeassistant/ Das fertige, im Einsatz befindliche Home-Assistant-Panel
(panel_custom Custom Element + pyscript-Backend). Echte Fahrzeug- und
Personendaten (fahrzeugprofil.json, fahrten.jsonl, tankvorgaenge.jsonl,
Tankbelege) bleiben per .gitignore außen vor; die anonymisierte Vorlage
fahrzeugprofil.example.json ist mit dabei.
- design-system/ Eigenständige React-Komponentenbibliothek (@audi-dash/ui),
die die visuelle Sprache des Panels nachbildet - ohne Audi-Markenzeichen
und ohne die lizenzierte Hausschrift. Dient als Grundlage für Claude
Design. War bis hierher ein eigenes Repository und ist in dieses
eingeschmolzen worden.
- companion-app/ Datenschicht der neuen App DataMetric360 (iOS/Android via
Capacitor, zusätzlich als Iframe im HA-Dashboard). Noch ohne Oberfläche:
REST- und WebSocket-Zugriff auf Home Assistant plus Warteschlange für
Änderungen ohne Netz. Ersetzt das eingespritzte hass-Objekt, das nur
innerhalb des HA-Frontends existiert.
Dazu die Projektdokumentation: SPECIFICATION.md (Ist-Stand des Panels),
COMPANION_APP_ARCHITECTURE.md (Architekturentscheidungen der neuen App),
AUDIT_2026-08-10.md, DESIGN_BRIEF_DATAMETRIC360.md und der ursprüngliche
Bauauftrag.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tobias