Automations vs Scenes: How to Use Both in an Aqara Home

A trigger can be a sensor reading, a device state, a schedule or another supported condition. The automation checks any additional conditions and then performs its actions. For example: when motion is detected in the passage after sunset, turn on the passage light at a low brightness.

Good automations are specific enough to avoid surprises. Time windows, presence conditions and short delays can distinguish a useful response from a light that turns on at the wrong moment.

Write the logic as WHEN, IF and THEN before opening the app. WHEN is the event that starts evaluation. IF contains the conditions that must be true. THEN contains explicit actions, including brightness, colour temperature, delay and final state where relevant. This exposes vague requirements early.

A scene can be started from the Aqara Home app, a compatible ecosystem, a voice command, a wireless button or a control panel. One Evening scene might close the curtains, change selected lights to a warmer colour temperature and reduce brightness for the living area.

Scenes work well when the same group of actions is useful but the timing depends on the household.

A scene normally represents an outcome rather than a toggle. ‘Evening’ should set the intended state even if some lights are already on and others are off. This makes repeated execution predictable and avoids a mixed result caused by toggling every device blindly.

A scene can act as a reusable action group. Instead of rebuilding the same set of light and curtain actions in several automations, create one scene and call it from the relevant routines where the platform supports this.

This makes future changes easier. Adjusting the scene once can update the experience everywhere it is used.

For example, an Evening scene can define curtains closed, ambient lights at 40 per cent and tunable fittings at a warm setting. A schedule may call it on ordinary days, while a wireless button lets the household choose it early. Both paths reach the same documented result.

A sensor event alone rarely describes the whole situation. Motion in a passage should turn on a light only when the area is dark enough. A door opening may mean arrival, departure or a person collecting a delivery. Add conditions that distinguish those situations, but do not create a chain so complex that nobody can explain why it failed.

Time ranges are simple but inflexible. Sunrise and sunset offsets follow seasonal changes. Illuminance measures the actual environment but is affected by sensor position and switching lights. Presence or home modes add household context but need a dependable way to change state. Choose the smallest combination that resolves a real ambiguity.

Sensors can report repeatedly. A motion automation that restarts a long sequence on every report may flood notifications or keep resetting a timer. Use cooldowns, sustained-state conditions or a separate occupancy state where the platform supports them.

Delays also survive differently across hubs and cloud platforms. Test what happens if a device is manually changed during the delay, if the hub restarts, or if a second trigger arrives. For important routines, prefer logic whose final state is clear instead of relying on a fragile chain of timed toggles.

A routine can live in Aqara Home, Apple Home, Google Home, Alexa or another controller, depending on the devices and features involved. Avoid creating overlapping versions in several platforms. When two controllers react to the same event, duplicated actions and timing differences are difficult to diagnose.

Record the owner beside the automation name and keep device names consistent across integrations. If a scene is exposed from Aqara Home to another platform, confirm whether the destination starts the Aqara scene or maintains a separate copy of its actions. The distinction affects where future changes must be made.

Automation design is not finished when the happy path works. Test the routine with children, guests, late nights and internet outages in mind.

Keep a short test matrix: normal trigger, condition false, repeated trigger, manual override, device unavailable and internet unavailable. Note the expected result for each. This is enough discipline to catch most frustrating home-automation behaviour without turning a residence into a software project.

• What happens when someone is still in the room but sitting quietly?
• Should the automation run on weekends and public holidays?
• Can a guest operate the home without the app?
• Is there an obvious physical way to override the result?