Live browser preview of interpreted scenes (WASM)

[mariusandra]

Run interpreted scenes directly in the browser: FrameOS now ships a WebAssembly build of the scene runtime, and every scene, template, and scene-editor toolbar gets an In-browser preview that renders the scene client-side — rendering, code nodes (QuickJS), timers, and interactive events included. Around that headline feature, this PR also standardizes the scene action buttons, adds one-click scene updates from repositories, and lets FrameOS share frames with Home Assistant.

In-browser preview

• livePreviewLogic spawns a module Web Worker (preview-worker.js) that drives the wasm module and paints frames to a canvas. The modal shows the scene's event nodes as clickable buttons, the frame's GPIO buttons, terminal-styled parsed logs (render:scene / render:done, like the device runner), and an editable live scene-state panel.
• The same modal works for templates: the template preview button opens the browser preview directly (scenes are passed explicitly since they aren't installed), with Add to frame and Preview on frame buttons next to it. Form field values are sent as the scene's initial state.
• Open state persists in the URL hash across reloads. Scenes that use apps missing from the wasm build (or localImage) get a warning; compiled-only templates are tagged, since only interpreted scenes can run in the preview.

Runtime (Nim → WASM)

• New entry point frameos/src/wasm/wasm_main.nim (gated on -d:frameosWasm), modeled on the ESP32 embedded runtime. Small C ABI: init, load_scenes, select_scene, render, event, scene_state/scene_info, next_sleep.
• Reuses the existing frameosEmbedded seams: every host-only feature already excluded on embedded (networking, child processes, threads, filesystem, ImageMagick/exiftool) is also excluded on wasm. The apps_nim.py generator gains the same gate, so process-spawning apps (chromium screenshot, RTSP snapshot) are compiled out.
• Gotcha: the module must end with emscripten_exit_with_live_runtime() — ARC/ORC otherwise emits destructors for all module-level globals when main() returns, freeing the scene/asset tables and aborting the first exported call.

Build & shipping

• frameos/tools/build_wasm.sh compiles QuickJS + the runtime with emscripten into frontend/public/frameos-wasm/ (bundle is gitignored). -sGROWABLE_ARRAYBUFFERS=0 keeps memory non-resizable so Chrome's TextDecoder accepts heap views.
• Dev: a wasm pane in mprocs.yaml builds it. Prod: the Dockerfile installs emsdk and builds it before the frontend bundle (which copies public/ into dist/).

Secrets & external HTTP

• frameos_wasm_init takes a settingsJson param so apps read real API keys from frameConfig.settings. The frontend fetches them from a new project-authed GET /frames/{id}/scene_preview_settings (returns get_frame_json(...)["settings"] — the same per-app secret set the device receives).
• Data apps that fetch external URLs are routed through a same-origin, project-authed, SSRF-guarded POST /frames/{id}/scene_preview_proxy (honoring the app's request timeout), so they work despite browser CORS — the backend fetches server-side and mirrors the upstream status/body, exactly like the device.

Scene management UX

• Scene actions (activate / preview on frame / preview in browser) are standardized into one split-button with a dropdown; picking an option arms the button globally, clicking runs it.
• Adding scenes to a frame no longer saves the frame automatically.
• Homepage scene list gains multiselect + bulk delete; split scenes get precise box sizes with split/swap/remove panel controls.
• Events panel: custom events can be dragged onto the scene as listen/dispatch nodes. Scene toolbar icons clarified; chat panel keeps only Clear.

Scene updates from repositories

• Installed scenes track their repo origin (repository/template/sceneId + a version that's an explicit template.json version or a content hash of the scenes), so scene dropdowns and tiles offer a one-click Update scene that replaces the scene's content in place — multi-scene templates update as a group with ids preserved so links keep working.
• The update UI lives in a lightweight sceneUpdatesLogic, deliberately separate from scenesLogic/controlLogic so the frames home doesn't fetch per-frame state just to render dropdowns.

Home Assistant

• New sync service (backend/app/ha) publishes every non-archived frame as an MQTT-discovered HA device — image entity with the latest render, status/scene/last-seen sensors, plus a hub sensor — and forwards frame events to the HA event bus as frameos_event. Runs as a singleton arq worker task, reacting to existing broadcast events; add-on installs auto-discover the Supervisor connection and Mosquitto broker, standalone installs configure URL/token/MQTT in Settings → Home Assistant ("Share frames with Home Assistant" toggle + "Save & sync now"). get_frame_json strips the sync internals from settings deployed to frames.
• Release workflow: release notes are generated once and prepended to the add-on repo's CHANGELOG.md (HA's changelog tab was empty because that file never existed); the GitHub release reuses the same artifact.

Verification

• Native FrameOS and ESP32 embedded builds still compile clean (shared gates unchanged).
• Headless Chromium end-to-end: renders the Counter sample (button events drive state 1 → 111), renders a 1920×1080 frame (exercises memory growth + the TextDecoder fix), and renders a downloadImage → render/image scene through the proxy (real photo, not an error frame).
• Secret plumbing proven via data/openaiText (missing-key error only when the key is absent). SSRF guard unit-checked (loopback/private blocked, public allowed). HA discovery/sync covered by backend tests.
• Frontend kea-typegen + tsc + production esbuild pass; the full frontend e2e + visual suite is green (including the frames-home "no /states requests" guard and the add-scene drawer, whose repository-template thumbnails now load).

Note: device-only apps (chromium screenshot, camera snapshot) remain unavailable in the preview by design.

🤖 Generated with Claude Code