💡 Clean & Simple Universal Occupancy Lighting for PIR & Radar Sensors (examples: Aqara FP300, Eve Motion)

Blueprints Exchange
1

What this blueprint does:

Motion-activated lighting for any PIR or radar sensor – designed to be easy to configure with only the settings you actually need, nothing more. Quick to set up, covers the most common use cases.

Features: Multi-sensor support · separate on/off light targets · illuminance gate · brightness & color temp · fade-in transition · off-delay in seconds (10 s for hallways, 5 min for offices) · dim-before-off warning · “keep lights on” override for visitors · schedule restriction · manual off is respected

Works with: Aqara FP300, Eve Motion, Philips Hue Motion, IKEA VALLHORN, and any sensor with occupancy/motion/presence device class.

Just try it :wink:

Import link: home-assistant_blueprints/Clean_and_Simple_Universal_Occupancy_Lighting_for_PIR_and_Radar_Sensors.yaml at main · MajorLazer2142/home-assistant_blueprints · GitHub

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

Feedback and suggestions welcome! :blush:

Release History:

Release History

• v2.0 – March 11, 2026 – “Keep Lights On” override
Feature: New optional input_boolean / switch helper to prevent automatic turn-off. While active, lights won’t dim or turn off – but still turn on normally with occupancy. Perfect for visitors.

• v1.9 – March 11, 2026 – Manual off respected
Fix: Lights manually turned off (voice, switch, app) while the room is still occupied no longer turn back on during the dim-before-off phase. If all target lights are already off, the dim/off sequence is skipped entirely.

• v1.8 – March 10, 2026 – Off-delay in seconds
Feature: Off-delay changed from minutes to seconds (0–3600), enabling short delays like 10 s for hallways. Default: 300 s (= 5 min).

• v1.7 – March 10, 2026 – Bugfixes & robustness
Fix: Off-delay now starts from the last sensor going off, not the first. Fix: “Schedule Restriction” without a selected helper no longer causes an error. Fix: Sensors with state unavailable/unknown no longer block turn-off. Improvement: Re-check after dim phase prevents turn-off if someone re-enters during dimming. Improvement: Added max_exceeded: silent to suppress log spam from frequent sensor events.

• v1.6 – January 15, 2026 – Fade-in on turn-on
Feature: Configurable fade-in transition when lights turn on (0–60 s, default: instant).

• v1.5 – January 2, 2026 – Schedule restriction
Feature: Optional schedule helper to restrict automation to specific time periods.

• v1.4 – January 2, 2026 – UI polish
Improvement: Enhanced description with emojis and version info. Required fields marked, input groups collapsed by default, improved selectors.

• v1.3 – December 31, 2025 – Dim before off
Feature: Optional courteous dim phase before turning off, with configurable transition and hold time. Inputs now organized into sections with icons.

• v1.2 – December 29, 2025 – Multi-sensor support
Feature: Support for multiple occupancy/motion sensors. Renamed blueprint to reflect broader compatibility. Default off-delay increased to 5 min.

• v1.1 – December 27, 2025 – Illuminance fix
Bugfix: Lux check now only evaluated on turn-on, preventing feedback loop from the lamp’s own light.

• v1.0 – December 26, 2025 – Initial release
Occupancy-based lighting with illuminance gate, fixed brightness/color temp, and configurable off-delay.

2 Likes
2

Thank you perfect timing! Got hold of 2x FP300 today, initial one setup and will set up another later.

Do you it would be easy to dim if no presence is detected then wait 5mins before turning off?

1 Like
3

Version 1.3, including your dim idea, is now online! :blush:
Hope it works well!

5

Works well, still need to play around and tweak so its just right

1 Like
6

Thank you so much for your work. It works perfectly with the Aqara FP300! As a beginner, I struggled to get the automation working. Yours is perfect. I use it in the garden to control the patio lights when I go outside.

1 Like
7

Looking good, but no devices show or are listed when selecting Lights to Turn ON, Select Target. Deep gloom

8

I have an FP300 I just got today and I hooked it up Matter over Thread. I can see luminance and presence change within the device panel but this automation just doesn’t want to trigger for some reason. Any ideas on how I can troubleshoot?

9

Nicely done! This made it quick to setup a small automation on some of my office lights.

I really like the courtesy dim before the lights turn off. Would there be a way to ramp the lights up instead of going directly to the brightness setting?

I.e., ramp from an off state to whatever the predefined state is over say…5 seconds, etc?

1 Like
10

Hey love your Blueprint here. Any chance you can make the turn off be in seconds? I choose to only have the hallway lights on for 10 secs. The minimum of your Blueprint is 1min. Thanks in advance.

11

Getting error: Message malformed: expected a dictionary for dictionary value @ data[‘actions’][0][‘choose’][0][‘sequence’][0][‘target’]

description: ""
alias: Clean & Simple Universal Occupancy Lighting for PIR & Radar Sensors
use_blueprint:
  path: >-
    MajorLazer2142/Clean_and_Simple_Universal_Occupancy_Lighting_for_PIR_and_Radar_Sensors.yaml
  input:
    occupancy_sensors:
      - binary_sensor.presence_fp300_presence
    lights_turn_on:
      entity_id: light.led_bulb_t2_e27_cct_2
