Domain auf datametric360.de umgestellt (war .app)

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>

AGENTS.md

@@ -231,7 +231,9 @@ Home Assistant (`npm run smoke`, `npm run smoke:auth`). `npm run dev` in the rep
   architecture doc, marked ÜBERHOLT. Details and open steps in section B below.
 - Frontend access: HA REST + WebSocket with a long-lived access token (no `hass` object).
 - External access: Cloudflare Tunnel + reverse proxy with a path allowlist; HA itself stays
-  unreachable. Domain **`datametric360.app`** registered (all-inkl, 2026-08-11).
+  unreachable. Domain **`datametric360.de`** registered (all-inkl, 2026-08-11; originally `.app`,
+  switched to `.de` 2026-08-28 — every doc reference updated the same day, including the note in
+  `COMPANION_APP_ARCHITECTURE.md` §5 item 4 that `.app`'s HSTS-preload advantage no longer applies).
 - Distribution: **sideload only** (license reason) — hence real Audi assets are allowed there.
 - Trip detection moves to FMM003 ignition; the pause-tolerance feature
   (`fahrten_pausenzeit_min`) is a deliberate product decision and must be preserved.
@@ -419,7 +421,7 @@ wraps the web app for iPhone; a PWA home-screen install is the accepted intermed
 
 ### B) Infrastructure / commissioning (partly waits for FMM003 hardware)
 
-- [ ] Switch `datametric360.app` nameservers at all-inkl to Cloudflare ("full setup") —
+- [ ] Switch `datametric360.de` nameservers at all-inkl to Cloudflare ("full setup") —
       prerequisite for the tunnel; domain carries nothing else, so this is consequence-free. Step-by-
       step runbook for this and everything below it now exists:
       [`homeassistant/INTERNET_ZUGRIFF_EINRICHTEN.md`](homeassistant/INTERNET_ZUGRIFF_EINRICHTEN.md)
@@ -427,7 +429,7 @@ wraps the web app for iPhone; a PWA home-screen install is the accepted intermed
       add-on UI all remain the owner's own action; nothing here can be done unattended.
 - [x] Decide hostname split — **resolved 2026-08-28: no split, one hostname is enough.** The original
       app-domain-vs-API-subdomain question assumed a served web build; distribution stayed native/
-      sideload only (never built as a web app), so `https://datametric360.app` alone covers both API
+      sideload only (never built as a web app), so `https://datametric360.de` alone covers both API
       calls and the app's own OTA bundle. See `COMPANION_APP_ARCHITECTURE.md` §5 item 4.
 - [x] Choose reverse proxy — **decided 2026-08-28: Nginx Proxy Manager**, not Traefik. See
       `COMPANION_APP_ARCHITECTURE.md` §5 item 3.

COMPANION_APP_ARCHITECTURE.md

@@ -1,7 +1,7 @@
 # DataMetric360 — Companion App Architecture (design decided, not yet built)
 
 **App name: `DataMetric360`** (decided 2026-08-10). Public hostname: a subdomain of
-**`datametric360.app`**,
+**`datametric360.de`**,
 a dedicated domain registered at all-inkl solely for this purpose (see §5.4 for why it must be a
 separate domain). Both the app name and the domain are deliberately neutral — they don't advertise
 "Audi", "car", or "GPS tracker" to anyone who sees the hostname or the app icon, which is a small but
@@ -402,14 +402,19 @@ else in this document:
    picked and is what `homeassistant/REVERSE_PROXY.md` and `INTERNET_ZUGRIFF_EINRICHTEN.md` are written
    against. Setup itself (Cloudflare account, nameserver switch, add-on installation) is still the
    owner's own action to perform — see the runbook for the exact steps.
-4. **Cloudflare Tunnel domain** — ✅ **ERLEDIGT: `datametric360.app` ist bei all-inkl registriert**
+4. **Cloudflare Tunnel domain** — ✅ **ERLEDIGT: `datametric360.de` ist bei all-inkl registriert**
-   (Stand 2026-08-11). Eigens dafür angelegt, ohne Webseite und ohne Postfach darauf — genau so, wie
+   (ursprünglich `.app`, seither auf `.de` umgestellt — Stand 2026-08-28). Eigens dafür angelegt, ohne
-   es die unten stehende Einschränkung verlangt. Vorgesehene Adresse der App später:
+   Webseite und ohne Postfach darauf — genau so, wie es die unten stehende Einschränkung verlangt.
-   `https://datametric360.app`.
+   Vorgesehene Adresse der App später: `https://datametric360.de`.
 
-   `.app` steht auf der HSTS-Preload-Liste: Browser erzwingen dort HTTPS bedingungslos. Das passt zum
+   **Korrektur 2026-08-28:** die ursprüngliche `.app`-Wahl hatte einen zusätzlichen Vorteil, der mit dem
-   Cloudflare Tunnel (immer HTTPS) und schließt eine versehentliche Klartextverbindung von vornherein
+   Wechsel auf `.de` entfällt — `.app` steht auf Chromes HSTS-Preload-Liste, `.de` nicht, der Browser
-   aus.
+   erzwingt dort also nicht von sich aus HTTPS ohne vorherigen Kontakt zur Domain. Das ändert nichts an
+   der Sicherheit dieses Aufbaus: Cloudflare Tunnel liefert ohnehin ausschließlich HTTPS aus, und Nginx
+   Proxy Manager kann zusätzlich "Force SSL" erzwingen (siehe `INTERNET_ZUGRIFF_EINRICHTEN.md` Schritt
+   4) - nur der zusätzliche, browserseitig *vorab* erzwungene Schutz vor dem allerersten Verbindungs-
+   aufbau (bevor die App überhaupt einmal erfolgreich verbunden war) entfällt. Für ein sideload-only
+   installiertes, nicht öffentlich beworbenes Gerät eine vernachlässigbare Einbuße.
 
    **Noch offen, und der eigentliche Knackpunkt:** die Nameserver der Domain müssen bei all-inkl auf
    Cloudflare umgestellt werden („Full setup") — erst dann kann der Tunnel einen Hostnamen darunter
@@ -420,7 +425,7 @@ else in this document:
    ✅ **ERLEDIGT (2026-08-28): ein einziger Hostname genügt**, kein Split nötig. Der ursprüngliche
    Gedanke (App-Domain vs. API-Subdomain) setzte voraus, dass die App selbst als Web-Build unter einer
    eigenen Adresse ausgeliefert würde — das wurde nie gebaut (Distribution blieb nativ/sideload, §1).
-   Es gibt nur eine Adresse, die überhaupt gebraucht wird: `https://datametric360.app`, die die App
+   Es gibt nur eine Adresse, die überhaupt gebraucht wird: `https://datametric360.de`, die die App
    sowohl für API-Aufrufe als auch für ihr eigenes OTA-Bündel verwendet (siehe §5 Punkt 1 oben,
    `homeassistant/REVERSE_PROXY.md`).
 
@@ -433,7 +438,7 @@ else in this document:
    ($200/month)**, i.e. not realistic here.
 
    **Therefore: never point this at an existing all-inkl domain carrying live websites or email** —
-   hence the dedicated `datametric360.app`. Nothing about the owner's existing domains/mail is touched.
+   hence the dedicated `datametric360.de`. Nothing about the owner's existing domains/mail is touched.
 
    Note the all-inkl "Neue Domain anlegen" dialog asks for a target (Webspace / Redirect /
    Webbaukasten) — that choice is irrelevant here, since DNS gets delegated to Cloudflare afterwards

UMSETZUNGSPLAN.md

@@ -484,39 +484,44 @@ nicht ein Riesencommit.
 
 ## Phase 12 — Externer Zugriff: Cloudflare Tunnel + Reverse Proxy 🟡 VORBEREITET
 
-> Fertige Freigabeliste samt Prüfbefehlen: `homeassistant/REVERSE_PROXY.md`.
+> **2026-08-28 aktualisiert/teilweise überholt.** Die Schritte unten stammen aus der frühen
-> Ausführung braucht Cloudflare-Konto und die Nameserver-Umstellung.
+> Planungsphase (2026-08-11) und enthalten inzwischen überholte Annahmen: zwei getrennte Hostnamen
+> (App-Domain + API-Subdomain — entfällt, die App wird nie als Web-Build ausgeliefert, siehe
+> `COMPANION_APP_ARCHITECTURE.md` §5 Punkt 4) und pyscript-Entitäts-/Dienstnamen (seit der
+> Integrations-Umstellung 2026-08-23 `sensor.audi_dashboard_*`/`audi_dashboard.<name>`, siehe
+> `AGENTS.md` Abschnitt H). Reverse-Proxy-Wahl (Nginx Proxy Manager) und die vollständige, aktuelle
+> Freigabeliste stehen bereits fest. **Maßgeblich für die tatsächliche Einrichtung sind
+> [`homeassistant/INTERNET_ZUGRIFF_EINRICHTEN.md`](homeassistant/INTERNET_ZUGRIFF_EINRICHTEN.md)
+> (Schritt-für-Schritt-Anleitung) und [`homeassistant/REVERSE_PROXY.md`](homeassistant/REVERSE_PROXY.md)
+> (die Freigabeliste selbst)** - die Liste unten bleibt nur als Entscheidungsprotokoll stehen, nicht
+> als aktuelle Anleitung.
 
 **Ziel:** Die App funktioniert von unterwegs (Mobilfunk), ohne dass HA selbst erreichbar ist.
 Referenz: `COMPANION_APP_ARCHITECTURE.md` §4/§5. Teilweise Besitzer-Aufgaben (Konten/DNS).
 
-1. **[Besitzer] Nameserver umstellen:** `datametric360.app` bei all-inkl auf die
+1. **[Besitzer] Nameserver umstellen:** `datametric360.de` bei all-inkl auf die
    Cloudflare-Nameserver zeigen lassen (Cloudflare-Konto → Site hinzufügen → „Full setup";
-   Domain trägt sonst nichts, Umstellung ist folgenlos). ✅ wenn `dig NS datametric360.app` die
+   Domain trägt sonst nichts, Umstellung ist folgenlos). ✅ wenn `dig NS datametric360.de` die
    Cloudflare-Server liefert.
-2. **Hostnamen festlegen** (Empfehlung aus dem Architekturdokument übernehmen): App unter
+2. ~~Hostnamen festlegen (App-Domain + getrennter API-Hostname)~~ — **überholt, siehe Hinweis oben:**
-   `https://datametric360.app`, API unter `https://api.datametric360.app` — getrennter
+   ein einziger Hostname (`https://datametric360.de`) genügt, da die App nativ/sideload-only bleibt
-   API-Hostname hält die Allowlist übersichtlich. Entscheidung in `AGENTS.md` protokollieren.
+   und nie als eigener Web-Build ausgeliefert wird.
-3. **Cloudflared-Add-on** in HA installieren, Tunnel erstellen, zwei öffentliche Hostnamen:
+3. **Cloudflared-Add-on** in HA installieren, Tunnel erstellen, **ein** öffentlicher Hostname
-   `datametric360.app` → Reverse-Proxy-Port (statische App-Dateien + nichts weiter),
+   (`datametric360.de` → Reverse-Proxy-Port). Kein Router-Port wird geöffnet. Genaue Klicks:
-   `api.datametric360.app` → Reverse-Proxy-Port (API-Pfade). Kein Router-Port wird geöffnet.
+   `INTERNET_ZUGRIFF_EINRICHTEN.md` Schritt 3/5.
-4. **Reverse Proxy:** Nginx Proxy Manager-Add-on (Standard-Empfehlung; Traefik nur, falls NPM
+4. **Reverse Proxy:** Nginx Proxy Manager-Add-on (entschieden, nicht Traefik). Die Allowlist ist
-   an Grenzen stößt — Entscheidung dokumentieren). Allowlist ausschließlich:
+   umfangreicher als unten ursprünglich skizziert (aktueller Entitäts-/Dienststand plus das
-   - `GET /api/states/pyscript.audi_dashboard_*` und `GET /api/states/pyscript.reifen_*`
+   OTA-Bündel unter `/audi_dashboard_static/app/*`) - wortwörtlich in `REVERSE_PROXY.md` gepflegt,
-   - `POST /api/services/pyscript/audi_dashboard_*`
+   nicht hier dupliziert. ⚠️ Ehrliche Einschränkung bleibt bestehen: `/api/websocket` lässt sich
-   - `GET /api/` (Verbindungsprüfung) und der WebSocket-Pfad `/api/websocket`
+   nicht pfadgenau beschneiden — nach `auth_ok` sind darüber alle States lesbar. Schutzschicht
-   Alles andere (v. a. `/auth`, `/lovelace`, `/config`, `/api/config`) wird geblockt.
+   bleibt der LLAT (ohne Token keine Verbindung).
-   ⚠️ Ehrliche Einschränkung dokumentieren: `/api/websocket` lässt sich nicht pfadgenau
+5. **Prüfen von außen** (Mobilfunk, VPN aus): die Prüfbefehle stehen in `REVERSE_PROXY.md`
-   beschneiden — nach `auth_ok` sind darüber alle States lesbar. Schutzschicht bleibt der LLAT
+   ("Nach der Einrichtung prüfen"). HA-Port 8123 ist von außen nicht erreichbar.
-   (ohne Token keine Verbindung); das ist die im Architekturdokument akzeptierte Abwägung.
+6. ✅ Fertig wenn: Schritt 5 vollständig besteht und die Server-Adresse in der App eingetragen ist
-5. **Prüfen von außen** (Mobilfunk, VPN aus): App lädt, Login klappt, `curl` auf einen
+   (`INTERNET_ZUGRIFF_EINRICHTEN.md` Schritt 7). In `AGENTS.md` Block B abhaken.
-   Nicht-Allowlist-Pfad (z. B. `/auth/authorize`) liefert 403/404; HA-Port 8123 ist von außen
-   nicht erreichbar.
-6. ✅ Fertig wenn: Schritt 5 vollständig besteht. Die endgültige Allowlist wortwörtlich in
-   `COMPANION_APP_ARCHITECTURE.md` §5.1 eintragen (dort als offener Punkt vorgemerkt) und in
-   `AGENTS.md` Block B abhaken.
 
-Schritte 2–4 können gegen die bestehende HA-API **vor** der FMM003-Hardware erledigt werden.
+Schritte 3–4 können gegen die bestehende HA-API erledigt werden (die FMM003-Hardware läuft seit
+2026-08-13 bereits über flespi, siehe Phase 13 unten — diese Phase hängt nicht mehr daran).
 
 ---
 
@@ -595,6 +600,6 @@ kommen asynchron über Entitäten (Muster: Beleg-Upload).
 
 Die App gilt als fertig, wenn: alle Screens aus Phase 7 in beiden Layouts funktionieren; Onboarding,
 Offline-Queue und Beleg-Upload gegen die Produktiv-HA laufen; die App als PWA und (falls Capacitor
-umgesetzt) nativ auf dem iPhone installiert ist; der externe Zugriff über `datametric360.app`
+umgesetzt) nativ auf dem iPhone installiert ist; der externe Zugriff über `datametric360.de`
 funktioniert, ohne dass HA exponiert ist; das alte Panel archiviert ist; und `AGENTS.md` den
 Endstand widerspiegelt (alle Blöcke A–D abgehakt oder begründet gestrichen).

