I have automated my curtain.

I built an Arduino dingus so that I can close my curtains from the command line. Wanna see?

Tags: , ,

60 Responses:

  1. Dennis C says:

    Neat project...

    This is why I hate dealing with hardware: since there's no "undo" and no backups, you end up frying things all the time, and then it's just gone. So something that seems like it should be a simple hack made mostly of a handful of $1 components turns into a huge and expensive clown-car mess unless you already have a fully stocked workshop.

    I can see your point. I tried a Netduino project and felt the same way. However the flip side is that writing code that physically moves things also gives me a shiver. All all my other code does fascinating things like add rows to a grid, or draw a graph if I'm really lucky, so debugging thru code that actually does something real is kinda fun..

  2. Eric TF Bat says:

    Is there a word for fear and adulation at the same time? That's what I'm feeling for you right now. You are a disturbing, yet somehow magnificent, individual.

  3. Chas. Owens says:

    What follows is a probably unwelcome and impromptu code review. Please ignore if, as I suspect, you could give a shit.

    Rather than write your own error function in Perl 5, you can just hook into the die signal handler:

    $SIG{__DIE__} = sub { die "$progname: ", @_ };

    Also, you could say

    (undef, my $version, undef) = qw{ $Revision: 1.2 $ };

    But I don't know if that is more readable or less.

    You can avoid the $1 like variables most of the time with code like:
    die "unparsable device: $device" unless my ($host, $port) = $device =~ m@^([^:/]+):([^:/.]+)$@;

    Rather than write your own sleep function, take a look at Time::HiRes:

    use Time::HiRes qw/usleep/;
    usleep $microseconds;

    • jwz says:

      I didn't know the __DIE__ trick, thanks! I had always been using my own error function solely because I hate the default output format that die prints. Error messages from random shell commands should not include line numbers.

      Not using things like Time::HiRes is a poor habit left over from the bad old days when I was trying to avoid ever using a Perl module that wasn't installed by default, since CPAN never worked right for me.

      • Chas. Owens says:

        The die and warn functions don't print the file and line number of the error if the message ends in a newline:

        perl -e 'warn "has location"; warn "does not have location\n"; die "no location\n"'

        The simple rule is: if the message is meant for the user, use a newline, but if the user shouldn't see the message don't (that way the user can report where the unexpected error occured). Even better, using confess from Carp (which has always been core in Perl 5) will give you a full stacktrace. Basically it is the difference between an error message and an assert.

        If you are using a recent version of Perl 5, you can find out when a module was added to the core with the corelist command.

        Time::HiRes has been in the core since Perl 5.8.0 (well Perl 5.7.3, but that was a development release).

        Installing CPAN modules has gotten a lot easier since APP::cpanminus came out. Combining APP::cpanminus with APP::perlbrew solves most of the problems with the admin side of Perl 5 (carton looks like it might solve the remaining ones).

      • nandhp says:

        More potentially unwanted Perl advice: If you put a newline at the end of the die or warn message, it doesn't add the line number.

        die "I can't do that."; # Produces: I can't do that. at filename.pl line 1.
        die "I can't do that.\n"; # Produces: I can't do that.

  4. LafinJack says:

    I know this is utterly beside the point, but how much time did this take vs. how much time do you think it will save?

    • Wibble says:

      Who cares how much time it saves, he's living in the future. The note at the end, that one button push now pauses iTunes, turns on the TV projector, and closes the curtains? That's some Jetsons-level awesome right there. When does the moving sidewalk get installed?

      • LafinJack says:

        That's true. I didn't click through and assumed he was just closing the curtains, and just using it by literally sitting at the computer and typing it into the command line, so that's on me.

    • jwz says:

      What Wibble said, but also, the function of several features of this setup is to help me sleep better, which is not solely a matter of saving time.

      • Liam says:

        I would be interested in knowing what you are doing - that works - in the 'help me sleep better' area, as that is something that I have recently been struggling with, but have no strategies mapped out to work with as yet.

        • jwz says:

          Well, like I said, having the curtains open in the morning helps me get out of bed at a more reasonable time because of the sunlight; and if I'm half asleep and moving from the couch to the bed, being able to turn things off by just smacking a big and easy-to-hit button that's along my walking/stumbling path without having to really open my eyes prevents me from waking up all the way during that trip. I found that if I had to focus my eyes and use fine motor control to turn things off, I'd end up lying there awake for a while.

      • Jon Konrath says:

        This may sound like hippy pseudo-science, but have you looked into a full-spectrum light? I work on east coast time, meaning that here in the bay, opening the curtain has little effect, especially in winter. I run one of those light therapy things for a half hour in the morning, and it's helped immensely in keeping my sleep schedule regular and making sure I don't go postal. No CLI for it yet, but it's on my list.

  5. Travis Dixon says:

    Wait, isn't the Blind controller already speaking X10 (according to the Amazon page)? Seems like getting an X10 computer interface would have been a much simpler solution... though finding an excuse to mess with the Arduino seems like it would have been fun in and of itself.

    • Travis Dixon says:

      Nevermind. Further research seems to indicate that the motor still requires an outboard lamp control module, so not speaking X10 natively...

  6. artag says:

    Glad you got it going, but the article comes over a bit whiny. Hardware isn't that difficult, and it doesn't break for no reason any more than software does. You just need some basic knowledge, a bit of care, and the desire to investigate the faults. Imagine taking on software project with this workflow :

    Have an idea. Needs
    Cast about for a likely library. Spot something that sounds right.
    Flick through the API and spend an hour or two calling a few functions.
    PC bluescreens. Curse a bit, try again.
    PC trashes project and something else you forgot to check in.
    Angrily ditch project
    Try again a few months later, when you hear of a different library. Take time to read a bit more documentation.
    Project sort of works. Crashes often.
    Fix some of the more annoying bugs
    It's a wrap. Bask in enjoyable success

    Now, this is OK for a noob having a first go. But it's not how you'd want to work, is it ? You know doing it right involves several years of experience, some informed planning, and a rigorous approach to failure.
    Hardware projects aren't any different.

    And DHCP ? Or MAC addresses ? You know, the nice thing about open source stuff is that if you don't like what somebody else did, you get to improve it. And then it's better, and everyone gains.

    • erinn says:

      I think his point is partially that because most things don't literally break (and thus become wholly unusable) in software, you can iterate faster and the only expense is time. Software is basketball and hardware is skiing.

    • HalibetLector says:

      If you intend on doing this stuff for a living, sure, spend several YEARS and THOUSANDS of dollars on equipment. It doesn't take several years to learn perl (for example) nor does it take anything more than a laptop (which you already have). Also, the likelihood of bluescreening your computer these days is next to nil. The worst a piece of software is going to do is just not work. You waste no money, just a bit of time fixing the bug.

      Re: the whiny tone - you must be new here.

      • J. Peterson says:

        After doing this sort of electronics stuff for a while, I can attest the investment is hundreds (a few), not thousands. Basic tools and parts on hand will set you back maybe $300 or so (wire, connectors, passives, soldering & hand tools, a decent meter). Much can be scavenged. At some point if you're serious, you'll invest in a scope and/or logic analyzer (another $200-$2K), but it's not necessary for Arduino-scale stuff. CAD software is another investment if you need to get boards made.

        The projects themselves range from free (contest dev kit + eng sample) to $1K or more.

        • DFB says:

          Does anyone sell a good ~$300 hobby electronics starter set? I've been fielding questions from people who want to hit the ground running but don't want to make multiple trips to the store, and I've lost my gear to startups twice (on good terms, but still....)

    • jwz says:

      Glad you got it going, but the article comes over a bit whiny. Hardware isn't that difficult, and it doesn't break for no reason

      I think my only possible response here is, "Go fuck yourself".

      • Richard says:

        Is there some Adafruity way to remotely initiate the box of cocks sucking procedure?

    • Liam says:

      "Hardware isn't that difficult" and "You just need some basic knowledge, a bit of care" is rather oxymoronic with your later statement "You know doing it right involves several years of experience, some informed planning".

      Just because someone can already type doesn't automatically mean they will find soldering easy.

      • artag says:

        No, it's not oxymoronic. In the first statements I'm stating general principles and in the last I'm comparing a learning exercise with the way a seasoned operator will tackle a project.

        My point isn't that it was very easy, or that jwz did it badly. It was that you can't expect everything to work first time - especially if it's new to you - and when it doesn't, a more thorough approach to find the problem usually pays off. Just as in software. It's true that when it breaks, it's sometimes for good (not usually, as it happens). Software can be just as frustrating when you don't know the cause, and in some cases can be equally destructive.

    • relaxing says:

      And DHCP ? Or MAC addresses ? You know, the nice thing about open source stuff is that if you don't like what somebody else did, you get to improve it.

      The proper response to this, posted here, is most definitely, "Go fuck yourself."

    • gronk says:

      The most time-consuming thing is learning how to debug. And question everything. I've debugged a self-etched and soldered PCB for two days straight, as I couldn't find out why SPI (a three-pin programming interface) didn't work. Turned out to be a tiny copper burr which connected one pin to ground. Also, a good old serial interface is golden (hook up a MAX232 to PD0/PD1 on the average AVR and you're set).

  7. Chad Altenburg says:


  8. J. Peterson says:

    Now you just need to get a dog named "Grommit."

  9. Joe says:

    LH's recent Arduino article got me thinking "Hmm..." But now I'm thinking "Meh..."

  10. Leolo says:

    If you ever think of using an Arduino again, let me suggest a Ruggeduino. Also, always look over the prebuilt shields for the interface you need. Lastly, a drawer full of every resistor and capacitor can be had for suprisingly little. Mine cost me less then 50 $ from Futurlec.

    • Christian Vogel says:

      Hey, that's a cool product. Considering the strange things people tend to connect to the arduino pins that go straight to the microcontroller, the added protection certainly is a good idea. I think I'll recommend this to people having those strange ideas...

  11. Thomas Lord says:

    Um... is this going to culminate with some sort of rotating circular bed, instant disco lighting, Mantovoni on surround sound, rose petals falling from an unseen conduit in the ceiling, a mysteriously chilled bottle and two flutes of champaign gliding out of the corner atop a hacked rumba, video projections on three walls of cut-up David Lynch works, theatrical blood squibs, headgear from the cinema scene of Catch 22 with a framed letter of authenticity, contrasting display cases for finely made contemporary German blades and registered historic Japanese blades, a cape, a pet octopus, scented candles, and a well-timed pizza delivery, if you know what I mean?

  12. gryazi says:

    Interesting crowd here. My 0.002941181 BTC is that I prefer hardware over software because you can smell what's burning [and physical products are inherently held to the minimal quality standard of actually maintaining their existence, usually]. I've foregone all the Arduinage because it's usually faster and cheaper and less code-drudgery to just bodge together X10 bits or other surplus, but respect to a project well-done.

    [I also admire how real software heads would, say, casually make that hrr-I'm-on-the-Internet exchange rate derp there update in realtime.]

  13. David M.A. says:

    "I have automated the curtain. Pray I do not automate it any further."

  14. 205guy says:

    Just wait 'til it gets hacked. hrr-drr I'm in your 'duino, hacking your curtainz--or something like that. I will admit I went to see if the MAC address was in the code you released.

    The code also answered a question I had: "The device has a switch on it that adjustable stops on the motor's wheel hit to tell us when we've reached the end. (The wheel flips the switch to the left at one end, and to the right at the other.)"

  15. Bill Paul says:

    "You still have to hardcode the MAC address into the source code, though, which is just idiotic. Instead of the MAC being burned into the hardware, the board has a sticker on it with the address printed on it, and you have to type those numbers into the source."

    Please pardon me for a moment while I punch you repeatedly in the cock.

    Now that that's out of the way, please realize that one does not simply burn the MAC into the hardware. The ethernet controller itself doesn't usually have the address burned into it: instead, there is a separate non-volatile memory chip (usually a serial EEPROM) connected somewhere, and it's up to the driver software to extract the address and program it into the controller's receive filter when you turn it on. When you buy a standalone NIC, look closely and you'll likely see a tiny 8-pin chip that says 94Csomething on it. That's the EEPROM. I have seen a case where the ethernet MAC has fusible links inside and the manufacturer can program the station address as they come off the assembly line by popping some of the fuses, but this doesn't seem to be too common yet.

    In some cases, the MAC address will be stored in flash instead. This is true for boards with several peripherals that need to load configuration data: instead of a bunch of little EEPROMs, they use a single flash device, with different areas reserved for different devices.

    Now, the arduino board already has flash on it (since that's where you put your programs), so the designers probably decided that an EEPROM woudl be redundant. But the issue with the flash approach is deciding where in the flash to store the MAC address. Picking a standard location where it won't be overwritten is tricky when the user (that's you) can reflash the device at will, and potentially scramble it up in any number of unexpected ways.

    So they leave it to the user to decide how to deal with it. If you were going to mass produce your little curtain frobber, you would have to create a provisioning strategy for assigning unique MACs to each unit, but given that you have to flash each one anyway, that would not be too hard.

    "But Bill," I hear you ask, "did you have to punch me repeatedly in the cock to explain that?"

    No. No I didn't. Have a nice day.

    • jwz says:

      "Burn into the hardware" was obviously shorthand for "have this number stored in some tiny piece of ROM that is read when the hardware initializes." I do in fact understand how this shit works.

      You have done a fine job of explaining how a Hardware Person would make a series poor design decisions leading to this idiotic result, but that makes the result no less idiotic, when there are obvious solutions.

      The fact that I have to manually transcribe numbers from paper is an idiotic design flaw. The fact that I have to recompile my source code if I want to run a second instance of the same device on the same network is an idiotic design flaw. I'm sure the designer had a reason for deciding to do it that way. I'm here to tell you that their reason sucked. Given that you can buy an Ethernet jack that contains an HTTPS web server for $65, solving this problem sanely is clearly neither difficult nor cost-prohibitive.

      But thanks for the excellent demonstration that the classic Worse is Better approach of, "Well, I know what the right thing to do is, but that sounds hard so I'll just punt it off to every user instead of solving it once upstream", is alive and well.

      • Rick C says:

        Just in case you ever want to make another device, Micro Center actually carries Arduinos, and there's one in Santa Clara.

        • J. Peterson says:

          I've even seen them on the rack at Radio Shack.

          • Rick C says:

            Huh, that's pretty cool. I haven't been in one in ages. Sparkfun has retail blister-packed product now. I saw them at a local electronics store too (the kind of place that has nothing but aisle after aisle of resistors and relays and the like.)

  16. Chris Davies says:

    Every day I marvel at the popularity of that underfeatured, outdated, power-sucking MCU. Is arduino a ploy to get rid of some vast stockpile of soon to expire ICs or something?

    • Nick Lamb says:

      Things that actually exist always trump the things that are theoretically far better but don't exist, modulo the Osborne effect. The Arduino exists.

      That's why you're using the World Wide Web to read about this, rather than any of dozens of far more theoretically complete distributed hypermedia systems that nobody actually put into use.

      It's why so much stuff is written in Perl and not in some hypothetical super-modern language that isn't actually installed anywhere and doesn't quite work yet.

      And it's why most of those Perl scripts are running on a machine with an x86 compatible CPU rather than a PowerPC or a bunch of transputers or a crystal of pure light energy.

      • some jackoff says:

        There are a thousand superior alternatives to Arduino. The bare AVR microcontroller with no Arduino environment is superior in every application.

        Remember when Visual Basic came out and suddenly, everyone with $299 and Visual Basic 3.0 was writing Windows applications? And there were just so many shitty Windows applications that you couldn't find anything good?

        That's what Arduino is doing. It enables retards to write embedded code. And now that retards-to-be don't know that anything apart from Retarduino even exists, you end up crippling systems that are actually useful and worthwhile.

        Then retards go and claim that they're Embedded Systems Engineers 'cos they made a Arduino Testicle Washer once, and I get fired for some cheaper retard, and I drink heavily and beat my kids. Then the Arduino implanted in someone's chest cavity explodes and kills them and we blame outsourcing or some shit.

        And not that anyone cares, but I write 8-bit microcontroller firmware for a living. Much of it existing inside living people's bodies. Much of it responsible for those living bodies not ceasing to live. I have no limit of contempt for the garbage produced by users of the Arduino system.

        • gryazi says:

          This is the vibe I get while only wishing I'd gotten around to becoming a grizzled hardware engineer, but as the posts above allude to without quite getting at, it's really the Apple vs. Commodore situation all over again. (Do the business-school types have a name for the earliest instance of does-less costs-more winning out?)

          When you dig back into the history, Jobs [and perhaps Woz too, they both weren't stupid] made the decision that he was only going to target people with $N,000 or so in hand. That dovetailed with how much hardware they could actually manage to produce, and how much support they could give, and left enough to blow on marketing to get their foot in the door of the planet.

          Commodore meanwhile was flying MOS guys out there (well, one) to help them bootstrap, while meanwhile being quite the crazy engineering shop internally, with sort of a 'rational' focus on shaving costs while trying to push out More Magic for the money - resulting in a pretty surprising spread of products in their heyday, with subtle technical differences that only an engineer (and sometimes only a CBM engineer - I still look at stuff like all the flavors of the B128, and the admission that 'software compatibility' didn't become a recognized demand until really late in the game - and wonder just what they were thinking). They also had an.. interesting.. approach to support, apparently, and the best line of communications was probably engineer-to-engineer.

          The Arduino dude/dudes bombed the crap out of Make and Slashdot and BoingBoing and so on (don't the operators of all those connect on a sex chart?) with a relatively high-price low-parts-cost product targeting all the individual VB-of-EE types that are both too annoying and too low-volume for Atmel to bother targeting itself. Srs bsns demands you bring at least a clue or an order for a couple hundred thousand parts or preferably both, after all - and if you have a clue you're quietly scrounging whatever you need on your own and not begging for one do-it-all prebuilt breadboard running LOGO. So they've found Apple's niche in the DiY hardware space, and as long as they don't cut themselves off at the knees somehow they'll probably keep rolling for a while. [Biggest competition: old smartphones becoming cheap enough and standardized and low-power enough to run with an even cheaper USB- or Bluetooth-to-GPIO adapter; and the risks of internal motivation to Lisa it all up overtaking the smarter course of trying to get it all into one black-box package and really entrenching it as the good-enough-x86 of controlling your pacemaker.]

          Of course, as far as the software stack, they're already there, because the ability to port whatever looked like it worked in on the bench in the garage to millions of vehicles on the roads (to pick another comforting example) without a rewrite is going to be a big draw.

          [That said, while none of this should be allowed anywhere near anything life-endangering, somehow we still survive in a country where you can potentially buy beer and propane and a chainsaw and a firearm all in one store. If the simplified environment actually makes it any easier for these kids to spot and correct their own little Therac bugs before their garage-door automation project crushes Timmy, I ain't complaining.]

          Why do I even write these posts?

        • Christian Vogel says:

          Yes the AVRs are "superior" (here: less codesize, more versatile, faster, ...) when programmed on the bare metal, but who cares? Just wipe the board, get your gcc/binutils/programmer and you're set.

          Everyone currently wants to join the frenzy, so you can get "Arduino compatible" boards with almost any small microcontroller (i.e. ARM7TDMI with USB2.0, half a meg flash for $30) for almost nothing!

          I'm happy that a lot of people without former electronics-experience can join the fun of building embedded electronics, and if it makes them happy to blink a LED and turn a motor, so be it. Let me enjoy the wealth of affordable hardware I can just purchase for $10 by mailorder instead of having to cook up my own breakout-board while they indulge in their new world of stackable shields that blink and beep.

          If you think those folks playing with things really endanger your job, even though you claim to be working in a highly regulated and quality-assurance-infested area like the medical industry, you are a little bit paranoid.

        • The flip side to that is that the people writing shitty VB programs (and building shitty Arduino projects) previously had no way to turn their ideas into software/hardware. I know there's tons of legacy VB shitware out there. I'm sure there's a lot of amateur Arduino hardware hacks being produced of crap quality. But the alternative is to "leave it to the professionals", which seems like a pretty terrible attitude. Should Jamie not be allowed to automate his curtains just because he doesn't have a degree in EE? I don't think anyone would argue that the person writing the code running on a pacemaker should be the best of the best, but do you really think people fiddling with Arduinos are endangering your job? I (as a professional software engineer) am certainly not worried about people writing VB.

        • hattifattener says:

          You write this as if professional embedded systems engineers somehow weren't turning out reams of crap code and flaky systems already. It's been well over a decade since I had a job that involved looking at other peoples' professionally-written firmware, but the old adage about sausage and the law applied in spades. You can tell at a glance that most Arduino code is not written by experts, but somehow it still compares pretty favorably.

  17. Tyler says:

    "So I ordered one of those, and threw away all of the work we had done so far."

    I hope nobody was trying to reproduce your work by reading your post chronologically as instructions.

  18. Paul says:

    Blowing up crap left and right, trying to make the almost right tool work, and endless hardware nonsense is why I am a member of a hackerspace. I don't get there much since I have an adorable, playful little parasite anymore, but being able to get to a point in your project where you blow something up, or can't quite solder on that cursed part that digikey only sold as surfacemount because under a magnifying lens your hands look like they shake more than michael j fox, there's always some hardware geek trying to figure out his perl script, and I can skill trade for 20 minutes to get that stupid part on the board.

    My local one also has a well stocked parts lab including more MCUs in case you blow up your ardunio.

    Your local one was founded by mitch altman, who doubtless curates a very nice selection of electronics stuff.

    All hackerspaces I've ever been in welcome non paying guests, even ones that don't have their own wikipedia entry. Not useful now that your project is complete, but for your next project you may want to lazyweb your way into there (or just wander by, if it's close enough) for the construction phase

  19. Lexein says:

    As others have noted, the Wiznet chip is MAC-address agnostic. I agree that it would have been nice for the Arduino folks to preburn it into the ATMega's (usually fucking unused 1K) EEPROM in some nice high address area. Just so it's there if people want to reference it.

    I'm guessing a word from you/us might convince them to sequence & store a MAC address at final test, instead of (or in addition to) printing a silly label.

  20. chris t says:

    People who tell you how easy this crap is are invariably people who already have a drawer full of every resistor, capacitor and relay known to man, instead of having to spend days waiting for the turnaround on ordering the components they need.

    Yeah, I've spent several months iterating that loop on a couple of simple projects. (Plus feature creep, because everything needs a soft power button.) I feel the same way about cooking. And food goes bad on a timescale that, by salaryman standards, is terrifyingly aggressive.

  21. Nice reversing control circuit using the relays... I've borrowed it here for a class I'm teaching.