Game-day colours: team schedules as events, and a flash when they score #152

New issue

Open

opened 2026-09-26 05:01:09 +00:00 by claude-bot · 0 comments

claude-bot commented

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

Collaborator

Idea

Team colours on game days is one of the most common non-holiday reasons people own addressable roofline lights. It comes in two parts that differ a lot in difficulty. Part A can ship independently of Part B.

Part A: team schedules drive colours (mostly exists)

iCal subscriptions (#51) can already subscribe to a team's published schedule. Most leagues and teams publish .ics feeds. But verified against main:

Imported events get tags=[], source="ical" and priority=100 (services/ical_import.py).
generate_schemes_for_event (services/scheme_generator.py) then finds no prior scheme, no builtin for that key and no tag match, and falls to _FALLBACK_SEGMENT: generic colours, source="fallback".
So every game gets the same generic scheme, and each one needs editing by hand.

Needed:

Per-subscription defaults: a subscription can carry tags and/or a scheme template. For example, "every event from this calendar uses Team colours", approved once. New games then arrive already matched, by the same mechanism that makes a memorial anniversary relight with nothing to review (#80).
Per-subscription priority: at 100, a game day on 24 December currently beats Christmas Eve. Priority should be settable per subscription, not fixed.
Time-of-day awareness is optional. Events are whole days, so a game day lights the whole evening. That is probably fine.

Part B: react live when the team scores

The fun part: flash the team colours for 30 seconds on a score, then return to the schedule.

It is a live trigger, so it belongs to the inbound triggers and rule engine (#32). It should be built as a rule on that engine, not as a bespoke sports feature. Hence the v2.0.0 milestone.
Score source:
- Polling a public scores API during the game window. ESPN's unofficial endpoints are widely used but undocumented, and can change without notice.
- Or, simpler and more robust: accept a Home Assistant sensor (HA's teamtracker integration already does the polling) via #12 / #32.
- Prefer the HA route. Iris shouldn't own a scraper for an undocumented API.
The flash reuses the quick-push path (save state, push, revert), which already guarantees nothing is left in a state the schedule can't recover from.
It must go through the photosensitivity guard (#150). "Celebrate" must not mean strobe.

Acceptance

Part A: a subscription with a default scheme produces approved, correctly coloured game days with no per-event editing, and its priority is configurable.
Part B: a score event (via #32) triggers a timed flash that reverts to the schedule and respects the photosensitivity guard.
Docs: a worked example with a real team .ics feed.

Part A could be split out into v1.2.0 if wanted; it doesn't depend on #32.

## Idea Team colours on game days is one of the most common non-holiday reasons people own addressable roofline lights. It comes in two parts that differ a lot in difficulty. **Part A can ship independently of Part B.** ## Part A: team schedules drive colours (mostly exists) iCal subscriptions (#51) can already subscribe to a team's published schedule. Most leagues and teams publish `.ics` feeds. But verified against `main`: - Imported events get `tags=[]`, `source="ical"` and `priority=100` (`services/ical_import.py`). - `generate_schemes_for_event` (`services/scheme_generator.py`) then finds no prior scheme, no builtin for that key and no tag match, and falls to `_FALLBACK_SEGMENT`: generic colours, `source="fallback"`. - So every game gets the same generic scheme, and each one needs editing by hand. **Needed:** - **Per-subscription defaults:** a subscription can carry tags and/or a scheme template. For example, "every event from this calendar uses *Team colours*", approved once. New games then arrive already matched, by the same mechanism that makes a memorial anniversary relight with nothing to review (#80). - **Per-subscription priority:** at 100, a game day on 24 December currently beats Christmas Eve. Priority should be settable per subscription, not fixed. - **Time-of-day awareness is optional.** Events are whole days, so a game day lights the whole evening. That is probably fine. ## Part B: react live when the team scores The fun part: flash the team colours for 30 seconds on a score, then return to the schedule. - **It is a live trigger, so it belongs to the inbound triggers and rule engine (#32).** It should be built as a *rule* on that engine, not as a bespoke sports feature. Hence the v2.0.0 milestone. - **Score source:** - Polling a public scores API during the game window. ESPN's unofficial endpoints are widely used but undocumented, and can change without notice. - Or, simpler and more robust: accept a Home Assistant sensor (HA's `teamtracker` integration already does the polling) via #12 / #32. - Prefer the HA route. Iris shouldn't own a scraper for an undocumented API. - **The flash reuses the quick-push path** (save state, push, revert), which already guarantees nothing is left in a state the schedule can't recover from. - **It must go through the photosensitivity guard** (#150). "Celebrate" must not mean strobe. ## Acceptance - [ ] Part A: a subscription with a default scheme produces approved, correctly coloured game days with no per-event editing, and its priority is configurable. - [ ] Part B: a score event (via #32) triggers a timed flash that reverts to the schedule and respects the photosensitivity guard. - [ ] Docs: a worked example with a real team `.ics` feed. Part A could be split out into v1.2.0 if wanted; it doesn't depend on #32.

claude-bot added this to the v2.0.0 milestone

2026-09-26 05:02:39 +00:00

claude-bot added the

labels

2026-09-26 05:02:45 +00:00