Processing

Because our sprinkler control circuits and our existing automated controller all are in the garage, and because we don’t want to leave a PC in the hot and cold extremes of the garage, we decided we needed to use actuators remote from the PC running the control software.We don’t want to run new control wires from PC to actuators, either, leaving the possibilities of either a wireless link such as you saw in Chapter 2 or X-10 power line controls. If we’d planned to control each sprinkler circuit independently, an embedded microprocessor with a relay bank at the sprinkler control station would have made using a wireless serial link simple.We choseto use X-10 interfaces instead, however, because we planned to control the sprinklers on an overall on/off basis.

The logic behind the decision to control only the entire bank of sprinkler circuits (using one relay in the ground line) was that we didn’t want to deploy as many soil moisture sensors as would be required to sample enough areas of the yard to be able to resolve the need for running one circuit versus all the rest. Consequently, our system design works like this:

1. We use the conventional automated sprinkler controller to sequence the time of day when each sprinkler circuit will run and for how long.

2. We set the conventional controller to run more often than necessary — every day — and rely on the PC control to enable or disable watering for the day based on the soil moisture readings.

3. We use a combination of infrequent deep watering and more frequent, light surface watering. The deep watering is under control of the PC, while the surface watering is always enabled and just enough to get shallow-rooted plants through the heat of the day.

4. Because we use the PC controls only to modulate the deep watering cycles, we keep the sprinklers enabled except for the time spans when deep watering is scheduled. That approach makes it possible to run the sprinklers manually at any time, too, so we don’t have to go running to the PC when we need to test sprinklers for coverage or other faults.

Using X-10 power line communications to control the actuators drove another design choice, too — we separated monitoring the sensors and computing whether watering was required from controlling the actuators.We wrote new software for monitoring and controlling,described later in this chapter, and used the same HomeSeer software we use for other  home automation responsibilities for actuator control.

The other major component of our processing was the decision to link the monitoring and computing software to an Internet weather forecast source. The Vantage Pro equipment we used provides a weather forecasting function, and we built decoding into the software to detect when the hardware was forecasting rain.We noticed that the forecast changes relatively frequently, however, and that it didn’t correspond to actual events as often as we wanted. Supplementing the hardware forecast with samples from an Internet source (based on ZIP code) creates the option to use either forecast, both, or none.

We used an

XML feed from the Web for the forecast data to simplify locating and parsing the data, and found usable feeds at both weatherroom. com and weather.com.We initially planned to use the weather.com feed (because itexplicitly includes a probability of precipitation estimate), but found them impossible to work  with. Not only does their license agreement require consent to terms in a developers’ guide you can’t get before you consent, they were completely unresponsive to e-mails asking for clarification  of how to comply with the licensing terms in the context of our software. The weatherroom. com license was far more lenient, but their forecast data provides only qualitative descriptions of the chance of precipitation.We made some arbitrary assignments of probabilities to those terms in our software to fill the gap.

Simple as the communication needs to be — HomeSeer merely needs to be told when the sprinklers are enabled or disabled — the interface between our software and HomeSeer required some thought. There were two key design issues:

1. There is some time required to read the serial port on the Vantage Pro, and a potentially much longer time required to read in the XML weather forecast feed. HomeSeer’s architecture requires plug-ins, its most tightly coupled programming interface, to respond faster than those delays would permit, requiring use of a multi-threaded plug-in, making the programming more complex.

2. HomeSeer presents an interface to its plug-ins designed for use with Microsoft’s Visual Basic. The C++ equivalent interface is fairly complex due to Microsoft’s design of the Visual Basic interface conventions, and not explicitly documented by HomeSeer.

Rather than deal with the complexity of a plug-in, therefore, we decided to use an old Unixstyle approach and communicate the interface data through a file. The software we wrote is therefore a standalone C++ application. Its design, implementation, and use is described in the section “Software” later in this chapter. HomeSeer monitors the interface file using a recurring event