Live remote-control page

claude-bot commented

2026-07-07 17:38:16 +00:00

Contributor

Goal

A simple "set the lights right now" control surface: a color wheel / brightness / effect picker that pushes to the device immediately, distinct from the review workflow.

Why it's valuable

Sometimes you just want to grab the lights manually (a party, testing, showing someone). Today that means quick-push buried in the review UI. A dedicated, mobile-friendly control page makes Iris pleasant to use as an everyday remote.

Sketch

New route reusing the existing POST /wled/quick-push + DELETE /wled/quick-push endpoints and the auto-revert-at-next-scheduler-event behavior.
Live color wheel, brightness, effect selector; "revert to schedule" button.
Works well as a PWA / phone home-screen shortcut.
Admin-gated (viewers already limited to bounded previews).

Acceptance criteria

Immediate manual control that pushes live
One-tap revert to the scheduled scheme
Mobile-friendly layout
Respects existing role guards

Proposed enhancement (brainstorm follow-up).

## Goal A simple "set the lights right now" control surface: a color wheel / brightness / effect picker that pushes to the device immediately, distinct from the review workflow. ## Why it's valuable Sometimes you just want to grab the lights manually (a party, testing, showing someone). Today that means quick-push buried in the review UI. A dedicated, mobile-friendly control page makes Iris pleasant to use as an everyday remote. ## Sketch - New route reusing the existing `POST /wled/quick-push` + `DELETE /wled/quick-push` endpoints and the auto-revert-at-next-scheduler-event behavior. - Live color wheel, brightness, effect selector; "revert to schedule" button. - Works well as a PWA / phone home-screen shortcut. - Admin-gated (viewers already limited to bounded previews). ## Acceptance criteria - [ ] Immediate manual control that pushes live - [ ] One-tap revert to the scheduled scheme - [ ] Mobile-friendly layout - [ ] Respects existing role guards Proposed enhancement (brainstorm follow-up).

claude-bot added the

labels

2026-07-07 17:39:38 +00:00

claude-bot added this to the v1.1.0 milestone

2026-07-15 15:32:56 +00:00

rbrooks referenced this issue from a commit

2026-09-05 01:25:51 +00:00

Add a page for grabbing the lights right now (#24)

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

2026-09-05 01:26:01 +00:00

Add a page for grabbing the lights right now (#24) #135

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:40:53 +00:00

Add a page for grabbing the lights right now (#24)

claude-bot closed this issue

2026-09-05 01:58:51 +00:00

claude-bot referenced this issue from a commit

2026-09-05 01:58:51 +00:00

Add a page for grabbing the lights right now (#24) (#135)

claude-bot commented

2026-09-05 01:59:02 +00:00

Author

Contributor

Landed in #135 (squash-merged to main). All four acceptance criteria met.

/remote: colour swatches, a custom picker, brightness, effect, speed and intensity — all pushing immediately — plus a one-tap Back to schedule. Laid out for a phone first, because the plausible use is standing in the garden looking at the tree.

It drives the existing quick-push endpoint rather than inventing a second push path. That's what makes it safe to hand to someone at a party: quick push saves the controller's state, applies the new one, and hands the night back at the next scheduler event, so nothing the page does can leave the lights somewhere the schedule won't recover from. A second path would have had to reimplement that, and the version that forgot to would be indistinguishable from the working one until the evening it mattered.

Quick push gained brightness_pct, effect_id, effect_speed, effect_intensity — meaningful only alongside a colour, since a scheme carries its own. All four default to the previous behaviour, and there are tests pinning that specifically: solid_color_state is shared with the no-event ambient state and the scheduler's fallbacks, so a "harmless" default change here would quietly alter both.

Two interaction decisions: tapping a swatch sets and pushes in one action (a second tap on Apply is one too many when you're looking at the lights), and sliders push on release, not on drag (the same reasoning for a control that would otherwise send sixty requests a second).

A real bug turned up while reading the push path. POST /wled/push — the "Push now" button — built its scheme id directly instead of going through the resolver #74 added, so on an interpolated event the button sent the phase anchor while the scheduler sent the blended day. That's the same drift #93 fixed once already, and #74 added a third asker of the question without my noticing. Fixed, with a test that fails against the old lookup:

assert 'interp_event_2026_mid' == 'interp_event_2026@2026-12-05'

Verified: 21 new backend tests, ruff/mypy clean, 780 backend tests, frontend tsc/eslint/vitest/build clean, CI green.

Landed in #135 (squash-merged to `main`). All four acceptance criteria met. `/remote`: colour swatches, a custom picker, brightness, effect, speed and intensity — all pushing immediately — plus a one-tap **Back to schedule**. Laid out for a phone first, because the plausible use is standing in the garden looking at the tree. **It drives the existing quick-push endpoint rather than inventing a second push path.** That's what makes it safe to hand to someone at a party: quick push saves the controller's state, applies the new one, and hands the night back at the next scheduler event, so nothing the page does can leave the lights somewhere the schedule won't recover from. A second path would have had to reimplement that, and the version that forgot to would be indistinguishable from the working one until the evening it mattered. Quick push gained `brightness_pct`, `effect_id`, `effect_speed`, `effect_intensity` — meaningful only alongside a colour, since a scheme carries its own. All four default to the previous behaviour, and there are tests pinning that specifically: `solid_color_state` is shared with the no-event ambient state and the scheduler's fallbacks, so a "harmless" default change here would quietly alter both. Two interaction decisions: tapping a swatch **sets and pushes** in one action (a second tap on Apply is one too many when you're looking at the lights), and sliders push **on release, not on drag** (the same reasoning for a control that would otherwise send sixty requests a second). **A real bug turned up while reading the push path.** `POST /wled/push` — the "Push now" button — built its scheme id directly instead of going through the resolver #74 added, so on an interpolated event the button sent the *phase anchor* while the scheduler sent the *blended day*. That's the same drift #93 fixed once already, and #74 added a third asker of the question without my noticing. Fixed, with a test that fails against the old lookup: ``` assert 'interp_event_2026_mid' == 'interp_event_2026@2026-12-05' ``` Verified: 21 new backend tests, `ruff`/`mypy` clean, 780 backend tests, frontend `tsc`/`eslint`/vitest/build clean, CI green.

Rows
Columns

Live remote-control page #24

Goal

Why it's valuable

Sketch

Acceptance criteria