💡 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:

22

Is it possible to make the brightness and colour temperature optional?

I have two use cases where this would be helpful for me. Both relate to a room which contains a number of spotlights for general illumination. They are zigbee and configured as a group in Z2M. Two of these spotlights are directly above a workbench and are configured as a second group as well as being members of the first group. There is therefore an overlap of the two groups. HA is fine with this configuration.

Case 1:
When I'm in the room I often manually set the colour temperature and brightness of the full group according to my mood. If I go out of the room and return I want the same lighting conditions to be re-established, the blueprint forces the temp/brightness, simply turning them on without temp/brightness does re-establish my mood configured lighting.

Case 2:
This is an extension of case 1. I mentioned two spotlights directly over my workbench. With general lighting set as per my mood I will specifically set the two spots (as a group) generally to a high/max brightness/temperature whilst I'm working. Because the blueprint currently forces a set brightness/temperature it applies this to the main group including the workbench group (because of the overlap). If I leave the room and come back I still want the workbench spots set as I left them not reset where I again have to adjust them.

I don't use scenes here because I don't have specific brightness/colour temperature settings that I generally use, it's not like watching a movie or reading a book differences. Sometimes I want dim cool, other times mid warm etc.

A second request, can you split the sensors into two groups, sensors which trigger the occupied state (any one on) and sensors that trigger the off state (all off)?

My use case for this is that in one room the FP300 PIR doesn't pick us up when entering through a couple of doors at the far end of the room, if the mmWave sensor is active it generally does see us in those areas. So I use separate PIR sensors to trigger the lights on. These are transit areas so after a couple of steps the FP300 takes over and the PIR sensor values don't matter. But the issue I have is that the PIR sensors stay activated for a couple of minutes once triggered.

This is mostly a non-problem as even if we simply walk through the room the lights staying on for a couple of minutes extra is neither here nor there but it just kind of bugs my senses to know that they are potentially on longer than needed. There might also be some cases where a different set of sensors trigger on to off though I can't specifically think of any.

Hopefully you are happy to make changes to save me having to learn how to make pull requests or forks :smile:

23

finally getting around to throwing this in, as i'm re-implementing light in some rooms where some of the other blueprints get some things very wrong for me .. and this one is going to be nearly perfect for my hallway area ... being that i have a closet door in the hallway that i want to have the hallway light stay on for (and i want to control the brightness when the closet is open, but this is not a request for that, i'm going to make a separate automation for that), so having the stay-on helper is great!

Now, this probably won't affect my usage of it, because you have to be in the hallway in sight of the PIRs to close the closet, but it does seem to be a bit of a bug, if someone had wired that helper to something that was external to the area covered by their PIRs -- If you were to turn off the helper while all the PIRs are off, it doesn't look like the lights would turn off. Maybe I'm just not reading it right, though. I haven't tested, because .. well.. my helper is inside the PIR zone :slight_smile: it's just something I noticed while reading through the implementation

also, i'd like to vote for the having an option to not mess with the light's brightness .. it already has an option for not messing with the light's temperature .. i'd like to be able to use other scripts to control the color/temp/brightness, making this one a simple on/off gate.