DuckDNS: Let's Encrypt bewusst fallen gelassen, Portfreigabe erledigt

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.

AGENTS.md

@@ -203,8 +203,13 @@ capacitor/iframe/browser (`umgebung.ts`), types + entity table (`types.ts`), fac
       Remaining: upload root/client cert/key to the FMM003 Security tab — filenames must end in
       `.pem`/`.pem.crt`/`.pem.key` (Configurator rejects plain `.crt`/`.key`, content-agnostic check)
 - [x] Decide broker reachability for the vehicle — port-forward 8883 (not VPS bridge), decided
-      2026-08-11; DuckDNS hostname `datametric360.duckdns.org` set up, Dual-Stack confirmed on the
-      router (no DS-Lite blocker). Remaining: the port-forward itself on the Speedport Smart 4 Plus
+      2026-08-11; DuckDNS hostname `datametric360.duckdns.org` set up and reliably updating,
+      port-forward 8883 done on the Speedport Smart 4 Plus, FMM003 confirmed sending data. Let's
+      Encrypt for HA's own local UI deliberately dropped (`deploy_challenge` DNS-01 hook failed
+      reproducibly inside the DuckDNS add-on container specifically — root cause not found despite
+      thorough diagnosis; not worth pursuing since HA is Tailscale-only anyway, see
+      COMPANION_APP_ARCHITECTURE.md §5 item 2a for the full writeup). `configuration.yaml`'s
+      `http: ssl_certificate/ssl_key` block stays commented out permanently.
 - [ ] MQTT Client Type on the FMM003: "Custom server" (value 3, seen in Configurator help text) was
       not selectable in practice — use **"AWS IoT Custom"** pointed at the own broker instead
       (confirmed working by two independent community reports); verify once the device is live

COMPANION_APP_ARCHITECTURE.md

@@ -347,10 +347,26 @@ else in this document:
    App (§4, dort bleibt es bei Cloudflare Tunnel — kein Widerspruch, siehe dort die Begründung, warum
    ein eng begrenzter, zertifikatsgesicherter Port etwas anderes ist als HA selbst offenzulegen).
    **Umsetzungsstand (2026-08-11):** DuckDNS-Hostname `datametric360.duckdns.org` angelegt und als
-   Add-on in HA eingerichtet (inkl. eigenständigem Let's-Encrypt-Zertifikat für die HA-Oberfläche
-   selbst — unabhängig von den MQTT-Zertifikaten unten, siehe dortige Anmerkung). Router bestätigt
-   **Dual-Stack** (kein DS-Lite) — die Portfreigabe funktioniert damit grundsätzlich. **Noch offen:**
-   die Portfreigabe selbst am Speedport Smart 4 Plus.
+   Add-on in HA eingerichtet, aktualisiert zuverlässig die öffentliche IP — das ist der für den
+   FMM003-Pfad tatsächlich entscheidende Teil. Router bestätigt **Dual-Stack** (kein DS-Lite), die
+   Portfreigabe 8883 am Speedport Smart 4 Plus ist eingerichtet, FMM003 sendet bestätigt Daten.
+
+   **Let's-Encrypt-Zertifikat für die HA-Oberfläche selbst — bewusst NICHT umgesetzt:** Der
+   `deploy_challenge`-Hook (DNS-01, TXT-Eintrag via DuckDNS-API) scheiterte reproduzierbar mit
+   `timeout 120s` beim Warten auf den eigenen TXT-Eintrag. Diagnose ausführlich durchgeführt: der
+   TXT-Eintrag wird von DuckDNS korrekt gesetzt (manuell per `txt=`-Parameter bestätigt, `OK`/
+   `UPDATED`) und ist öffentlich sofort sichtbar (bestätigt per `nslookup` gegen `8.8.8.8` vom PC
+   *und* per `dig` aus der HA-eigenen SSH-Konsole gegen den internen Supervisor-Resolver
+   `127.0.0.11`/`172.30.32.3` — beide sahen den aktuellen Challenge-Wert sofort). Trotzdem scheiterte
+   ausgerechnet der interne `dig`-Aufruf *im DuckDNS-Add-on-Container selbst* wiederholt (auch nach
+   Wechsel des HA-DNS-Servers auf `1.1.1.1` und komplettem Host-Neustart, `host_network: false`
+   bestätigt — Ursache innerhalb des Add-on-Containers blieb ungeklärt). **Entscheidung:** Let's
+   Encrypt im DuckDNS-Add-on deaktiviert statt weiter zu debuggen — verhältnismäßig, weil HA laut
+   Sicherheitsprinzip oben sowieso nie öffentlich exponiert wird und nur über Tailscale erreichbar
+   ist (das verschlüsselt den Transport bereits); ein eigenes Zertifikat für die lokale UI ist damit
+   ein Nice-to-have, kein Sicherheitserfordernis. Der `http: ssl_certificate`/`ssl_key`-Block in
+   `configuration.yaml` bleibt deshalb dauerhaft auskommentiert (er hatte HA sonst am Start
+   gehindert, solange die referenzierten Dateien nie erzeugt wurden).
 
    Nebenbei geklärt: ein Vorschlag, stattdessen komplett auf Cloudflare zu setzen, wurde geprüft und
    **ist keine Alternative** — Cloudflare Tunnel kann kein rohes MQTT/TCP transportieren (nur HTTP),