Useful Smart Home Routines: Triggers, Examples and Safe Testing
Start with a clear trigger, condition and action, then define manual override and missing-sensor behaviour. Test small comfort routines before expanding them.
- Write a trigger, condition and action
- Example: a considerate night light
- Example: a window reminder without notification noise
- Example: an evening scene with a manual escape
- Test failures and keep rules understandable
- Questions about this guide
- Further reading
- Related help
- Terms in this area
- Read next
- Tell us about your own situation.
- Services
- Resources
- Company
- Get in touch
Start with a clear trigger, condition and action, then define manual override and missing-sensor behaviour. Test small comfort routines before expanding them. A useful automation does one recognisable job and leaves people able to override it. A corridor light that turns on at night can be helpful; the same light repeatedly switching off while someone is still there is a poorly defined rule. The difference is usually in triggers, conditions and recovery, not in the number of connected gadgets. This guide gives practical examples you can adapt with your platform’s supported tools. They are design examples, not tested recipes for every brand. Start with non-critical lighting or reminders, explain the behaviour to the household and test unexpected states. Do not apply an experimental comfort routine to locks, heating, medical support or security-critical equipment without an appropriate assessment. Start with a clear trigger, condition and action, then define manual override and missing-sensor behaviour. Test small comfort routines before expanding them. Write a trigger, condition and action A trigger starts the rule: a button press, a sensor change or a scheduled time. A condition asks whether the rule should continue, such as whether it is dark. The action performs the useful job. In event-driven systems, a condition is normally checked when the trigger occurs; it is not a promise to wait until that condition becomes true later. If a person arrives before sunset, an arrival rule with a darkness condition may do nothing, and sunset later may not run it unless separately included as a trigger. Describe that behaviour in plain language before building the rule. Then define how it ends and how a user can stop it. Example: a considerate night light Use a supported motion or presence sensor to request a modest lighting scene only during the chosen night period. Decide whether the scene may replace a manually selected brightness. Keep the light on while presence is still reported; do not use a blind timer that ignores a person standing still. If the sensor becomes unavailable, choose a predictable non-critical fallback rather than interpreting “unknown” as “nobody home”. Test entry, lingering, leaving and returning during the off delay. The example is not a fall-prevention system or emergency light. Retain a physical control and suitable ordinary lighting for the household’s actual needs. Example: a window reminder without notification noise A contact sensor can p
Why does my routine work manually but not automatically?
When you start it by hand, the test may skip the trigger or conditions. A useful step is to look at the event and the condition state at the moment the automatic run should have started.
Should an unknown sensor reading mean nobody is home?
No. "Unknown" or "unavailable" simply means information is missing. Choose a deliberate fallback instead of treating it as a reliable "no".
Can I copy these examples straight into any platform?
Not directly. They describe behaviour for you to build with the features your platform supports. Device states, delays and execution modes differ, so please test them on your own system.