A three-minute door reminder is easy to test once: open the door, wait, hear the alert. The more revealing tests are what happens around the timer and when the rule starts running.
For a notification-only rule using an Aqara contact sensor, I would check:
Already open: leave the contact open before enabling the rule or entering its active time window. Does it start timing, or need a fresh open event?
Closed before expiry: close it just before the threshold. Does the pending reminder stop, or still arrive after the door is closed?
Close, then reopen: does the second opening get its own full delay, or inherit the first countdown?
Still open after an alert: is the reminder one-shot or repeated? Check the repeat interval and confirm that closing the contact stops any repeats.
Write down the sensor model, hub, app version, exact trigger wording, active time window, and actual alert times. An “opens” trigger and an “is open” condition may behave differently; I would verify the chosen rule rather than assume they are interchangeable.
The practical target is no stale alert after closure, a deliberate repeat policy, and a clear decision about doors that were already open. Keep this test limited to notifications, without linking it to a lock or motor.
Has anyone compared these four cases in Aqara Home? The exact rule wording alongside the result would be especially useful.
Just out of curiosity: Are you approaching this from a software QA and backend testing perspective, or are you just looking to build a reliable everyday automation for yourself?
From a standard user perspective within the Aqara Home app, the system abstracts this into a simple Trigger → Condition → Action flow.
Cases 1 to 3: The app clearly differentiates between a trigger (state change) and a condition (current state). If I set a trigger to “door left open for 3 minutes”, the system requires an uninterrupted state. If the door closes at 2 minutes and I still get an alert, or if a quick close/reopen doesn’t reset the timer, that’s not really a configurable edge case on the user’s end. That would just be a bug in Aqara’s backend timer management.
Case 4 (Repeats): Aqara Home doesn’t natively support endless loops. An automation will only fire once. You can’t easily build an “alert every 3 minutes until closed” rule. You either have to hardcode multiple separate automations (at 3 min, 6 min, 9 min), or theoretically try a messy workaround where two automations continuously enable/disable each other (though I haven’t actually tested if the app allows this in practice).
For anything involving loops or complex state retention (like Case 4), I usually bypass the Aqara app entirely and push the logic to Home Assistant, where repeat/until actions make this trivial.
Are you trying to build a specific workaround natively in the Aqara Home app, or are you just reverse-engineering how they handle their timers under the hood?
Hello, I disagree with you. Later I will write an automation where there will be a cyclical notification (you can set the time you need). It’s just that this automation will have one additional Aqara smart lamp.
Hi, I think there might be a slight misunderstanding, but we are actually on the same page! I didn’t mean that cyclical notifications are completely impossible in Aqara Home. My point was just that there is no native repeat/loop action block in the app itself, like the one you have in Home Assistant.
Using a smart lamp as a timer or trigger for a cycle is a really clever workaround. It perfectly highlights what I meant. We have to rely on secondary devices or creative automation setups to build a loop, instead of just using a built-in repeat function.
I am definitely looking forward to seeing your sample automation. It is always great to learn new tricks in the Aqara ecosystem!
The lamp is an additional signal about the open door. You can use any unused contact of a relay or switch instead of the lamp.
You choose the interval and content of the message yourself.
By the way, @JohnD, you once wrote to me about cyclic Off/On automation lamp: “Interesting automation, but where can it be used?” Here’s a clear example, any automation has its application.
The aim is a reliable everyday reminder; these are acceptance checks, not a claim that I have reproduced a timer bug or identified where one would run. For case 1, the distinction I want to document is enabling the rule while the door is already open versus receiving a fresh opening event. Your clarification about a native repeat action versus a device-assisted cycle is helpful, and @gafich10’s lamp example gives that fourth case a concrete implementation to test. I would check that closing the door stops the cycle and that reopening starts a fresh interval, with notifications only during testing.
The “stop” signal appears if the IF conditions are invalid (doors are closed). I have tested this automation. Also, in the WHEN section, I recommend setting a delay period (delay) of 5 seconds for the lamp. This condition ensures a 100% start cycle with the door open.
That makes the stop behavior testable. I would add one negative check: close the door during the five-second lamp delay and confirm that the first notification never starts. That separates “the cycle stops after it has begun” from “a pending start is cancelled before the cycle begins.”
