This blueprint provides an easy and flexible way to automate the IKEA MYGGSPRAY (E2494) Matter motion sensor.
The goal of this blueprint is to allow you to trigger any action in Home Assistant (scripts, service calls, toggles, etc.) based on motion events, rather than being locked into just controlling a light entity.
Features
Flexible UI: Select any action for âMotion Detectedâ and âMotion Stoppedâ.
Customizable Wait Time: Set how long to wait after motion stops before running the âoffâ action.
Reliable: Uses mode: restart to ensure the timer resets properly if new motion is detected during the wait period.
blueprint:
name: IKEA MYGGSPRAY E2494 Motion Sensor (Matter)
description: 'Full-featured automation for the IKEA MYGGSPRAY E2494 Matter motion sensor.
Supports arbitrary actions for both motion detected and motion stopped events.
Ideal for controlling lights, scripts, or custom hardware like light-control boards.
'
domain: automation
source_url: https://github.com/aledziko/HA-blueprints/blob/24a1999e0ac7a5f588e81f335992cff35676a1fc/IKEA/Matter/ikea-myggspray-e2494/ikea-myggspray-e2494-matter-motion-sensor.yaml
author: aledziko
input:
motion_entity:
name: MYGGSPRAY Motion Sensor
description: Select the MYGGSPRAY motion sensor entity (binary_sensor).
selector:
entity:
filter:
- device_class: occupancy
domain: binary_sensor
- device_class: motion
domain: binary_sensor
no_motion_wait:
name: Wait time
description: Time to wait after last motion is detected before running the "off" action.
default: 120
selector:
number:
min: 0
max: 3600
unit_of_measurement: seconds
motion_on_action:
name: Action to run when motion is detected
description: The actions to perform when the sensor detects motion.
default: []
selector:
action: {}
motion_off_action:
name: Action to run when motion stops
description: The actions to perform when the sensor stops detecting motion and the wait time has elapsed.
default: []
selector:
action: {}
# If motion is detected within the delay, we restart the script.
mode: restart
max_exceeded: silent
triggers:
- trigger: state
entity_id: !input motion_entity
from: "off"
to: "on"
actions:
- alias: "Run motion detected action"
sequence: !input motion_on_action
- alias: "Wait until there is no motion"
wait_for_trigger:
- trigger: state
entity_id: !input motion_entity
from: "on"
to: "off"
- alias: "Wait the number of seconds that has been set"
delay: !input no_motion_wait
- alias: "Run motion stopped action"
sequence: !input motion_off_action
Iâm currently using an older motion sensor for this purpose, but it has the hardcoded 2-minute time-out after detecting motion.
So with this MYGGSPRAY you can actually set any time-out, say, 5 seconds?
Iâve just pushed an update to this blueprint (v2.0)!
The Import Link in the original post is already updated to this version. If you are already using this blueprint, you can simply re-import it to get the new features.
Whatâs New?
Intelligent Motion: Added an optional LUX Cutoff (only trigger lights when itâs dark).
Sunlight Automation: Added independent Light High and Light Low actions (great for e.g. curtains or ambient light based on lux levels).
Battery Alerts: Built-in low battery monitoring and custom actions.
High Reliability: Switched to parallel mode so motion timers and light/battery events never block each other.
Thanks for the feedback and enjoy the upgrade!
Thanks for the feedback! You can definitely set the timeout to 5 seconds in the blueprint, but there is a hardware detail to keep in mind:
Immediate âOnâ: The âMotion Detectedâ action runs instantly as soon as the sensor sees you.
Hardware âOffâ Delay: The IKEA MYGGSPRAY has a built-in âcooldownâ or âblind timeâ of about 25-30 seconds. This means the sensor stays in the âonâ state for that duration after it last saw motion before it tells Home Assistant it is âoffâ.
Blueprint Wait Time: The âWait timeâ you set in the blueprint (e.g., 5s) starts after that hardware cooldown finishes.
So, if you set a 5-second wait, the total time until the lights turn off will be around 30-35 seconds (25s hardware + 5s blueprint). Itâs much faster than your old 2-minute sensor, but you canât go lower than the hardwareâs internal 25-second limit!
Thatâs fine, thanks for the response! Yeah the tablet keeps the screen on for a minute anyway, so thatâs perfect.
Now I gotta learn to use Blueprints, this will be my first. Itâs crazy - Iâve already setup so much in Home Assistant, but everyday I still learn and do new things on this amazing platform.
Iâve really got to be cautious to not complicate things too much; thatâs where blueprints like this can really help I guess. Once again: thanks for sharing!
Hi, Thanks for this! Very new to HA and just setting up my smart home with the new Ikea sensors⌠Found an issue where the lux is only reported as 1. tested on 2 MYGGSPRAYs and they both report 1 regardless of the light shining on it. Any ideas. Factory reset didnt help either⌠The HW no shows as P2.0
Update: the 3rd sensor works⌠But seems like illuminance is only updated every 5mins which is a bit annoying since it keeps the light off if you go into the room within 5 mins since its measured the light ON illuminance.
Hi @amjednizam,
Yes there is some internal hardware delay in the MYGGSPRAY lux sensor. I didnât measure it but it takes even a few minutes for it to notice change in light brightens. Unfortunately I cannot do anything about it.
Iâve just updated this blueprint to include the Active Hours feature. You can now restrict the automation to specific times of the day (e.g., motion lights only at night, or door alerts only during work hours).
Whatâs new:
Enable Active Hours: Toggle to restrict triggers to a specific window.
Custom Start/End Times: Full control over when the automation is active.
Parity: All blueprints in the IKEA Matter collection now share this unified feature set.
Hi, i am fairly new to HA, so thanks for this, it helps. I donât know if I am misunderstanging something, but the illuminance sensor does seem a bit random. I have have the sensor in my hallway, which can get a bit dark, so this should be ideal. However, I have the cutoff setting turned down to just 1 lux and the motion sensor still activates during the daylight hours. Have I got this wrong? I am on version 2 and see V3 is now available, so will update, but the active hours defeats the object for me. Any help appreciated.
Whilst the illuminance sensor is usable, its use case seems better for daylight rather than low light.
There seems to be a huge difference between readings of 1 - 5 LUX, which is a tiny difference on the sensor (which iâve seen go as high as over 1000 LUX,), but in reality, at those low light conditions, the difference is huge between 1 LUX and 3 LUX.
Hi @Tribillowl and @Rofo! Thanks for the feedback and troubleshooting data.
Iâve just released an update (v2.1) that addresses the âstale luxâ issue for the MYGGSPRAY. Testing confirms that these battery-powered Matter sensors have a very specific reporting rhythm:
The measured pulse of the sensor (Performance Data):
Motion ON: Lux updates ~1s after the motion event.
Motion OFF: Lux updates ~10s after the hardware goes off.
Idle: If no motion occurs but light levels change, the sensor updates roughly every 30 seconds.
Whatâs new in v2.1:
Sync Buffer: Added a 1.5s safety delay before checking the lux cutoff. This ensures Home Assistant receives the âfreshâ light level packet before deciding to trigger.
Note: This does mean there is now a mandatory 1.5s delay before the action triggers, which is unavoidable to ensure the sensor syncs correctly.
Hardened Logic: The lux template has been refactored to be rock-solid even when the cutoff is set to 0 lx.
Split-Trigger Bugfix: Following a separate report on GitHub, I have refactored the backend for MYGGSPRAY, KLIPPBOK (Leak), and MYGGBETT (Door). These now use a âSplit-Triggerâ architecture which eliminates overlapping timers and fixes the âpremature offâ bug.
@Tribillowl: Donât worry about the Active Hours feature - those settings are entirely optional. If you donât need them, just leave them disabled, and the automation will behave exactly as before. A re-import is perfectly safe!
Hi, thanks for your reply and information. I have updated and will try.
Having downloaded a lux meter onto my phone, the hall at the sensor is recording 0 Lux, so maybe my hall is darker than I thought! Previous reply about the sensors do indicate they may work better when the light levels increase towards summer, and that the sensor does not really like the low light levels.
Thanks again.
Just reiterating that if you plan to use the device outside, at low light, the lux reading is pretty rubbish.
The sensor drops to 1 LUX far too quickly, even when (by the human eye), its still twilight and there are many more âstepsâ before its really dark (0 LUX).
This is not so much of a problem indoors, when you want to decide if a light needs turning on or off, but for an outdoor light, 1 LUX is too early, and 0 LUX is too late, so Iâd had to also look at other factors, like time of dusk, or time since 1 LUX was recorded to figure out how âfarâ into twilight it is.
I agree. There is a hardware limitation regarding low LUX precision in the MYGGSPRAY, which we canât change from the blueprint. My unit also returns 1 LUX even when itâs in a completely light-isolated box.
While itâs good enough to determine a basic âday vs. nightâ state, it does hit that 1 LUX floor a bit early for outdoor use. To get around this limitation, a common trick is to use a Hybrid Condition in your automation:
LUX Sensor: Handles dark, stormy days when it gets gloomy earlier than expected.
Sun Elevation: Handles the âdeep twilightâ transition that the sensor misses.
By checking if LUX < 2 OR Sun Elevation < -3.0, you get the best of both worlds: reactive lighting during storms and accurate timing during clear sunsets.
@mivi2266 There is a delay already in the blueprint for motion action " Wait time (Motion); Time to wait after last motion is detected before running the âoffâ action." Is this what you are looking for?
A new update (v2.2) has just been pushed to the blueprint, bringing compatibility improvements and latency optimizations!
Here is a summary of the changes:
Expanded Sensor Compatibility (Merged from @kstrâs contribution)
Added support for occupancy and presence device classes in the motion entity filter, making the blueprint compatible with a much wider range of binary sensors.
Instant Triggering & Dynamic Safety Delay
Implemented a fully dynamic and configurable Safety Delay parameter.
Previously, there was a hardcoded 1.5-second delay to wait for battery-powered lux sensors to report fresh values. This introduced a noticeable lag for wired systems (like alarm motion detectors) or setups that do not use light thresholds.
The safety delay is now automatically bypassed (0s) if no lux sensor is configured or if the lux cutoff is set to 0. This enables instant motion-to-light triggering out of the box.
For setups that do require a light threshold check, it still safely defaults to 1.5s (or can be adjusted to any custom value).
Features
Installation
Blueprint Code
Update: v2.0 - Additional Features Released!
