It's week three. The bedroom lights were supposed to shut off at 10 p.m. They didn't. You open the app, squint at the rule, and everything looks exactly right. Two nights later it works perfectly, as if nothing happened.
Nothing in the rule changed. That's what makes it so infuriating.
This is the defining misery of smart home automation: not failure, but inconsistent failure. A system that breaks on a schedule you can predict is a problem you can solve. One that breaks randomly, and then heals itself, is a system that will gaslight you for months.
The trigger heard a slightly different question
Most people treat their automation rules as binary. Condition met, action fires. What's actually happening underneath is closer to a relay race where any runner can quietly pocket the baton and walk off.
Take a motion-sensor rule: "When motion is detected in the hallway after sunset, turn on the hall light." That single sentence hides at least three separate data dependencies. The sensor has to report its state change to the hub. The hub has to successfully check its internal clock or hit an external sunset API. Then the hub has to dispatch a command to the bulb before a timeout kills the whole process.
Any one of those steps hiccups, the rule fails.
But only that one time, because 95% of the time the network latency is low enough, the API responds fast enough, and the Zigbee mesh is healthy enough. You built the rule during a good moment and assumed good moments were the default. They're not. They're just the majority.
The state problem nobody talks about
Here's where it gets subtle. Smart home platforms like Home Assistant, Apple Home, and SmartThings all maintain an internal model of what state each device is in. Your hub thinks the living room lamp is off. The lamp itself might disagree.
This diverges constantly. A bulb loses power briefly during a thunderstorm and comes back in its factory default state (usually full brightness, warm white) while the hub still has it logged as "off, 2700K, 40%." Every rule that depends on that lamp's current state is now running on stale data. The hub is confidently operating on a ghost.
Consider Marcus and Priya, who set up nearly identical Home Assistant configs on the same weekend. Marcus runs his hub on a Raspberry Pi 4 with a cheap SD card. Priya runs hers on an SSD. Six months in, Marcus is chasing random failures two or three times a week. Priya sees one or two a month, almost always traceable to a specific Zigbee device going offline.
The SD card in Marcus's setup introduces tiny write delays that occasionally cause the state database to log events out of sequence. The automations aren't broken. The memory of what happened is.
That distinction matters more than most smart home guides will tell you.
What actually makes them reliable
The fix isn't smarter rules. It's more paranoid ones.
Instead of triggering on a state change (motion detected), trigger on a confirmed state and add a fallback condition. Most platforms let you stack a second check: if the light is still off after this trigger fires, turn it on. That sounds redundant. It is. That's the whole point.
Poll your critical devices on a slow schedule, every five minutes is plenty, to force state reconciliation. Home Assistant supports this natively for most Z-Wave and Zigbee integrations. It's off by default because it adds network traffic, but across a dozen devices it's negligible.
For time-based rules, never rely solely on an external sunset API if your hub can calculate it locally. A brief internet outage at 7:58 p.m. will silently break every "at sunset" rule that evening, and you won't know until you're sitting in the dark.
Then check your mesh. A Zigbee bulb that's technically connected but hovering at the edge of reliable range will execute commands maybe 80% of the time. That other 20% looks exactly like a rule failure, because the app reports the command as sent. Sent is not received. Those are two completely different things, and conflating them is where most debugging goes wrong.
So ask yourself: are your failures clustering around one device, one time of day, one specific condition? If you can answer yes to any of those, you're already ahead of most people who have spent months blaming their hub.
The infrastructure under a smart home is, at its core, a dozen cheap radios negotiating with a database, a clock, and the open internet, all riding on a home network built for streaming video. It's less a computer program and more a group chat where anyone can go on read-receipt at any time. The rules aren't what's fragile. Build for the infrastructure underneath them, and the misfires drop to almost nothing.