Doing the Christmas Lights Webcam/Webcontrol for Real!

I've had thousands of christmas lights at my house since 2000 - it's a big hit for all the neighborhood kids/families - so in 2002, I decided to add a christmas webcam where folks on the Internet could not only view my lights, but turn them on & off and see the webcam results on their computer screen. It got more & more popular each year, and in 2004, a media frenzy erupted over it and the story went around the world on the Internet, in print, on radio, and on TV - here are some nifty christmas movies including me doing a live report for the Denver ABC-7 6:00 News ... a 1,000 feet up in their helicoper! ;-)

Only one problem - it was all a fun little christmas hoax. The lights were real, but a sequence of still images were used to provide the illusion that people were changing 'em. My wife was changing the lights when the chopper was overhead, but the rest of the time they never changed! I approached the Wall Street Journal to fess up, and after they broke the story, there was another round of international publicity and countless laughs from bazillions of people around the world, although there were a few bruised ego's in the media.

So everybody has been asking me what will I do to top this in christmas 2005?
What if I did it for REAL - think anyone would believe it?!? ;-)

Remember that the best hoax stretches the imagination, but doesn't break it. So while what I did was quite doable, there are some real challenges for the individual homeowner. Since 2002 (when I first did this), people would say "great idea Alek and I'm going to wire up my lights with X10/webcam too" ... but I have yet to see anyone do it anywhere close to the degree I demonstrated ... so pulling it all togather is not as easy as you might think. But just for grins, lets walk through some of those issues.

Misc. Issues with Doing the Christmas Webcam/Webcontrol for Real

  1. Wife/Family: #1 is getting approval on the home front, as this is a hefty distraction from family life. Plus if the lights really are going on & off like crazy, that can be a bit bothersome to folks that live there. My wife may put up with my nuttiness for one more year, and my guess is the kids will say it's crazy great; so I think I'm OK there.
  2. Neighbors: How would you like to live across a street with thousands of blinking christmas lights? And rubber-necker traffic can be an issue - for instance, there is an awesome light display in Broomfield (about 20 minutes away) that attracts hundreds (thousands?) of visitors every night, they must have darn good neighbors. I've actually read news reports about lawsuits that have ensued over christmas lights - yikes. Fortunately, I have pretty good neighbors ... and I try to be neighborly myself, even though they vandalized my snowman one year! ;-) They have not only said they would be OK with (real) blinking lights, but are OK with me mounting a webcam on their roofs - really nice people who have the Christmas Spirit if you ask me!
  3. Real World Analog Stuff: I didn't have to worry about 90 MPH winds (yes, those happened in mid-December/2004) blowing my lights all over the place. Well actually, it did ... but (as least according to the webcam), I got 'em all put back in the exact same spots by that night; dang I'm good! BTW, I did have some "random motion" in the webcam image that increased as the wind speed (I wget'ed data from a local weather site) picked up. But hey, let the wind blow and shake the webcam (I just gotta mount it well) and people will see it ... welllll ... for real! I also never had to worry about rain/snow blocking the view or moisture on the lens. Real world anomolies are normal - I'll have to work through 'em, but web surfers should accept that stuff happens.
  4. Buying/putting up the lights: I got plenty of lights (check out my basement crawl space where I plan to store 'em) as I buy 'em at the post-holiday sales for 75% or even 90% off - good thing, because my wife (rightfully so) doesn't see my investment in christmas lights leading to an early retirement. Some of my lights are getting a bit dodgy - my colored icicles may not make another year and I wasn't able to score any rope light on good sales last year - one can be fairly creative with that stuff. It's a lotta work to actually put the lights up (myself and family do this every year ... and the takedown), especially if I go for over 10,000 of 'em, and I don't like to repeat a theme. While it would be funny to just put a "ON & OFF - REAL?" display on the front lawn, I'll have to do something more Christmas'y than that.
  5. PowerLine Control Technology: I really did (!) have my lights controlled by X10 - there was just no interface to the Internet ... and no, I'm not going to tell you my "House Code", since I have a wireless receiver/transmitter and you could drive by and turn my lights on & off! ;-) This was useful because it automatically turned my lights on at 4:30 every day and turned 'em off at 10:00 in the evening. And with the wireless key fob, I could let kids (and reporters!) turn the lights on and off, plus it's what my wife used when the ABC-7 chopper was overhead, which incidentally was the only time the lights really blinked. X10 has been around forever and does the job, but it's a bit slow (maximum update rate is one/second), the signals occasionally are dropped, and I don't get status information back from my outlet/appliance modules. I certainly could do X10 again in 2005 as there are Internet addressible interfaces. However, I've read about some wireless control technology (basically 802.11 gear in an outlet) and there is also a newer powerline control technology called UPB that promises great reliability, pretty fast (5 times/second), and status information. So I'm not sure which direction I should go - I'll need less than a dozen outlets and appliance modules, and since I installed the original X10 stuff I should be able to pop whatever I go with in place. Note that whatever is picked must have some sort of computer interface - i.e. ideally a Linux box that will be at my house that the web server at the ISP can send commands to that toggle lights and report status.
  6. Webcam Stuff: Since this never really existed in 2002-2004, it's the area that needs the most work.
    1. Webcam Internet connectivity: Since the webcams (Notice the plural use of the word - would be really cool to have more than one!) will be mounted across the street, the plan would be to use wireless to send images and control the webcam. 802.11g currently reaches over there, but is prone to interference (for instance, microwave ovens also operate at 2.4 GHz) - from what I've read about 802.11n, it really ROCKS for increasing range/stability, but that standard hasn't been formalized yet, but my guess is that 802.11g will probably suffice; although I may need to add a Pringle Can attenna or something. Wireless bandwidth should not be an issue since even a Mbit/second should be plenty - the choke point is actually the uplink speed with Comcast. This was recently upgraded from 256 to 384 Kbits/sec (40 KBytes/second tops), so that has some bearing on image format, size, and frame rate. One nifty approach might be to have the webcam uplink using my neighbor's cable connection, which if more than one webcam, would be a nice load balancing, and also address some of the wireless range issues. Comcast also has a "gold tier" service where they offer 768 Kbit/sec upstream, which might be needed. I don't expect the control transmissions (to the webcam or the lights) to consume much bandwidth and those should not be an issue. I doubt anyone is doing to run an OC-12 line to my house (that would be nice), so beside Comcast (which oughta work), any other clever ideas out there to put a Mbit/sec or so of image data upstream toward my web server? Should be doable with Comcast stuff, but if you happen to work internally at Comcast and can help, drop me a line.
    2. Webcam Image format/size/frame rate: As mentioned above, there are contraints on the uploading of the image(s) from the webcam(s) itself to the webserver, which then provides images to the general public. My guess is that 640x480 will probably end up being the size (as it was demonstrated in 2004) but not sure if I should stream video (what format?) or use refreshed JPEG's? Motion JPEG looks kinda interesting since you aren't dependant on the previous frame, so you always have a "good" image, but you don't get the inter-frame compression. Since the image doesn't change too often, my guess is that a frame rate of one/second may be acceptable, but faster is always cool if doable. One is also constrained by the exposure time to obtain a good image - see below.
    3. Webcam PTZ control: For 2004, people were able to Pan/Tilt/Zoom (PTZ) the webcam ... or at least think they were! ;-) While I used a queueing system that limited PTZ updates to one/second, the webcam would still end up "swinging" wildy all over the place when things were busy. There are real-life PTZ webcam's (although not sure of any yet that have sub-second full-range PTZ capability as I demonstrated!), so it would be cool to have this capability for real. Adds some complexity and an inbound communication channel to the webcam, but should be doable; especially since the web server front end has all this code already. See discussion below about the privacy issues with being able to zoom and identify things.
    4. Webcam Image Quality: In 2004, the sequence of stills were shot with a Canon 10D DLSR; a leading edge $1,500 camera in terms of image quality. 1/4 second exposure times were also used to minimize noise - in fact, some people noticed this saying "he must have darn good webcam" even though I added a couple of hundred pixels of noise on the final 640x480 image to make 'em more realistic. While that image was a crop/resize, it still had really good image quality and I'll be curious to see even with optical zoom if a leading-edge webcam can approach that image quality, especially if I'm willing to go with longer exposure times.
    5. Shoot large resolution images and simulate PTZ: One funky idea would be that if the webcam was able to take reasonable quality high resultion (probably at least 1280x960) images, then simply transfer those to the web server, and (based on user input), do a 640x480 crop/resize of the appropriate area and present that. I.e. just like in 2004, the webcam never moves, but a portion of the picture is shown. Heck, some high-end DSLR's have wireless attachments, so you could mount a DSLR up there, control it remotely, and process the image as I did earlier; although the net effect as a webcam would be a bit laggy. I don't think I want to do this, but it would be one way to do PTZ! ;-)
  7. Web Server Bandwidth/Capacity: Remember that web surfers never talk "directly" to the webcam or lights, but to the webserver, which handles queueing, control, data-flow, etc. and then ends up sending the surfer updated page information with the latest image. Streaming video is cool, but a whole new level in terms of bandwidth than used for 2004. For instance, I was sending about 20 KByte images (with a 10 KByte HTML page) which could (IF you clicked on the webcam update button) get updated once/second. Multiply that by 300 people and you have completely saturated a 100baseT line. In actual practice, I still had a bit of room to spare, since I required surfers to click to get a new image update, plus I limited how many times you could do it in a 5 minute interval which greatly throttled things. Now lets say I have streaming video - that's like all those people continually hitting update every single second, plus I've heard some people just leave multiple webcam browser windows open all day long. For Christmas/2004, the Slashdot Effect resulted in a peak rate of over 10,000 people in the first hour of posting on /. (and Fark). While my web server handled it pretty darn well (thank you mod_perl!), I should try to come up with some solution to handle this influx and degrade gracefully, maybe limiting webcam time as a function of number of users (?) My web server is hosted at ThePlanet who have a major datacenter and have rocked - they might be willing to help me out with some surge capability.
  8. Privacy: While I have talked about this in christmas FAQ, it was never an issue before because in taking my still pictures (and even some of the christmas pictures) I always made sure there was no unsuspecting people clearly identified; although I digital inserted shadows of people to enhance the realism. However, with a real webcam (especially one with optical zoom), you could potentially zoom in on some unsuspecting person to "watch" them. The good news in my case is that the field of view is basically my house/property, and since I allready have an ADT sign up for the security system, that seems like a reasonable heads-up to folks. I always showed the lights at night (much easier to spoof!) which you probably wouldn't be able to identify people anyway with a real webcam, even with decent zoom. But daytime is another matter, so I'll have to give this one some thought ... maybe for those obnoxious Internet users, I'll "moon" 'em on the webcam! ;-)
  9. System Integration: Don't underestimate this! Countless big companies have spent bazillions of dollars on projects to integrate proven technologies and have failed. Argueably one of the more difficult aspects of computers (software, hardware, etc.) is getting it to all talk to each other. On the other hand, I got quite a few pieces to work in 2002, 2003, and 2004 ... or at least good enough to convince a lot of people and the mass media it was real, so maybe I stand a chance on that one! ;-)
  10. Does Alek want to do it? It's a lotta work, but my reasons would be the same as before: an interesting technology puzzle to see if I can pull it off, and a chance to spread Christmas cheer. Ironically, I had a neighbor I hadn't met tell me just last night (early April) that they hope I do it again for that exact reason. On the other hand, I've gotten a small percentage of negative Emails (you can never please all the people all the time - oh well) and those kinda suck, so I just can't let those get me down. I did (and continue to receive) TONS of positive Emails from folks and those I really appreciate - gets me pumped up to do it - the #1 thing everyone keeps saying to me is - "You gotta do it for real Alek!"
