D31/D32: ids, topics, retain and availability for the HA MQTT interface, MVP entity list. D33: MVP notification via the notify entity. D34: configuration file format. D35: shipping libmosquitto. D36: NFR-3 measurement. D37: MVP implemented in four iterations, DSH-1 first. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
5.4 KiB
Progress
Where the project stands, and what happened in each session. Newest first. The process is in CLAUDE.md ("Working rules").
Current state
- Iteration 1, phase 2 (planning and design). Phase 1 is approved (D13); REQUIREMENTS.md is the baseline. High-level architecture done (DESIGN.md); MVP details next.
Next steps
Requirements and design cover the whole MVP; it is implemented in four small iterations (D37), each with implementation, testing and assessment:
| Iteration | Content | Platform change | Checked by |
|---|---|---|---|
| 1 | DSH-1: HA web UI (Qt WebEngine) in a dashboard tab; configuration (D34) with start-up hook and --config |
start-up hook (D21), WebEngine initialisation before the QGuiApplication |
HA web UI in the tab on the Frame; result documented |
| 2 | MQTT client (own thread), HA device with discovery and availability, libmosquitto in the package, status display UI-1 | modes (D22) | device appears in HA, online/offline right, reconnect works |
| 3 | OpenVR wrappers and the 13 sensor entities | --desktop with optional SteamVR (D22) |
sensor values in HA on the Frame |
| 4 | notification manager, notify entity, world overlay |
world overlay, premultiplied flag (D25) | notification from HA in VR, also in a game |
Next: the detailed plan for iteration 1 (files, classes, tests, order) for the user's approval; that ends phase 2 for iteration 1.
Log
2026-10-05: requirements approved
- User approved REQUIREMENTS.md including the priorities (D13). Phase 2 started.
- Q4 decided: libmosquitto, shipped in the package (D14). Qt MQTT ruled out: private Qt API requires the exact Qt version. Checked on the Frame: no MQTT library installed; libssl/ libcrypto 3 and libcjson 1 present.
- HA discovery: own small layer on QJson, device-based discovery (D15); hacpp and the embedded libraries rejected.
- Checked on the Frame which Qt modules, plugins and audio/network tools exist; library list per requirement in REQUIREMENTS.md Appendix C. Notable: Qt WebEngine and Qt WebSockets are present (relevant for Q2/Q3).
- libmosquitto ABI check: Debian's 2.0.21 needs at most
OPENSSL_3.0.0/GLIBC_2.34; the Frame has OpenSSL 3.2.1 and glibc 2.39. No libcjson dependency. D14 holds. - MVP implemented in four iterations; DSH-1 first, at the user's wish (D37).
- NFR-3 measurement method, manual in the MVP (D36). MVP details done.
- Shipping libmosquitto (D35).
- Configuration file format (D34).
- MVP notification:
notifyentity with first line as title; JSON command later (D33). - HA MQTT interface: ids (D31), topics, retain, availability (D32), MVP entity list.
- Test strategy in four levels (D30). High-level architecture done.
- Threads: MQTT client in its own thread, everything else incl. OpenVR in the main thread (D29).
- DSH-1 split: web UI out-of-the-box test in the MVP, full dashboard as DSH-2 (D28).
- Overlays: two kinds (D25), one overlay for all notifications (D26), MVP placement "spawn in front, then stay" (D27). Researched notification UI in VR (DESIGN.md, Appendix A). Found: premultiplied-alpha flag missing in the platform.
- HA channels: MQTT for everything device-related; dashboard channel decided with Q2/Q3 (D24).
- Entities: one class per HA entity type, native types preferred, own service only as fallback
(D23). Found: MQTT
notifydrops the title. - Start-up hook
prepare()in the platform (D21); modes,--desktop-novrand--config(D22). - New requirement UI-1: status display in the main tab (D20).
- The user installed
mosquittoon the dev host, so native builds can use libmosquitto. - Started docs/DESIGN.md: one process (D16), three layers (D17), HA-centric object classes (D18). HA side: FrameAssistant needs only stock HA; how the user wraps commands (scripts, pyscript) is up to them (NFR-6 unchanged).
- Agreed to settle the high-level architecture first (list under "Next steps"), before component details.
- Stay with the Debian build container: an Arch container wouldn't match SteamOS's own package versions (private repos, rolling Arch) and has no arm64 multiarch for cross builds.
2026-10-04/05: project set-up and requirements
-
Copied the vrdashboard template. Removed what the app doesn't need:
examples/(diagnostics app) and theVRDASH_BUILD_EXAMPLESoption- the Frame test package (
scripts/package-frame-test.sh,docs/FRAME-TESTING.md, screenshots) - the demo UI (
src/qml/DemoPage.qml)
Main.qmlshows a placeholder card. -
Named the app FrameAssistant, "Steam Frame companion for Home Assistant":
- CMake project
frameassistant, executableframe-assistant - app key
net.matzman.frameassistant, tab "Frame Assistant", QML moduleFrameAssistant
Names rejected:
- "Steam…" and "…Home Assistant": trademarks
- "HASS…": the user dislikes it, because "Hass" is German for hate.
- CMake project
-
Agreed working rules (in CLAUDE.md):
- explicit permission for everything; ask instead of assuming
- iterative five-phase cycle; an informal "ok" approves a phase
- document everything in Markdown in
docs/
-
git init. Baseline commit4a5b090. -
Requirements engineering (several question rounds with the user). The results are in REQUIREMENTS.md:
- decisions D1–D12
- 51 requirements
- research on OpenVR data sources (Appendix A)
-
Checks:
native-debugbuilds,ctestpasses 6/6 (Vulkan surface test skipped, no Vulkan on this host),--snapshotrenders.