Building a Flexible Guest Motion Lighting System in Home Assistant

TL;DR

I expanded my Home Assistant lighting setup so Philips Hue motion sensors can drive both Philips Hue bulbs and WLED strips—without turning it into another hard-coded “motion → lights on” automation.

The result is a small lighting control layer you can enable when guests are home and tune from the dashboard:

• Master switch to enable or disable the whole system
• Two independent zones: Kitchen and Bedroom
• Selectable light mode: Hue / WLED / All
• Light groups instead of hard-coded entities
• Lux threshold so daylight doesn’t waste motion lighting
• Auto or Manual brightness, with a simple time-of-day schedule
• Configurable timeout via a Number helper
• Hue → WLED sync paused while Guest Motion Lighting is active

Everyday behaviour lives in helpers and Mushroom cards. YAML stays for structure, not for constant tweaking.

The Goal: Motion Lighting Without Constant YAML Edits

I already had Philips Hue motion sensors and a mix of Hue bulbs and WLED strips. A basic motion automation is easy. What I wanted was something I could leave installed permanently and only turn on when guests are around—then adjust brightness, timeout, and which lights respond without opening YAML.

In short: configurable guest motion lighting, not another one-off automation.

What I Implemented

Guest Motion Lighting master switch

A single helper enables or disables the entire system:

input_boolean.guest_motion_lighting

The automation can stay installed forever. When I don’t need it, I flip one switch.

Two independent motion zones

Motion in one room does not affect the other. Kitchen and Bedroom can run at the same time.

Selectable lighting mode

An input_select chooses what actually turns on:

• Hue — only Philips Hue lights
• WLED — only WLED strips
• All — both

Home Assistant light groups

Instead of scattering individual light entities through the automation, I use groups:

• Kitchen Hue lights
• Kitchen WLED lights
• Bedroom Hue lights
• Bedroom WLED lights

If I add another WLED strip later, I add it to the right group. The automation does not need a rewrite.

Illuminance-based activation

Hue motion sensors report illuminance. Lights should not fire every time someone walks through a bright room.

A Number helper sets the lux threshold:

input_number.guest_motion_lux_threshold

Example: with a threshold of 250 lx, motion lighting is allowed only when the room is below 250 lux.

Configurable brightness

Two brightness modes via input_select.guest_motion_brightness_mode:

• Manual — uses input_number.guest_motion_brightness from the dashboard
• Auto — follows a simple time-of-day schedule

That keeps night motion lighting very dim, while daytime can be a bit brighter when needed.

Configurable timeout

No hard-coded “turn off after X seconds.” A Number helper owns it:

input_number.guest_motion_timeout

When the sensor goes clear, the automation waits for that timeout, then checks that the room is still clear before switching the lights off.

Independent room timers

Kitchen and Bedroom can run in parallel. The automation uses mode: parallel, so activity in one room does not cancel the run for the other.

Solving the Hue → WLED Synchronization Conflict

I already had an automation that mirrors Philips Hue lights onto corresponding WLED strips. That created an awkward side effect:

Guest Mode = Hue
        ↓
Motion turns Hue on
        ↓
Hue → WLED sync detects the change
        ↓
WLED turns on too

So Hue behaved like All.

The fix was a condition on the Hue → WLED sync automation: disable synchronization whenever Guest Motion Lighting is active.

Guest Motion then has exclusive control over the selected lighting mode. Sync can resume when guest mode is off.

Dashboard Controls

I put the controls in a dedicated Guest Motion Lighting subview using Mushroom cards, so the main dashboard stays clean.

Current controls:

I also added a compact Mushroom chip that summarizes the current config, for example:

🟠 Hue · Auto · 1 min

• Tap — toggles Guest Motion Lighting on or off
• Long press — opens the full configuration subview

Helpers Used

Most everyday behaviour is driven by helpers:

That was the important design choice: helpers for day-to-day tuning, YAML for structure.

Current Automation Flow

Motion detected

Motion detected
      ↓
Is Guest Motion Lighting enabled?
      ↓
Check room illuminance
      ↓
Is illuminance below configured threshold?
      ↓
Check selected mode
   ↙     ↓      ↘
 Hue   WLED     All
      ↓
Determine brightness
(Auto or Manual)
      ↓
Turn appropriate lights ON

Motion becomes clear

Motion becomes clear
      ↓
Wait configured timeout
      ↓
Is room still clear?
      ↓
Turn room's motion lights OFF

What I Like About This Approach

• One automation covers multiple rooms
• New WLED devices can join through light groups
• Brightness and timeout changes do not require YAML edits
• The whole system can be disabled when I do not need it
• Hue and WLED can be controlled independently
• Daylight does not unnecessarily trigger lights
• Kitchen and Bedroom operate independently
• The main dashboard stays compact
• The architecture can grow without a redesign

Possible Future Improvements

A few ideas I may add later:

• Accent lighting mode with a curated mix of Hue and WLED lights
• Lux-aware brightness based on measured illuminance, not only time of day
• Manual-override detection so intentional light-ons are not switched off by the timeout
• More rooms and motion sensors
• Presence sensors instead of (or in addition to) PIR motion sensors
• Context-aware behaviour depending on house occupancy, guests staying, or everyone sleeping

Closing

What started as a simple motion-light automation became a small, configurable lighting control layer on top of Hue, WLED, and Home Assistant.

The part that matters most to me: I can keep adding lights and tweaking behaviour from the UI—without redesigning the whole thing every time.