14

@jmiranda
Hi! This isn’t a bug in the blueprint – the target selector expects a specific format. It looks like you edited the YAML manually. Change this:

yaml

lights_turn_on:
  entity_id: light.led_bulb_t2_e27_cct_2

to this:

yaml

lights_turn_on:
  entity_id:
    - light.led_bulb_t2_e27_cct_2

The easiest way to avoid this is to use the UI picker instead of editing the YAML directly – it will always produce the correct format. Same applies to lights_turn_off. Hope that helps!

@TechMage313
Thanks, glad you like it! Great timing with your request – in v1.6 we actually added exactly this feature. :slightly_smiling_face:

In the :bulb: Lights & Appearance section, you’ll now find a setting called “Fade-in Duration when Turning On (seconds)”. It defaults to 0 (instant on), so just set it to 5 and your lights will smoothly ramp up over 5 seconds to the configured brightness. Enjoy!

@bdb7
Thanks, appreciate it! Done – v1.8 is now live. :slightly_smiling_face:

The off-delay has been changed from minutes to seconds (0–3600), so you can now set it to 10 seconds for your hallway. The default is 300 seconds (= 5 min) so nothing changes for existing users. Enjoy!

15

Just scanned through the code for this, it doesn’t look like this one has a feature I’m looking for – I use the dimming feature, but I haven’t yet found a blueprint that does that, that will check to see if something has already turned the lights OFF before doing the dim – so if I walk into a room, the lights come on, then I shut them off via voice control or remote or something, then they come on dimmer when the timeout happens, but they should just stay off.

16

Hello,

The blueprint is really great and supports quick setup. I have several Aqara FP300s in use myself, one in each room.

So far, everything is fine, but another helper would be very helpful. Unfortunately, the time-based configuration with the helper is too inflexible for me.

It would be great to have the option of using a switch or something similar to, for example, keep the lights on in certain rooms until they are manually switched off.

For example, if you have visitors and move to a different room, you might want the lights in the other room to stay on.

Best regards

17

@ekdikeo
Great catch, thanks! This is fixed in v1.9. :slightly_smiling_face:

The blueprint now checks whether any of the target lights are still on before starting the dim/off sequence. So if you turn the lights off manually (voice, switch, app, etc.) while the room is still occupied, they’ll stay off when the sensors eventually clear – no more phantom dim-on.

@ghostridernrw40
Hi ghostridernrw40, great idea! This is now available in v2.0. :slightly_smiling_face:

There’s a new section :lock: Keep Lights On (Optional) in the blueprint. Just create an input_boolean helper and select it in the blueprint. As long as that helper is turned on, the automation will not dim or turn off the lights – but they still turn on normally with occupancy.

You can toggle the helper via a dashboard button, voice command, or even another automation. Perfect for your visitor scenario – just flip the switch when guests are over, and the lights stay on until you turn it off again.

18

Hi,

Thank you so much for the quick implementation. It works exactly as desired. One more thing occurred to me regarding the optional schedule.

While you can use times (hours) here, in my opinion it makes much more sense to use sunset and sunrise as entities, including a deviation range.

For example, one hour after sunset. Of course, this contrasts with the illuminance, but it would create a dynamic time period instead of a fixed one like the current option of specifying hours.

As we all know, the days get longer in summer :slight_smile:

Best regards

19

Thanks for the feedback, glad it works! :slightly_smiling_face:

For dynamic time windows based on sunset/sunrise, I’d actually suggest two approaches that already work today:

Option 1 – Illuminance sensor (recommended): This is already built in and arguably better than sunset/sunrise, because it adapts not just to seasons but also to cloudy days, rain, etc. If your FP300 reports illuminance, just set a threshold and you’re done.

Option 2 – Dynamic schedule via a small automation: Create a simple automation that turns your Schedule Helper on at sunset (with offset, e.g. +01:00) and off at sunrise. That way the blueprint’s schedule restriction becomes fully dynamic – no changes needed.

Adding sun-based triggers directly would mean 4+ new inputs and significantly more complex logic – and at that point we’d have to drop the “Clean & Simple” from the name. :smile: I’d rather keep the blueprint focused and let HA’s existing tools handle the rest.

20

Thanks for the blueprint. It is easy to use and very efficient.

Although there is one problem with first option that you have mentioned and it is the time that FP300’s Illuminance sensor requires
to actually update it’s reading after the lights go off. I have noticed that on many occasions when there is some movement in the area sensor does not update on time for the trigger to go on. So on first instance lights go on sensor picks new readings that are above the threshold. Lights come off and if somebody enters in short time (10 to 20 even 30 seconds) after, the condition is not met due to the Illuminance sensor not changing it’s reading yet so the lights are not getting switched on.
Has anybody got any suggestion how this could be resolved?

21

Fantastic! Thanks for the implementation, I’ll hopefully get some time to check it out soon :slight_smile: