Been chipping away at a little e-ink reader build lately and hit a snag I can't quite wrap my head around. The case I printed has a slide switch for power, the kind that stays where you flip it. But my code was written around a button that springs back after a press, so it just waits for a quick tap to wake or sleep. Now the two don't agree and the sleep behavior is all over the place. Sometimes it sleeps fine, sometimes it wakes straight back up because the switch is still sitting in the on position from before. I'm guessing the clean fix is rewriting the firmware to watch for state changes instead of press events, but I keep second-guessing myself. Am I overthinking this? Is there a reason anyone would stick with a momentary button on a reader instead, like accidental wake in a bag or somethig? The slide switch felt nice and deliberate when I picked it, but now I wonder if that was a mistake. Also curious how people handle the printed cap over a switch like this. My first attempt has so little clearance that the cap drags on the case wall when I slide it, and adding more gap makes it feel loose and wobbly. Did anyone else go through a few tries before it felt right, or is mine just badly sized?
Is it normal for a latching slide switch to fight with firmware that expects a momentary press?
Oct 12, 2026
Last reply: 8 hours ago
5 Replies
First reply
You're not overthinking it, edge detection is the right fix. Don't check wether the switch is on, check whether it just changed. Keep a variable with the last reading, compare it to the current one each loop, and only act when they differ. Add a small delay or a couple of…
Read the full replyYou're not overthinking it, edge detection is the right fix. Don't check wether the switch is on, check whether it just changed. Keep a variable with the last reading, compare it to the current one each loop, and only act when they differ. Add a small delay or a couple of repeat readings before you trust the new state, because slide switches bounce a bit as they settle. That gets you the same wake-or-sleep behavior you coded for the button, and the switch position itself stops mattering. It's maybe twenty lines of change, not a rewrite.
One thing to decide early: do you actually want the switch to control sleep, or woud you rather it cut power for real? A latching switch wired to a power circuit is honestly the nicer option for a bag, since nothing can wake the device accidentally, no matter what the firmware does. Plenty of readers do it that way, power switch is physical, and the momentary button handles wake and sleep in software. If your board supports deep sleep wake sources you could even keep both, switch for true off, button for soft sleep. Depends how much you care about battery drain vs convenience.
On the cap, yes, went through three or four prints before mine felt right. The trick that worked for me was putting the clearance in the slot, not around the cap. Make the walls of the channel slightly wider than the switch body, and let the cap be a snug fit into the switch itself. If the cap slides in a channel instead of floating over a gap it can't wobble, and it won't drag as long as the channel is the generous part. Also taper or round the leading edge of the cap a little, sharp square corners catch on printed walls way more than you'd expect. Print one test piece with just the switch pocket and cap before committing to a full shell, it's cheap and saves alot of guessing.
Agreed on watching for the change rather than the level, that's what fixed my reader too. One thing that bit me: my switch pin was floating when the slider was between contacts, so it gave phantom toggles til I enabled the internal pull-up and grounded the other side. Also I only sample the pin every 50ms in my loop instead of every pass, which settled the bounce without extra code. Curious if your OPDS library holds the RAM tight enugh that you can keep the wifi stack down while you're parsing feeds, mine choked on big catalog pages until I trimmed them.
Following this becuase I'm at an earlier stage with my own little reader, still on a breadboard with no case at all. My plan was actually the reverse of yours, I bought a latching switch thinking it would be simpler, then realized I have no idea how to wire it so it actually cuts power instead of just telling the chip to sleep. So your question about switch vs soft sleep is the thing I need to figure out too. One thing I noticed on mine, when the chip sleeps the screen keeps whatever was last drawn, which confused me for ages because it looked like it was still on. Might save you a panic when testing.
Before all this edge-detection code we used to just hang a small cap across the switch and let the hardware settle itself, works the same on a slider if you're tired of fiddling with sampling timers. On the battery drain side, one thing I learned the hard way on my first reader: a true power cut means your display keeps whatever's on it and your RTC loses the time, so the thing boots dumb every time. For the breadboard guy asking how to actualy cut power, you need the switch on the battery positive feeding a regulator enable pin or a small latching circuit, not just a GPIO. Easier to wire the switch to EN and live with sleep current, honestly.
Update: went with the edge detection approach and it works, mostly. But that floating pin thing someone mentioned was real. I'd skipped the pull-up at first and got phantom toggles whenever the slider sat in the middle. Enabled the internal pull-up and it settled down. Still seeing one wierd blip on wake though, like the state reads backwards for the first second. Anyone dealt with that?
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required