Extending the System
There are many ways to extend the security system beyond what we’ve shown in this chapter. From a hardware perspective, you can add different kinds of sensors for specific applications. Don’t be limited by conventional thinking — for example, you could use a sensor like the Memsic 2125 Dual-axis Accelerometer to detect when someone picks up or moves an object, possibly linking the sensor readings in wirelessly.
The software we wrote is relatively simple. Here are some ways you could extend it:
1. A Phidget digital output will let you turn on a siren using the circuit in Figure 4-10. You’ll use the write function from the PhidgetInterfaceKit, and should synchronize the write call with the operation of the worker thread, because you can’t assume the library is re-entrant.
2. The GeekSecurity code assumes a persistent connection to the Internet. You could revise it to automatically dial a connection if necessary, send the e-mail, then disconnect. The WinInet functionality in the Microsoft Platform SDK provides what you need — see the MSDN article Establishing a Dial-Up Connection to the Internet
3. PJ Naughter wrote another useful class, one to send Short Message Service (text) messages. Using a cell phone enabled for SMS service, you could send alarm notifications to the cell phone you carry.
4. Our code assumes the 888 is connected when the software starts up, and that it remains connected as long as the software is running. You could use the CPhidgetManager to detect attach and detach events, which would allow handling accidental or intentional unplugging of the interface. Attach and detach events would have to be coordinated with the CPhidgetInterfaceKit, since opening or holding open a device that’s not connected doesn’t work very well.
5. Our implementation assumes eight digital input ports. You can extend the code to use a 16-port interface just by changing the MAXZONES constant, extending the dialog box, and recompiling. More difficult is to handle more than one PhidgetInterface; we’d approach that by using the board serial numbers, which are passed to the PhidgetManager attach and detach handlers.
6. The code stores e-mail authentication for username and password in the registry. That’s insecure; better would be to keep them in encrypted form.
7. The GeekSecurity software receives changed Phidget analog sensor readings, but currently throws that information away. If you wanted to process information from temperature,light, motion, or other analog sensors, you’d need to establish thresholds to categorize readings into normal or alarm states. That requires code to store thresholds, compare new readings against the thresholds, and send alarms if necessary. You calibrate some of the sensors (such as temperature) for readings based on absolute value, while the direction of change of the analog values is the useful information for some of the sensors; for example, the motion sensor (which detects movement in one axis across the sensor) values indicate which direction the movement is in, while the light sensor values get higher for brighter light.
8. Our implementation sends an e-mail immediately when a zone triggers, which allows no time to disable the alarm when you enter the building. You’d fix that by adding a delay from when the alarm triggers to when the software sends e-mail, along with an alarm disable button (perhaps with a password) in the user interface. You might want to add alarm enable and disable states, along with an exit delay once you arm the system.
9. Zones are assumed to be normally open in the software. You could add a checkbox for each zone defining whether it’s normally open or normally closed, and generate the alarm e-mail when the state changes from normal.