diff --git a/AGENTS.md b/AGENTS.md index 4d2f77a..bb0ca76 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -202,17 +202,36 @@ capacitor/iframe/browser (`umgebung.ts`), types + entity table (`types.ts`), fac validity; Mosquitto configured (`certfile`/`keyfile`/`cafile`/`require_certificate: true`). 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 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 is now working too (root cause of the earlier DNS-01 failures - was a stray `aliases` entry in the DuckDNS add-on config, not DNS/network — see - COMPANION_APP_ARCHITECTURE.md §5 item 2a for the full writeup). HA's SSL config now lives in +- [ ] Decide broker reachability for the vehicle — **reopened 2026-08-11 evening**: port-forward + 8883 on the Speedport Smart 4 Plus looked correctly configured (rule present, right internal + IP, right port) and internal reachability was confirmed (`homeassistant.local:8883` open from + the LAN, Mosquitto TLS listener genuinely up, TLS cert chain end-to-end verified byte-for-byte + against the FMM003's uploaded client cert), but the port stayed **closed from outside** + (confirmed via external port checker, both before and after a router reboot that changed the + dynamic WAN IP — DNS/DuckDNS matched correctly each time, so not a DNS or CGNAT issue). + Community reports (ComputerBase, Telekom Hilft) describe this as a known, Telekom-acknowledged + firmware bug on this router model; a full disable-the-firewall workaround doesn't exist on this + model either. Port-forward rule has been removed again. **New direction: route the FMM003 + through flespi instead** (native Teltonika/Codec8 channel, IMEI-based auth, no certs, no + inbound port needed at all — flespi has a stable public endpoint; HA pulls data back out via + flespi's REST API or MQTT, outbound-only). Free flespi tier (10 devices/2 channels) is enough + for one vehicle. Next step: user creates the flespi account + Teltonika channel; a `flespi` + custom integration is already present in this HA instance (unconfigured) — check what it + needs once flespi-side setup exists. + Unrelated but still valid from the same session: DuckDNS hostname + `datametric360.duckdns.org` reliably updating; Let's Encrypt for HA's own local UI works (root + cause of the earlier DNS-01 failures was a stray `aliases` entry in the DuckDNS add-on config, + not DNS/network — see COMPANION_APP_ARCHITECTURE.md §5 item 2a). HA's SSL config now lives in Settings → System → Network (UI), not `configuration.yaml`'s old `http:` block, which was - removed after HA started migrating/ignoring it. -- [ ] 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 + removed after HA started migrating/ignoring it. The Mosquitto TLS setup itself (cert chain, + `require_certificate: true`, `certfile`/`keyfile`/`cafile`) is verified correct and can be + reused as-is if a self-hosted broker is ever revisited. +- [ ] MQTT Client Type on the FMM003 ("Custom server" not selectable in practice, "AWS IoT Custom" + pointed at a self-hosted broker was confirmed working by two independent community reports) — + **moot for now** given the flespi pivot above: flespi uses the device's native Codec8/TCP + channel, not MQTT at all, so Server Settings should switch to Protocol: TCP against the flespi + channel host/port instead, and Codec set to "Codec 8 Extended". Revisit this item only if a + self-hosted broker is picked back up later. - [ ] Capture the first real Codec JSON message (`mosquitto_sub`/MQTT Explorer) and build the field mapping from it — **do not guess beforehand** (explicit decision) - [ ] Move trip detection to FMM003 ignition (reuse the `fahrterkennung.py` pattern, keep pause @@ -220,6 +239,20 @@ capacitor/iframe/browser (`umgebung.ts`), types + entity table (`types.ts`), fac ### C) Maintain the existing HA panel (low priority — being replaced) +- [x] Wide-screen/desktop layout (`@container (min-width:860px)` in `audi-dashboard-ios.css`, + turns the same `.tabbar` into a 264px side-nav via CSS only, no JS/markup duplication) — done + 2026-08-11 from the Claude Design "DataMetric360 Board" draft (`claude.ai/design` project + `c28a8d4d-ec4e-4178-9e49-ab5b90c02097`). Found and fixed a real regression while verifying it + live in `audi_ha_test`: the overlay's `:host > div{height:100%}` (meant to drop the old + 412px-cap for the sidebar layout) was applied unconditionally instead of only inside the + `@container` block, which broke the **normal mobile layout too** — HA doesn't reliably + propagate a real height down through `panel_custom`, so `height:100%` collapsed `main#view` to + ~0px (tabbar rendered right under the header, content invisible). Fix: kept the outer wrapper + viewport-anchored (`min(880px, calc(100dvh - 24px))`, matching `audi-dashboard.css`'s original + reasoning) at all widths, and only drop the 880px cap (`calc(100dvh - 24px)`, still + viewport-anchored, not parent-relative) inside `@container (min-width:860px)`. Verified live at + both narrow (mobile tab bar, full content) and wide (1144px container, grid side-nav, + navigation clicks, settings back-arrow) — screenshots taken, no regressions found. - [ ] Fix documentation drift (statistics claim, INSTALL variable names, README gaps, obsolete TODO comment) — text-only changes - [ ] Harden `profil_lesen()` against missing/corrupt `fahrzeugprofil.json` diff --git a/homeassistant/www/audi-dashboard-ios.css b/homeassistant/www/audi-dashboard-ios.css index 50fdb45..a80cb80 100644 --- a/homeassistant/www/audi-dashboard-ios.css +++ b/homeassistant/www/audi-dashboard-ios.css @@ -47,8 +47,15 @@ html,body{height:100%} gedacht) wird hier unbedingt aufgehoben, nicht nur ab 860px: auf schmalen Bildschirmen macht der Viewport selbst die Breite eng genug, :host-Selektoren innerhalb @container werden von diesem Browser aber - offenbar verworfen - deshalb unbedingt statt bedingt. */ -:host > div{height:100%;max-width:none} + offenbar verworfen - deshalb unbedingt statt bedingt. + Die Hoehe bleibt dagegen viewport-verankert (100dvh statt 100%): das ist + der Grund, warum audi-dashboard.css das ueberhaupt so baute - HA gibt der + panel_custom-Kette keine verlaessliche Hoehe weiter, height:100% liess den + Hauptinhalt hier auf 0px kollabieren (Tabbar direkt unter dem Header, + main#view unsichtbar). Erst ab 860px (siehe @container unten) darf die + 880px-Deckelung fallen, damit die App auf grossen Bildschirmen mehr als + eine schwebende Telefonkarte ist. */ +:host > div{height:min(880px, calc(100dvh - 24px));max-width:none} .phone{width:100%;max-width:none;height:100%;border-radius:0; font-family:"Audi Type",Helvetica,Arial,sans-serif; -webkit-font-smoothing:antialiased;letter-spacing:0} @@ -174,6 +181,9 @@ main{padding:0 16px 30px;scroll-behavior:smooth} eigenen Rahmen sitzt und nicht die Fensterbreite messen darf. Schwelle 860 px. ================================================================== */ @container (min-width:860px){ + /* Ab hier keine schwebende Telefonkarte mehr - die 880px-Deckelung faellt, + die App fuellt die tatsaechliche (weiterhin viewport-verankerte) Hoehe. */ + :host > div{height:calc(100dvh - 24px)} .phone{display:grid;grid-template-columns:264px minmax(0,1fr); grid-template-rows:auto auto minmax(0,1fr)} .topbar{grid-column:2;grid-row:1;padding:38px 44px 8px} diff --git a/homeassistant/www/audi-dashboard-version.json b/homeassistant/www/audi-dashboard-version.json index 9c94edd..9f03e94 100644 --- a/homeassistant/www/audi-dashboard-version.json +++ b/homeassistant/www/audi-dashboard-version.json @@ -1 +1 @@ -{"version": 1786377887} +{"version": 1786473562}