From 7c57cec92acdafe0593f58052e5c842539240052 Mon Sep 17 00:00:00 2001 From: Tobi G Date: Tue, 11 Aug 2026 16:04:48 +0200 Subject: [PATCH] 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 | 9 +++++++-- COMPANION_APP_ARCHITECTURE.md | 24 ++++++++++++++++++++---- 2 files changed, 27 insertions(+), 6 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 4d003c1..ddb50e0 100644 --- a/AGENTS.md +++ b/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 diff --git a/COMPANION_APP_ARCHITECTURE.md b/COMPANION_APP_ARCHITECTURE.md index e30dd70..bf5b893 100644 --- a/COMPANION_APP_ARCHITECTURE.md +++ b/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),