*scottstuff*

It looks like Canon’s finally about to announce the long-rumored 40d and 1Ds mk III. They’ve been rumored forever, but they now have product pages at Amazon, so they’re probably legitimate this time:

• Canon 40d
• Canon 1Ds mk III
• Canon EF 14/2.8L II

The 40d looks fantastic–they increased the resolution slightly to 10 MP, which isn’t all that exciting, but they also raised the frame rate to 6.5 fps, bumped the buffer to 75 JPEG/17 RAW images, added their anti-dust shaker, sRAW, 14-bit DACs, weather shielding, and live view. They also completely re-did the AF unit–it still uses the same 9-point format as the 30d, but all nine sensors are now cross-type sensors up to f/5.6; this should make a huge difference in AF accuracy. They don’t appear to have improved the camera’s ISO range; it’s still 100-1600 + 3200, but other then that they seem to have picked up almost every other improvement that the 1D mk III added. I’m impressed; in the past Canon left features out of their mid-range series to avoid competing with higher-end models, but that doesn’t seem to have happened this time.

There’s also a new wireless module, the WFT-E3A, but Amazon doesn’t have any details yet. Presumably it’s a very slight change from the 1D mk III’s new wireless transmitter, hopefully at a lower price point. It doesn’t make a lot of sense to pay $999 for a wireless transmitter for a $1,299 camera. I could actually see myself picking up a 40d in addition to my 5d–it looks like a great camera for taking sports pictures, and the 1.6x multiplier would make my 100-400 lens a lot more useful for bird pics.

The 1Ds mk III is a bit out of my price range at $7,999. It’s up to 21.1 MP now, at 5 fps. It looks like they added everything from the 1D mk III, plus a new UDMA CF module, doubling write speeds with Sandisk Extreme IV and the equivalent Lexar cards. Amazon doesn’t mention ISO sensitivity at all, so it’s not clear if they now support ISO 6400 or not.

Finally, they updated their 14mm lens for better compatibility with the 1Ds mk III. Yawn.

All in all, this looks pretty good. Way to go Canon.

I mentioned last week that I’ve been working on building sort of a lightweight home security system for my house so my 4-year-old daughter won’t be able to sneak out of the house again.

I spent about a day researching possible solutions, to see if there was something simple that I could buy that would make me happy, and I couldn’t find anything on the market that was cheap and would tell me which of my 6 exterior doors had been opened loudly enough to hear from across the house. There’s no point in putting a door buzzer on the basement door if you can’t hear it from the master bedroom. The only solutions that I found were from professional alarm companies, and they probably would have charged me a couple thousand for installation plus $30-$50 per month for monitoring. I’m just not willing to pay that much, and it’s not really what I was looking for–it’s gross overkill for my problem.

So, I decided to build it myself. After a few hours’ searching, I decided to use Perceptive Automation’s Indigo home-automation software for the Mac. It’s commercial software, but I like its user interface and capabilities better then any of the open-source solutions that I’ve seen. It’s under active development, supports just about everything that I need, it’s client-server so I can access it from any Mac I own, and it comes with a nice web interface that I can get to via my phone. I figured that it’d be cheaper to pay the money for Indigo then to spend most of a week hacking away at one of the open-source packages to get them to do what I want. Plus, er, pretty much every open source home automation program that I could find was written in Perl, and I’ve been successfully avoiding Perl for almost 5 years now. The last thing I really want to do is spend a week modifying someone else’s Perl. That kind of thing gives me nightmares.

So I fired Indigo up on an old Powerbook that I had laying around and bought a bunch of hardware from MacHomeStore and SmartHome.com. The important bits are a W800RF32A wireless reciever and a whole bunch of $12 DS10a door and window sensors. The sensors broadcast their state over the air, and the receiver feeds them into my Mac.

That took care of the input side of the equation, but I still needed some relatively cheap way to play audio around my house. I poked around for a while looking at random X10 hardware and radio solutions before I realized that most VoIP phones support audio paging. Since my house is full of VoIP phones and I run my own Asterisk server, all I’d really need to do was write a couple dozen lines of Asterisk dialplan code, and everything should just work. I ended up ordering two new VoIP phones (Grandstream GXP-2020s) because two of the phones that I have are too old to be usable for paging. I probably could have used $45 Budgetones, but I have future plans for the GXP-2020’s big displays, so I decided to spend a bit more for them.

