74 lines
4.4 KiB
Markdown
74 lines
4.4 KiB
Markdown
# Power Monitor Demo — Questions for Georg
|
|
|
|
**Status:** DRAFT (for Mike's review before sending) · **Date:** 2026-06-05
|
|
Companion to `GATEWAY-SPEC.md`. Where we have a recommendation it's noted as **(our take)**
|
|
so Georg can confirm or redirect rather than start from scratch.
|
|
|
|
---
|
|
|
|
## A. Intent, audience, timeline
|
|
1. **Feedback format** — is a session a live demo you walk partners through, or self-service
|
|
access they poke at on their own? (Drives how much auth friction is acceptable.)
|
|
2. **Testers** — roughly how many, and the internal/external split? Any names/emails you
|
|
already know, so we can size the user list?
|
|
3. **Timeline** — when do you want `PWM.dataforth.com` reachable for the first round?
|
|
4. **Shipped product form** — is the eventual customer product a **packaged desktop app
|
|
they install** (the `dev_server.exe` lineage) or an **on-prem server** they browse to?
|
|
Doesn't block the demo; it shapes the product-side advice (install/update, where auth lives).
|
|
|
|
## B. Hosting & access (the "external connection" from your email)
|
|
5. Your *"need an internal IP available for an external connection"* note — what did you
|
|
picture for letting outside partners reach this? **(Our take:** host a small gateway
|
|
**inside** your network and tunnel it out to `PWM.dataforth.com` — no meter is ever
|
|
exposed publicly. Does that fit?)
|
|
6. Where can a small always-on box (VM/container) live **on the meter network** to host
|
|
that gateway?
|
|
7. Is `dataforth.com` on **Cloudflare** (we'd use a Cloudflare Tunnel), or should we front
|
|
it with **our reverse proxy / NPM** for the tunnel + TLS?
|
|
|
|
## C. Meters & demo data
|
|
8. **Which real meters** should appear in the demo (names + IPs)?
|
|
9. For `explore / add a meter by IP` (internal users only), **what IP range** should that
|
|
be limited to?
|
|
10. **Simulated units stay**, with a clear **"SIMULATION — representative data"** marker —
|
|
agreed? **(Our take:** yes — keep them, just label them.)
|
|
11. Should **external partners see live meter *data*** at all (IPs always hidden), or should
|
|
externals be **simulation-only**? You mentioned staff validating live data — confirming
|
|
whether that extends to outside partners.
|
|
|
|
## D. Users & permissions
|
|
12. Confirm the model: **simple self-managed user list** (no AD/SSO), **passwordless
|
|
magic-link** logins, **you + Mike as admins**. **(Our take:** yes.)
|
|
13. Per-internal-user destructive toggles we'd gate: **firmware update, config write,
|
|
reboot/restore**. Anything else you want as a switch (e.g. CSV/data export, clearing
|
|
event logs)?
|
|
14. Should **firmware update even be reachable** in the demo (as a *simulated* screen so
|
|
partners can give feedback on it), or **hidden entirely**?
|
|
15. **New external users default to read-only + simulated-only** — agreed?
|
|
|
|
## E. Code structure & build (so the demo doesn't fight the product)
|
|
16. Open to **extracting the simulation/mock logic out of `w3js_main.js` into a standalone
|
|
"demo module"** — so the same code drives the demo *and* can be cleanly omitted from a
|
|
production build? **(Our take:** yes; it also resolves the "mock data fused into the live
|
|
path" item.)
|
|
17. **Buildless** (include/omit the demo file) vs **adding a small build step** — preference?
|
|
Note: since this is **never getting flashed onto the meter**, the "no build tools"
|
|
rationale in your `project.md` no longer applies — a build step is back on the table if
|
|
you'd find it useful.
|
|
18. How are you iterating with **Antigravity** — should the demo **always track your latest
|
|
build**, or be a **pinned snapshot** per feedback round?
|
|
|
|
## F. What you want from ACG
|
|
19. Concretely, what's our role: **(a)** stand up + host the gated demo gateway, **(b)** a
|
|
formal external code-review writeup, **(c)** advise/shape only — or some combination?
|
|
|
|
---
|
|
|
|
### Heads-up worth mentioning to Georg regardless
|
|
- `project.md` still justifies the whole vanilla-JS / zero-dependency design on *"serve from
|
|
embedded hardware flash."* If it's never flashed, that rationale is outdated — which quietly
|
|
**reopens technology choices** (a light framework or build step) he may have ruled out.
|
|
- The package as-sent contains dev/forensic artifacts (Gemini "Antigravity" transcript
|
|
scrapers with his local path, a script listing live internal meter IPs) and an
|
|
`original_ui/` duplicate — none of which should travel in an external deliverable.
|