0.9: ha-paneld can now render the dashboard itself — the background, and where this is going

[maxlyth]

ha-paneld 0.9 changes something I've been deliberate about since the first release, so it deserves a proper explanation rather than a changelog line: ha-paneld can now render the Home Assistant dashboard itself, in its own built-in WebView, instead of always deferring to a separate dashboard app. This post covers why the project's stance moved, what the built-in renderer does today, and what the position is going forward.

Where ha-paneld started

ha-paneld began as a strictly headless agent. The philosophy was: wall panels have a hardware gap — screen, LEDs, buttons, sensors, relays, audio, provisioning — and that gap is what ha-paneld exists to close. Dashboard rendering already had a good answer in the official HA Companion app, so ha-paneld ran as a background service, never took the foreground, and treated the Companion as the permanent dashboard host. The README said exactly that.

That stance was honest, and it mostly worked. But running a real multi-panel fleet with it for months surfaced a pattern: almost every hard operational problem I hit lived in the seam between the two apps, not in either app.

• A factory reset (or a vendor firmware update that wipes /data) removes both apps. ha-paneld reinstalls and reprovisions in seconds — but signing the Companion back in means an OAuth flow typed on a wall panel, rendered by whatever WebView the panel shipped with. On one of my panels that WebView was too old to render the login page at all: a chicken-and-egg dead end that took real effort to dig out of.
• Keeping the Companion updated on no-Play-Store panels is its own job — one update crash-looped on the oldest SoC in my fleet and needed a version pin plus a watchdog to contain.
• The watchdog and kiosk features can only treat another app as a black box: restart it, foreground it, and hope. There's no way to know whether the dashboard inside it is actually connected and rendering, no way to bound its memory over weeks-long uptimes, and no way to recover its page-level failures.

What people actually want from a "kiosk app"

Requests kept arriving for kiosk-app integrations (see #20 and the launchers discussion in #13). Looking hard at those apps, what panel users actually need from them reduces to three things: auto-launch at boot, kiosk lock (don't let casual taps leave the dashboard), and render the dashboard. ha-paneld already did the first two natively — boot-to-dashboard, HOME-role management, a foreground-return watchdog, kiosk lock. The only missing piece was the renderer, and a WebView pointed at the HA frontend is a much smaller, simpler thing than integrating and supporting a third-party kiosk product per panel.

So rather than build configuration surfaces for other people's kiosk browsers, 0.9 builds the renderer in.

What the built-in renderer is

A WebView inside ha-paneld, pointed at your dashboard, that authenticates using the same external_auth contract the Companion app itself uses — no localStorage token tricks, the documented frontend interface. Around it, the things a wall panel actually needs:

• Zero-typing sign-in. On a panel already running a signed-in Companion app (root), switching the picker to Built-in borrows the Companion's sign-in automatically — no URL, no token, nothing typed; the Companion keeps its own login, so switching back is the same picker change. For fresh or wiped panels, provision.sh --builtin --ha-url … --ha-user … signs the panel in from your admin machine; the password never reaches the panel, which holds a revocable refresh token.
• Engineered for weeks-long uptimes. The page freezes while the screen is off (about 70% of renderer CPU saved overnight); a handshake watchdog reloads a dashboard that loaded but never actually connected, with backing-off retries behind a clean "Reconnecting…" screen instead of a grey browser error; memory is bounded by invisible reloads at screen-off; renderer crashes are contained and rate-limited, falling back to the admin launcher rather than flashing all night; a genuinely revoked login stops retrying and shows fix-it instructions on the panel and in the web UI.
• First-class integration. The watchdog and kiosk lock treat it as the dashboard (no more black box), pull-to-refresh does an instant in-app re-navigate, idle return-to-home and an edge-to-edge fullscreen mode are built in, camera streams autoplay, private-CA HTTPS works, and the panel's dark/light preference drives the dashboard's default theme.

One APK, one thing to update, one thing to provision — and every layer of it observable and fixable from the agent itself.

What it is not

Honesty matters more than the pitch, so, clearly stated: the built-in renderer has no Voice Assistant (Assist) and no notifications. Those are genuinely good reasons to keep the Companion app on a panel, and ha-paneld does not try to reimplement them today. Fullscreen media niceties (file chooser, casting-style playback) are permanently out of scope — for all of that, the answer remains the Companion app.

The position going forward

• The Companion app remains today's default and a permanently supported path. Nothing changes for existing setups; ha-paneld will keep detecting, launching, watching, and updating it exactly as before. This is an addition of choice, not a replacement.
• The built-in renderer is experimental ("skunk-works" in the UI, off by default). It has been running on my entire fleet — different SoCs, Android 8.1 through 14 — for continuous soak, and the 0.9 release-candidate line was almost entirely the result of that soak: real lifecycle bugs found and fixed rather than papered over.
• Where it lands long-term depends on how it holds up in setups that aren't mine. If you try it, feedback here — good or bad, especially boring reliability reports after a week of uptime — is the most useful thing you can contribute.

Trying it

On 0.9.0 or later, on a panel already running a signed-in Companion app: Configure → Dashboard → Dashboard app → "Built-in renderer" — that's the whole procedure; the renderer borrows the Companion's sign-in automatically (root panels). Otherwise set the HA URL and a token, or reprovision with provision.sh --builtin --ha-url … --ha-user …. Reverting is the same picker. The changelog carries the full detail per release.