It took me about 30 minutes to unpack everything, install Indigo, and have it receiving data from a test sensor. Each sensor assigns itself a random 8-bit ID when it’s powered up, so the first problem was mapping semi-random sensor IDs onto logical names. Indigo comes with a blob of sample AppleScript for doing this, and it only took me 5 minutes to modify it so that one of Indigo’s internal variables changed state to reflect the state of the door sensor–true when the door is closed and false when opened. Five more minutes and I had a nifty web page with a green blob that turned red when the door opened. A half-hour after that, I had a PNG floorplan of my house that I could use as a backdrop for a bunch of little red/green blobs:

After this, it’s all just a matter of plumbing. First, I modified Indigo’s sensor-handling AppleScript example into something that knows how to talk to Asterisk, using one of the Asterisk/AppleScript integration examples on the voip-info.org Wiki. Here’s I ended up with:

(*
  Door sensor tracking code for Indigo and Asterisk.
  By Scott Laird <scott@sigkill.org>
  http://scottstuff.net

  This code handles incoming security events, maps each numeric
  device ID onto a logical name, and then tells Asterisk to page all
  VoIP phones with a device-specific message.

  Net effect: opening the front door causes "Front door opened" to echo
  throughout the house.

  I'm calling doDialOut directly rather then using an Indigo trigger for 4
  reasons:
    1.  I have the extension name handy here, while I'd have to parse it back out of the variable name if I used triggers.
    2.  Creating an identical trigger for each of 10+ sensors is a pain in the neck.
    3.  We need to do *something* with unknown sensor events, but creating variables for them is pretty clearly wrong.
    4.  My AppleScript is lousy, and I can't get triggers to call doDialOut correctly.
*)

using terms from application "IndigoServer"
  on receive security event of eventType with code devID
    set extension to "unknown"

    -- Map sensor IDs onto logical names.  In a real language,
    -- I'd use some sort of hash and skip the if ... else if ... code,
    -- but I don't see anything suitable in AppleScript.  Sigh.  I'm
    -- stuck writing code in blub.
    if devID is 95 then
      set extension to "frontdoor"
    else if devID is 175 then
      set extension to "deckdoor"
    else if devID is 99 then
      set extension to "stairs"
    else if devID is 201 then
      set extension to "backyard"
    else if devID is 55 then
      set extension to "upgarage"
    else if devID is 155 then
      set extension to "downgarage"
    else if devID is 253 then
      set extension to "slider"
    end if

    -- If we get a request for an unknown devID, then send it on to Asterisk 
    -- so we get an audible indication that *something* happened.  Since batteries
    -- falling out of DS10 modules can cause the ID to change, I'd rather not ignore
    -- these.  YMMV, however.
    if extension is "unknown" then
      my doDialOut(devID)
    else
      -- Indigo variable names are derived from Asterisk extension names.

      -- In retrospect, doorClosed_ is a great name for doors, but not so hot
      -- for doorbells or motion sensors.  Feel free to change this.
      set var to ("doorClosed_" & extension)
      set seen_var to ("lastSeen_" & extension)
      set change_var to ("lastChanged_" & extension)
      set timestamp to (current date) as string

      -- Figure out if it opened or closed.  There are actually 4 different
      -- results that the sensors can return (normal/active X min/max),
      -- but we only care about normal/active.
      if eventType is sec_SensorNormal_min then
        set val to "true"
      else if eventType is sec_SensorNormal_max then
        set val to "true"
      else
        set val to "false"
      end if

      -- Create the Indigo variables if they don't already exist.
      if not (variable var exists) then
        make new variable with properties {name:var, value:val}
      end if

      if not (variable seen_var exists) then
        make new variable with properties {name:seen_var, value:timestamp}
      end if

      if not (variable change_var exists) then
        make new variable with properties {name:change_var, value:timestamp}
      end if

      -- Did the value of this variable just change?
      if not (value of variable var is val) then
        set value of variable change_var to timestamp

        -- If it just changed and it's now false, then send an alert.
        -- The DS10a sensors send a signal once per hour, even if nothing's changed.
        -- So we don't want to alert *unless* something's changed.
        if val is "false" then
          my doDialOut(extension)
        end if
      end if

      -- We need to keep track of the time that each DS10 was last seen.
      -- This way we can spot bad batteries.
      set value of variable seen_var to timestamp
      set value of variable var to val
    end if
  end receive security event

  -- doDialOut tells Asterisk to dial a specific extension using
  -- Asterisk's management interface.  This doesn't require that Asterisk
  -- runs on the same machine as Indigo.
  --
  -- To get this to work in your environment, you'll need to change the IP
  -- address, username, and password, and possibly the contexts and/or 
  -- extension names used at the bottom.
  on doDialOut(extension)
    log "Paging extension " & extension using type "Dialer"
    set expectscript to "set timeout 20;