companion-app/src/api/umgebung.ts

@@ -101,7 +101,7 @@ const SCHLUESSEL_BASIS = "dm360.basis_url";
 const SCHLUESSEL_TOKEN = "dm360.token";
 
 export interface Zugang {
-  /** Basis-URL ohne abschließenden Schrägstrich, z. B. https://audi.datametric360.app */
+  /** Basis-URL ohne abschließenden Schrägstrich, z. B. https://audi.datametric360.de */
   basisUrl: string;
   /** Long-Lived Access Token aus dem HA-Benutzerprofil. */
   token: string;

homeassistant/INTERNET_ZUGRIFF_EINRICHTEN.md

@@ -13,7 +13,7 @@ es hier keine Automatisierung, nur die genauen Schritte. Alles, was als Datei/Ko
 werden konnte, ist bereits fertig (`REVERSE_PROXY.md`s Regeln).
 
 **Voraussetzungen, die bereits erfüllt sind** (nichts davon ist hier noch zu tun):
-- `datametric360.app` ist bei all-inkl registriert (siehe `../COMPANION_APP_ARCHITECTURE.md` §5 Punkt 4)
+- `datametric360.de` ist bei all-inkl registriert (siehe `../COMPANION_APP_ARCHITECTURE.md` §5 Punkt 4)
   - eigens dafür, ohne Webseite/Postfach darauf.
 - Die companion-app spricht bereits ausschließlich REST/WebSocket gegen eine konfigurierbare
   "Server-Adresse" (kein `hass`-Objekt, kein fest verdrahteter Hostname) - dieser Schritt ändert nur,
@@ -24,7 +24,7 @@ werden konnte, ist bereits fertig (`REVERSE_PROXY.md`s Regeln).
 ## 1. Cloudflare-Konto anlegen, Domain hinzufügen
 
 1. Auf [cloudflare.com](https://cloudflare.com) ein (kostenloses) Konto anlegen.
-2. Im Dashboard *Add a Site* → `datametric360.app` eingeben.
+2. Im Dashboard *Add a Site* → `datametric360.de` eingeben.
 3. Plan **Free** wählen - reicht vollständig aus (Tunnel und DNS sind im Free-Plan enthalten, nur das
    "partial/CNAME setup" ohne Nameserver-Wechsel wäre Business-only, siehe Schritt 2).
 4. Cloudflare scannt bestehende DNS-Einträge der Domain und schlägt zwei Nameserver vor (z. B.
@@ -35,7 +35,7 @@ werden konnte, ist bereits fertig (`REVERSE_PROXY.md`s Regeln).
 **Das ist der eigentliche Knackpunkt** - erst danach kann der Tunnel überhaupt einen Hostnamen
 veröffentlichen.
 
-1. Bei all-inkl (KAS-Verwaltung) einloggen → *Domains* → `datametric360.app` → Nameserver-Einstellungen.
+1. Bei all-inkl (KAS-Verwaltung) einloggen → *Domains* → `datametric360.de` → Nameserver-Einstellungen.
 2. Von all-inkls eigenen Nameservern auf die beiden von Cloudflare vorgeschlagenen (Schritt 1.4)
    umstellen - das ist ein **"Full setup"**: die komplette DNS-Verwaltung der Domain wandert zu
    Cloudflare, nicht nur ein einzelner Eintrag. Das ist hier folgenlos, weil auf dieser Domain nichts
@@ -69,7 +69,7 @@ veröffentlichen.
 2. Die Weboberfläche des Add-ons öffnen (Standard-Login beim ersten Start: `admin@example.com` /
    `changeme` - **sofort ändern**, siehe Add-on-Dokumentation).
 3. *Hosts → Proxy Hosts → Add Proxy Host*:
-   - **Domain Names:** `datametric360.app`
+   - **Domain Names:** `datametric360.de`
    - **Forward Hostname/IP:** `homeassistant` (interner Name im Supervisor-Docker-Netz;
      alternativ `localhost`/`homeassistant.local.hass.io`, je nach Add-on-Version - im Zweifel im
      Add-on-Log nachsehen, mit welchem Namen sich `homeassistant:8123` von dort aus auflösen lässt)
@@ -89,9 +89,9 @@ veröffentlichen.
 
 1. Zurück im Cloudflare-Dashboard: *Zero Trust → Networks → Tunnels* → den Tunnel aus Schritt 3 öffnen →
    *Public Hostname* → *Add a public hostname*.
-2. **Subdomain:** leer lassen (Apex-Domain `datametric360.app` selbst - kein Subdomain-Präfix, siehe
+2. **Subdomain:** leer lassen (Apex-Domain `datametric360.de` selbst - kein Subdomain-Präfix, siehe
    "Ein einziger Hostname genügt" in `REVERSE_PROXY.md`).
-3. **Domain:** `datametric360.app`
+3. **Domain:** `datametric360.de`
 4. **Service Type:** `HTTPS` (nicht `HTTP` - Nginx Proxy Manager terminiert selbst wieder TLS).
 5. **URL:** die interne Adresse des Nginx-Proxy-Manager-Add-ons, üblicherweise der Add-on-Hostname im
    Supervisor-Netz plus dessen konfigurierten Port (im Add-on selbst unter *Info* nachsehen, welcher
@@ -111,7 +111,7 @@ das muss ins Leere laufen).
 ## 7. Server-Adresse in der App eintragen
 
 Auf jedem Gerät, auf dem die companion-app sideload-installiert ist: beim (erneuten) Einrichten
-`https://datametric360.app` als Server-Adresse eintragen, den bestehenden Zugriffstoken wiederverwenden
+`https://datametric360.de` als Server-Adresse eintragen, den bestehenden Zugriffstoken wiederverwenden
 oder einen neuen erzeugen. Ab hier funktionieren sowohl die normalen Datenabrufe als auch
 Fern-OTA-Updates (`AGENTS.md`, Abschnitt zu `@capgo/capacitor-updater`) über denselben Weg - lokal im
 Heimnetz weiterhin genauso wie zuvor, da HA selbst unverändert nur lokal erreichbar bleibt und die App

homeassistant/REVERSE_PROXY.md

@@ -137,7 +137,7 @@ location / {
 ```
 
 **Ein einziger Hostname genügt.** Die frühere Überlegung, App und Schnittstelle auf zwei getrennte
-Hostnamen zu legen (`datametric360.app` für die App, `api.datametric360.app` für die Schnittstelle),
+Hostnamen zu legen (`datametric360.de` für die App, `api.datametric360.de` für die Schnittstelle),
 stammte aus der Annahme, die App würde selbst als Web-Build unter einer eigenen Adresse ausgeliefert
 (siehe Korrektur-Hinweis oben) - das entfällt mit der nativen Distribution ersatzlos. Es gibt nur noch
 *eine* Adresse, die überhaupt gebraucht wird: die, die die App beim Einrichten als "Server-Adresse"
@@ -150,7 +150,7 @@ Von einem Netz ohne VPN, etwa über Mobilfunk (Hostnamen unten sind Platzhalter
 Einrichtung tatsächlich gewählt wurde):
 
 ```bash
-API=https://datametric360.app
+API=https://datametric360.de
 T=<Zugriffstoken>
 
 # muss gehen
@@ -177,7 +177,7 @@ Zusätzlich: Port 8123 darf von außen **gar nicht** antworten.
 Siehe [`INTERNET_ZUGRIFF_EINRICHTEN.md`](INTERNET_ZUGRIFF_EINRICHTEN.md) für den vollständigen,
 geordneten Ablauf - kurz zusammengefasst bleibt vor der ersten echten Nutzung dieser Liste offen:
 
-- Cloudflare-Konto anlegen, `datametric360.app`-Zone hinzufügen
+- Cloudflare-Konto anlegen, `datametric360.de`-Zone hinzufügen
-- Nameserver von `datametric360.app` bei all-inkl auf Cloudflare umstellen („Full setup")
+- Nameserver von `datametric360.de` bei all-inkl auf Cloudflare umstellen („Full setup")
 - Cloudflared- und Nginx-Proxy-Manager-Add-ons installieren, Tunnel + öffentlichen Hostnamen einrichten
-- `https://datametric360.app` als Server-Adresse in der App eintragen (jedes Gerät, beim Einrichten)
+- `https://datametric360.de` als Server-Adresse in der App eintragen (jedes Gerät, beim Einrichten)