Patent Publication Number: US-2013253713-A1

Title: Method and System for Electric-Power Distribution and Irrigation Control

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application is a continuation-in-part of U.S. application Ser. No. 13/471,257, filed May 14, 2012 and entitled “Method and System for Electric-Power Distribution,” which claims the benefit of U.S. Provisional Application No. 61/485,552, filed May 12, 2011 and entitled “Method and System for Electric Power Distribution,”; the entire content of both of which applications are incorporated by reference herein. This application claims priority from U.S. Provisional Application No. 61/750,455, filed Jan. 9, 2013 and entitled “METHOD AND SYSTEM FOR ELECTRIC-POWER DISTRIBUTION AND IRRIGATION CONTROL,” the entire content of which is incorporated by reference herein. 
     In addition, this application is related to the following: U.S. application Ser. No. 13/______, filed Mar. 12, 2013, and entitled “LIGHTING SYSTEM CONTROL AND SYNTHETIC EVENT GENERATION,” which claims priority to U.S. Provisional Application No. 61/750,425, filed Jan. 9, 2013 and entitled “LIGHTING SYSTEM CONTROL AND SYNTHETIC EVENT GENERATION”; U.S. application Ser. No. 13/______, filed Mar. 12, 2013, and entitled “LIGHT BALANCING,” which claims priority to U.S. Provisional Application No. 61/750,435, filed Jan. 9, 2013 and entitled “LIGHT BALANCING”; U.S. application Ser. No. 13/______, filed Mar. 12, 2013, and entitled “LIGHT HARVESTING,” which claims priority to U.S. Provisional Application No. 61/750,443, filed Jan. 9, 2013, and entitled “INVERSE LIGHT HARVESTING”; U.S. application Ser. No. 13/______, filed Mar. 12, 2013, and entitled “LIGHTING AND INTEGRATED FIXTURE CONTROL,” which claims priority to U.S. Provisional Application No. 61/750,492, filed Jan. 9, 2013 and entitled “LIGHTING AND INTEGRATED FIXTURE CONTROL.” The entire content of the applications listed above is incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     The current application is related to automated control systems for controlling and monitoring individual lighting elements, lighting elements associated with individual fixtures, and arbitrarily sized groups of lighting fixtures located across local, regional, and larger geographical areas, particularly LED-based lighting, and, in particular, to automated lighting-control systems that additional distribute electrical power to consumers. The current application is also related to automated control systems for controlling and monitoring sprinklers in a water irrigation system. 
     BACKGROUND 
     Lighting systems for public roadways, thoroughfares, and facilities, private and commercial facilities, including industrial plants, office-building complexes, schools, universities, and other such organizations, and other public and private facilities account for enormous yearly expenditures of energy and financial resources, including expenditures for lighting-equipment acquisition, operation, maintenance, and administration. Because of rising energy costs, falling tax-generated funding for municipalities, local governments and state governments, and because of cost constraints associated with a variety of different enterprises and organizations, expenditures related to acquiring, maintaining, servicing, operating, and administering lighting systems are falling under increasing scrutiny. As a result, almost all organizations and governmental agencies involved in acquiring, operating, maintaining, and administering lighting systems are seeking improved methods and systems for control of lighting fixtures in order to lower administrative, maintenance, and operating costs. 
     Further, in conventional irrigation systems and methods, the amount of fluid emitted from a sprinkler head may be determined by measuring the fluid level in the soil, and then the amount of fluid may be altered by manually adjusting the fluid emission level to a desired output. Such conventional systems and methods require a technician to be on-site at the sprinkler head and to physically manipulate the sprinkler head to make the desired adjustments. As such, conventional systems and methods for irrigation may be costly and time consuming. Alternatively, various irrigation sensors (e.g., soil moisture sensors, water pressure sensors, rain sensors, temperature sensors, wind speed sensors, humidity sensors, solar radiation sensors, etc.) may be used to determine soil conditions. The determined soil conditions may then be transmitted to a controller which compares the determined conditions with the desired conditions and then adjusts the amount of fluid emitted from the sprinkler head to meet the desired level. Such systems require irrigation detectors to be disposed onsite at all times with a continuous real-time feed back communication protocol. However, onsite detectors can become damaged or stolen, or the communication protocol can be inadvertently shut off. Accordingly, there is a need in the art for a more efficient system and method of controlling an irrigation system. 
     SUMMARY 
     The present disclosure is directed to a system and method for providing control or management of resources by networked systems at individual-location, local, regional, and larger-geographical-area levels that distribute resources (e.g., water, electrical power, lighting, etc.) to consumers/users. One such system or method includes an irrigation-control system for controlling the output of water in irrigation operations. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a portion of a traditional lighting system observed in parking lots, along thoroughfares and roadways, and within industrial sites, school facilities, and office-building complexes. 
         FIG. 2  shows a modestly sized industrial or commercial site with associated lighting-fixture locations. 
         FIGS. 3A-B  illustrate a conceptual approach to lighting-system control. 
         FIG. 4  illustrates, using the same industrial-site layouts shown in  FIG. 2 , groupings of individual lighting fixtures to facilitate automated control, as made possible by lighting-control systems. 
         FIG. 5  illustrates a displayed schedule for automated control of the various groups of lighting fixtures shown in  FIG. 4 . 
         FIG. 6  provides a generalized architecture for the automated hierarchical lighting-control system. 
         FIG. 7  provides a block diagram for a radio-frequency-enabled light-management unit. 
         FIG. 8  provides a block diagram for a stand-alone routing device. 
         FIG. 9  illustrates communications between routers, radio-frequency-enabled light-management units, and end-point light-management units. 
         FIG. 10  illustrates division of the 256 possible command codes into four subsets. 
         FIG. 11  shows the type of data stored within each light-management unit. 
         FIGS. 12A-B  illustrate data managed by a router for all of the different light-management units or light-fixtures which the router manages. 
         FIG. 13  shows various commands used in router-to-light-management-unit communications. 
         FIGS. 14A-N  show the data contents of the various commands and replies discussed above with reference to  FIG. 13 . 
         FIGS. 15-18  provide flow-control diagrams for the control functionality with a light-management unit. 
         FIG. 19  provides a state-transition diagram for one router user interface. 
         FIG. 20  shows a block diagram for the RF-enabled LMU. 
         FIG. 21  provides additional description of the microprocessor component of the RF-enabled LMU. 
         FIG. 22  provides a circuit diagram for a portion of the optocouple-isolation subcomponent of the RF-enabled LMU. 
         FIG. 23  provides a circuit diagram for the switched-relay component of the RF-enabled LMU. 
         FIG. 24  provides a circuit diagram for the internal-power-supply component of the RF-enabled LMU. 
         FIG. 25  provides a circuit diagram for the power-meter component of an RF-enabled LMU. 
         FIG. 26  provides a circuit diagram for a circuit that interconnects output from a sensor or monitor device to an interrupt-like input to the microprocessor. 
         FIGS. 27-29  illustrate characteristics of LED-based lighting elements. 
         FIG. 30  illustrates a LED-based street-light luminaire. 
         FIGS. 31-33  illustrate one type of constant-output-current LED lamp driver. 
         FIG. 34  illustrates an RF-enabled LMU/LED-based-luminaire-driver module. 
         FIG. 36  illustrates certain of the enhancements made to the data stored within each LMU and enhancements to LMU functionality that are made to provide for electric-power distribution. 
         FIG. 37  illustrates enhancements to the stored data and functionality within routers and/or network control centers. 
         FIGS. 38A-C  illustrate a representative electric-power-distribution transaction. 
         FIG. 39  illustrates an example of an irrigation control system according to the present disclosure. 
         FIG. 40  illustrates an exemplary, basic operation of the irrigation control system illustrated in  FIG. 39 . 
     
    
    
     DETAILED DESCRIPTION 
     There are many different types of lighting fixtures, lighting elements, or luminaires, and lighting applications.  FIG. 1  illustrates a portion of a traditional lighting system observed in parking lots, along thoroughfares and roadways, and within industrial sites, school facilities, and office-building complexes. Such lighting systems commonly employ street-light fixtures, such as street-light fixtures  102 - 104  in  FIG. 1 . Each street-light fixture includes a rigid, vertical pole  110  and arms or brackets  112 , through which internal electrical wiring runs, that together support one or more lighting units  114 . Each lighting unit generally includes one or more lighting elements and associated electrical ballasts that limit voltage drops across, and current drawn by, lighting elements and that buffer voltage and/or current surges and shape the input voltage or current in order to provide a well-defined output voltage or current for driving the lighting elements. Many different types of lighting elements are currently used, including light-emitting-diode (“LED”) panels, inductive-lighting or compact fluorescent elements, high-pressure-sodium lighting elements, mercury-halide lighting elements, incandescent lighting elements, and other types of lighting elements. A series of lighting fixtures is often interconnected along a common electrical path within a public-utility electrical grid. Lighting fixtures are often controlled by photocell switches  116 , which respond to ambient illumination and/or lack of ambient illumination, to power on lighting elements during periods of darkness and power off lighting elements when adequate ambient daylight is available. 
     Even modestly sized industrial, commercial, educational, and other facilities often employ a large number of lighting fixtures for a variety of different purposes.  FIG. 2  shows a modestly sized industrial or commercial site with associated lighting-fixture locations. The industrial site shown in  FIG. 2  includes an administration building  202 , an operations building  204 , three laboratory buildings  206 - 208 , and three parking lots  210 - 212 . The locations of lighting fixtures are shown as filled disks, such as filled disk  214 . Certain of the lighting fixtures are located along roadways, such as lighting fixture  220 , and may serve to illuminate the roadways as well as illuminating portions of buildings adjacent to the roadways, building entrances, walkways, and other portions of the environment surrounding the buildings and roadways. This type of lighting provides safety for operators of motor vehicles and pedestrians, and may address certain security concerns. Other lighting fixtures, including double-arm lighting fixtures  224 - 226 , illuminate parking lots, and are employed primarily for the convenience of parking-lot users as well as for security purposes. Other lighting fixtures, including the lighting fixtures that surround the laboratory buildings  206 - 208 , including lighting fixture  230 , may serve primarily for facilitating security in and around high-security buildings and areas. 
     There are many problems associated with even simple lighting systems, such as those shown in  FIGS. 1 and 2 . Photocell control of lighting fixtures is relatively crude, providing 100 percent power to light fixtures during periods of darkness and no power to light fixtures during periods of adequate ambient light. Thus, lighting is controlled primarily according to day length, rather than to the needs of facilities and people who work in, and travel through, the facilities. Photocells and photocell-control circuitry may fail, leading to lighting fixtures remaining constantly powered on, significantly shortening the useful length of lighting elements and significantly increasing energy consumption by lighting fixtures. As discussed with reference to  FIG. 2 , various different lighting fixtures within a facility may be used for different purposes, and therefore could optimally be controlled according to different schedules and lighting-intensity requirements, were such control possible. However, current lighting systems generally lack effective means for differentially operating lighting fixtures and lighting elements within them. For these and many other reasons, manufacturers and vendors of lighting fixtures and lighting systems, organizations and agencies responsible for acquiring, operating, maintaining, repairing, replacing and administering lighting systems, and ultimately all who enjoy the benefits of lighting systems continue to seek improved systems for controlling lighting systems, so that lighting can be provided as cost effectively as possible to meet various different lighting needs and requirements. 
     As discussed above, current lighting systems, in which individual lighting fixtures are controlled generally by photocells, and in which groups of electrically interconnected lighting fixtures may be additionally controlled at the circuit level by timers and other crude control mechanisms, do not provide flexibility and precision of control needed to optimize control of lighting systems in order to provide needed lighting intensities at particular times on an individual-lighting-fixture basis, monitor lighting fixtures for output, component failure, and other operational characteristics, and provide local-area-wide, regional, and larger-geographical-area-wide approaches to control of lighting systems. By contrast, examples of the currently described lighting systems provide precise control of lighting fixtures, regardless of electrical-connection topologies, in local, regional, and larger areas through automated control systems, public communications networks, including the Internet, radio-frequency communications, and power-line communications. Examples of the currently described lighting systems thus provide for flexible, scheduled, and controlled operation of lighting fixtures down to the granularity of individual lighting elements within individual lighting fixtures and up to arbitrarily designated groups of lighting fixtures that may include millions of lighting fixtures distributed across large geographical areas. In addition, examples of the currently described lighting systems provide for automated monitoring of lighting elements, lighting fixtures, and the environment surrounding lighting fixtures made possible by flexible control of light-management units, lighting-fixture-embedded sensors, and bi-directional communications between light-management units, routers, and network-control centers. Examples of the currently described lighting systems provide for control of active components included in lighting fixtures, including automated activation of heating elements, failure-amelioration circuitry, and other such local functionality by the hierarchical control systems that represent examples of the currently described lighting systems. 
       FIGS. 3A-B  illustrates a conceptual approach to lighting-system control. According to this example, lighting-system control is implemented hierarchically, with a top-level network-control center  302  directly communicating with multiple routing devices, or routers,  304 - 310 , each of which, in turn, communicates with one or more radio-frequency (“RF”)-enabled bridging lighting-fixture-management units (“LMUs”)  320 - 332  within individual fixtures that control operation of the lighting fixtures and that, in turn, communicate with one or more end-point LMUs within individual lighting fixtures via power-line communications. In general, the network-control center communicates with routers via network communications, including the Internet. However, network-control centers may also employ cellular telephone network communications, radio-frequency communications, and other types of communications in addition to network communications, in alternative examples. The routers intercommunicate with LMUs via radio-frequency communications, power-line communications, and, in alternate implementations, using other types of communications. In certain examples of the currently described lighting systems, RF-enabled, bridging LMUs intercommunicate with routers using radio-frequency communications, and the RF-enabled, bridging LMUs communicate with additional end-point LMUs via power-line communications. 
     Each router, such as router  304 , is associated with a number of individual lighting fixtures containing LMUs, such as the lighting fixtures within the region enclosed by dashed line  340  in  FIG. 3 , that intercommunicate with the router to provide control of the lighting fixtures. The routers, in turn, communicate with a network-control center  302  that provides for centralized, automated control of all of the lighting fixtures controlled by all of the routers that communicate with the network-control center. In one example of the currently described lighting systems, there are four levels within the hierarchy of controllers: (1) the centralized network-control center  302 ; (2) a number of routing devices  304 - 310 ; (3) RF-enabled bridging LMUs  320 - 332 ; and (4) additional end-point LMUs that communicate with the RF-enabled bridging LMUs via power-line communications. In alternative examples of the currently described lighting systems, additional hierarchical levels may be included so that, for example, multiple network-control centers may communicate with a higher-level central control system for control of a very large geographical region. Alternatively, multiple geographically separated network-control centers may be implemented to interoperate as a distributed network-control center. Note that the lighting fixtures controlled through a particular router, such as the lighting fixtures within the area surrounded by dashed curve  340 , are not necessarily geographically distinct from the lighting fixtures controlled by another router. The LMUs contained within individual lighting fixtures provide policy-driven, individualized, automated control over each of one or more lighting elements within the lighting fixture, provide for manual control of lighting elements, receive and process data from sensors, and control various active devices within lighting fixtures. Up to 1,000 or more LMUs may communicate with, export data to, and receive policy directives and data from, a particular routing device, and the network-control center may communicate with, receive data from, and export policy directives to, up to 1,000 or more routing devices. Thus, the network-control center may provide automated control of a million or more individual lighting fixtures. 
     While examples of the currently described lighting systems allow individual lighting elements within individual lighting fixtures to be manually controlled from user interfaces provided by routing devices and user interfaces provided by the network-control center, manual control would be tedious and error prone. Automated lighting-control systems that represent examples of the currently described lighting systems provide the ability to logically aggregate individual lighting fixtures into various different groups of lighting fixtures for control purposes.  FIG. 4  illustrates, using the same exemplary industrial-site layout shown in  FIG. 2 , groupings of individual lighting fixtures to facilitate automated control, made possible by currently described lighting-control systems. As shown in  FIG. 1 , the various different lighting fixtures, represented by filled disks, such as filled disk  220 , are combined into 11 different control groups. Lighting fixtures along a public thoroughfare, including lighting fixture  220 , are grouped together into a first group  402 , labeled with the group number “ 1 .” Lighting fixtures behind the administration building and operations buildings  202  and  204 , along a smaller roadway  404  and a large parking lot  212 , are divided into two groups: (1) group  2  ( 406  in  FIG. 4 ); and (2) group  3  ( 408  in  FIG. 4 ). By partitioning these lighting fixtures into two groups, alternate lights along the roadway and parking lot can be activated on alternate days, lowering energy consumption and increasing lighting-element operational lifetimes. Alternatively, all of these lighting elements could be combined in a single group, and operated at lower light-intensity output in order to achieve similar purposes. Similarly, the dual-arm lighting elements within parking lot  212  are divided into two groups  410  and  412  so that lighting elements on only a single arm of each dual-arm lighting fixtures are powered on during a given day. Groups can be as small as individual lighting fixtures, such as groups  6  and  7  ( 420  and  422  in  FIG. 4 ) or even as small as individual lighting elements within lighting fixtures. The hierarchical, automated control of lighting can be feasibly scaled, according to examples of the currently described lighting systems, to control all of the lighting fixtures within an entire nation or continent. 
     The hierarchical implementation of the automated lighting control system that represents one example of the currently described lighting systems provides both scalability and communications flexibility. As one example,  FIG. 3B  shows a portion of a lighting-control system that uses a number of different types of communications methodologies. In  FIG. 3B , a router  350  manages LMUs within eight different lighting fixtures  352 - 359 . The lighting fixtures are partitioned into two different groups, including a first group  352 - 355  serially interconnected by a first power line  360  emitted from a transformer  362  and a second group  356 - 359  serially interconnected by a second power line  364  emitted from the transformer  362 . Were both groups of lighting fixtures connected to a single power line, without the transformer  362  separating the two groups of lighting fixtures, all of the LMUs within the lighting fixtures could directly communicate with the router using only power-line communications. However, power-line communications cannot bridge transformers  362  and various other electrical-grid components. It would be possible to use two routers, one for each group of lighting fixtures, and interconnect each router to its respective group of lighting fixtures using power-line communications. However, a two-router implementation would involve connection and location constraints with regard to the routers, unnecessary duplication of router functionality, and higher cost. Instead, according to various examples of the currently described lighting systems, the router  350  communicates by radio-frequency communications with RF-enabled, bridging LMUs in each of lighting fixtures  354  and  358 . Each RF-enabled, bridging LMU intercommunicates with the remaining lighting fixtures of the group of lighting fixtures in which the bridging LMU is located using power-line communications. The bridging LMUs serve both as a local LMU within a lighting fixture as well as a communications bridge through which end-point LMUs in each group can receive messages from, and transmit messages to, the router  350 . Thus, radio-frequency communications and RF-enabled, bridging LMUs provide a cost-effective and flexible method for bridging transformers and other power-line-communications-interrupting components of an electrical system. In addition, each LMU may include cell-phone-communications circuitry to allow the LMU to communicate directly with a cellular telephone  370 . A cellular telephone can act as a bridge to a router or as a specialized, local router, to enable maintenance personnel to manually control an LMU during various monitoring and servicing activities. 
     In certain examples of the currently described lighting systems, LMUs control operation of lighting elements within lighting fixtures according to internally stored schedules.  FIG. 5  illustrates a displayed schedule for automated control of the various groups of lighting fixtures shown in  FIG. 4 . Schedules may be displayed, in various ways, by router and network-control-center user-interface routines, allowing interactive definition, modification, and deletion of schedules by authorized users. As shown in  FIG. 5 , a schedule for lighting-element operation within the lighting fixtures of each of the 11 groups shown in  FIG. 4  is provided for a particular day. Each horizontal bar, such as horizontal bar  502 , represents the schedule for operation of lighting elements within the lighting fixtures of a particular group according to the time of day. In certain examples of the currently described lighting systems, entire lighting fixtures, including all lighting elements within the lighting fixtures, are assigned to groups, while in alternative examples of the currently described lighting systems, individual lighting elements within lighting fixtures may be separately assigned to groups. The time of day increments from 12:00 a.m.  504 , at the left-hand edge of the horizontal bar  502 , to 12:00 p.m.  506  at the right-hand edge of the horizontal bar  502 . Shaded regions within the horizontal bar, such as shaded region  508  in horizontal bar  502 , indicate times during which the lighting elements should be powered on. The heights of the shaded regions indicate the level to which the lighting element should be powered on. For example, shaded region  510  in horizontal bar  1  indicates that the lighting elements within the lighting fixtures of group  1  should be powered on to 50 percent of maximum intensity between 12:00 a.m. and 2:00 a.m., while the right-hand portion of shaded region  508  indicates that the lighting elements within the lighting fixtures within group  1  should be powered on to maximum intensity from 6:30 p.m. until midnight, after a half hour of 50 percent of maximum intensity powering from 6:00 p.m. to 6:30 p.m. 
     In addition, event-driven or sensor-driven operational characteristics can be defined for each group. For example, in  FIG. 5 , small horizontal bars, such as horizontal bar  514 , indicate how the lighting elements should be operated when various different events occur. For example, horizontal bar  514  indicates that, in the event that the photocell output transitions from on to off, indicating that the ambient lighting has increased sufficiently to trip the photocell-signal-output threshold, the lights, when already powered on at or above 50% of maximum intensity, should be operated for an additional 15 minutes at 50 percent of maximum light-intensity output, represented by shaded bar  516 , and then powered off. Operational characteristics can be specified for the photocell-on event, indicating a transition from adequate lighting to darkness, and for an input signal from a motion sensor indicating motion within the area of a lighting fixture. Operational characteristics for many additional events may be specified, as well as operational characteristics for additional controllable devices and functionality, including heating elements activated to remove snow and ice, various failure-recovery and fail-over systems, and other such devices and functionality. 
     There are many different approaches to specifying lighting-element operation and many different considerations for providing the different operational characteristics represented by the different horizontal bars for each group shown in  FIG. 5 , which in turn represent encoded operational schedules and event-related operational directives. For example, it would make no sense to power on lighting elements in response to a photocell-off event. The intent of the small shaded bar  516  within horizontal bar  514  is that, had the lights been powered on to greater than 50 percent of maximum intensity, lighting elements should be powered down to 50 percent of maximum intensity for a brief period of time before being powered off entirely. Thus, a combination of the time-incremented, large horizontal bar  502  and smaller horizontal bar  514  may specify that, at any point in time, the light should be powered on to the minimum power level indicated in the time-of-day schedule bar and the shorter horizontal bar corresponding to the photocell-off event. However, in other cases, light may need to be powered on to the maximum power level indicated in the time-of-day schedule bar and a different, shorter horizontal bar corresponding to a different type of event. In general, the ultimate operational characteristics of a light fixture, implemented by an LMU installed within the light fixture, may be defined by arbitrary Boolean and relational-operator expressions or short interpreted scripts or computer programs that compute, for any particular point in time, based on sensor input signals and on the stored time-based schedule and stored operational characteristics associated with particular events, the degree to which the lighting element should be powered on. 
       FIG. 6  provides a generalized architecture for the automated hierarchical lighting-control system that represents one example of the currently described lighting systems. Large-area control is exercised over many lighting fixtures within a large geographical area via automated control programs running within a network-control center  602 . The network-control center includes, in addition to the control programs, one or more relational database management servers  603  or other types of data-storage systems and multiple web servers, or other interface serving systems,  605 - 607  that together comprise a distributed, automated lighting control-system network-control center. The network-control center web servers serve lighting-system-control information to multiple routers  610 - 613  via the Internet  616  or via radio-frequency transmitters  618 . In addition, the network-control center may provide a web-site-based network-control-center user interface  620  via a personal computer or work station  622  interconnected with the network-control center by the Internet or a local area network. In certain examples of the currently described lighting systems, the network-control center may provide functionality similar to that provided by individual routers, including the ability to monitor the state of individual LMUs, define groups, define and modify schedules, manually control lighting fixtures, and carry out other such tasks that can be carried out on a local basis through the user interface provided by a router. In addition, the network-control center may provide additional functionality, not provided at the router level, including computationally complex analysis programs that monitor and analyze various characteristics of lighting systems, including power consumption, maintainability, and other such characteristics, over very large geographical areas. 
     The routers may be implemented in software that runs on a laptop or personal computer, such as router  611 , may be stand-alone devices, such as routers  610  and  612 , or may be stand-alone devices associated with a personal computer or workstation on which stand-alone routers display user interfaces provided to users, as in the case of router  613  in  FIG. 6 . Routers communicate with RF-enabled LMUs  630 - 640  via wireless communications, including IEEE802.15 (Zigbee) communications, and the RF-enabled LMUs may both control a particular lighting fixture as well as act as a bridge between additional end-point LMUs with which the bridge LMUs communicate via power-line communications, including Echelon Power Line (ANSI/EIA 709.1-A). In certain examples of the currently described lighting systems, routers may communicate to LMUs via power-line communications, such as router  612  and LMU  633  in  FIG. 6 . In still further examples of the currently described lighting systems, other types of communications may be employed for communicating information between network-control centers and routers, between routers and bridge LMUs or end-point LMUs, and between bridge LMUs and end-point LMUs. Various different chip sets and circuitry can be added to LMUs, routers, and components of network-control centers to enable additional types of communications pathways. 
     Both bridge LMUs and end-point LMUs control operation of lighting elements within light fixtures and collect data through various types of sensors installed in the light fixtures. Both types of LMUs control lighting-fixture operation autonomously, according to schedules downloaded into the LMUs from routers and network-control centers or default schedules installed at the time of manufacture, but may also directly control operational characteristics of lighting fixtures in response to commands received from routers and network-control centers. The schedules and other control directives stored within LMUs may be modified more or less arbitrarily by users interacting with user interfaces provided by routers and network-control centers. While, in many applications, the control functionality of the LMUs is a significant portion of the automated lighting-system control functionality provided by examples of the currently described lighting systems, in many other applications, monitoring functionality provided by LMUs is of as great a significance or greater significance. The LMUs architecture provides for connecting numerous different sensor inputs to LMUs, including motion-sensor inputs, chemical-detection-sensor inputs, temperature-sensing inputs, barometric-pressure-sensing inputs, audio and video signal inputs, and many other types of sensor inputs in addition to voltage and power sensors generally included in LMUs. The LMUs&#39; response to each of the different types of input signals may be configured by users from user interfaces provided by routers and network-control centers. The various types of sensor input may be used primarily for providing effective control of lighting-system operation, in certain cases, but also may be used for providing a very large variety of different types of monitoring tasks, at local, regional, and large-geographical-area levels. LMU sensing can be employed, for example, for security monitoring, for monitoring of traffic patterns and detection of impending traffic congestion, for facilitating intelligent control of traffic signals, for monitoring local and regional meteorological conditions, for detecting potentially hazardous events, including gunshots, explosions, release of toxic chemicals into the environment, fire, seismic events, and many other types of events, real-time monitoring of which can provide benefits to municipalities, local government, regional governments, and many other organizations. 
       FIG. 7  provides a block diagram for a radio-frequency-enabled light-management unit. The RF-enabled LMU includes an RF antenna  702 , a wireless communications chip or chip set  704  that provides for wireless reception and transmission of command and response packets, a power-line-communications chip or chip set  706  that provides for power-line reception and transmission of command and response packets, a noise filter  707  that band-pass filters noise from the power-line connections, a CPU  708  and associated memories for running internal control programs that collect and store data, that control lighting-element operation according to stored data and stored programs, and that provide forwarding of packets from RF to PL communications and from PL to RF communications, an internal power supply that converts AC input power to DC internal power for supplying DC power to digital components, an optocouple isolation unit  710  that isolates the CPU from power surges, a dimming circuit  712  that provides digital pulse-width modulation of the electrical output to lighting elements to provide a range of output current for operating certain types of lighting elements over a range of light-intensity output, a digital-to-analog circuit  714  that provides controlled voltage output to lighting elements or other components, and a switched relay  716  for controlling power supply to various devices or components within a lighting fixture, including ballasts. 
       FIG. 8  provides a block diagram for a stand-alone routing device. The stand-alone routing device includes many of the same elements as included in the RF-enabled LMU, as shown in  FIG. 7 , with the addition of a local-area-network communications controller and port  802  and other communications components  804  and  806  that allow the stand-alone router to interconnect with a personal computer or workstation for display of a user interface. 
       FIG. 9  illustrates communications between routers, radio-frequency-enabled light-management units, and end-point light-management units. Both commands and responses are encoded in packets comprising between seven and 56 bytes for RF communications. The RF communications protocol is a command/response protocol that allows routers to issue commands to RF-enabled LMUs and receive responses from those commands and that allows RF-enabled LMUs to issue commands to routers and receive responses to those commands from the routers. Broadcast messages and one-way messages are also provided for. Each command or response packet includes a six-byte ID  902 , a single-byte command identifier or code  904 , and between zero and 49 bytes of data  906 . The ID  902  is used to identify particular LMU or RF-enabled LMUs from among the LMUs that communicate with the router. The commands and responses are packaged within power-line-communications applications packets for communications via power-line communications via the Echelon power-line communications protocol. 
       FIG. 10  illustrates division of the 256 possible command codes into four subsets. In  FIG. 10 , a central horizontal column  1002  includes the 256 different possible command codes that can be represented by the one-byte command-code field within the communications packets used both for RF communications and PL communications. The even-numbered command codes correspond to commands, and the odd-numbered command codes correspond to responses, with the response for a particular command having a numeric value one greater than the numeric value of the command code for that particular command. Command codes and response codes for router-to-end-point-LMU commands have the lower-valued codes, represented as the code values above horizontal dashed line  1004 . Router-to-bridge LMU commands have the higher-valued command codes, represented by the command codes below the horizontal dashed line  1004 . Thus, a bridge LMU can immediately determine, from the command code, whether a command received from a router should be processed by the bridge LMU for local control of a light fixture or forwarded, via PL communications, to downstream LMUs. Similarly, the end-point-LMU-to-router commands have lower-numbered command codes and the bridge-LMU-to-router commands have higher numerically valued command codes. Any particular command code, such as command code “ 0 ”  1006 , may correspond to a router-to-LMU command or to an LMU-to-router command. The routers and LMUs can distinguish these different commands because the router receives only LMU-to-router commands and LMUs receive only router-to-LMU commands. 
       FIG. 11  shows the type of data stored within each light-management unit. Each LMU stores information for each of up to a fixed number of lighting elements  1102 - 1105 , a number of group identifiers  1112  that identify groups to which the LMU is assigned, various input/output device descriptors  1114 , the status for each of various different events  1116 , and a schedule  1118  comprising up to some maximum number of operational directives. Each set of information describing a particular lighting element, such as the information that describes lighting element “ 0 ”  1102 , includes a lamp-status  1120  with a bit indicating whether or not the lighting element is powered on or off  1121  and a field indicating the degree to which the light is powered on with respect to the maximum light-intensity output of the light  1122 . In addition, the total hours of operation for the lighting element  1124 , total operation of the ballast associated with the lighting element  1126 , and the number of power-on events associated with the lighting element  1128  are stored, along with various additional types of information. Information regarding the light fixture  1108  includes a current power consumption  1130 , a current or instantaneous voltage across the lighting fixture  1132 , a current drawn by the lighting fixture  1134 , an accumulated energy used by the lighting fixture  1136 , flags that indicate whether particular alarms, other sensor inputs, or other input signals are active or inactive  1138 , and a set of flags indicating whether or not particular relays and other output components are active or inactive  1140 . Lighting fixture information also includes a cumulative light status  1142  that indicates whether or not any of the light elements associated with the light fixture are on or off. The status bits  1110  include a variety of different bit flags indicating various types of problems, including override events, sensor failures, communications failures, absence of stored data needed for control of light-element operation, and other such events and characteristics. The I/O device descriptors  1114  provide a description of the meaning of each of various input signals that can be monitored by the LMU. Each operational directive within the schedule  1118  includes an indication of the day  1150 , start time  1152 , end time  1154 , and lamp status  1156  associated with the directive, as well as a group ID  1158  that indicates a group to which the directive applies. 
       FIGS. 12A-B  illustrate data managed by a router for all of the different light-management units or light-fixtures which the router manages. In  FIGS. 12A-B , a set of relational-database tables are provided to indicate the types of information maintained by a router regarding the LMUs managed by the router. Of course, any number of various different database schemas may be designed to store and manage information for routers in alternative examples of the currently described lighting systems. The relational tables shown in  FIGS. 12A-B  are intended to provide an exemplary database schema in order to illustrate the types of data stored within a router. The relational tables of the exemplary schema include: (1) Component Type 1202, which lists the various types of components within a lighting control system, including internal components of lighting fixtures and lighting elements as well as LMUs, routers, and other components; (2) Address  1204 , which includes various different addresses referenced from other tables; (3) Manufacturer  1206 , which contains information about particular component manufacturers; (4) Maintainer  1208 , which contains information about various maintenance individuals or organizations responsible for maintaining components of the automated lighting control system; (5) Administrator  1210 , which contains information about various administrative organizations or individual administrators that administrate portions of the lighting-control system; (6) additional tables describing individuals or organizations responsible for supplying power, supplying various other services, and other such individuals and organizations, not shown in  FIGS. 12A-B ; (7) Components  1212 , which stores detailed information about particular components within the lighting-control system; (8) Elec  1214 , which stores detailed electrical characteristics of particular system components, the rows of which are referenced from rows of the Components table; (9) Software  1216 , which stores detailed software characteristics of particular system components, the rows of which are referenced from rows of the Components table  1212 ; (10) Mechanical  1218 , which stores detailed mechanical characteristics of particular system components, the rows of which are referenced from rows of the Components table  1212 ; (11) Contains 1220, which stores pairs of component IDs that form the relationship “contains,” indicating the first component ID of the pair identifies a component that contains the component identified by the second component ID of the pair; (12) Manages  1222 , which stores a “manages” relationship between components; and (13) Groups  1224 , which contains information about various groups of LMUs defined for the router. 
     In the exemplary data schema shown in  FIGS. 12A-B , the Component Type table  1202  contains ID/description pairs that describe each of the different types of components in the automated lighting system. The IDs, or identifiers, are used in the CT ID column of the Component table  1212 . The Address  1204 , Manufacturer  1206 , Maintainer  1208 , and Administrator  1210  tables include rows that provide descriptions of addresses, in the case of the Address table, and individuals or organizations, in the case of the Manufacturer, Maintainer, and Administrator tables. Each entry in the component table  1212  describes a different component within the automated lighting system. Each component is identified by an identifier, or ID, in the first column  1230  of the component table. Each component has a type, identified by the component-type identifier included in the second column  1232 . Each component has a manufacturer, identified by a manufacturer ID in the third column  1234  of the Component table  1212 , where the manufacturer IDs are manufacturer identifiers provided in the first column  1236  of the Manufacturer table  1206 . Components are additionally described by warranty information, in columns  1240  and  1242 , an installation date, in column  1244 , a serial number, in column  1246 , references to rows in the Elec, Software, and other tables in columns  1248 ,  1250 , and additional columns not shown in  FIG. 12A , and by a GPS location, in column  1252 . Many other types of information may be included in additional columns that describe components. The Elec table  1214  describes various electronic characteristics of a component, including the estimated lifetime, in column  1254 , an accumulated runtime for the component, in column  1256 , the number of power-on events associated with the component, in column  1258 , and various thresholds, in columns  1260 ,  1262 , and additional columns not shown in  FIG. 12B , for triggering events associated with a component. As one example, column  1260  includes a run time alert that specifies that the lighting-control system should take some action when the accumulated runtime hours are equal to or greater than the threshold value shown in column  1260 . The Software and Mechanical tables  1216  and  1218  include various characteristics for software components and mechanical components. Each group, in the Groups table  1224 , is described by an ID, in column  1270 , a name, in column  1272 , various IDs for administrators, maintainers, and other service providers associated with the group in columns  1274 ,  1276 , and additional columns not shown in  FIG. 12B , the component ID of a router associated with a group, in column  1278 , and the current schedules for the group, in an unstructured column  1280 . 
     Information stored in exemplary data schema shown in  FIGS. 12A-B  allows for responding to many different types of queries generated by user-interface routines executed on a router or network data center. For example, if a user of the router-provided user interface wishes to find all poles, or light fixtures, in the Supermall parking lot group, the following SQL query can be executed by router user-interface routines to provide serial numbers and GPS coordinates for the identified poles: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 Select GPS, SerialNo 
               
               
                   
                 From Component C, ComponentType CT 
               
               
                   
                 Where C.CTID = CT.ID AND 
               
               
                   
                  CT. Description = ‘pole’ AND 
               
               
                   
                  C.ID IN 
               
               
                   
                   (Select CID2 From Manages M1 
               
               
                   
                   Where M1.CID1 
               
               
                   
                    (Select CID2 From Manages M2 
               
               
                   
                    Where M2.CID1 IN 
               
               
                   
                     (Select RID From Groups G 
               
               
                   
                     Were G.Name = ‘Superman Pkg’ 
               
               
                   
                     ) 
               
               
                   
                    ) 
               
               
                   
                   
               
            
           
         
       
     
     In certain examples of the currently described lighting systems, a database stored locally within the router or stored in a database management system accessible to the router via the network-control center may automatically trigger generation of messages sent from the router to LMUs when data is added or updated. In other examples of the currently described lighting systems, the user interface routines may execute queries to update the database, in response to user input through the user interface, and, at the same time, generate commands for transmission to LMUs, when appropriate. In certain cases, a separate, asynchronous router routine may periodically compare the contents of the database to information stored within the LMUs to ensure that the information content of the LMUs reflects the information stored within the database. In general, the information stored within the LMUs, including status, run-time characteristics, definitions of sensors, and other such information, is also stored in the database of the router. 
     Routers exercise control over LMUs through a command interface.  FIG. 13  shows various commands used in router-to-light-management-unit communications. These commands include: (1) the set-time command, which sets the time stored with an LMU; (2) the define-groups command, which sets entries in the list of groups ( 1112  in  FIG. 11 ) to which an LMU belongs; (3) the define-schedule command, which is used to define schedules stored within LMUs; (4) the define-input/output command, which defines the various sensor devices and associated events within LMUs; (5) the force-lamp-state command, which provides for manual operation of a lighting unit via the LMU by a user interacting with the router through the user interface or, in alternative examples, by a user interacting with a cell phone; (6) the report-status command, which solicits status information by the router from LMUs; (7) the report-status-command reply, several forms of which are used to respond to report-status commands received by LMUs; (8) the event command, which reports events and which can be sent by any unit; (9) the set-operating-hours command, which allows the router to set various electrical characteristics for components within a lighting fixture maintained by an LMU; (10) the define-lamp-characteristics command, which allows the router to store particular lamp characteristics for lighting elements within the LMU that manages those lighting elements; (11) the firmware-update command, which prepares an LMU for reception of a firmware update; (12) the backdoor command, a debugging command used to obtain data from LMUs; and (13) the add/remove command, which informs a bridging LMU of the addition or deletion of an end-point LMU from the bridging LMU&#39;s power-line network.  FIGS. 14A-N  show the data contents of the various commands and replies discussed above with reference to  FIG. 13 . The tables describing data fields of messages, provided in  FIGS. 14A-N , are self-explanatory, and are not discussed further. 
       FIGS. 15-18  provide flow-control diagrams for the control functionality with a light-management unit.  FIG. 15  provides a control-flow diagram for an LMU event handler, which responds to events that arise within an LMU. The event handler waits for a next event to occur, in step  1502 , and then determines which event has occurred, and responds to the event, in the set of conditional statements, such as conditional statement  1504 , that follow the wait step  1502 . The event handler runs continuously within the LMU. When an asynchronous sensor event has occurred, such as the output signal from a photocell transitioning from on to off or from off to on, as determined in step  1504 , then the event descriptor for the event is found in the table of events ( 1116  in  FIG. 11 ) and updated. When a timer has expired indicating that it is time to check the various events for which event descriptors are supplied in the list of events ( 1116  in  FIG. 11 ), a check-events routine is called, in step  1508 . When the event corresponds to queuing of an incoming message to an incoming message queue, as determined in step  1510 , then a process-received-commands routine is called in step  1512 . When the event corresponds to queuing of an outgoing message to an outgoing-message queue, as determined in step  1514 , then a process-outgoing-commands routine is called in step  1518 . When the event represents expiration of a timer controlling periodic checking of the stored operational schedule, as determined in step  1520 , then a check-schedule routine is called in step  1522 . Any of various other events that may occur are handled by a default event handler, evoked in step  1524 . The events explicitly handled in  FIG. 15  are merely a set of exemplary events, used to illustrate overall functionality of the LMU event handler. 
       FIG. 16  provides a control-flow diagram of the check-events routine, called in step  1508  of  FIG. 15 . In the for-loop of steps  1602 - 1608 , each event descriptor in the list of event descriptors ( 1116  in  FIG. 11 ) within an LMU is considered. If the event is described as being active, or having more recently occurred than handled, then, in general, a message reporting the event is queued to an outgoing message queue, in step  1604 , and, when local action is warranted, as determined in step  1605 , the event is handled locally in step  1606 . Following message queuing and local handling, the event status is reset, in step  1607 . Other types of events may be reported, but not handled locally. Other types of events may bath be reported to the router as well as handled locally. For example, a temperature-sensor event may elicit local activation or deactivation of a heating element in order to locally control temperature. 
       FIG. 17  provides a control-flow diagram of the routine “process received commands” called in step  1512  of  FIG. 15 . The next command is dequeued from an incoming command queue in step  1702 . When the command is a retrieve-information command, as determined in step  1704 , then the appropriate information is retrieved from the information stored by the LMU and included in a response message that is queued to an outgoing-message queue, in step  1706 . A queue-not-empty event is raised, in step  1708 , upon queuing the message to the outgoing message queue. When the command is a store-information command, as determined in step  1708 , then information received in the command is stored into the appropriate data structure within the LMU, in step  1710 . When an acknowledgement is needed, as determined in step  1712 , then an acknowledgement message is prepared, in step  1714 , and queued to the outgoing message queue. When the command elicits local action, as determined in step  1716 , then the local action is carried out in step  1718  and, when an acknowledgment message is required, as determined in step  1720 , the acknowledgement message is prepared and queued in step  1714 . When the command queue is empty, as determined in step  1722 , then the routine ends. Otherwise, control returns to step  1702  for dequeuing the next received command. 
       FIG. 18  provides a control-flow diagram for the routine “check schedule,” called in step  1522  of  FIG. 15 . In the for-loop of steps  1802 - 1810 , each entry in the schedule ( 1118  in  FIG. 11 ) stored locally within the LMU is considered. Current time is compared to the start-time and end-time entries of the currently considered schedule, in step  1803 . When the current time is within the range specified by the start-time and end-time entries of the currently considered schedule event or entry, then, in the inner for-loop of steps  1805 - 1809 , each lighting element within the light fixture controlled by the LMU is considered. When the currently considered lighting element is within the group for which the schedule entry is valid, as determined by comparing the group ID of the schedule entry with the group ID of the lighting element, then when the current lighting-element output is different from that specified by the schedule, then, in step  1808 , the LMU changes the output of the lighting element to that specified in the schedule by altering the voltage or current output to the lighting element. 
       FIG. 19  provides a state-transition diagram for one router user interface. When a user interacts through a user interface with a router, the router initially displays a home page  1902 . The user may wish to view data, update and modify data, or manually control one or more LMUs and, in certain examples of the currently described lighting systems, may select one of these three types of interactions and undergo authorization in order to carry out these types of actions through one or more authorization pages  1904 - 1906 . Users may be required to provide passwords, pass fingers over fingerprint identifiers, provide other information that authorizes the user to carry out these and other types of tasks by interacting with the user interface. Various sets of web pages may allow a user to view or modify groups defined for LMUs and the association of LMUs with groups, calendar-like schedule of desired lighting operation, information regarding lighting fixtures and components contained within lighting fixtures, and information regarding fixture locations, including the ability to view fixture locations overlaid onto maps or photographic images of the area within which the LMUs are contained. There are a large number of different possible user interfaces that can be devised to provide interactive control of LMUs and lighting fixtures managed by a particular router. Similar user interfaces may be provided at the network-control center level. 
       FIGS. 20-26  provide additional description of the radio-frequency-enabled light-management unit (“RF-Enabled LMU”) discussed above with reference to  FIG. 7 .  FIG. 20  shows a block diagram for the RF-enabled LMU that represents one example of the currently described lighting systems, similar to the block diagram shown in  FIG. 7 , with additional detail and with dashed-line indications of subcomponents, circuit diagrams for which are provided in  FIGS. 21-26 . The circuit diagrams provided in  FIGS. 21-26  include addition description of the following subcomponents, indicated by dashed-line rectangles in  FIG. 20 : (1) the microprocessor  2002 ; (2) the optocouple-isolation subcomponent  2004 ; (3) the switched-relay subcomponent  2006 ; (4) the internal-power-supply subcomponent  2008 ; and (5) a power-meter subcomponent  2010 . The power-meter component  2010  is an integrated-circuit-implemented power meter that monitors power usage of the luminaire or luminaires that receive electrical power through the AC power lines  2012 - 2013 . Software routines within the RF-enabled LMU query the power-meter component  2010 , generally at regular intervals in time and/or upon requests received from a router or network control center, in order to monitor power usage by the luminaire or luminaires managed by the RF-enabled LMU and report the power usage back to the router or network-control centers. 
       FIG. 21  provides additional description of the microprocessor component ( 2002  in  FIG. 20 ) of the RF-enabled LMU. The microprocessor  2102  includes a large number of pins, to which external signal lines are coupled, that provide an interface between the microprocessor and other RF-enabled-LMU components. In  FIG. 21 , the pins are numerically labeled from 1 to 32. Interrupt-like signals  2104 - 2105  are input to pins  12  and  13  by various sensor or monitor components of the RF-enabled LMU. The microprocessor outputs a relay signal  2106  to the switched-relay component ( 2006  in  FIG. 20 ) to disconnect the luminaire from the AC power source. The microprocessor receives a signal  2108  from a thermistor temperature sensor in order to monitor the temperature within the light-fixture housing in which the RF-enabled LMU resides. A group of signals  2110  provide a universal-asynchronous-receiver-transmitter (“UART”) interface to the wireless module ( 704  in  FIG. 7 ) and another group of signal lines  2112  provides an interface to the power-line communications module ( 706  in  FIG. 7 ). Signal lines  2114 - 2115  provide a clock input to the microprocessor and the group of signal lines  2116  implements a serial-peripheral-interface (“SPI”) bus interface to the power-meter component ( 2010  in  FIG. 20 ). Another group of signal lines  2118  implements a pulse-width-modulation output. Several pins connect the microprocessor to internal DC power  2120  and to ground  2122 . The microprocessor  2102  includes flash memory for storing software programs that implement control and communications functionalities of the RF-enabled LMU, as well as traditional processor subcomponents, including registers, arithmetic and logic units, and other such subcomponents. Any of a variety of different microprocessors may be employed in RF-enabled LMUs. 
       FIG. 22  provides a circuit diagram for a portion of the optocouple-isolation subcomponent ( 2004  in  FIG. 20 ) of the RF-enabled LMU. Input and output lines are electronically isolated from one another by an optical connection  2202  in which electronic signals are converted to light signals and the light signals converted back to electronic signals by a light-emitting diode (“LED”) and photodiode, respectively. 
       FIG. 23  provides a circuit diagram for the switched-relay component ( 2006  in  FIG. 20 ) of the RF-enabled LMU. When the relay signal  2302  is deasserted, a solenoid switch or solenoid-switch-like device  2304  conductively interconnects input AC power to output AC power. However, when the relay signal  2302  is asserted by the microprocessor ( 2102  in  FIG. 21 ), the solenoid decouples the input AC power lines from output AC power lines, thus disconnecting the luminaire from the main input power lines. When the microprocessor is not functioning, and prior to assertion of control over a light fixture by the microprocessor and microprocessor-resident software control programs within the RF-enabled LMU, the luminaire is connected to the AC-input main power lines, as a default state. Thus, prior to initialization of the microprocessor and control programs, and whenever the microprocessor and/or control programs fail to actively control the components of the light fixture, the luminaire is directly connected to the main power lines. As discussed above, the luminaire may be disconnected from the main power lines under RF-enabled LMU control as a result of commands received from a router or network-control center. 
       FIG. 24  provides a circuit diagram for the internal-power-supply component ( 2008  in  FIG. 20 ) of the RF-enabled LMU. Input AC power  2402 - 2403  is rectified and stepped down, by a rectifier and transformer  2404  to produce five-volt internal DC output  2406 . The output power signal is stabilized by stabilization circuitry and components, including capacitor  2408 . 
       FIG. 25  provides a circuit diagram for the power-meter component ( 2010  in  FIG. 20 ) of an RF-enabled LMU. The power meter is implemented as an integrated circuit  2502  that interfaces to the microprocessor via the SPI bus interface  2504  discussed above with reference to  FIG. 21 . 
       FIG. 26  provides a circuit diagram for a circuit that interconnects output from a sensor or monitor device  2602  to an interrupt-like input  2604  to the microprocessor. The output signal  2604  is asserted when the voltage drop across sensor-output signal lines is greater than a threshold value. 
     For many reasons, light-emitting-diode (“LED”) based area lighting, including street lighting, is rapidly becoming a preferred lighting technology in many applications, including street-lighting applications. LED-based luminaires provide significantly greater energy efficiency than incandescent bulbs, fluorescent lighting elements, and other lighting element technologies. LED-based luminaires can be implemented and controlled to produce output light with desired spectral characteristics, unlike many other types of lighting elements, which output light of particular wavelengths or wavelength ranges. LED-based luminaires can be quickly powered on and off, and achieve full brightness in time periods on the order of microseconds. The output from LED-based luminaires can be easily controlled by pulse-width modulation or by controlling the current input to the LED-based luminaire, allowing for precise dimming. LED-based luminaires tend to fail over time, rather than abruptly failing, as do incandescent or fluorescent lighting elements. LED-based luminaires have lifetimes that are longer than the lifetimes of other types of lighting elements by factors of between 2 and 10 or more. LED-based luminaires are generally more robust than other types of lighting elements, being far more resistant to shock and other types of mechanical insults. For these and other reasons, LED-based luminaires are predicted to largely replace other types of lighting elements in street-lighting applications during the next five to ten years. 
     However, despite their many advantages, LED-based luminaires have certain disadvantages, including a non-linear current-to-voltage response that requires careful regulation of voltage and current supplied to LED-based luminaires. In addition, LED-based luminaires are relatively temperature sensitive. For these and other reasons, RF-enabled-LMU control of LED-based luminaires may provide even greater advantages for LED-based lighting than for traditional types of lighting. For example, RF-enabled LMUs may include power meters and output-lumen sensors to facilitate automated monitoring of LED-based-luminaire output in order to determine when LED-based luminaires need to be replaced. In the case of traditional types of lighting elements, which abruptly fail, it is relatively easy for maintenance personnel to identify failed lighting elements. By contrast, since LED-based luminaires fail gradually, monitoring by RF-enabled LMUs can provide a far more reliable, automated system for monitoring and detecting failing LED-based luminaires than monitoring by maintenance personnel. In addition, the RF-enabled LMUs can monitor temperature within lighting fixtures at relatively frequent intervals and can automatically lower power output to luminaires and take other ameliorative steps to ensure that the temperature-sensitive LED-based luminaires remain within an optimal temperature range. 
       FIGS. 27-29  illustrate characteristics of LED-based lighting elements.  FIG. 27  shows a typical, small LED lighting device. The LED light source is a relatively small chip of semiconducting material  2702  across which a voltage dropped by a potential applied to the lighting device via anode  2704  and cathode 2706 elements. Typically, a semiconducting chip  2702  is mounted within a reflective cavity  2704  to direct light outward, in directions representing a solid angle defined by the reflective cavity. In higher-power LEDs, the semiconductor chip is of significantly greater size and generally mounted to a metal substrate to provide for greater heat removal from the larger semiconductor chip. 
       FIG. 28  illustrates a principal of LED operation. A semiconductor crystal that forms the light-emitting element of an LED device  2802  is differentially doped to produce a p-n junction  2804 . The p side of the crystal contains an excess of positive charge carriers, or holes, such as hole  2806 , and the n side of the semiconductor contains an excess of negative charge carriers, or electrons, such as electron  2808 . At the interface  2804  between the p and n portion of the semiconductor crystal, a shallow barrier region  2810  is formed in which electrons diffuse from the n side to the p side and holes diffuse from the p side to the n side. This barrier region represents a small potential-energy barrier to current flow. However, when a voltage is applied 2812 across the semiconductor in a forward direction, as shown in  FIG. 28 , referred to as “forward biasing,” the barrier is easily overcome, and current flows across the p-n junction. Reversing the polarity of the voltage source, referred to as “reverse biasing,” can induce current to flow through the semiconductor in the opposite direction, although, when reverse current flow is allowed to increase past a threshold reverse current, sufficient heat is generated to disrupt the semiconductor lattice and permanently disable the device. Asymmetrically doped semiconductor crystals, which implement p-n junctions, comprise the basic functional unit of many components of modem electronic systems, including diodes, transistors, and other components. In the case of a light-emitting diode (“LED”), when the semiconductor chip is forward biased, and current flows across the p-n junction, excited electrons combine with holes in a process by which the electrons transition to lower energy levels by releasing light of a specific wavelength. 
       FIG. 29  shows a current-versus-voltage curve for a typical LED. When 0 V is applied across the LED  2902 , no current passes through the LED. Forward biasing of the LED produces a small initial current which increases exponentially past a threshold forward-biasing voltage  2904 . Reverse biasing of the LED produces an exponential increase in reverse current flow past a breakdown-voltage threshold  2406 . The LED emits lights that when an applied forward-biasing voltage exceeds the threshold voltage  2904  in  FIG. 29 . However, the operational applied-voltage range within which light is emitted without sufficient current flow to destroy the semiconductor lattice is quite narrow. In other words, as shown in  FIG. 29 , a LED exhibits a high degree of non-linearity in current flow with respect to applied voltage, and even small increases in applied voltage in the exponential regions of the current-versus-voltage curve can induce sufficient current flow within the device to destroy the device. For this reason, unlike in incandescent and fluorescent light elements, control of voltage or current output to an LED-based luminaire needs to be relatively precise. LED-based area lighting fixtures generally employ LED driver components that rectify input AC power and that output either constant-voltage or constant-current DC power to the luminaire. 
       FIG. 30  illustrates a LED-based street-light luminaire. The LED-based street-light luminaire  3002 , shown inverted from normal installation orientation, includes a transparent cover  3004  through which light emitted by LED elements, such as LED element  3006 , in an array of LED elements  3008  passes to illuminate an area. The LED-based street-light luminaire includes a generally metallic housing  3010  with multiple fin-like projections, such as fin  3012 , to facilitate heat removal from the LED array. The LED-based street-light luminaire may also include an LED driver that acts as a constant-voltage or constant-current power source for the LED array. Input power and signal lines run through a collar-like fixture  3014  that also serves as a mechanical couple to a light-fixture bracket. In alternative types of LED-based street-light luminaires, the LED driver may instead be placed within a component of a light fixture other than the luminaire housing, shown in  FIG. 30 , and interconnected to the LED array by wiring threaded through the collar-like fixture. 
     Many types of LED drivers are commercially available. One popular LED driver, used in certain street-light applications, outputs a constant current of 0.70 A from input voltages of between 100V and 277V. The LED driver includes thermal-protection circuitry and tolerates sustained open-circuit and short-circuit events in the LED array. The LED driver is housed within a long, rectangular enclosure weighting under three pounds and with dimensions of approximately 21×59×37 centimeters. 
       FIGS. 31-33  illustrate one type of constant-output-current LED lamp driver.  FIG. 31  shows the LED-lamp-driver. The LED-lamp-driver drives a string, or series, of LEDs  3102  based on input AC power  3104  using a fixed-frequency pulse-width modulation controller integrated circuit  3106 .  FIG. 32  provides a functional block diagram for the integrated circuit ( 3106  in  FIG. 31 ) of the LED-lamp driver.  FIG. 33  provides a functional circuit diagram for the integrated circuit ( 3106  in  FIG. 31 ) within the LED-lamp driver. 
       FIG. 34  illustrates an RF-enabled LMU/LED-based-luminaire-driver module. As shown in  FIG. 34 , the RF-enabled-LMU/LED-base-luminaire driver  3402  includes the RF-enabled LMU components  702 ,  704 ,  708 ,  710 ,  707 ,  709 , and  716  discussed above with reference to  FIG. 7  as well as an additional switch relay  3406 , LED-driver output subcomponent  3408 , and a LED driver  3410  that rectifies and stabilizes input AC power to produce a constant-current DC output to an LED array  3412 . The additional switch relay  3406  is controlled in identical fashion as the switch relay  716  to ensure that, in a default mode prior to initialization of the RF-enabled LMU software or during periods of time in which the RF-enabled LMU is not actively controlling the light fixture, the LED driver is provided with input signals, in addition to input AC power, to drive light output from the LED array. 
     A problem that is addressed by a LED-driver-enhanced RF-enabled LMU is that the power factor for a LED-driver coupled to one or more luminaires is generally not 1.0, as would be desired for maximum light output for minimum current drawn from the main, but generally significantly less than one. When the power factor is 1.0, the waveform of the voltage matches that of the current within the load, and the apparent power, computed as the product of the voltage drop across the load and current that passes through the load, is equal to the power consumed within the load and ultimately dissipated to the environment as heat, referred to as the real power. Linear loads with only net resistive characteristics generally have a power factor of 1.0. By contrast, linear loads with reactive characteristics, due to capacitance or inductance in the load, store a certain amount of energy and release the stored energy back to the main during each AC cycle. Therefore the apparent power provided to the load exceeds the real power consumed by the load. Non-linear loads, including rectifiers and pulse-width-modulation-based dimming circuits, change the voltage and current waveforms in complex ways, and may result in power factors significantly below 1.0. LED-drivers include both rectifiers and pulse-width-modulation-based dimming circuits, and therefore represent non-linear loads that have power factors significantly below 1.0. 
     The problem with a power factor below unity is that more current is drawn by the load from the main power supplier than is actually used to generate power within the load. Although the excess current is not used in the load, and is returned to the power supplier through the main, the higher currents drawn by the load result in higher power losses during transmission, as a result of which power suppliers often charge higher rates for supplying power to devices with low power factors. Thus, for maximum cost and energy efficiency, the LED driver incorporated into a LED-driver-enhanced RF-enabled LMU needs additional circuitry and circuit elements to increase the power factor of the LED-driver-enhanced RF-enabled LMU and LED-driver-enhanced RF-enabled-LMU-controlled-luninaires to a value as close to 1.0 as possible. The power factor of reactive, linear loads can also be increased by offsetting inductance in the load with added capacitance or offsetting capacitance in the load with added capacitance inductance, referred to as “passive power factor correction.” The power factor of non-linear loads can be increased by using active circuit components, including boost converters, buck converters, or boost-buck converters, referred to as “active power factor correction.” Depending on the particular implementation of the LED driver included in a LED-driver-enhanced RF-enabled LMU, the LED-driver-enhanced RF-enabled LMU needs additional active-power-factor-correction components, and, in certain cases, may also employ additional passive-power-factor-correction components. In general, loads with power factors of between 0.95 and 1.0 are not subjected to higher fees by power suppliers, and thus the LED-driver-enhanced RF-enabled LMUs are desired to have power factors in excess that equal or exceed 0.95. An additional problem with LED drivers is that the power factor may decrease when dimming circuitry is active, due to pulse-width modulation that introduces additional harmonics into the voltage/current waveform. Thus, preferred LED-driver-enhanced RE-enabled LMUs include dynamic power-factor correction that can adjust to and correct dynamically the changing power factor of the LED-driver and coupled luminaires as the level of luminaire dimming changes. 
     Incorporation of an LED driver into the RF-enabled LMU provides a one-component solution for control of LED-based luminaires. For many reasons, the types of centralized monitoring and control of light fixtures made possible by RF enabled LMUs are of particular need in LED-based street-light fixtures. LED drivers and LED-based luminaires have narrow operational parameter ranges, including narrow operational temperature ranges and relatively strict requirements for input voltage and input current due to the non-linearity of LED lighting elements. While certain types of temperature monitoring and control circuitry can be included in LED drivers, RF-enabled LMUs provide a second level of centralized, remote monitoring of operational parameters and both local and remote control over lighting fixtures to minimize and/or eliminate occurrences of LED-driver-damaging and LED-array-damaging conditions. As discussed above, RF-enabled LMU control can provide for precise monitoring of power consumption and light output by LED-based luminaires in order to determine automatically and remotely the points in time at which luminaires need to be serviced and replaced. Furthermore, integrating the RF-enabled-LMU and LED-features together in a single module simplifies the design and manufacture of light-fixture components and reduces the cost of light fixtures. 
     The above-described automated lighting-control system is a complex, highly robust, distribution system for distributing light to customer facilities and regions. As discussed above, the automated lighting-control system includes one or more network control centers, multiple routers, and a large number of LMUs located within individual light fixtures that control operation of lighting elements as well as to collect sensor data and other information from the regions in which the light fixtures are located on behalf of routers and the network control center. All of this highly interconnected and centrally managed infrastructure can be used, as discussed above, for many additional purposes, including environmental sensing, security monitoring, traffic-flow analysis, and other such purposes. 
     With projected increases in fossil-fuel prices and decreases in fossil-fuel availability, significant research and development efforts have been, and are continuing to be, directed to developing electric vehicles. Already, major automobile manufacturers have developed and marketed capable electronic vehicles with reasonable driving ranges that operate entirely from stored electrical energy. However, a potential limitation to widespread acceptance of electrical vehicles involves current difficulties experienced by electrical vehicle owners involved with recharging their electrical vehicles while traveling and in locations other than their places of residence. Although electric-power distribution is available throughout the world in almost every populated region, convenient outlets for recharging electric vehicles are not widely available. Not only are convenient electric-power-dispensing units needed in locations accessible to drivers, but an entire infrastructure for providing electric-charge dispensing monitoring and transactions needs to be developed before convenient recharging of electric vehicles is possible. 
     The above-described automated lighting-control system is uniquely positioned, both geographically and commercially, to provide widespread and convenient electric-power distribution for recharging electric vehicles. First, because LMUs are already conveniently located near streets, parking lots, and other vehicle-accessible regions, and because the LMUs receive, monitor, meter, and dispense electrical power, the automated lighting-control system already dispenses electrical power at the very locations where it is potentially needed by electric-vehicle drivers. Second, because the automated lighting-control system is already robustly interconnected by a capable communications system, and provides communications facilities for transferring data to, and receiving data from, vehicle-accessible geographical locations, the automated lighting-control system infrastructure can be modified to provide for full-service dispensing of electric power for recharging electrical vehicles. 
       FIG. 35  illustrates one example of the currently described lighting systems. As shown in  FIG. 35 , a lighting fixture  3502  is controlled by the above-described automated lighting-control system, and has been enhanced for electric-power distribution by the addition of an automated kiosk  3504 , similar to various already-existing automated interfaces, including ATM machines, ticket-dispensing machines, and other such automated systems, to provide a transaction interface for electric-vehicle drivers. In addition, a number of street-accessible or parking-lot-accessible charge-dispensing units, such as charge-dispensing unit  3506 , are electronically connected to LMU control functionality as well as to the external power supply that powers the lighting fixture. The LMU control functionality is easily adapted to powering on, powering off, and metering the electric power dispensed through each charge-dispensing unit. In addition, the database management systems and control functionality within the network control center or centers and the routers is easily adapted to provide electric-power-dispensing transactions, control of electric-power dispensing through local automated kiosks, and centralized billing and accounting. 
       FIG. 36  illustrates certain of the enhancements made to the data stored within each LMU and enhancements to LMU functionality that are made to provide for electric-power distribution. Data structures are created and maintained by the LMU to describe the automated kiosk  3602  and each of the charge-dispensing units  3604 - 3605 . These data structures are equivalent to the data structures, shown in  FIG. 11 , that store information related to lighting fixtures and luminaires. In addition, the LMU is enhanced to include a kiosk-management module  3608  and a charge-dispensing-unit management module  3610  for automated control of the kiosk ( 3504  in  FIG. 35 ) and each of the charge-dispensing units ( 3506  in  FIG. 35 ). 
       FIG. 37  illustrates enhancements to the stored data and functionality within routers and/or network control centers. These enhancements include storage of relational tables or other data structures to describe electric-power-distribution customers  3702  and individual electric-power-distribution transactions  3704 . The routers and/or network control centers further include additional charge-distribution modules  3706 , a billing and accounting module  3708 , and a customer-management module  3710 . This stored information in additional modules provides for customer subscription, credit-card authentication and verification, transaction management and automated billing for electric-power distribution, and for real-time control of the automated kiosks and the power-distribution transactions. 
       FIGS. 38A-C  illustrate a representative electric-power-distribution transaction. These figures are divided into three columns, a left column  3802  corresponding to the customer/automated kiosk, a central column  3804  corresponding to the LMU control functionality, and a right-hand column  3806  corresponding to the router/control-center functionality. Referring now to  FIG. 38A , the transaction is initiated in step  3810  when a customer inputs a transaction-initiation input to the automated kiosk, generally by pushing a button or touching the screen as directed by the kiosk display. Upon receiving the customer input, the kiosk transmits, in step  3811 , an initiation signal to the kiosk-management module within the LMU. The kiosk-management module receives the initiation signal, in step  3812 , and initiates collection of data needed to carry out an electric-power-distribution transaction. In step  3813 - 3814 , the kiosk-management module transmits various data-input screens, or indications for the kiosk to display the various input-requesting screens, and the kiosk displays the input-requesting screens and receives appropriate customer input. Once the kiosk-management module has collected the information needed to conduct a power-distribution transaction, the kiosk-management module prepares a transaction-initiation message and transmits the message to a router or network-control center in step  3815 . In step  3816 , the router or network-control center receives the transaction initiation message, authorizes the transaction in step  3817  using a credit-card authorization service, comparing input information to information stored in the customer&#39;s relational table ( 3702  in  FIG. 37 ), and by other such means, and returns the authorization and fueling-permission message, in step  3818 , to the LMU. In step  3819 , the LMU receives the authorization from a fueling-permission message and, in steps  3820 - 3821 , carries out a display of fueling instructions and monitoring of the fueling process via information displayed by the kiosk, power-distribution metering and monitoring, and by other types of testing and monitoring. 
     Turning now to  FIG. 38B , once the customer has begun to carry out electric-vehicle recharging, in step  3822 , and the charge-dispensing unit and LMU have cooperated, in steps  3823  and  3824  to monitor and complete the power-distribution operation, a fueling-complete signal is generated, in step  3825 , either by customer interaction with the kiosk, by the LMU sensing a cable disconnect, charge completion, or other events, or by some other fashion, resulting in transmission of a fueling-complete signal, in step  3826 , to the LMU. In step  3827 , the LMU receives the fueling-complete signal and, in step  3828 , prepares a power-distribution-transaction-completion message which the LMU sends to the router and/or network control center. In step  3829 , the router and/or network control center receives the transaction-completion message, updates the transaction table and other stored database information, and returns an acknowledgement in step  3831  to the LMU. In step  3832 , the LMU receives acknowledgement and, turning to  FIG. 38C , transmits any final instructions and an acknowledgement, in step  3833 , to the automated kiosk. In step  3834 , the automated kiosk displays the final instructions and acknowledgement and, in step  3835 , re-initializes the kiosk display in preparation for carrying out another power-distribution transaction. 
     In general, the automated kiosk is capable of simultaneously carrying out as many power-distribution transactions as there are charge-distribution units associated with the LMU. The charge-distribution units may include an extendable power cord with an adaptor or adaptors compatible with electric vehicles. In many examples of the currently described lighting systems, the charge-dispensing unit can be controlled, by customer input to the kiosk and potentially by sensors within the charge-dispensing unit, to output a particular voltage and current compatible with the electric vehicle. Many different additional types of charge-dispensing units, automated kiosks, and other automated systems for carrying out power-distribution transactions are contemplated as alternative examples of the currently described lighting systems. 
     The automated control systems discussed above have been disclosed for controlling and monitoring lighting elements. However, the subject technology can provide for the management and controlled distribution of other types of resources, such as water. For exemplary embodiments of the subject technology, control systems can be utilized for controlling and monitoring irrigation systems as described below. 
       FIG. 39  illustrates an exemplary embodiment of an irrigation control system  3900  according to the present disclosure. The irrigation control system  3900  can be used to control an irrigation system that includes one or more irrigation lines  3910 , each having one or more apertures or orifices  3912  for supplying irrigation water to a desired area. For some applications, the orifices may be part of or located in sprinkler heads. Each line  3910  can include a valve  3914  for example, a shut-off valve, that is operative to control water flow through the line. The valves  3914  can be of any suitable type, such as butterfly valves. While each line  3910  is shown having its own valve  3914 , a single valve  3914  may be used to control the flow of water, or any other liquid, through all of the irrigation lines  3910 . The control system can include one or more sensors  3920  that operate to detect conditions associated with the irrigation systems and provide relevant data to an associated controller  3930  and/or linked second controller  3940 , e.g., a site controller. The controller  3930  is operative to control the valves  3914 , and may be linked to another controller, e.g., the site controller  3940 , by suitable communications link such a RF link. Any suitable communications protocol may be used for the communications link(s). For different applications and desired irrigation conditions, the irrigation system can be adjusted by the control system  3900  to a certain desired line pressure for a desired time period. Accordingly, the amount of water put on the ground by the irrigation system can be calculated as a function of time, among other parameters. This is because typically, an irrigation system operates optimally at a constant known pressure, and the amount of water distributed is calculated from the product of the time and the flow rate of the water. As such, if the pressure is not known, an accurate determination cannot be calculated in this way. If the pressure is too low, for example, the distribution of the water through the apertures or orifices  3912  will be insufficient to cover the desired area, and certain areas may be left unwatered. If the pressure is too high, overlap may result, or water may be sprayed on surfaces not intended to be watered, resulting in waste. Additionally, high pressure could also damage equipment, resulting in further cost and time wasted for maintenance and repair. The area of irrigation coverage (e.g., diameter of area from each sprinkler head) can be adjusted as desired based on line pressure. Though sprinkler heads are depicted for the orifices  3912 , other types of irrigation equipment may be used within the scope of the present disclosure, e.g., bubbles, drip irrigation lines, etc. 
     As noted above, the sensors  3920  can be used for the control of the irrigation system, and can measure a wide range of parameters and conditions. Any suitable device can be used as a sensor  3920 . Such sensors include, but are not limited to, soil moisture sensors, water pressure sensors, rain sensors, temperature sensors, wind speed sensors, humidity sensors, solar radiation sensors, light sensors, and may also include flow meters, etc. 
     The sensors  3920  can be positioned at any suitable location, e.g., in or near the coverage area of the irrigation system, and can be fixed or mobile. For example, a moisture sensor can be arranged on the surface of the soil or at a predetermined depth in the soil to detect the moisture level. Alternatively, a moisture sensor can be a portable device which is carried by a technician. In this case, the portable device can be part of a smart device (e.g., IPHONE®, IPAD®, or the like). The portable device can also be communicably coupled to the smart device, which can receive the various measurements from the sensors through, for example, a UBS port and then transmit the measurements to the central controller  3930  and/or site controller  3940 . 
     The sensors  3920  can communicate (e.g., for monitoring and/or reporting processes) with the central controller  3930 , and/or site controller  3940  through either hard-wired communications lines or known wireless communications links including, but not limited to, infrared and radio (RF) links (and may use any suitable protocols). For some applications, the control system  3900  may be connected to and accessed through the Internet or other suitable network (which may be local area or wide area). 
     The present disclosure allows a user of the irrigation system to receive information in real time regarding the status of the system. For example, by use of various sensors, such as a pressure sensor, the pressure in the irrigation line may be monitored. Because the information is received in real time, a user of the system can respond to incongruities, such as faulty valves or leaks, with the operation of the system immediately. Further, the user can detect faults in both the sensors and the controls in the system by comparing actual to expected behavior. For example, if the pressure reading indicates reduced pressure in the irrigation line, the user will be alerted to the possibility of a damaged or malfunctioning part in the system. In other examples, a broken irrigation line  3910  may be detected by the flow of water through a flow sensor  3920  when no flow is expected, or a broken sprinkler head  3912  may be detected by comparing the actual flow rate to the expected rate. Other examples include if a ground sensor reports dry soil after irrigation, the user may be alerted that the sensor is malfunctioning, or has been damaged or moved. Moreover, since the user may obtain the information in real time, the ability to respond to faults in the sensors or the system allows the user to prevent or reduce the extent of the damage caused by the malfunction. 
     For example, in the embodiment shown in  FIG. 40 , a method for irrigating includes the steps of supplying a liquid to an irrigation system (step  4001 ). When the liquid has been supplied to the irrigation system, and the desired pressure and flow rate has been established, the liquid may then be outputted to a desired area according to a predetermined schedule programmed in the processor (step  4002 ). Once in operation, a sensor is used for monitoring a property of the area (step  4003 ). The property may be any of those discussed above, such as soil conditions, moisture, water pressure, rain, temperature, wind speed, humidity, solar radiation, etc. 
     The data obtained by the sensor concerning the property is then communicated from the sensor to the controller (step  4004 ). The communication may be wireless, or with the use of wire transmittal technology. The controller, with the use of one or more processors, analyses the data received from the sensor (step  4005 ). The analysis may involve comparing the data with reference data stored in a memory associated with the processor. For example, if the moisture content of the soil is too low in a certain area, the processor may determine that extra pressure is required to increase the distance from which the liquid is outputted. Once the analysis is complete, the output of the liquid may be adjusted based on the data (step  4006 ). 
     In conventional irrigation control systems, there can be a need to have onsite moisture sensors at all times to continually monitor the amount of water supplied for irrigation. According to an aspect of the present disclosure, calibration may be utilized to eliminate or reduce the need for a moisture sensor to be permanently located onsite for constant use. For example, moisture levels for given locations (including soil conditions) can be calibrated versus time and/or temperature conditions. Accordingly, the irrigation control system can operate without or with reduced need for moisture sensors. 
     Although the present invention has been described in terms of particular embodiments, it is not intended that the invention be limited to these embodiments. Modifications will be apparent to those skilled in the art. For example, different hardware has been described for irrigation systems; other irrigation system components of any suitable type may be used within the scope of the present disclosure. 
     The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the invention. The foregoing descriptions of specific embodiments of the present invention are presented for purpose of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments are shown and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents: