Drive colour smart lights with the night's scheme: Twinkly, Govee, Hue, Nanoleaf #157

New issue

Open

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

claude-bot commented

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

Collaborator

Idea

Plenty of holiday lighting isn't WLED:

Twinkly strings and trees, and Govee permanent outdoor lights, are among the best-selling holiday lighting products.
Philips Hue is often on the porch.
Nanoleaf panels are in the front window.

A household with a WLED roofline and a Twinkly tree should see both follow the same approved scheme on the same night.

Behaviour

Palette-based. Each device gets the night's palette: per-bulb or per-zone colours for addressable devices (Twinkly, Govee segments, Nanoleaf panels), and the dominant colour or a slow palette rotation for single-colour bulbs (Hue). This is where a scheme describing intent rather than WLED effect IDs pays off.
Energy maps to each device's native effects where they exist. Twinkly and Nanoleaf have their own effect engines; Hue has only transitions. Where there's no match, still is the safe default.
Brightness, dim and ramp follow the envelope like WLED does, within what each API can do. Hue transitions are capped, and many devices don't fade at all.
The photosensitivity guard (#150) applies to every device's rendering, not only WLED's.

Backends

Home Assistant first. Its light.turn_on with rgb_color, brightness and effect covers all four through existing HA integrations, with one implementation. It shares the HA connection with #156 (smart plugs) and #12.
Direct local APIs, where HA is absent or too limited:
- Twinkly: local REST. Supports uploading per-LED movies, so a real palette pattern is possible.
- Govee: LAN API (UDP), segment colour on supported models.
- Hue: Bridge API v2. Entertainment areas are overkill; plain light state is enough.
- Nanoleaf: local OpenAPI with a token.
Each gets recorded-response fixtures, like the WLED compatibility work (#62).

Depends on

The device-model design issue (#155): palette-based intent and the color capability.
#28 (WLED palette/gradient support): shares the palette representation.
#13's multi-device plumbing.

Acceptance

One approved scheme renders sensibly on WLED plus at least one colour device via HA, verified on real hardware.
The side panel previews each device's rendering before approval.
Envelope, dim and ramp behave within each device's limits, and the limits are documented per backend.
At least one direct backend (Twinkly suggested, since it's the most holiday-specific) with fixtures.

## Idea Plenty of holiday lighting isn't WLED: - **Twinkly** strings and trees, and **Govee** permanent outdoor lights, are among the best-selling holiday lighting products. - **Philips Hue** is often on the porch. - **Nanoleaf** panels are in the front window. A household with a WLED roofline and a Twinkly tree should see both follow the same approved scheme on the same night. ## Behaviour - **Palette-based.** Each device gets the night's palette: per-bulb or per-zone colours for addressable devices (Twinkly, Govee segments, Nanoleaf panels), and the dominant colour or a slow palette rotation for single-colour bulbs (Hue). This is where a scheme describing **intent** rather than WLED effect IDs pays off. - **Energy maps to each device's native effects where they exist.** Twinkly and Nanoleaf have their own effect engines; Hue has only transitions. Where there's no match, still is the safe default. - **Brightness, dim and ramp** follow the envelope like WLED does, within what each API can do. Hue transitions are capped, and many devices don't fade at all. - **The photosensitivity guard** (#150) applies to every device's rendering, not only WLED's. ## Backends 1. **Home Assistant first.** Its `light.turn_on` with `rgb_color`, `brightness` and `effect` covers all four through existing HA integrations, with one implementation. It shares the HA connection with #156 (smart plugs) and #12. 2. **Direct local APIs, where HA is absent or too limited:** - **Twinkly:** local REST. Supports uploading per-LED movies, so a real palette pattern is possible. - **Govee:** LAN API (UDP), segment colour on supported models. - **Hue:** Bridge API v2. Entertainment areas are overkill; plain light state is enough. - **Nanoleaf:** local OpenAPI with a token. Each gets recorded-response fixtures, like the WLED compatibility work (#62). ## Depends on - The **device-model design** issue (#155): palette-based intent and the `color` capability. - #28 (WLED palette/gradient support): shares the palette representation. - #13's multi-device plumbing. ## Acceptance - [ ] One approved scheme renders sensibly on WLED plus at least one colour device via HA, verified on real hardware. - [ ] The side panel previews each device's rendering before approval. - [ ] Envelope, dim and ramp behave within each device's limits, and the limits are documented per backend. - [ ] At least one direct backend (Twinkly suggested, since it's the most holiday-specific) with fixtures.

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:47 +00:00

claude-bot referenced this issue

2026-09-26 05:04:10 +00:00