Switch non-pixel decorations on and off: inflatables, spotlights and projectors on smart plugs #156

New issue

Open

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

claude-bot commented

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

Collaborator

Idea

Most holiday displays are not only pixels. Inflatables, laser and gobo projectors, floodlights, animated reindeer and fog machines sit on smart plugs or relays, and people run them on dumb timers that don't know about sunset, holidays or the late-night cut-off. Iris already knows exactly when the display should be on. Let it switch those too.

This is the cheapest and most useful first step beyond WLED: an on/off device needs no colour mapping at all.

Behaviour

Each device follows the envelope by default: on at the on transition, off at the off transition. Per-device options:
- off at the late-night dim instead of at sunrise (an inflatable's blower doesn't need to run all night)
- follow the morning window (#52)
- only on certain events or tags. For example, the Halloween projector runs only on events tagged halloween, and the inflatable snowman from 1 December to 6 January.
Staggered switch-on (a few seconds between devices), so a dozen inflatable blowers don't start on one circuit at the same instant. That inrush current is a real reason GFCIs trip.
Weather hold (with #25): keep inflatables down above a wind-speed threshold. Inflatables in high wind are a genuine hazard, and the most requested reason for weather-reactive control.
Covered by the watchdog (#148): a plug that is off when it should be on is corrected, and reported.

Backends, in order

Home Assistant, via its REST API (switch.turn_on / turn_off with a long-lived token). This covers nearly every smart plug brand at once, through the integrations the user already has. It overlaps #12: #12 is Iris publishing its state, and this is Iris commanding entities. Share the HA connection settings.
MQTT (#12's aiomqtt dependency), for Tasmota and Zigbee2MQTT users without HA.
Direct HTTP for Shelly and Tasmota. Both have trivial local APIs, so there's no broker and no HA needed.

Depends on

The device-model design issue (#155), for the Controller Protocol with a switch capability. Don't build this as a WLED-shaped special case.
#13's multi-device plumbing.

Acceptance

Devices are configured in Settings, and each follows the envelope with per-device overrides.
Event and tag-scoped devices switch only on matching nights.
Staggered start, and a configurable gap.
The HA backend works end-to-end against a real HA instance. MQTT and Shelly/Tasmota have tests against recorded API responses, the same approach as the WLED fixtures (#62).
Failures go through the same retry, webhook and metrics paths as WLED pushes.

## Idea Most holiday displays are not only pixels. Inflatables, laser and gobo projectors, floodlights, animated reindeer and fog machines sit on smart plugs or relays, and people run them on dumb timers that don't know about sunset, holidays or the late-night cut-off. Iris already knows exactly when the display should be on. Let it switch those too. This is the cheapest and most useful first step beyond WLED: an on/off device needs no colour mapping at all. ## Behaviour - **Each device follows the envelope by default:** on at the on transition, off at the off transition. Per-device options: - off at the late-night dim instead of at sunrise (an inflatable's blower doesn't need to run all night) - follow the morning window (#52) - **only on certain events or tags.** For example, the Halloween projector runs only on events tagged `halloween`, and the inflatable snowman from 1 December to 6 January. - **Staggered switch-on** (a few seconds between devices), so a dozen inflatable blowers don't start on one circuit at the same instant. That inrush current is a real reason GFCIs trip. - **Weather hold** (with #25): keep inflatables down above a wind-speed threshold. Inflatables in high wind are a genuine hazard, and the most requested reason for weather-reactive control. - **Covered by the watchdog** (#148): a plug that is off when it should be on is corrected, and reported. ## Backends, in order 1. **Home Assistant**, via its REST API (`switch.turn_on` / `turn_off` with a long-lived token). This covers nearly every smart plug brand at once, through the integrations the user already has. It overlaps #12: #12 is Iris *publishing* its state, and this is Iris *commanding* entities. Share the HA connection settings. 2. **MQTT** (#12's `aiomqtt` dependency), for Tasmota and Zigbee2MQTT users without HA. 3. **Direct HTTP for Shelly and Tasmota.** Both have trivial local APIs, so there's no broker and no HA needed. ## Depends on - The **device-model design** issue (#155), for the `Controller` Protocol with a `switch` capability. Don't build this as a WLED-shaped special case. - #13's multi-device plumbing. ## Acceptance - [ ] Devices are configured in Settings, and each follows the envelope with per-device overrides. - [ ] Event and tag-scoped devices switch only on matching nights. - [ ] Staggered start, and a configurable gap. - [ ] The HA backend works end-to-end against a real HA instance. MQTT and Shelly/Tasmota have tests against recorded API responses, the same approach as the WLED fixtures (#62). - [ ] Failures go through the same retry, webhook and metrics paths as WLED pushes.

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

claude-bot referenced this issue