Thanx for reading this far and send me an Email with your ideas.

Webcam/Webcontrol System Architecure

Webcams are mounted on the neighbors roofs (note plural!) and maybe also on my house, although the later will require a wide-angle lens. While one house has a big barking dog, I'll probably have a webcam watching the webcams as a theft deterrent - read this great story about how Duncan Grisby caught a burgler red-handed with his. The webcams all get local power from the respective house they are in (I'll probably add a cheapo UPS to 'em for some surge and brownout protection) and use wireless to communicate; 802.11g or (ideally) 802.11n if available. They'll send image information and receive commands directly from my web server using my Comcast Cable line. They recently upgraded to 384 Kbps, so I might have to pay the $10/month extra for 768 Kbps, or have 'em use my neighbors for uplink purposes.

The powerline control is all in my house, so some sort of central box will communicate to/from the web server, and then send commands and get status to/from the various outlets using either a wired or wireless technology. This ideally will be asynchronous, but it should be low enough bandwidth that I could do polling if need be.

The web server (physically located in Dallas with about a 30 msec latency to/from my house) handles the (potentially) bazillions of web surfers. A front-end CGI handles all of them and queues up the requests which are then communicated via a back-end which gets the updated images and data. I.e. web surfers NEVER communicate directly to the webcam or light controls - this would completely overload the Internet connection into my house, the webcam, and the powerline control which probably aren't designed to have dozens of people a second try to fiddle with 'em. I wrote a couple thousands lines of Perl to do the demo so the front-end CGI would not have to change that much, and the back-end would still be an "image generator" ... just doing it for real now! ;-)


Thanx for reading this far and send me an Email with your ideas.