Halloween & Christmas webcam FAQ

Last Updated October 18th, 2007 Click here for the main christmas lights FAQ.
Note that this FAQ is a bit superceded by this disclosure ... although the same principals still apply. For 2005, I ante'd up the big bucks for a D-Link DCS-6620G wireless webcam that generates a 704x480 JPEG image that is FTP'ed to my web server and then re-broadcast from there. It can generate an MPEG4 video stream, but I haven't figured out how to rebroadcast that ... and neither do the guys at D-Link - drop me a note if you know how.

So you want to build your own webcam and webcontrol?

First you need to know a little bit about X10, which is a protocol for sending signals through your house wiring via the A/C sine wave. It is not the annoying company/internet site x10.com - yes, they are the company with the annoying pop-up ads talking about their latest wireless webcam that shows scantily clad women! ;-) Although in fairness, this was the "old" X10.com as I haven't seen these ads in a while.

What's really nice about X10 PROTOCOL is that it uses the existing wires - so you don't need to re-wire anything except the outlets/switch/whatever. And you can also do stuff like plug a wireless receiver, a dusk/dawn light sensor, control unit for timed events (I have all of these), and other misc. into a power outlet, which can then receive/send signals through your house wiring to the lights. You assign codes/zones to various outlets and control them individually or as a group. One minor issue with the upcoming LED Christmas Lights is since they draw a lot less power, X10 may have difficulty with that for small number of strings on a controller.

So my lights are plugged into X10 outlets. Remember that I allready turn the lights ON and OFF (for the day) automatically via a control unit - actually two of 'em for redundancy! ;-) One is plugged in at the garage and other in my office. And I allready mentioned on the main web page that I like to "mess with kids" by using a wireless fob to turn them on/off in real-time; this works by sending a signal to the wireless receiver which then tells the outlet to turn itself on/off - stupid geek tricks, eh?!?

Note that X10 is (basically) a one-way protocol. You send commands to the devices and you hope/assume they are done. While some of the newer, more advanced modules have a query capability, I just have the old, cheap stuff. So there is no way for me to find out if something is on or off - you just have to look at the webcam to see the live coverage and find out! ;-)

All of the above is "old news" and I've had it operational for a couple of years. It's simple and it works (almost all of the time ;-). So how does one add webcam and webcontrol functionality?

The webcam can be obtained from a variety of vendors; just don't use it to shoot pictures of scantily clad women, OK? Then you have to find a location where you can good a good view of the lights - a tree or roof location across the street would work well, but you need your neighbor to allow this and provide power. Communication to/from the webcam is typically done via Ethernet or wireless - obviousely, the later is preferred for this application. Note that some webcams are addressible via the network - and I even read about a webcam that will do 1024X768 at 15 fps, hopefully your lights aren't being updated THAT fast! ;-)

The 2002 webcam generated an image that was 480X360 and was fixed (i.e. not pan'able - no movement) without any zoom. For 2003, the image generated is 640X480 and there is Panning capability - i.e. it has the capability to slew 15° right & left and 10° up & down of center. It also has 2X optical zoom capability, and 2.5X digital zoom for a total of 5X ... although we all know that digital zoom is bogus since all that does is make the pixels bigger. It can also optionally tag the images with these current values. The webcam seems to be fairly precise/repeatable when it points somewhere, but it does move around a bit, especially if the winds are gusting. This is, of course, even more noticeable if you are zoomed in.

So when it's time to take a picture, you simply request that, and it returns a JPEG file (time-stamped with the other info). i.e. optionally send the pan/zoom commands to the webcam, wait for the webcam to adjust and then verify settings, and then snap the picture. That's it - pretty simple, and not much different than any old security camera setup.

The webcontrol requires one more device - an X10 "dongle" that connects (typically serial or USB) to the computer and then plugs into wall power. So after the Perl/CGI script on the web server validates the input/selection (such as "TURN OFF #2"), that X10 command is sent to the dongle, which then is sent through the house wiring and the outlet turns off. You can then verify that the command took (resending if needed), and then you are ready to ask the webcam to snap the new image. Note that the Perl/CGI script simply requests status info on the various zones to show which ones are currently on or off. Again, not so difficult, 'eh.

The software is the "fun" part. For 2005, there is a mod_perl CGI program that handles all the web requests ... and then does a back-end command to a Sony Viao laptop at my house. This then turns around and runs the "flipit" command which causes the X10 serial interface Firecracker device to send a wireless command. Lotta stuff, but actually works pretty reliably. In previous years when it was a simulation, there were two programs (each that have bloated up to a few thousands lines) written in Perl. One is the CGI script running on an Apache Web Server on a Red Hat Linux box. For Christmas/2004, I got this working using mod_perl, which is a huge performance improvement. On the 2.4 Ghz Xeon (with Gigabyte of RAM), it can now sustain about 20 requests/second ... whereas using cgi_exec, it topped around around 4. This program provides the web interface that the surfer sees, and handles all the communications/etc. behind the scenes so that you see a pretty picture! The second program is a "daemon" program that handles the interface between the CGI and the lights/webcam - uses UNIX signals to communicate. Among other tricks, there is a 1-second "throttle" that limits how frequently the lights can be changed - X10 is fairly "slow", and it is not possible to change the lights much faster than this. The server croaked from the thousands of connections from a Slashdotting in 2002 (on a 1 GHz, 128 Mbyte PC, and T-1 (!) network link) but with a bigger server, faster ISP, and better code, it handled the 2003 Slashdotting much better - while the web server got pretty laggy, the daemon program was pretty much driven for most of that night at close to the theoretical max rate of an update/second ... my neighbors commented that it was quite the "light show!" There were a few minor corner cases (now fixed, but I'm sure more) where some (hidden) errors popped up due to race conditions - the Slashdot Effect is a good stress test! ;-)

There was a variety of other X10 tricks demonstrated - click here to read the X10 sensors FAQ.

So now that I've described how to do this, I expect to see a lotta webcam & webcontrol pages available on the Web! ;-)
BTW, here are some cool webcam pictures of the webcam throughout the years.

Questions/comments/whatever about this extravaganza? Check out the Email Santa Forum with replies to various questions - somewhat humorous! ;-)

P.S. Read about some folks who did nutty stuff like web-control the lights of an entire building!