From 41f2a644d365a98c444aaa7db77155d1c181b6fe Mon Sep 17 00:00:00 2001 From: Tobi G Date: Sun, 23 Aug 2026 21:36:30 +0200 Subject: [PATCH] HACS-Entscheidung und die dabei aufgefallene Auslieferungsluecke festgehalten HACS scheidet fuer den aktuellen Aufbau aus, gegen die installierte Version 2.0.5 geprueft statt aus dem Gedaechtnis: HACS kann ausschliesslich GitHub (fest verdrahtet, dieses Repo liegt auf Gitea), und keine der sechs Kategorien installiert nach /config/pyscript/ - die Zielpfade sind custom_components/, www/community/, python_scripts/, themes/, custom_templates/ und appdaemon/apps/. Die App braucht aber pyscript/, audi_dashboard/ und Eintraege in der configuration.yaml. Einziger Weg waere die Konvertierung des pyscript-Backends zu einer echten custom_component - die nebenbei panel_custom, das www-Kopieren, die data-Umbenennung, allow_all_imports/hass_is_global und die pyscript-Abhaengigkeit selbst erledigen wuerde. Umfang gemessen: 2.911 Zeilen, 21 Dienste, 15 State-Trigger, 10 Zeit-Trigger. Der Besitzer hat entschieden, das bis nach der ersten echten Inbetriebnahme zurueckzustellen. Dabei aufgefallen und ebenfalls festgehalten: die Paritaetsregel sichert Quell-Paritaet, nicht Auslieferungs-Paritaet. Das Panel holt sich audi-dashboard-version.json bei jedem Seitenaufruf und ist damit sofort aktuell; die Companion-App ist eine Capacitor-Huelle mit gebuendelten Assets, package.json sagt 0.1.0 und in src/ prueft nichts jemals eine Version. Die iOS-App kann also wochenlang hinterherhinken, ohne dass es irgendwo sichtbar wird. Loesungsskizze im Abschnitt notiert, noch nicht gebaut - die Entscheidung ueber den Auslieferungsweg steht aus. Co-Authored-By: Claude Opus 5 --- AGENTS.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index f5c4fc0..d254634 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1793,6 +1793,52 @@ especially for how long a full year takes (the UI waits up to two minutes before in the background). Address reverse-geocoding is not attempted for imported trips (`start_address`/ `end_address` stay null, same as live-detected ones before the user edits them). +### H) HACS: deferred by decision, and the deployed-parity problem it exposed (2026-08-23) + +**Decision: no HACS conversion for now.** Owner asked whether the app could be installed via HACS. +Checked against the actually installed HACS 2.0.5 rather than from memory — it cannot, for two +independent reasons: + +- **HACS is GitHub-only.** `github.com`/`api.github.com` are hardcoded throughout; no Gitea, GitLab + or self-hosted support. This repo lives on `gitea.nothaft.cloud`. +- **No HACS category installs to `/config/pyscript/`.** The six categories resolve to + `custom_components//`, `www/community//`, `python_scripts/`, `themes/`, + `custom_templates/` and `appdaemon/apps//` (verified in `repositories/*.py` → `localpath`). + The app needs `/config/pyscript/` **and** `/config/audi_dashboard/` **and** `configuration.yaml` + entries — none of which HACS can do. + +The only path is converting the pyscript backend into a real custom integration +(`custom_components/audi_dashboard/`), which would also kill `panel_custom:`, the `www/` copying, +the `data/`→`audi_dashboard/` rename, `allow_all_imports`/`hass_is_global` and the pyscript +dependency itself. Scope measured: 2.911 lines, 21 services, 15 state triggers, 10 time triggers, +39 `task.executor`, 12 `state.set`. Owner chose to defer it until after the app has actually run on +the real HA — sensible: converting first means debugging the rewrite and the real environment at the +same time. **Do not start this without the owner raising it again.** + +**The open question this surfaced — deployed parity of the iOS app.** The parity rule (binding, +above) guarantees *source* parity: both codebases change in the same session. It guarantees nothing +about what is *running*. Today those two are wired completely differently: + +- the panel fetches `/local/audi-dashboard-version.json` with `cache: "no-store"` on every page load + and reloads its assets when the number changed — current within one page load, no user action +- the companion app is a Capacitor shell with `webDir: "dist"` and **bundled** assets, sideloaded + through Xcode. `package.json` says `0.1.0` and **nothing in `src/` ever checks a version.** It + stays on whatever was bundled at signing time, silently, indefinitely + +So the iOS app can be weeks behind the panel with nothing anywhere making that visible. That is a +real gap, not a hypothetical one, and it gets worse once the app is genuinely in daily use. + +Proposed shape (discussed 2026-08-23, **not yet built** — needs the owner's call on the delivery +layer): one shared version stamp fed into both builds instead of today's unrelated +`audi-dashboard-version.json` integer and `0.1.0`; the backend publishing the version it shipped +with, so both frontends can compare their own build stamp against it and show a visible hint when +behind (drift becomes loud instead of silent); and for delivery, OTA web-bundle updates so the iOS +shell can follow without an Xcode rebuild. Pointing Capacitor's `server.url` at HA was considered +and rejected: it would make the app as current as the panel, but the shell then cannot boot without +reaching HA, which guts the deliberately built offline queue (`api/warteschlange.ts`). Note the +whole mechanism survives the later integration conversion unchanged — that end state serves panel +assets and companion bundle from the same component, so one HACS update moves both. + ### G) Fresh-install audit + installer hardening (2026-08-23, before the first real deployment) Owner is about to install on the real HA OS instance and asked for two things: that the one-click