An automation can work perfectly once and still be a poor household routine. It may run in daylight, switch off lights while someone sits still, conflict with another app, or become impossible to manage when the original owner moves out. This automation planning and testing worksheet is for documenting one rule end to end, proving that its failure cases are tolerable, and recording how to disable it.
Use the interactive worksheet below, or copy the printable tables further down. The scope is intentionally narrower than our general smart-home planning worksheet, which covers household goals, equipment, budgets and rooms. For the concepts behind triggers, conditions and manual fallback, begin with our reliable smart-home automations Guide. This Resource is an implementation record, not a competing how-to article or a product recommendation.
Scope and verification: Designed for renters, homeowners and property managers. US-first editorial review: 19 October 2026. Platform behavior differs by account permissions, device model, firmware, region and editor version. This worksheet does not control devices, guarantee compatibility, or replace electrical, life-safety or accessibility assessments.
The decision record: event, conditions, outcome and fallback
Write a sentence specific enough to fail a test: “When the hallway sensor reports a new motion event after dark, illuminate the hallway, then return it to a predictable state while maintaining manual control.” Avoid a vague objective such as “make lights smart.” For a trigger, record the particular change; for a condition, record what must already be true when that event occurs. Treat those as different controls. Home Assistant explicitly describes triggers as event reactions and conditions as present-state checks; Google Home’s newer household editor calls them starters, conditions and actions. Home Assistant trigger documentation; Google Home supported automation components.
| Part | Hallway lighting example | A question that can prevent failure |
|---|---|---|
| Starter | Hallway motion becomes detected. A sensor transition begins the evaluation. | A motion sensor becoming unavailable is not the same as new motion. |
| Conditions | Time is within the household’s chosen after-dark window, and the automation is enabled. | The platform must actually support the proposed condition. |
| Action | Turn on the hallway light at a chosen brightness. | Confirm the correct light, not a similarly named device. |
| Stop/reset | After a tested interval without relevant motion, return lighting to a predictable state. | A PIR sensor may miss a person who sits still. |
| Manual fallback | Normal physical light control remains understandable and usable. | Do not require an app to walk through the hallway. |
Interactive automation worksheet
Complete Part A before enabling a new rule. Run Part B against real devices and ordinary household conditions. Record evidence rather than choosing Pass because the app screen looks correct. Part C creates a handover or correction record. When finished, download your worksheet as JSON or print it to a PDF through your browser. There is no account, paywall, automatic storage or server-side form submission.
Private and reversible: This worksheet runs locally in the browser and does not submit form entries to WesternTechy. It does not save automatically; download a copy before leaving. Do not include passwords, camera access details, exact addresses, account recovery codes, or access credentials.
The status above is a self-reported planning aid, not a functional test, safety certification, cybersecurity assessment, or assertion that a particular device supports these features. Validate with current vendor documentation.
How to interpret failed tests
A failed condition test means the rule ran even though it should have been blocked. Disable or simplify it before adding another trigger. An unreliable timeout may indicate the sensor is motion-based rather than true presence detection; test an occupied but still room and keep manual controls usable. A duplicate-rule conflict is common when a device is controlled in both a manufacturer app and a household platform. Identify the single authoritative schedule before tuning delays.
Repeated events need special attention: in Home Assistant, the selected automation mode can ignore a second event, restart, queue or run in parallel. Do not assume another ecosystem offers the same run modes or has equivalent scheduling semantics. See Home Assistant automation modes. A manually run action may bypass normal conditions in some systems; Home Assistant’s trigger-automation action, for example, skips conditions by default. Therefore test the actual sensor or clock event as well as the manual “Run” command. Home Assistant manual trigger behavior.
Printable fallback: use without JavaScript
If the interactive controls are unavailable, print this page and complete the following blank record by hand. Retain one record per routine. Use Unverified instead of guessing about hardware support or a skipped test.
| Field | Record |
|---|---|
| One-sentence intended behavior | ________________________________________ |
| Platform, home and editing role | ________________________________________ |
| Trigger event and source device | ________________________________________ |
| Conditions and AND/OR rules | ________________________________________ |
| Target, action and expected stop state | ________________________________________ |
| Repeated events and conflicting schedules | ________________________________________ |
| Failure response and manual override | ________________________________________ |
| Who disables/removes it at handover? | ________________________________________ |
| Test | Pass / Fail / Unverified / N/A | Observation and date |
|---|---|---|
| Actual trigger under allowed conditions | ____________ | ________________________ |
| Event occurs when a condition should block | ____________ | ________________________ |
| Repeated event while action still running | ____________ | ________________________ |
| Person remains still during off-delay | ____________ | ________________________ |
| Normal physical control | ____________ | ________________________ |
| Reversible outage and device recovery | ____________ | ________________________ |
| Conflicting schedules or second platform | ____________ | ________________________ |
| Disable rule and restore normal behavior | ____________ | ________________________ |
Before you leave the routine enabled
Ask three closing questions. Can a person still operate the device manually? Does anyone know who owns the rule and how to pause it? Would failure be inconvenient rather than dangerous? If the last answer is no, keep that function independent from consumer convenience automations. Never use an ordinary lighting or smart-plug automation as a substitute for a certified smoke/CO alarm, required ventilation, life-safety equipment, accessible emergency access or manufacturer-approved appliance protection.
For SmartThings users, the documented Routines model uses IF conditions and THEN actions, and it provides choices for whether multiple conditions require Any or All. Treat this as an implementation reference, not proof that an unsupported sensor exposes a particular event. SmartThings Routines support. In Google Home, not every feature is available across its older editor, script editor and newer household editor. Check the actual controls available to your device before recording a test as N/A or Pass.
Related WesternTechy resources
- Reliable automation design: triggers, conditions and fallbacks — concept and implementation guide.
- Smart Home Compatibility Matrix — record device, protocol, controller and app assumptions.
- Network Readiness Checklist — confirm routers, hubs and discovery before automation tests.
- Device Inventory & Account Transfer Tracker — retain owner and lifecycle information when someone moves.
- Access & Privacy Audit — remove sharing and integrations safely.
Sources, scope and editorial method
Primary vendor documentation reviewed 19 October 2026: Home Assistant triggers, conditions, run modes, Google Home automation components, and SmartThings Routines. WesternTechy’s worksheet structure and negative-test scenarios are original editorial synthesis, not reported hands-on tests of specific devices. The logic is user-controlled; we do not claim to have performed or verified the reader’s tests. Reconfirm vendor UI and device behavior after software updates.