Selbst-Update: Ergebnis erscheint ohne Neuladen, Panel übersteht Neustart
Zwei Meldungen des Besitzers ("Update installieren" braucht manuelles
Neuladen, um den Neustart-Knopf zu zeigen; die "HA startet neu..."-
Anzeige ebenso) auf denselben Grund zurückgeführt: datenLaden() rief
render() nur bei Änderungen an profil/fahrten/tank/status/batt auf,
nie bei einer reinen Änderung des Versions-Sensors. Dazu ein bereits
im Code kommentiertes, bisher nur per Tab-Klick umgangenes Rennen
beim echten HA-Neustart gefunden und behoben: panel_custom baut das
Element neu auf, aber nichts zeichnete es automatisch, bis der Nutzer
irgendwo klickte. companion-app erhielt den passenden Fix für die
Neustart-Anzeige (Panel-Bug 1 betraf sie nicht, siehe AGENTS.md).
Alle drei Fixes live im Testcontainer über einen echten
homeassistant.restart bestätigt, nicht nur simuliert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
@@ -2710,6 +2710,97 @@ reported by the owner as a problem — worth a look if it ever is.)
|
||||
|
||||
Manifest bumped to `2026.8.24.12` for this fix.
|
||||
|
||||
**A fourth same-day fix (2026.8.24.13): the two "needs a manual page refresh" reports the owner filed
|
||||
right after — turned out to be the exact gap flagged (but not investigated) at the end of the previous
|
||||
paragraph.** Two distinct reports, one shared root cause on the panel side:
|
||||
|
||||
1. **"Update installieren" needs a manual page refresh to see the restart button.** Traced to
|
||||
`datenLaden()`: it unconditionally reads `sensor.audi_dashboard_app_version`'s `daten.integration_update`
|
||||
into the module-level `INTEGRATION_UPDATE` variable on every tick, but only calls `render()` inside the
|
||||
`geaendert` block — which only compares `profilState`/`fahrtenState`/`tankState`/`statusState`/`battState`
|
||||
identity, never `versionState`. A version-only state change (exactly what `update_pruefen`/
|
||||
`update_installieren` produce) updated the in-memory value but never triggered a re-render on its own —
|
||||
the UI only caught up whenever some unrelated entity happened to change next, which in practice meant
|
||||
"never, until a manual reload re-initializes everything from scratch." Fixed by tracking `letzterVersionState`
|
||||
the same way the other five states are tracked, and calling `render()` directly whenever `versionState`'s
|
||||
identity changes and nothing else already triggered one (a small `if (versionGeaendert && DATEN_GELADEN) {
|
||||
render(); return; }` right after the existing `geaendert` block, left untouched).
|
||||
2. **The "Home Assistant startet neu …" spinner also needs a manual page refresh after the restart
|
||||
actually completes.** Root cause was different: `INTEGRATION_UPDATE_LAEUFT` is set to `"neustart"`
|
||||
right before calling the `homeassistant.restart` service, and the *only* place that ever cleared it
|
||||
back to `null` was the `.catch()` error handler on that same call — deliberate, per section L's original
|
||||
comment, since a successful restart normally disconnects the page before the success path could run
|
||||
anyway. But nothing ever picked it back up on the other side: once the websocket reconnects after HA
|
||||
comes back, `set hass()` fires again (`HASS` was never nulled out while disconnected, so this isn't the
|
||||
`erster`/first-connect path), but no code ever reset the stuck `"neustart"` flag, so the spinner stayed
|
||||
forever. Fixed by listening once for the underlying `home-assistant-js-websocket` connection's own
|
||||
`"ready"` event (fires on every successful (re)connect, confirmed live via
|
||||
`HASS.connection.addEventListener`) — wired in `set hass()`, guarded by a new module-level
|
||||
`VERBINDUNG_UEBERWACHT` flag so it's only attached once rather than once per `hass` push — and clearing
|
||||
`INTEGRATION_UPDATE_LAEUFT`/re-rendering there if it was still `"neustart"`.
|
||||
|
||||
**Checked companion-app for the same two bugs (parity rule) rather than assuming React's own re-render
|
||||
model made it immune:** bug 1 does *not* reproduce there — `updatePruefenAusloesen()`/
|
||||
`updateInstallierenAusloesen()` in `Einstellungen.tsx` already `await neuLaden()` right after the service
|
||||
call resolves, which re-fetches `appVersionAngabeLesen()` directly over REST and updates React state
|
||||
synchronously, no push-event dependency. Bug 2, however, **does** reproduce identically: `updateNeustartLaeuft`
|
||||
is local `useState` in `Einstellungen.tsx`, deliberately left out of the `try/finally` (same reasoning as
|
||||
the panel), and nothing else ever reset it — `DatenKontext.tsx`'s own reconnect handling
|
||||
(`api.live.aufVerbindung()` → `neuLaden()` on `"verbunden"`) only refreshes the *shared* `integrationUpdate`
|
||||
context value, which this screen-local boolean doesn't derive from. Fixed with a small `useEffect` in
|
||||
`Einstellungen.tsx` watching the already-available `verbindung` context field, clearing
|
||||
`updateNeustartLaeuft` when it flips to `"verbunden"` while still `true`.
|
||||
|
||||
**Verified (panel, first pass):** `node --check` clean. Live in the test container at `2026.8.24.13`:
|
||||
clicked "Update installieren" (Gitea test remote genuinely offered `.12`, since that's what had last been
|
||||
pushed there) — the tile transitioned on its own from "Installiere …" straight to "Version 2026.8.24.12
|
||||
installiert … Jetzt neu starten" with **no page reload**, confirming bug 1 fixed. Clicked "Jetzt neu
|
||||
starten" and waited for the container to fully restart — this is where a third, previously-undiscovered
|
||||
bug surfaced (below), which blocked a clean confirmation of bug 2 until it was also fixed.
|
||||
|
||||
**A third bug found while verifying bug 2 for real (2026.8.24.14), not a new report — an already-known,
|
||||
already-commented race in the code that a genuine backend restart finally exercised end to end.** After
|
||||
the real `homeassistant.restart` completed, the browser tab reconnected but the panel stayed stuck on the
|
||||
static "Lädt …" placeholder indefinitely — not the Einstellungen page with a lingering spinner (bug 2's
|
||||
literal symptom), but back on Übersicht, showing nothing. Traced to: Home Assistant's `panel_custom`
|
||||
mechanism recreates the `<audi-dashboard-panel>` custom element from scratch after a real backend restart
|
||||
(confirmed live — a fresh `_aufbauen()` run, fresh skeleton DOM), but the JS *module* itself is not
|
||||
reloaded, so all its module-level state (`CONFIG`/`CAR`/`DATEN_GELADEN`/etc.) survives untouched from
|
||||
before the restart. The fresh element's first `datenLaden()` call didn't reliably produce a `render()`
|
||||
(the exact scenario `go()`'s own existing comment already describes: *"Bekanntes Race … auf einem langsam
|
||||
startenden Backend kann die App auf 'Lädt …' hängen bleiben … der bislang einzige beobachtete Ausweg war
|
||||
ein Tabwechsel"*), and — unlike `go()`, which unconditionally calls `render()` on every tab click regardless
|
||||
of this race — nothing about `_aufbauen()` itself ever painted anything beyond the static skeleton.
|
||||
Confirmed live: clicking any tab immediately showed full correct data (proving `CONFIG`/`CAR` were fine in
|
||||
memory all along — only the *paint* was missing), exactly matching `go()`'s own workaround comment.
|
||||
Fixed the same way `go()` already does it, just made unconditional instead of click-triggered: `_aufbauen()`
|
||||
now calls `render()` immediately after building a fresh skeleton, if `DATEN_GELADEN` is already `true` (i.e.
|
||||
this is a rebuild after already having loaded once, not the very first paint — that case is correctly left
|
||||
to `datenLaden()`'s own arrival). This is the real, complete fix for "the app doesn't recover cleanly after
|
||||
HA restarts without user interaction" — bug 2's spinner-not-clearing report was one visible symptom of it;
|
||||
this fix (plus the earlier `"ready"`-listener reset of `INTEGRATION_UPDATE_LAEUFT`) is what makes the whole
|
||||
class of "just restarted, tab open, nobody touches it" scenario self-heal.
|
||||
|
||||
**Verified (panel, final pass) at `2026.8.24.14`:** `node --check` clean. Triggered a real
|
||||
`homeassistant.restart` directly (`HASS.callService("homeassistant", "restart", {})` from the open tab, no
|
||||
button click, to isolate this from the update-install flow specifically), confirmed via `docker logs` that
|
||||
the integration set up a second time end to end (`s6-rc` stop/start sequence, "Audi Dashboard 2026.8.24.14
|
||||
eingerichtet" logged twice). The browser tab — never manually reloaded, never clicked — automatically showed
|
||||
full real content (vehicle name, range, "Nächster Service", …) the moment it reconnected. No stuck "Lädt …",
|
||||
no manual refresh, no tab click needed. This also confirms bug 2 properly this time (the spinner-clearing
|
||||
`"ready"` listener from the first pass runs as part of the same reconnect path this test exercises).
|
||||
- companion-app: `tsc --noEmit` clean, full suite still green at 145/145 (no behavior change needed
|
||||
testing beyond the existing suite for its own bug-2 fix — a reconnect-driven reset of already-tested
|
||||
local state, not new business logic; the deeper element-recreation race is panel-specific, since
|
||||
companion-app is a normal React SPA that doesn't get its component tree torn down and rebuilt by an
|
||||
external host on backend restart).
|
||||
|
||||
Manifest bumped to `2026.8.24.13`, then `2026.8.24.14` once the deeper race above was found and fixed in
|
||||
the same live-testing session. `npm run ota` not rerun yet for this round — only the `useEffect` addition
|
||||
in `Einstellungen.tsx` touches companion-app source (the panel-side fixes don't affect the OTA bundle,
|
||||
which ships companion-app only), no OTA bundle rebuild triggered until the owner asks or the next round
|
||||
bundles it together with something else.
|
||||
|
||||
---
|
||||
|
||||
## Working conventions (observed — keep them)
|
||||
|
||||
Reference in New Issue
Block a user