spawn telnet 10.0.0.1 5038;
expect \"Asterisk Call Manager/1.0\";
send \"Action: login
username: my_username
secret: secretsecret

\";
expect \"Message: Authentication accepted\";

send \"Action: originate
Exten: " & extension & "
Context: security-paging
Channel: Local/all@paging
Priority: 1
Callerid: Security: " & extension & " <0>

\";

sleep 1;

send \"Action: logoff

\";
"
    set results to do shell script "/usr/bin/expect -c  '" & expectscript & "'"
  end doDialOut
end using terms from

In addition to simply monitoring the current state of the sensors, this also tracks their last change as well as the last time each sensor sent out a “nothing’s changed” report. Eventually I’ll add monitoring for this so I can spot failing batteries immediately, and not two months later when I discover that two doors aren’t monitored anymore. Indigo tracks each variable internally, and gives you a handy window for viewing and modifying them:

Once all of that was in place, it was time to add paging logic to Asterisk. I created two new contexts, security-paging to contain the messages that need to be played back and paging to handle the phones. The AppleScript above basically glues the two ends together, sending ‘deckdoor@security-paging’ to ‘all@paging’. Here’s the relevant bit of my Asterisk config:

[security-paging]
  exten => frontdoor,1,Playback(security/frontdoor)
  exten => deckdoor,1,Playback(security/deckdoor)
  exten => backyard,1,Playback(security/backyard)
  exten => stairs,1,Playback(security/stairs)
  exten => upgarage,1,Playback(security/upgarage)
  exten => downgarage,1,Playback(security/downgarage)
  exten => slider,1,Playback(security/slider)

  exten => _.,1,SayNumber(${EXTEN})

[paging]
  exten => all,1,Page(Local/203@paging&Local/204@paging&Local/205@paging&Local/206@paging)

  ; Cisco 7940; no Call-Info support, but you can create a new line and turn on auto-answer on the phone.
  exten => 203,1,Dial(SIP/203aa)

  ; Sipura 841.  It needs a semicolon before answer-after.
  exten => 204,1,SipAddHeader(Call-Info: \;answer-after=0)
  exten => 204,n,Dial(SIP/204)

  ; Grandstream GXP-2020s, although the same config will work for most modern phones.
  exten => 205,1,SipAddHeader(Call-Info: answer-after=0)
  exten => 205,n,Dial(SIP/205)

  exten => 206,1,SipAddHeader(Call-Info: answer-after=0)
  exten => 206,n,Dial(SIP/206)

Then I just had to record some audio files to use for annoucements. The easiest way to do this is just to call yourself up and leave voicemail, and then copy the VM files over into Asterisk’s sound file directory, usually /var/lib/asterisk/sounds. You could get better quality recordings with a good microphone and audio-processing app, but I’m not sure that there’s really a point, given the quality of most speakerphone speakers.

All told, it took me about 8 hours of research to put this all together, and maybe 10 hours to implement it all, including learning a bit of AppleScript. Now I have a programmable system for monitoring my house, and all of the pieces in place for adding X10 or Insteon components as they make sense. It’s all under my control; if I can code it, then I can make it happen.

So, does it all work? Yep–Monday morning it caught my daughter trying to sneak into the garage. Mission accomplished.

