Accessing Remote Devices From Centralized Hosts

What is interesting to me whenever we look at software and hardware to solve problems is the needless level of complexity and cost. Let me explain. When you meet with vendors, their first inclination is to add lots of hardware to your infrastructure....and other Cities must just buy lots of it because they seem shocked that we question their solutions and want to keep it simple.

In this particular case, we are adding the ability for our Recreation department to put photos of citizens on their recreation cards. When you review cameras, you begin to hear, "Well you will just add a PC at each remote site to connect to the camera and process the photos". What?!? Huh?? It's very clear that this is unneeded and adds support and upgrade costs. I think sometimes these vendors fail to understand that if you deployed in their design, you would have 100 extra PCs on your network in no time.

So how do we fit in something like a remote camera into a thin client environment? I'm a strong proponent of centralized software and only having very minimal hardware in the field. I didn't want to get a usb webcam that needed drivers and software on the thin clients. Too many problems, and keeping up with ever changing hardware is very difficult. Very often we buy a few devices, and within a few months that same model isn't available anymore. Touching and QAing thin clients and updating them with drivers is not a good idea. I also didn't want the hosts to communicate via USB to remote sites. We always use stateless connections to keep things simple and stable.

So I honed in on the Cisco/Linksys WVC80N Internet camera. Ok, so some problems were solved. We can use the motion sensors, and our employees at the remote sites won't have to push any buttons. All they have to do is sit down the citizen and the photos are taken automatically. Very cool. The camera snaps the photos on motion, and then uploads them via FTP. Because some sites are on lower bandwidth lines, I decided not to send the photos back to our servers. Otherwise anytime there was movement photos would be uploading constantly and possibly slowing their performance. Ever see how many kids run around at recreation sites? :) I wanted to only send the photos when they are really needed by our host software.

It was a logical progression of thought then to house the photos at the remote site until they are used. But where? It turned out that we could store them on the thin clients very easily. We already use FTP to transfer files back and forth from USB sticks to the server to ensure that all file transfers and connections are stateless. So what I did was create a "fake" USB stick in /media that is really a RAMfs (tmpfs) with 20MB of space. This was to avoid having to have a USB stick plugged into the thin client to house the pictures. It was not desirable to store the photos on the flash drive of the thin client itself, these drives have a fixed amount of writes.

When someone moves in front of the camera, it shoots the pictures and puts them on the thin client located at that site via FTP. When we then need those photos from our host based software, we FTP then off the thin clients and back to the server. Clean, solid state and hardware independent. When this camera is discontinued, all we have to do is buy the newer model and drop it into the same location.

Total cost to take photos of our citizens, $110.