Six-fifty in the morning, and the bedroom is still dark. The schedule said the shades open at six-thirty. You open the app and the shade is sitting there, reporting itself closed, reporting itself online, reporting a healthy battery, entirely untroubled by the fact that it has just ignored an instruction. You tap the open button and it opens instantly, smoothly, perfectly. Which is the part that makes you want to throw something — because a broken thing that stays broken is a repair, but a thing that works every time you watch it and fails every time you don’t is something else. As an Amazon Associate I earn from qualifying purchases.
We are the Smart Home Guide Editors, and this page is about that exact failure and no other. Not a shade that won’t pair. Not a shade that’s mechanically stuck. Not a shade that’s dead. A shade that responds to manual commands the instant you send them, and silently skips its own schedule. Over a long stretch of deliberately provoking this on a reference setup — battery and wired shades, hub-owned and cloud-owned schedules, sunrise offsets across a season, DST boundaries, deliberately drained cells, deliberately weakened radio paths — we arrived at a conclusion that reframes the whole problem. In the overwhelming majority of our logged incidents, the shade never disobeyed the command. It never heard the command. And nothing in the system was designed to notice.
How A Scheduled Shade Actually Works, And Why That Explains Everything
To fix this you need one piece of mechanism, and it’s the piece that no app screen will ever show you.
When you set “open at 6:30,” you have not programmed the shade. You have almost certainly programmed something else — and which something else it is determines every single failure mode you will ever see. The instruction lives in one of three places, and they behave nothing alike.
It can live in the cloud. A server somewhere watches the clock, and at 6:30 it sends a message down to your house, through your internet connection, through your hub or bridge, over the radio, to the shade. It can live in the hub — a box on your shelf watches the clock and sends the command locally, no internet involved. Or, far more rarely than people assume, it can live in the shade itself, which watches its own clock and moves its own motor with nothing else in the loop.
Now add the second piece of mechanism, the one that turns this from trivia into a diagnosis. Most battery-powered shades are not listening.
A shade that runs for a year or two on a cell cannot keep a radio receiver powered continuously — that alone would flatten the battery in weeks. So it sleeps. It wakes on a duty cycle, checks whether anyone has anything for it, and goes back to sleep. Between those wakeups it is, for practical purposes, not on the network at all. It is a mailbox, not a phone. The network holds messages for it and hands them over at the next checkin.
Put those two facts together and the whole thing snaps into focus. A scheduled command is fired at an exact instant by something that is awake, at a device that is probably asleep, across a layer that may or may not hold the message and retry. When you press the button in the app, you keep pressing, or you watch, or you press again — you are a retry mechanism made of meat. The schedule has no such thing. It fires once, into the dark, and if nothing catches it, nothing anywhere logs a complaint.
| Cause class | Signature you can observe | Share of our logged incidents |
|---|---|---|
| Command fired while the shade was asleep, no retry | Intermittent skips, no pattern by time of day, worse as the battery ages | Largest class by a wide margin |
| Weak or congested radio path at the moment of firing | Skips cluster on the shades farthest from the hub; manual commands still work because you retry | Second largest |
| Sunrise/sunset offset drift across the season | Not a skip at all — it ran, at a time you no longer expected | Moderate; very commonly misread as a failure |
| Time zone, DST, or clock ownership mismatch | Systematic, not intermittent; wrong by a whole hour or runs on the wrong days | Moderate |
| Battery sag triggering the motor’s own protection | Shade tries and aborts; often a partial move; correlates with cold | Small but sharply defined |
| Cloud outage or account/token expiry | Everything on that brand stops at once, on a schedule, while manual control still works | Small |
| The scheduling engine itself losing the schedule | The schedule is visibly gone or disabled when you look | Smallest class; rare in our log |
Read the top row and the bottom row together, because that contrast is the finding. The bottom row is what “my shade ignored the schedule” sounds like it means — the automation broke. It barely happened. The top row is what actually happens, and note carefully what it is: the automation worked perfectly and the delivery failed. Those need completely different fixes, and almost everyone spends their time rebuilding the automation.
How We Logged It
Here’s what we did, so you can weigh the conclusions properly.
We ran a reference set of shades across several rooms and provoked the failure deliberately rather than waiting for it, because waiting for an intermittent fault is how you spend a season learning nothing. We ran the same schedule from three different owners — a cloud account, a local hub, and where the hardware allowed it, the shade’s own onboard timer — against the same physical shade, so that the only variable was who was holding the clock. We moved shades progressively farther from the hub and through more walls, logging where the skips started. We ran cells from fresh down to the point of refusal, logging what changed as they aged. We watched the sunrise-linked schedules across enough of a season for the actual sunrise to move substantially. We crossed a DST boundary on purpose, with the hub, the phone, and the cloud account deliberately set to disagree.
Two honest limits on all of this. First, our shares are shares of our incidents on our hardware in our building — a different house with a different radio environment would shift the ordering, though we’d be surprised to see the top and bottom rows swap. Second, the sleep behavior we describe is a design pattern across battery-powered shade hardware, not a spec sheet number we can read off a page; individual products duty-cycle differently and some are far more forgiving than others. Where we say “most,” we mean most of what we logged, not a census of the market.
What we did not do is guess. Every claim below is something we made happen on purpose and then made go away on purpose, which is a much higher bar than watching it happen once.
The Sleeping Shade: The Big One
This is the finding, so it gets the most room.
When a scheduled command misses a sleeping shade, what happens next depends entirely on a layer you have never been shown a screen for: whether anything in the chain is willing to hold the message and hand it over later. Some radio stacks are built around exactly this. The device’s parent — a mains-powered node it’s associated with — accepts the message on its behalf, holds it, and delivers it at the next checkin. This works beautifully and is completely invisible when it’s working. Other paths have no such custody. The command is transmitted at 6:30 into a room where nobody is listening, and that is the end of it. No error. No retry. No log line. The app will cheerfully show you a schedule that “ran.”
Here is the single most useful thing in this article. Test the schedule at a moment you can watch. Not the open button — the schedule. Set a temporary schedule for two minutes from now, walk to the shade, and stand there. If it moves, your delivery chain is intact and your problem is elsewhere in this article. If it doesn’t move, and then you press the button and it moves instantly, you have just reproduced the entire failure in ninety seconds and proved that the difference is not the shade and not the schedule but the delivery. Almost nobody runs this test, because pressing the button feels like testing the shade. It isn’t. It’s testing the one path that was never broken.
What actually helped, in the order it helped:
Give the sleeping device a wakeful neighbor. A mains-powered device of the same radio family, placed between the hub and the shade, changes the topology — it becomes a router with custody of the message. In our log this was the single most effective intervention, and it is the one that looks least related to the symptom. You are not “boosting signal.” You are giving the message somewhere to wait. A well-placed mains-powered smart plug that acts as a repeater costs very little and does more for this specific fault than any setting.
Move the schedule closer to the shade. If the same schedule can be owned by a local hub instead of a cloud account, move it. You delete an entire internet round trip and every hop it contains. If the shade has a genuine onboard timer, that is better still — but be honest about whether it does. Many products present an app-side schedule as if it were onboard. The test: cut the internet, cut the hub, and see if it still runs. Most don’t.
Stop scheduling a single instant. This is the ugly, unsatisfying, extremely effective one. If your platform can fire the same command twice, two minutes apart, do it. A shade that’s already open ignores an open command harmlessly. You have converted a one-shot into a retry, which is exactly what the system failed to give you. It is not elegant. It worked more reliably than anything except the repeater.
Distance, Walls, and the Shade at the End of the House
The second class is the one people think they’ve already ruled out, because the shade “shows as online.”
Online is a status, and status is a memory. It means the device checked in at some point that the system considers recent enough. It is not a live measurement of whether a command sent right now will arrive. A shade at the far end of a house, behind two walls, will check in successfully most of the time and still miss commands at a meaningful rate — and every miss you experience by hand you silently repair by pressing again.
The diagnostic is positional, and it’s free. Log which shades skip. If the skips cluster on the far ones and never touch the ones near the hub, the radio path is your problem, and no amount of rebuilding the schedule will do a thing. In our log this pattern was unmistakable once we bothered to write it down, and completely invisible when we relied on memory — because you remember the annoying skip in the bedroom, not the eleven flawless mornings in the hall.
The other half of this is congestion, and it has a specific and unfair shape: it’s worst at exactly the times you schedule things. Morning and evening are when your house’s wireless is busiest — phones waking, backups running, everything reconnecting. Your shade schedule fires into the two noisiest windows of the day. If you have the option, shifting a schedule by even ten minutes off a round number moved skips in our log, which is a strange sentence to write and was a genuinely repeatable effect.
Sunrise Offsets: The Failure That Isn’t One
A large share of what gets reported as “my schedule stopped working” is a schedule working exactly as instructed.
If you anchored to sunrise, you anchored to something that moves — substantially, across a season, and in a direction that depends on where you live. The shade that opened at 6:30 in one month opens at a genuinely different time two months later, and it is not wrong. You are.
The tell is clean: it’s not intermittent. A sunrise-drift complaint is every single day, shifted, in one direction, getting worse gradually. A delivery failure is random and comes and goes. If someone tells you “it’s been getting later and later,” that is not a fault, and the fix is a fixed clock time or a capped offset — not a repeater, not a rebuild.
The related trap is the offset sign. “Thirty minutes before sunrise” and “thirty minutes after” are one tap apart in most interfaces and produce an hour of error. We did this to ourselves during logging, which is why it’s in the article.
Clocks: Who Owns The Time?
The fourth class is systematic rather than intermittent, and it’s diagnosed by its own regularity.
In a cloud-scheduled shade there are at least three clocks and three opinions about your time zone: the phone that created the schedule, the account that stores it, and the hub that may execute it. They are supposed to agree. When they don’t, the error isn’t random — it’s exactly an hour, or exactly some other whole number of hours, or the schedule runs Tuesday’s plan on Monday.
DST is where this surfaces, because it’s the one day the three clocks are allowed to disagree legitimately for a moment. What we logged: a mismatch that had been sitting there harmlessly for months became visible in a single morning, and it looked exactly like a sudden failure. It wasn’t sudden. It was disclosed.
The diagnostic is one question — is it wrong by a whole hour? — and it separates this from everything else in the article instantly. Nothing else on this list produces a clean sixty-minute error.
Batteries Don’t Fail At Zero
This class is small but it is the most consistently misdiagnosed one we logged, and it has a specific tell worth memorizing.
A shade motor’s hardest moment is the instant it starts moving — breaking static friction and getting a mass in motion draws far more current than keeping it moving. An aging cell has rising internal resistance, which means its voltage sags under exactly that kind of sharp load. The motor controller sees the sag, or sees the motor failing to spin up as expected, and concludes it is jammed. So it stops. That behavior is a safety feature, and it is doing its job — it just happens to be reading a tired battery as an obstruction.
What makes this evil is the reported battery level. A shade can report a comfortable percentage and still sag under load, because the reported figure is measured at rest and the failure happens under stress. The number is not lying. It’s answering a different question than the one you’re asking.
The tells: the shade tries and stops, or moves partway. It gets worse in the cold — a shade at a window in winter is at the coldest spot in the room, and cold raises internal resistance further, which is why “it only fails on winter mornings” is a real and completely explicable report. And it fails on the schedule while working on demand, which sends people straight back to blaming the automation, because when you press the button you’re usually standing in a warmer part of the day.
The test is decisive and takes one minute: put fresh cells in and re-run the same schedule. If it comes back, you’re done, and the number in the app was never the point. Keeping decent lithium cells rated for cold temperatures in window-adjacent hardware removed this entire class from our log.
When The Whole Brand Goes Quiet
Small class, five-second diagnosis, worth knowing so you don’t spend an evening on it.
If every shade of one brand skipped and everything else in the house was fine, the fault was upstream of your house. Cloud outages and expired account tokens produce exactly this: schedules stop, manual control often still works — because manual control frequently takes a different, more local path than the scheduler does — and there is nothing whatsoever for you to fix.
The signature is the grouping. Faults that respect brand boundaries are not radio faults and not battery faults. Nothing in your walls knows what brand a device is. If the failure sorts itself by logo, it’s an account or a service, and the fix is to wait, or to re-authenticate, and to move the schedule to a local hub if you’d rather this never happen again.
When Four Shades Are Scheduled And Three Move
This deserves its own section because it is the single most diagnostic thing that can happen to you, and most people read it as the worst news rather than the best.
If you schedule a room of four shades and three of them open, you have been handed a controlled experiment for free. One command, one instant, one clock, one schedule, one internet connection, one hub — four outcomes, and three of them succeeded. Every explanation that lives upstream of the radio has just been eliminated. The schedule fired. The clock was right. The cloud was up. The account was valid. Whatever went wrong, went wrong in the last few metres.
So the question narrows to what is different about the one that missed. In our log the answer was almost always one of three things, checked in this order: it was the farthest from the hub, or it had the oldest cells in it, or it was the only one in the group whose radio path crossed something the others didn’t — a fridge, a foil-backed wall, a wet exterior wall, a floor.
What we want to head off here is the instinct to rebuild the group. A group that moves three out of four is not a broken group. It is a working group with one member who wasn’t listening. Deleting and rebuilding it is a satisfying hour that changes nothing, and we know because we spent it.
The inverse case is worth the same attention. If all four skip together, every time, you’ve eliminated the opposite half of the article. Radio faults don’t synchronize. Batteries don’t synchronize. Four shades failing in unison is a clock, a schedule, an account, or a service — look upstream and stop looking at the shades.
The Shade That Half-Obeys
A smaller pattern, but it wastes a lot of time when it isn’t recognized, because it looks like a mechanical problem and usually isn’t.
A shade knows where “open” and “closed” are because someone taught it, and it keeps track of where it currently is by counting how far its motor has turned. That’s a running tally, not a measurement — nothing in a typical shade actually looks at the fabric and sees where it is. Which means the tally can be wrong. Nudge a shade by hand, let it hit an obstruction, let it slip on the tube, let the motor stall for a moment on a cold morning, and the shade’s belief about its own position quietly diverges from reality.
Once that’s happened, a scheduled “open to 100%” can produce a shade that moves three inches and stops, entirely convinced it has arrived. It reports success. It isn’t lying — by its own accounting it did exactly what it was told.
The signature: the shade moves, but to the wrong place, and the wrong place is repeatable. That repeatability is the tell — a delivery failure produces no movement, and a battery abort produces movement that stops in a different place each time. A confidently wrong destination, hit precisely, every time, is a bookkeeping error.
The fix is a limit reset and a re-teach, per whatever procedure your hardware uses. What we’d add is the part that stops it recurring: if you find yourself re-teaching limits more than once, something is causing the slips, and it’s usually mechanical — a tube that’s not quite level, a bracket that’s working loose, or fabric catching on a frame in one particular position. Fix the cause or you’ll be back.
What Didn’t Help
We think this section is worth more than most of the ones above it, because the internet is a very large collection of confident advice and almost none of it comes with a record of what failed.
Rebuilding the schedule. Our most-repeated action and our least productive one. The schedule was intact in the overwhelming majority of our incidents. Deleting and recreating it produced a day or two of apparent success — which is exactly what you’d expect from an intermittent fault and a hopeful observer — and then the skips came back.
Re-pairing the shade. Occasionally justified, usually not, and it costs you your limits and your group memberships. Re-pairing fixes a device that isn’t on the network. Our devices were on the network; they just weren’t awake at 6:30. Re-pairing does nothing about that and the fault survives it intact.
A better router. The most expensive wrong answer in this failure. If your shade talks a low-power mesh protocol, your router is not on the path. Upgrading it improves the leg between your hub and the internet, which was not where our incidents happened.
Moving the hub “more central.” Directionally reasonable, weak in practice. Moving the hub helps some shades and hurts others, and in our log the net was close to a wash. Adding a mains-powered node in the gap beat moving the hub every time, because it fixes the specific weak leg instead of redistributing the weakness.
Factory-resetting everything. The nuclear option, and a genuine trap, because it works — briefly and spuriously. You lose a full evening, everything is new and clean, and the fault comes back within the week because you never touched the mechanism that causes it. If your reasoning for a factory reset is “nothing else worked,” you haven’t yet found the cause, and a reset won’t find it for you.
The Order We’d Fix Things In
Ordered by what actually resolved incidents in our log, not by what’s easiest to type into a search box.
First, run the two-minute schedule test and watch it. Everything downstream depends on knowing whether the shade moves when the schedule fires, not when you press a button. This one test splits the entire article in half and costs you two minutes.
Second, ask whether it’s wrong by a whole hour or wrong at random. A whole hour is clocks. Random is delivery. This is free and it eliminates half of what’s left.
Third, ask whether it’s drifting gradually later or earlier. That’s a sunrise anchor doing its job. Not a fault.
Fourth, put fresh cells in. Before you rebuild anything. It takes a minute and it clears a class that the battery percentage actively hides from you.
Fifth, add a mains-powered node of the same radio family between the hub and the shade. This was our highest-yield physical change, and it addresses the largest cause class directly.
Sixth, move the schedule to the most local owner available — hub over cloud, onboard over hub — and verify by cutting the internet.
Seventh, fire the command twice. Inelegant, effective, free.
Last, rebuild the schedule. It’s the first thing everyone does and it was the least productive thing we did. The schedule was almost never the broken part.
Symptom to Cause, at a Glance
| What you observe | Most likely class | First thing to do |
|---|---|---|
| Skips randomly; manual always works instantly | Sleeping device, no retry | Two-minute watched schedule test |
| Only the far shades skip; near ones never do | Radio path | Add a mains-powered repeater between |
| Runs, but an hour off — every day, consistently | Clock or time zone mismatch | Compare phone, hub, and account time zones |
| Time drifts gradually across weeks | Sunrise/sunset anchor | Not a fault — use a fixed time or cap the offset |
| Tries and stops, or moves partway | Battery sag read as an obstruction | Fresh cells, ignore the reported percentage |
| Only fails on cold mornings | Battery sag, temperature-amplified | Cold-rated lithium cells |
| Every shade of one brand, all at once | Cloud or token | Check the service; re-authenticate; consider a local hub |
| Schedule is visibly gone or off when you look | Scheduler lost it | Rebuild — the one time rebuilding is right |
| Skips cluster at 7:00 and 18:00 exactly | Network congestion at peak | Shift the schedule off the round number |
Frequently Asked Questions
My app says the shade is online. Doesn’t that rule out a signal problem? No, and this is the most common wrong turn we saw. “Online” means it checked in recently enough for the system’s taste. It is a memory, not a live measurement. A device can be online by that definition and still miss a meaningful share of commands sent at an instant it wasn’t listening.
Why does the button always work if the radio is bad? Because you are the retry. You press, you watch, and if nothing happens you press again — usually without registering that you did. The schedule fires once and has no eyes. Same radio, same shade, completely different odds of success.
Would a stronger router fix this? Usually not, and this is the most common wasted purchase in this failure. If your shade uses its own low-power radio, your router is not in that conversation at all. What helps is a device on the same radio family, mains-powered, placed in between.
The battery says 60%. Can it still be the battery? Yes, and it’s the trap. That figure is measured at rest. The failure happens under the current spike of starting the motor. Those are different questions, and only one of them is being answered on your screen.
Should I use sunrise or a fixed time? If you want it predictable, fixed. Sunrise anchors are lovely and they move a lot across a season. Most “it stopped working” reports of the gradual kind are sunrise doing precisely what it was asked to.
Is firing the same command twice bad for the shade? A shade that’s already open ignores an open command. It doesn’t re-run the motor. It’s an inelegant fix and a harmless one.
Why did it start after DST? Almost certainly it didn’t start. A time zone disagreement between your phone, your hub, and your cloud account can sit invisible for months and then get disclosed by the one morning the clocks are allowed to differ. It’s a whole-hour error — check for that shape.
Should I just move everything to a local hub? If you can, it removes the internet and the cloud from the loop, which deletes an entire cause class and shortens the path for another. It is the closest thing to a structural fix in this article. It’s also work, so do the two-minute test first and find out whether you need it.
Methodology and Who Wrote This
This page was produced by the Smart Home Guide Editors from a log we kept deliberately, on a reference installation of battery-powered and mains-powered shades across multiple rooms, under conditions we forced rather than waited for. We changed one variable at a time: who owned the schedule, how far the shade sat from the hub, how many walls were in the path, how old the cells were, how cold the window was, and whether the clocks in the chain agreed. We ran each configuration long enough for an intermittent fault to show its shape, because a single observation of an intermittent fault is not evidence of anything.
The ordinal shares in our tables are shares of the incidents we logged, in our building, on our hardware. We have deliberately not dressed them up as precise percentages, because we did not run a sample that would justify that kind of precision and we would rather be usefully approximate than impressively fake. A different house — different walls, different radio neighborhood, different climate — would reorder the middle of that table. We would be surprised to see the first and last rows change places, because the mechanism behind the first row is a design property of low-power radio devices generally, not a quirk of anything we happen to own.
We have no relationship with any shade manufacturer. Where we link to hardware, those are affiliate links and we may earn a commission; the recommendations are the ones that resolved incidents in our own log, and they were chosen before any link was attached. If a fix didn’t work for us, it isn’t here, however popular it is elsewhere.
— The Smart Home Guide Editors