One of the things I really like about my Nokia E61 is that it’s not just a cell phone, it’s also a VoIP phone. It includes a SIP client that works with Asterisk, mostly, so I’m able to get by with just one phone at home–incoming calls headed to either my cell number *or* my home number ring to the same phone. Which is great.

Except it all stopped working when I upgraded to the latest E61 firmware a couple months ago. I re-created my SIP settings, but the phone just wouldn’t register with Asterisk. Deleting and re-creating the settings didn’t make much of a difference, and eventually I decided to put off debugging it and wait until I had more time.

So, this morning I spent about an hour and a half trying to fix the phone. I re-configured it using several different configs that I found on line, and none of them worked. They all just generated “Registration Failed” messages on the phone. So I turned on SIP debugging in Asterisk, but it wasn’t very helpful–it didn’t show the phone trying to register at all. So I fired up tcpdump and discovered that the phone wasn’t actually sending any SIP requests at all–it was failing locally without ever talking to the network at all.

So I did a bit more digging, and found a Nokia forum comment that suggests that the upgrade from firmware 2.x to 3.x corrupts the SIP settings, and simply deleting SIP configurations won’t fix it. The poster recommended deleting SIP connections before upgrading, and then re-creating them after.

That isn’t an option for me anymore–I can’t downgrade the phone back to 2.x–but a simple backup/restore cycle (using the built-in backup to memory card option) fixed everything. It took about 10 minutes, but my E61 is now registering with Asterisk again.

It’s been a big year for home improvements–I’ve painted two rooms, replaced the carpet in both, added a new light fixture, torn off a deck, and replaced a fence. Somehow, after all of that, I still feel behind–I need to re-do my back yard and add a new patio before The Dark and Cold sets in for the year.

Before that happens, though, I’m planning on spending some time updating the electronic side of the house. My home asterisk server is getting long in the tooth, and lately it’s been bouncing incoming phone calls. My config files are almost 3.5 years old, and the old thing’s getting kind of crufty, plus NuFone seems to be going through one of their annual crisises.

On top of that, my wife’s perpetually worried about our 4-year-old sneaking out of the house without us noticing–we’ve already caught her playing in the middle of the cul-de-sac once, and since she has no real fear of cars (or strangers, or getting lost), we’d like to add some sort of warning system to know when one of the exterior doors have been opened.

You know what they say–when all you have is a big pile of computer equipment and a credit card, then everything looks like an excuse to buy more hardware and write some code…

So, I have a small mountain of X10 and Insteon hardware due in later this week, and I’m going to set up door monitoring via a bunch of cheap RF door sensors. I’m planning on monitoring everything via Indigo running on an old Mac, and then announcing open doors via auto-answer on VoIP phones using Asterisk. Sounds easy enough, right? I can’t see any indication that anyone has ever done any Indigo-Asterisk integration work, but it doesn’t look all that hard. Along the way, I guess I’m going to have to completely re-write my Asterisk dial plan, because it’s really too crufty to live.

While I’m at it, I’m planning on adding a couple “smart” light switches, just to cut down on the number of basement and garage lights that get left on for days at a stretch. I figure they’ll pay for themselves, eventually…

Hopefully all of this’ll give me something to talk about at MindCamp this year.

I really should have done this nine months ago, but I just don’t have time to devote to my rails-app-installer project, and I’d love it if someone would volunteer to take it over.

This is the installer used in the Typo GEM; it’s designed to make it easy to turn any Rails app into an easily-installed GEM.

The code lives in Google Code; feel free to take a look around.

If you’re interested, then please either send me mail or let me know in person at OSCON this week.

I just arrived in Portland for OSCON. I’ll be wandering around most of the week, but if anyone really wants to flag me down, either send me mail at scott@sigkill.org, or drop by the Google booth either Wednesday or Thursday morning.

I usually avoid promoting products that I’m paid to work with, but I just love this one: Google Gears. It’s an open-source, cross-browser (IE and Win/Mac/Linux FF for now) plugin that provides a bunch of enhancements for developers of AJAX apps. Most importantly, it lets you add offline support to your AJAX apps without requiring a rewrite or fork. You just replace your existing XMLHttpRequest calls with a wrapper and off you go. The wrapper’s designed to fail gracefully if the plugin’s not available, so one set of code will work for everyone–with or without the plugin, online or offline. Presumably someone will integrate this into Prototype and other JS frameworks shortly, making it easy for thousands of developers to build offline-enabled web apps.

