I really hope this is the last post about these. RoboBlinds v1 were very simple. They just rotated the slats. They didn't actually lift the blinds. v2 lifted the blinds all the way up. v2 was a very clever design, almost entirely 3D printed, very compact, but it was annoyingly slow and waaaayyyy too loud. So for v3 I stopped obsessing over size and simplicity and I just used more robust COTS parts. v3 works pretty well. It only raises and lowers the blinds, which is fine. If I can raise and lower the blinds anytime I want, then there's really no need to have the ability to rotate the blinds as well.
The first big mechanical problem is getting the blinds to raise symmetrically. The blinds pull string is actually two strings, one attached to each side of the bottom strut, and if you don't lift them exactly in unison then your blinds get lopsided and look ridiculous. So you need some way of winding both strings perfectly in unison. If you just wind them on a simple cylindrical spool, inevitably they'll get out of sync. So the simplest solution I came up with was to wind them around a double-threaded shaft (a two-start thread, I think is the right terminology). But then we encounter the second big mechanical problem. I need to wind up 3.5m of 1mm string. If I make a threaded shaft with 50mm OD and 2mm x2 pitch it's only ~75mm long, but those thin 1mm strings aren't going to stay in the grooves. They're going to pop out and bunch up in the center. So I need some sort of winding mechanism to keep them aligned with the current thread all the way down the shaft. The simplest solution I came up with that minimized overall size was to simply move the shaft itself to keep the string perpendicular at all times. That's actually really easy to do if you just engage the threaded shaft from the outside, using the same threads that wind the strings symmetrically to move the shaft axially as it turns. But how do you do that effectively with a 50mm OD, 2mm pitch thread? Well, it's not easy. But I remembered a solution from the distant past. There's a mechanism used in older nuclear power plants that I haven't seen used anywhere else called "roller nuts". When you want a large, fine-threaded shaft to move with very, very low friction, instead of engaging it with a regular solid single-piece nut you can surround it with several rollers that have circular threads (not helical) that engage the threads and rotate themselves, sort of like a ball bearing for screws. And that seemed like the perfect solution for this problem. So I built it.
And it worked really well. I was able to put the COTS motor with reduction gear inside the spool and then engage the spool with four little rollers at one end, and the entire package was a little rectangular box about six inches long. Everything was 3D printed except the motor, which was about $10. And it worked really well. Unfortunately, it was really loud. The 12V brushed DC motor with spur gear reduction was loud when unloaded, and much louder when under heavy load. And the 3D printed roller nuts engaging with the 3D printed spool threads were really loud. And the motor was underpowered, so it took like a minute per window to lift the blinds and I didn't want to listen to that thing grinding for three minutes at a time, audible throughout the entire house. So as much as I liked the design concept, it just wasn't going to work in practice. I considered better motors and exotic solutions like urethane or metal roller nuts but it just wasn't worth the effort or expense.
And that takes us to v3. v3 worked in more or less the same way, but instead of engaging the spool threads directly, the spool engages a COTS acme-threaded lead screw. Precise and silent. Unfortunately that means I can't hide the motor inside the spool anymore, so the whole thing doubles in size. In v2 the motor itself was attached to a sliding bearing so it could move axially with respect to the housing. In v3 the motor is mounted directly to the housing and it turns a square shaft, which turns the spool but allows it to slide axially. Then the lead screw is fixed to the housing and the spool climbs along it. About twice the size of v2 in total. But much, much quieter. Quiet enough that if it goes off in another room it won't wake me up. This time I used more powerful 24V brushless DC motors with worm gear reduction and built in motor drivers, which also simplified the control circuitry that I had to build. At this point, the blinds themselves moving up and down are the loudest part, so unless I redesign those (no plans to do so) this is as quiet as it can get.
So that's great. But after we get actuators to raise and lower the blinds quietly and quickly and reliably, how do we control them? I switched from Raspberry Picos to ESP32s a while back. RPi is great, but it felt limited. ESP32 has a larger support community and a wider range of tools and libraries. So I threw together a very simple system to control three actuators (three windows per room) with one ESP32-C3. Three quarters of the blinds behavior is controlled by a clock. The living room blinds open automatically every day half an hour after sunrise and close automatically half an hour before sunset. The bedroom blinds close automatically at the same time, but never open automatically. So I need a manual trigger for those. And I need a manual trigger for the living room blinds too because I can imagine times when I'll want to open or close them manually.
For a while I just had a button on a wire hanging down the wall and I could press the button to toggle the blinds (open if they're closed, closed if they're open). But how clunky is that? I'm a perfectionist. I don't want a cable hanging down my wall. I liked the idea of controlling everything with Alexa, but unfortunately Alexa was way too unreliable. Alexa understood my voice commands maybe two out of three times. And when Alexa didn't understand, it would respond with a long and tedious "I'm sorry I'm didn't understand that, could you repeat it ..." or something similar. A simple beep would suffice, and would let me repeat the command instantly. So the two-second voice control process often ended up taking 30 seconds. If only there were something similar to voice commands but faster and much more reliable that I could implement myself ...
We solved this problem in the 1980s. The Clapper. I started out searching around and buying the parts to make the canonical Clapper circuit. You can google it. It's a textbook circuit example. But it's not very robust or configurable. And there's no reason to build complex filters in hardware in 2025. So after building one and messing around with it for a few minutes, I just plugged a microphone directly into an ESP32 and processed the output in software. I had Claude write up a simple filter to look for volume spikes with a certain timing sequence. For the bedroom blinds, that's a very simple three claps at normal clapping speed. Since I didn't want to accidentally trigger the blinds in the wrong room, I programmed the living room blinds to respond to a slow clap, much slower than the timeout for the bedroom blinds, and that should be fine since I don't expect to manually control the living room blinds on a regular basis.
So far so good. The actuators work great. No problems observed with them. The clap triggers work okay. I'm using a very simply volume/time sequence, looking for three loud moments with quiet before/after/in-between. I also tried a fancier FFT-based solution, but it was a lot more work and not noticeably better. I've had quite a few false positives so far that surprised me at the time but make sense in retrospect:
- dropping a hard plastic jar in the bathroom, and when it fell it hit a shelf, then the counter, then the floor
- dropping a metal bowl in the kitchen
- banging a spoon against a pot to shake food off of it
- hammering an object on my worktable
- coughing loudly
But then I also get some false positives that don't make sense to me:
- running the blender in the kitchen
- running the vacuum cleaner in the living room