Demo mode (built-in WLED simulator) and README screenshots

claude-bot commented

2026-07-15 15:38:35 +00:00

Contributor

From the 2026-07-15 review follow-ups. For public self-hosted adoption, let people try Iris with zero hardware and see it before installing:

DEMO_MODE=true (or WLED_HOST=simulator): an in-process fake controller implementing the /json/* surface the WLEDController client uses — accepts pushes, reports plausible info/state, never fails
Pairs with #14 (virtual-strip preview): the simulator provides the state, the preview renders it — together they make a full no-hardware experience
Seed demo data: current year generated + a few approved schemes so the calendar looks alive immediately
README: screenshots/GIF of the year calendar, day panel, and scheme editor (worth doing as soon as the UI is spec-complete via #48)
Optional: a public read-only demo instance behind DISABLE_AUTH + viewer-only role

From the 2026-07-15 review follow-ups. For public self-hosted adoption, let people try Iris with zero hardware and *see* it before installing: - [ ] `DEMO_MODE=true` (or `WLED_HOST=simulator`): an in-process fake controller implementing the `/json/*` surface the `WLEDController` client uses — accepts pushes, reports plausible info/state, never fails - [ ] Pairs with #14 (virtual-strip preview): the simulator provides the state, the preview renders it — together they make a full no-hardware experience - [ ] Seed demo data: current year generated + a few approved schemes so the calendar looks alive immediately - [ ] README: screenshots/GIF of the year calendar, day panel, and scheme editor (worth doing as soon as the UI is spec-complete via #48) - [ ] Optional: a public read-only demo instance behind `DISABLE_AUTH` + viewer-only role

claude-bot added this to the v1.1.0 milestone

2026-07-15 15:38:35 +00:00

claude-bot added the

labels

2026-07-15 15:38:35 +00:00

claude-bot referenced this issue

2026-09-05 00:52:15 +00:00

Two effect IDs don't mean what the code says they mean #132

claude-bot referenced this issue

2026-09-05 00:56:27 +00:00

Make two effect IDs mean what their comments claim (#132) #133

~~claude-bot referenced this issue 2026-09-05 01:37:31 +00:00~~

README screenshots and an optional public demo instance #136

claude-bot referenced this issue

2026-09-05 01:37:41 +00:00

README screenshots and an optional public demo instance #136

rbrooks referenced this issue from a commit

2026-09-05 01:38:23 +00:00

Let someone try Iris without owning a controller (#63)

claude-bot referenced this issue from a pull request that will close it,

2026-09-05 01:38:41 +00:00

Let someone try Iris without owning a controller (#63) #137

claude-bot closed this issue

2026-09-05 01:47:37 +00:00

claude-bot referenced this issue from a commit

2026-09-05 01:47:39 +00:00

Let someone try Iris without owning a controller (#63) (#137)

claude-bot commented

2026-09-05 01:47:52 +00:00

Author

Contributor

Landed in #137 (squash-merged to main) — the simulator, the pairing with #14, and the demo seeding. README screenshots and the optional public instance are split to #136; see below for why.

DEMO_MODE=true swaps the HTTP controller for an in-process simulator, so the whole workflow runs with no hardware: the year generates, the review queue fills, schemes preview as an animated virtual strip, and pushes and preset sync succeed.

Seeding gives an empty database three segments and sixteen approved schemes across eight events, so the calendar has colour rather than being a blank grid. It seeds only an empty install — existing segments and approvals are never touched, and it refuses to top up a partial layout, because this is a flag someone can set on a database with their real work in it. It deliberately leaves the rest as candidates: the review queue with things in it is the feature being demonstrated.

Subclassing the real controller paid for itself immediately. A test comparing the two surfaces found get_info un-overridden — it fell through to an HTTP call against host demo, producing a DNS error that would have read like a network problem rather than a missing method. Nothing in the class called it, so the hole was invisible until something compared them.

It serves the captured 16.0.0 effect catalogue, not invented names, because the browser simulator maps effect IDs to animations. That capture moved from tests/fixtures/ to app/data/ so there's one shipped copy rather than a test fixture duplicated into the image.

Three of my eight showcase event keys didn't exist — thanksgiving_us, christmas and new_years_eve are thanksgiving_week, christmas_season and nothing at all. A typo there is invisible: the seed approves nothing for that key and the calendar is a little greyer than intended. There's a test now.

Verified by booting it, not just unit tests — status reachable as "Iris Demo" with 220 effects, 3 segments, 108 schemes with 16 approved, push and quick push succeeding, preset sync writing 16 slots and verifying the read-back.

Two honest caveats, documented in the module, the README and .env.example: nothing on your network lights up while it's on (a startup warning says so), and it never fails, so it exercises none of the retry, fallback or unreachable-controller paths. It's a demo, not a test rig.

Why the screenshots are split (#136): I can generate them — Playwright is already set up — but I can't look at the result and tell whether the layout held, whether the crop shows the right thing, or whether it looks like software someone would want to run. Committing images I can't see to a README whose job is first impressions is the one place where "it produced output" is furthest from "it works". Demo mode makes that job easy for whoever does it, which is the useful half.

Verified: 29 new tests, ruff/mypy clean, 790 backend tests, CI green.

Landed in #137 (squash-merged to `main`) — the simulator, the pairing with #14, and the demo seeding. **README screenshots and the optional public instance are split to #136**; see below for why. **`DEMO_MODE=true`** swaps the HTTP controller for an in-process simulator, so the whole workflow runs with no hardware: the year generates, the review queue fills, schemes preview as an animated virtual strip, and pushes and preset sync *succeed*. Seeding gives an empty database three segments and sixteen approved schemes across eight events, so the calendar has colour rather than being a blank grid. It seeds **only** an empty install — existing segments and approvals are never touched, and it refuses to top up a partial layout, because this is a flag someone can set on a database with their real work in it. It deliberately leaves the rest as candidates: the review queue with things in it is the feature being demonstrated. **Subclassing the real controller paid for itself immediately.** A test comparing the two surfaces found `get_info` un-overridden — it fell through to an HTTP call against host `demo`, producing a DNS error that would have read like a network problem rather than a missing method. Nothing in the class called it, so the hole was invisible until something compared them. It serves the **captured 16.0.0 effect catalogue**, not invented names, because the browser simulator maps effect IDs to animations. That capture moved from `tests/fixtures/` to `app/data/` so there's one shipped copy rather than a test fixture duplicated into the image. **Three of my eight showcase event keys didn't exist** — `thanksgiving_us`, `christmas` and `new_years_eve` are `thanksgiving_week`, `christmas_season` and nothing at all. A typo there is invisible: the seed approves nothing for that key and the calendar is a little greyer than intended. There's a test now. **Verified by booting it**, not just unit tests — status reachable as "Iris Demo" with 220 effects, 3 segments, 108 schemes with 16 approved, push and quick push succeeding, preset sync writing 16 slots and verifying the read-back. Two honest caveats, documented in the module, the README and `.env.example`: nothing on your network lights up while it's on (a startup warning says so), and **it never fails**, so it exercises none of the retry, fallback or unreachable-controller paths. It's a demo, not a test rig. --- **Why the screenshots are split (#136):** I can generate them — Playwright is already set up — but I can't *look* at the result and tell whether the layout held, whether the crop shows the right thing, or whether it looks like software someone would want to run. Committing images I can't see to a README whose job is first impressions is the one place where "it produced output" is furthest from "it works". Demo mode makes that job easy for whoever does it, which is the useful half. Verified: 29 new tests, `ruff`/`mypy` clean, 790 backend tests, CI green.

Rows
Columns

Demo mode (built-in WLED simulator) and README screenshots #63