Scene, automation or schedule: choose the missing part
| Concept | Its job | Example planning question |
|---|---|---|
| Scene | Save desired device states. | What should Reading mode look like? |
| Automation | Respond to a trigger and evaluate any conditions before acting. | When should Reading mode be requested? |
| Schedule | Set a time-based plan. | Should it run on weekday evenings? |
| Script | Reuse a sequence of actions. | Do steps need an order or a delay? |
These distinctions are a planning vocabulary, not a promise that every app implements identical behaviour. Home Assistant documents scenes, automation rules and scripts separately. Another platform may group similar ideas under a single “routine” screen. Inspect the actual trigger, conditions and actions instead of relying only on the label.
A reading light: one result, several ways to request it
Suppose a household wants a floor lamp at 45% and a desk lamp at 70%. Those invented settings define the desired result. A saved Reading scene can make that result easy to request without adjusting both controls every evening.
The household can choose different starting events: a button press, a scheduled time or a suitable presence report. Those are separate decisions from the saved brightness values. Keeping them separate makes it easier to change when the room responds without repeatedly editing the same end state.
- TriggerA supported sensor reports presence.
- ConditionIt is within agreed reading hours.
- ActionRequest the Reading scene.
A trigger is the event that begins evaluation. A condition is a check. If the check fails, the requested action should not follow that rule. A change to a condition is not necessarily a new trigger; check the platform’s execution model when designing the routine.
Make the manual choice understandable
Ask what should happen when someone adjusts the lamp themselves. Should the next sensor report restore the scene immediately, wait until another session or respect an override? There is no universal household preference. Describe the intended behaviour before choosing the rule structure.
- Name scenes by the activity they support, such as Reading or Quiet evening.
- Keep the first rule narrow enough to explain to another household member.
- Avoid competing rules that request different states from the same lamp.
- Agree how guests can use the room without installing an app.
Use a small test table before adding more rules
| Situation | Desired behaviour to decide |
|---|---|
| Someone enters outside the chosen hours | Should anything happen? |
| A person stays seated | What signal and delay keep the result useful? |
| Someone changes brightness manually | How long should that choice persist? |
| An accessory is unreachable | How will you notice and recover? |
| Internet is lost | Which local actions should remain possible? |
Treat these as questions to resolve with your actual platform and equipment. A scene request does not prove every accessory reached the requested state. Test the result in the room rather than assuming that a successful app tap confirms all devices responded.
Continue with motion versus presence sensors when choosing an input, or everyday automation ideas when choosing a useful first task. The terminology index contains quick definitions of the individual building blocks.
Sources and method
Prepared with AI assistance and checked against these primary documents on 16 October 2026. Examples and test plans are original hypothetical scenarios, not hands-on product reviews. Manufacturer statements are model-specific. Read our editorial approach.