That’s not all that Google Gears is good for; it also includes Javascript thread support and an in-browser SQL database. I’ll let you use your imagination on those.

I’ve been watching this develop for the past few months, and I’m really excited about it. I can’t wait to see how people integrate this into Rails and other frameworks.

I can’t make it, but it looks like fun: SuperHappyDevHouse Vancouver this weekend.

Socialtext’ers are descending on Vancouver as part of their annual migration to meet, hack, and plan. They came up with the idea of bringing the Bay Area-based Super Happy Dev House to Vancouver.

Bryght is providing the venue and BBQ space at 1 Alexander Suite 400.

Hopefully I’ll be able to make it back up there for something this summer.

My maternal grandfather passed away this evening after a long fight with lung cancer.

When I saw him last week, it was clear that the end was near, but I’d hoped to be able to see him one more time.

I spent most of today trying to catch up on the three weeks’ worth of yardwork that I’d missed while I was in California. I didn’t make all that much progress, but along the way I spotted a few photogenic wildflowers growing in the middle of my back lawn. I still don’t own a real macro lens, but I bought a Canon 500D close-up lens last month before my trip but never had a chance to use it. So took a break from the yard work, slapped it on the 100-400, grabbed a couple flashes, and headed out into the yard. Here’s my favorite:

All in all, I’m pretty happy with the pictures. The 100-400L plus 500D gives roughly 1:1 magnification at the long end, with way more working distance then I’d expected. It may actually be too long for this sort of photography–I kept having to back up to give myself more room between the lens and the flower, especially at the long end of the lens. Fortunately, my 7-year-old assistant was able to keep the light on the flowers, even as I kept backing further and further away. Good help is hard to find :-).

One of the things that I’ve wished for in Lightroom is a focal-length histogram. I’d love to be able to select a bunch of pictures and ask “which focal lengths did I use most often?” I mean, I know which lenses I use most often, but which focal lengths do I actually use?

Fortunately, it’s not too hard to do this outside of Lightroom. Just turn on XMP auto-exporting and then use the usual set of Unix tools to summarize a few thousand XML files. I used something like this:

  $ find . -name '*.xmp' | xargs grep -h 'exif:FocalLength' | 
      cut -d '>' -f2 | cut -d '/' -f1 | sort -n | uniq -c

That finds all of the .xmp files in the current directory (and subdirectories), extracts their exif:FocalLength lines, then extracts the actual focal length number, sorts them numerically, and then counts how many occurrences of each focal length it sees.

I ran this over all of the pictures that I took while on vacation, and found a couple interesting patterns. First, I usually shoot with lenses at either their short or long end; the middle of the range gets a lot less use. My most common focal lengths were

A graph is (as usual) a bit more informative:

I shoot a lot of pictures in the 24-100mm range. 70mm is the most common, but the 35, 45, 55, and 65mm lines are all pretty big. It looks like I use my 24-70mm lens in the middle of its range quite a bit, while my longer lenses mostly get used at their extremes.

After 15 days on the road, I’m finally back home. We drove down to San Diego for my sister-in-law’s wedding, and then drove back slowly, spending a couple days in Sequoia National Park along the way. I really enjoyed the park; after spending a week split between LA and San Diego, it was nice to get away from the crowds. Not that the park was completely empty–we saw 3 of these guys:

From a photographic standpoint, the trip was a success. I’m not going to claim that I produced any great art, but I enjoyed myself and gave my new 5D and 100-400 a workout. I feel like a photographer again, after months of almost no photography at all. I probably went a bit overboard this time–according to Lightroom, I shot almost 4,100 frames. Most of those were kids-at-Disneyland snapshots or wedding pictures, but there were a few that stood out for me:

Strangely, most of my favorite shots were birds; I’m not quite sure how that happened. I’ve never been big on birds before. I’ll post more details once I’ve finished unpacking, and once my last few pictures have finished uploading to Flickr.

At $384 (plus shipping and tax), I think this is the cheapest way to buy a legitimate, non-educational copy of Photoshop this week:

