It's 10 p.m. The living room goes dark, the lock clicks, and your bedroom lamp sits there blazing like it didn't get the memo.
You've checked the automation twice. The schedule is correct. You've power-cycled the bulb, which is the smart home equivalent of percussive maintenance, and it helped exactly once. The routine looked airtight: one automation dims the living room at sunset, another locks the front door and kills the main lights on a timer, set two minutes apart. Except tonight both fired at 10:00:02, and now your hub reports the door locked, the lights off, and that one bedroom lamp stubbornly, inexplicably on.
This is a race condition. It's baked into how most consumer smart home hubs actually work.
A queue that wasn't built for traffic jams
Most hubs, whether a SmartThings, Home Assistant on a Raspberry Pi, or a Hubitat Elevation, process automations through a command queue. Think of it less like a traffic light and more like a single-lane roundabout: commands enter one at a time, loop through, exit. Under normal conditions, smooth. Add two commands arriving at the same millisecond and you get hesitation, re-queuing, and occasionally one command just stopping in the middle.
When two automations trigger simultaneously, the hub serializes them. It picks one to execute first. The second waits, usually milliseconds, but the devices on the receiving end don't wait patiently.
A Zigbee bulb getting a "dim to 40%" command while already processing a "turn off" from the first automation can interpret the overlap as a conflict and default to its last confirmed state. Which might be fully on.
The protocol matters here. Z-Wave sends acknowledgment packets so a device confirms receipt before the hub marks the command done. Zigbee is faster but uses a mesh where commands hop between devices, and a busy mesh during a simultaneous trigger can drop packets entirely. Wi-Fi devices like LIFX or TP-Link Kasa bulbs talk directly to the hub or cloud, which sounds simpler but adds latency whenever the cloud is the middleman.
So the bedroom lamp that ignored you probably received the command. It just received two commands inside a window it couldn't resolve, and it picked wrong.
The scenario that makes this click
Picture two neighbors, Priya and Daniel, who both bought the same starter kit: a Zigbee hub, eight smart bulbs, a smart lock. Priya set her automations ten minutes apart. Daniel, wanting a tighter evening routine, set his two seconds apart.
Priya's system runs flawlessly for months. Daniel's works perfectly too, until he adds a motion sensor that can trigger the "goodnight" scene from the hallway. Now on any night he walks past the sensor at exactly 10 p.m., the motion automation and the timer automation collide. Three bulbs in his living room start randomly staying on. He replaces two of them before realizing the hardware was never the problem.
The hub's event log tells the real story: two automation events stamped at 22:00:00.041 and 22:00:00.057. Sixteen milliseconds apart. The queue serialized them, but the Zigbee mesh was mid-hop on the first command when the second arrived, and two bulbs at the far end of the mesh never got a clean instruction.
What actually fixes it
The most reliable fix isn't better hardware. It's staggering your automations by at least three to five seconds, even when the difference feels arbitrary, because it is arbitrary and it works. Most hub interfaces let you add a delay offset. Use it.
For Home Assistant users, the `delay:` action inside an automation script is your friend. A two-second pause before any command that might compete with another routine running on the same schedule feels fussy. It works.
A question that tends to reframe things: how many bulbs have you replaced, or blamed on a dodgy batch, before checking your event log timestamps?
If you're running a large Zigbee mesh, more than fifteen devices, a dedicated coordinator like the SONOFF Zigbee 3.0 USB Dongle Plus rather than a hub's built-in radio reduces packet collision during high-traffic moments. More headroom in the mesh means the simultaneous-trigger window is less likely to catch a device mid-hop.
Cloud-dependent devices are a different animal entirely. When two automations both route through a manufacturer's cloud, you're at the mercy of their API rate limits, some as low as one command per second per device. Simultaneous local automations hitting a cloud-dependent bulb will always be serialized by a server you don't control, with latency you can't predict. That's a structural problem manufacturers have little incentive to fix, and it's not visible anywhere in the marketing materials.
The lamp that stayed on isn't a glitch. It's a scheduling problem wearing a hardware costume, and the smart home industry has done a poor job of explaining that distinction to the people buying these kits.
Separate your automations by a handful of seconds and most of this disappears. The mesh was never promised to be deterministic. Neither was your evening routine, until you treated it like one.