Smart Home Automation Not Working
Why Routines & Schedules Stop Firing

How an automation decides whether to run

Every routine, scene schedule or automation, whatever the app calls it, has the same three parts. A trigger starts it: a time, a door opening, motion, a button, a phone arriving home. Optional conditions are then checked: only after dark, only if nobody is home, only on weekdays. If every condition passes, the actions run: turn on the light, close the curtain, send the alert.

Thinking in those three parts turns a vague complaint (“the automation is broken”) into a question you can answer. Did the trigger happen and did the system see it? Did a condition say no? Did the command leave the hub but never reach the device? Each answer points to a different fix, and guessing at the wrong one is why many households give up on automations altogether.

Most hub apps keep some record of each run, such as a history, log or activity list, though it is often buried in a settings menu. Home Assistant calls it a trace and labels each run with the reason it stopped, which makes it a useful model for what to look for in any app.

Match the symptom to the likely cause

Use the table to narrow things down before changing anything. Change one setting at a time and test, so you know which change fixed it.

If several unrelated routines failed at the same moment, think about the hub, the internet connection or the account before looking at any single automation.

The trigger never fired, or was missed

A trigger can fail in two ways. The first is obvious: the sensor did not report. A motion sensor with a flat battery, a door contact whose magnet has shifted after the door was planed, or a button out of range of the hub never sends the event. Walk past the sensor and watch whether its state changes in the app. If it does not, the automation is not the problem.

The second way is subtler: the event arrived but did not match what the trigger was waiting for. Home Assistant's documentation gives a clear example. An automation that waits for a device to go from off to on will not start if the device dropped off the network in between, because the change it actually saw was from “unavailable” to on. The same kind of mismatch happens in other apps: a trigger set on “door opened” that ignores a sensor reconnecting, or a temperature trigger set to “rises above” that never fires because the reading was already above the line when the rule was saved.

Motion sensors add their own wrinkle. After detecting motion, many sensors wait before they can report again, so somebody who walks back into a room soon after leaving it may not trigger the light. That is the sensor's design rather than a fault; the guide to motion-sensor lighting indoors explains placement and timeouts.

Conditions that quietly block the run

Conditions are the most common reason an automation looks dead when it is actually working exactly as written. A condition is checked once, at the moment the trigger fires. It does not start anything when it later becomes true, and if the state changes a moment after the check, the run does not wait or try again. Home Assistant's own documentation spells this out, and other apps behave the same way even when they do not say so.

• A “only when dark” rule that uses the sun, checked on a bright evening before sunset.
• An “only when nobody is home” rule while a family member's phone still counts as home.
• A weekday-only schedule that was saved with the wrong days ticked.
• A rule that requires the aircon to be off, while the IR hub has lost track of the aircon's real state.
• Several conditions that must all be true, where one of them was meant to be “either”.

In the history, a run that started and then stopped without doing anything is the signature of a failed condition; Home Assistant labels it “Stopped because a condition failed”. Remove conditions one at a time, test, and add them back once you find the one that bites.

Time zone, sunset and schedule settings

A schedule that fires at the wrong hour, or never, often has nothing to do with the device. Hub apps work from the home's location and time zone, which are set when the account or hub is first created. If a hub was set up on a phone that was abroad, bought as a China-region unit, or carried over from an older account, the home may still be on another zone. In the app's home settings, check that the location is your actual address and the time zone is Malaysia (Kuala Lumpur).

Sunrise and sunset triggers depend on that location too. A home pinned to the wrong city fires its porch light at the wrong moment every evening. A sunset offset makes it worse when nobody remembers it is there. For outdoor lights in particular, the porch and driveway lighting automation guide compares a sun schedule with a light sensor.

Finally, check the obvious: many apps let you switch a schedule off without deleting it, and some pause every automation when the home is put into a holiday or away mode.

When the hub or the device is offline

An automation cannot move a device the hub cannot reach. If the history shows a completed run but the device did not change, open the device in the app: a grey icon, “offline” or “unavailable” means the problem is connectivity, not the routine, and Home Assistant's documentation notes that actions simply skip a device in that state. Devices that went offline after a new router or a changed WiFi password are covered in the guide to devices offline after a WiFi change, and the wider step-by-step process is in the smart home troubleshooting guide.

Cloud or local: where your automation actually runs

Two automations that look identical in the app can run in completely different places. Some run on the hub inside your home, and keep working when the internet is down. Others run on the maker's servers, so the trigger has to travel out to the internet and the command has to come back. When the connection, the server or the link between two companies' clouds hiccups, those cloud routines are the ones that fail.

The pattern to aim for is simple: anything that must work every time, such as security lights or a leak alert, should run as locally as possible. The guide to local control without internet explains which ecosystems can do that, and the guide to keeping a smart home running in a power cut covers keeping the hub and router alive when the power trips.

Arrive-home and leave-home triggers

Presence triggers rely on a phone telling the app where it is. Modern phones work hard to save battery, and the first thing they cut is background location for apps that are not used often. If the “welcome home” lights only work some days, check that the hub app has location access set to always, that battery optimisation is turned off for that app, and that each family member is signed in on their own phone.

Condos add a quirk: the home radius has to cover the car park and the lift lobby, but not the mamak downstairs where you sit after work. Too small and the trigger fires late; too large and it fires while you are still out. For the gate or the main door, many owners keep presence for lights only and open the lock or gate with a deliberate tap.

Two apps fighting over one device

A device paired to its maker's app and also linked to Google Home, Alexa or Home Assistant can be controlled by routines in every one of them. One app turns the fan on; another app's “all off at night” rule switches it straight off again. The household sees an automation that “does not work” when in fact two automations work against each other.

• Decide which app owns the automations, and delete or disable copies in the others.
• Look for loops: a rule that turns light A on when light B turns on, and another that does the reverse.
• Check whether a routine is set to allow only one run at a time; a new trigger that arrives while an earlier run is still waiting is dropped. Home Assistant reports this as “Stopped because only a single execution is allowed”.
• Name devices by room and purpose in one place, and keep the same names everywhere.

Renaming or re-pairing a device often breaks every automation that used the old entry, which is a common reason routines die after a tidy-up. If you also use a voice assistant, the guide to voice assistants not responding covers the naming side for voice commands.

Account, region and permission changes

Routines that cross between apps depend on account links that can expire. A changed password, a removed family member who originally created the link, or the maker updating its sign-in can silently break the connection between, say, a Tuya-based app and Google Home. The fix is usually to unlink and relink the service in the bigger app, then check that every device and routine came back.

Region matters for some ecosystems. A hub registered to a China server and devices registered to a global server cannot see each other, so automations between them never run. The guide to China versus global server regions explains how to check this before you buy more devices.

How ClickBina helps

We check automations and schedules that have stopped running: the triggers, the conditions, the home's location and time zone, which app owns each routine, and whether it runs locally or in the cloud. We do the smart device, app and low-voltage side of the job. Where it makes sense, we move critical routines onto a local hub and tidy duplicate automations so that one app is in charge.

Whoever does the work, keep the admin account for each app in your own name, and ask for a short list of which app runs which automation.

Sources & references

• Home Assistant: Troubleshooting automations: the unavailable-state trigger mismatch, runs stopped by a failed condition, actions skipped on unavailable devices, single-execution runs.
• Home Assistant: Automation conditions: conditions check the state at the moment the automation runs.
• Your hub app's own help pages: where its history or log lives and whether each routine runs locally.

This page is general guidance on why automations fail. Menu names and features differ between apps and change with updates.