1. Buy a Wacom tablet. Pretty much any current model will work, including the $85 Graphire 4x5.
2. Once it arrives, grab the Photoshop Elements 3 license key out of the box. Then follow the directions on store.adobe.com, and call Adobe Customer Service at 1-800-833-6687 to order Photoshop CS2 for $299. This only works for Wacom’s copies of PS Elements. The sales rep that I talked to had a hard time finding the deal in their database, but he did find it eventually. There is no expiration date listed.
3. Once CS2 arrives in the mail, call Adobe’s support line again and order your free upgrade to Photoshop CS3, as per Adobe’s CS3 FAQ. I can’t guarantee that this will work, but the Adobe phone sales guy that I talked to this morning claimed that the copy of CS2 that they’re sending me is eligible for the “I bought CS2 after CS3 was announced” free upgrade.

Enjoy.

Update (4/16): My copy of CS2 arrived successfully, so I registered it and called Adobe’s sales line. After almost an hour on hold, they took my credit card number and charged me $6 shipping to send me a copy of Photoshop CS3. Mission accomplished.

Update (4/25): CS3 arrived today as expected. So yes, you can buy a perfectly legal copy of Photoshop CS3 for under $400, over $250 off the usual price, and get a Wacom tablet for free.

Wow, apparently InfoWorld has decided to stop printing the paper edition, and focus entirely on their website.

It’s been a long time since I last saw a printed InfoWorld, but I had a subscription to it for years, starting in 1985 or so, and I remember looking forward to its arrival every week. I went through a phase where I was anxiously skimming through each issue to see if Apple had announced anything new and exciting the previous week. Compare that with the anxious coverage that stevenotes get today, and it should be pretty obvious why the paper version of InfoWorld was doomed–there’s really no point in reprinting week-old news anymore. I stopped reading it years ago, when I realized that the once-per-year phone call from their free subscription renewal people actually cost me more then the entire year’s subscription was worth.

I was looking at my Flickr account last week and realized that I hadn’t taken any interesting pictures since October of last year. The only new addition to my account in five months was a roll of high school reunion pictures from 2000 that I’d found while cleaning my office. I’ve always had a hard time finding worthwhile subjects in the dead of winter around here–it’s cold, dark, and wet, and not in an interesting way, but five months without a single good shot is just depressing. I think I’m generally happier when I’m out taking pictures, so I’ve been taking a few steps to make sure that this doesn’t happen again.

The first thing that I fixed was my bad case of photographic constipation–I had gigs of older, unprocessed pictures piled up on a couple laptops and a flash card or two with no easy way to get them processed and posted. I didn’t really have a good place to keep all of my pictures, and the disorder was making it hard to create anything new. So, as part of my ongoing office cleaning project, I took my old 17” PowerBook, plugged it into a 300 GB FireWire drive and a 24” LCD, and dedicated it to photo processing. I haven’t finished uploading everything to Flickr yet, but I’ve organized a huge number of pictures.

Once that was fixed, I headed out and took a few pictures. Last week I spent a few hours taking helping my sister-in-law and one of her friends with their beauty school portfolios, and today I took both kids on a 2-mile hike through the Snohomish Estuary.

Today’s hike was kind of a special occasion for me–I’m planning on retiring my old Canon D60 tomorrow, after 5 years of faithful service. UPS says that my new 5D is due tomorrow afternoon. The D60 was an amazing camera when it first hit the market–it was the first consumer-priced DSLR with enough pixels to be truly useful. It takes great pictures, as long as your subject isn’t moving and you have lots of light. ISO 100 is clean and crisp, but noise is clearly visible even at ISO 200. By ISO 400 there’s very little shadow detail, and most of the shadows have weird color casts. I only use ISO 800 when I have no other choice. I’m looking forward to the 5D’s usable ISO 1600 and 3200, along with a modern autofocus system and all of the other little improvements that Canon’s made over the years.

I’ll have a couple days to break the 5D in, and then we’re taking off for San Diego for a family wedding. We’re planning on driving the slow road back, stopping in Death Valley and Yosemite, so I should have lots of opportunities to take pictures of non-cold, non-dark, non-wet subjects.