US20180373209A1 - Control system, method and apparatus for utility delivery subsystems - Google Patents

Abstract

A control subsystem, for a utility delivery subsystem having an effector for enabling or disabling delivery of a utility from a source to an output device via a conduit, includes an effector host configured to receive the effector at a port. The effector host operates the effector in response to an instruction received via a wireless communications interface. The subsystem includes a control gateway having a two communications interfaces, a first to establish a connection with the effector host, and a second to connect to a network. The control gateway includes a memory storing schedule data received via the second interface, and a processor configured to send the instruction to the effector host via the first interface, based on the schedule data. The subsystem includes a server having a memory storing the schedule data and a server communications interface for transmitting the schedule data to the control gateway.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application claims priority from U.S. provisional application No. 62/269,791, filed Dec. 18, 2015, and U.S. provisional application No. 62/286,854, filed Jan. 25, 2016. The contents of the above-mentioned applications are incorporated herein by reference.
FIELD
• The specification relates generally to utility (e.g. water, lighting) delivery subsystems, and specifically to a control system, method and apparatus for such subsystems.
BACKGROUND
• Various systems for the delivery of utilities (e.g. water for irrigation, electricity for lighting and the like) are deployed over areas such as golf courses, parks and the like. In addition to delivery infrastructure, such as pipes, valves and nozzles for irrigation systems, it is also necessary to deploy means to control the infrastructure. The control components for an irrigation system may include actuators for valves, sensors for soil moisture, rainfall and the like. The deployment of such control systems can require the installation of substantial lengths of cabling throughout the above-mentioned areas to deliver power and operational signals to the delivery systems. Further, portions of the control systems are generally required to be placed in close physical proximity to corresponding components of the mechanical systems, and thus are also distributed over large areas. These requirements render the deployment of new delivery and control equipment difficult and costly.
SUMMARY
• According to an aspect of the specification, a control subsystem is provided for a utility delivery subsystem having an effector for enabling or disabling delivery of a utility from a source to an output device via a conduit. The control subsystem includes: an effector host having an effector wireless communications interface and a port configured to receive the effector; the effector host configured to operate the effector via the port in response to an instruction received via the wireless communications interface; a control gateway having a first communications interface configured to establish a connection with the effector host, and a second communications interface configured to connect to a network; the control gateway further including a memory storing schedule data received via the second communications interface, and a processor configured to send the instruction to the effector host via the first communications interface, based on the schedule data; and a server having a memory storing the schedule data and a server communications interface for transmitting the schedule data to the control gateway.
BRIEF DESCRIPTIONS OF THE DRAWINGS
• Embodiments are described with reference to the following figures, in which:
• FIG. 1 depicts a utility delivery and control system, according to a non-limiting embodiment;
• FIG. 2 depicts certain internal components of an effector host and a sensor host of the system ofFIG. 1, according to a non-limiting embodiment;
• FIG. 3 depicts certain internal components of a control gateway and a server of the system ofFIG. 1, according to a non-limiting embodiment;
• FIG. 4 depicts a method of subsystem control, according to a non-limiting embodiment;
• FIG. 5 depicts a method of generating and disseminating control data for a control subsystem, according to a non-limiting embodiment;
• FIG. 6 depicts a control gateway, according to another non-limiting embodiment;
• FIG. 7 depicts an effector host, according to another non-limiting embodiment;
• FIGS. 8A-8B depict control daughter boards for the effector host ofFIG. 7, according to another non-limiting embodiment;
• FIG. 9 depicts a sensor host, according to a non-limiting embodiment; and
• FIGS. 10 and 11 depict power sources for the components of the control subsystem, according to a non-limiting embodiment.
DETAILED DESCRIPTION OF THE EMBODIMENTS
• FIG. 1 depicts asystem100 comprising two subsystems, in the form of a utility delivery subsystem (also referred to herein as a delivery system) and a control subsystem (also referred to herein as a control system). The utility delivery subsystem, in general, includes a combination of devices and conduits for delivering a utility. The nature of the utility is not particularly limited, and can include materials such as water, as well as services such as lighting. In the present example, the delivery subsystem is configured to deliver water to a set of physical locations. More specifically, the delivery subsystem is an irrigation system configured to deliver water to a set of locations on a physical site orfacility102, such as a lawn, golf course, farm, park, or the like. In other examples, the delivery subsystem is a fire sprinkler system configured to deliver water to various locations within a facility (e.g. an office building) for fire suppression.
• Accordingly, in the present example the utility delivery subsystem includes autility source104, such as a municipal water supply line. The utility delivery subsystem also includes a plurality of delivery conduits108-1,108-2,108-3,108-4,108-5 and108-6 (collectively referred to asconduits108, and generically referred to as aconduit108; this nomenclature is also used for other elements discussed herein). As will now be apparent, any suitable number and arrangement ofconduits108 can be deployed in thesystem100. Theconduits108 include any suitable utility conduit, such as water pipes of any suitable construction.
• The delivery subsystem also includes a plurality of switching devices (also referred to herein as switches)112-1,112-2,112-3 and112-4 (as with theconduits108, any suitable number ofswitches112 can be provided), such as valves. As will now be apparent, theswitches112 act to control the delivery of the utility via theconduits108. Thus, in the example irrigation system, theswitches112 act to modulate the rate at which water flows through thecorresponding conduits108, from a null flow to a maximum flow. Further, the utility delivery subsystem includes a plurality of output devices116-1,116-2 and116-3 (although any suitable number of output devices can be deployed), such as sprinkler nozzles, drip nozzles or the like. The output devices can also simply be perforations in distal segments of theconduits108.
• As will now be apparent, the delivery subsystem receives the utility (e.g. water) from thesource104, and conveys the utility to the outputs116 via theconduits108 and theswitches112. The control subsystem serves to control the components of the delivery subsystem to convey the utility as mentioned above. Accordingly, the control subsystem of thesystem100 includes various devices and communications links to control the operation of the utility delivery subsystem. In the present example in which the utility delivery subsystem is configured to deliver water to the output devices116, the control subsystem is configured to control theswitching devices112 to vary (including, at least, enabling and disabling) the flow of water to each of the output devices116. Such control is, in the present example, implemented according to a predetermined schedule, to be discussed in greater detail below.
• The control subsystem includes at least one effector host control device120 (also referred to as an effector host). In the illustrated example, three effector hosts120-1,120-2 and120-3 are included. Theeffector hosts120 are each configured to connect to—and control the operation of—at least oneswitching device112, via either wired (solid lines inFIG. 1) or wireless connections (dashed lines inFIG. 1). As will be discussed in greater detail below, at least some of theeffector hosts120 are configured to connect to a plurality of switches112 (although not all available connections are required to be in use at any given time). For example, effector host120-3 is illustrated as being connected to two switches,112-3 and112-4. Eacheffector host120 is configured to monitor and transmit the current number ofswitches112 under its control, and to receive and implement control instructions for those switches. Although the effector hosts120 inFIG. 1 are all connected to valves, in other embodiments a variety of other types of effectors can also be controlled by corresponding types ofeffector hosts120.
• In addition to theeffector hosts120, the control subsystem includes at least one sensor host control device124 (also referred to as a sensor host). Thesensor host124 is configured to connect to, and receive sensor data from, at least onesensor128. In the present example, two sensors128-1 and128-2 are illustrated. Further, in the present example the sensor128-1 is a flow sensor configured to monitor fluid flow through conduit108-6 (i.e. the sensor128-1 is associated with the switch112-4), while the sensor128-2 is a soil moisture sensor. Various other types ofsensor128 are also contemplated (such as motion sensors, light level sensors, temperature sensors and the like). Thesensor host124 is configured to monitor the types of sensors connected thereto, receive the data from such sensors, and transmit the sensor data for further processing at another element ofsystem100. In some examples, eachsensor host124 is configured to handle only a single sensor type. In such examples, the system illustrated inFIG. 1 would require twosensor hosts124, one for each of the sensors128 (which are of different types). Further, in some examples, the control subsystem can includesensors128 that connect toeffector hosts120 rather than tosensor hosts124. For example, as shown inFIG. 1, a sensor128-0 in the form of a flow meter is placed to monitor flow immediately downstream of the switch112-1 (i.e. flow along the conduit108-1). The sensor128-0 is configured to connect to the effector host120-1 (via a wireless connection, such as Bluetooth) rather than to thesensor host124.
• In addition to the effector hosts120, the sensor hosts124 and thesensors128, the control subsystem includes acontrol gateway132. Thecontrol gateway132 is typically located withinsite102 or adjacent tosite102, as thecontrol gateway132 is configured to communicate via wireless links (e.g. WiFi, Bluetooth™, low power wide area networking technology such as LoRa, and the like) with the effector hosts120 and sensor hosts124. In particular, as will be discussed in greater detail below, the control gateway132 (also referred to herein as a hub) stores control data such as utility delivery schedule data. Based on the control data, as well as sensor data received from thesensor host124, thehub132 generates and transmits instructions to the effector hosts for controlling theswitches112.
• Further, the control subsystem includes aserver136 connected to thehub132 via anetwork140. Thenetwork140 can include any of a variety of local (e.g. WiFi) and wide-area networks (e.g. mobile networks, the Internet and the like), including both wired and wireless networks. Theserver136 is illustrated inFIG. 1 as being located off-site (i.e. not within the physical boundaries of site102). However, in other embodiments, theserver136 can be located within thesite102.
• Theserver136, in general, is configured to store the above-mentioned control data for transmission tohub132. As will be seen below, theserver136 is configured to generate the control data from transmission to thehub132 based at least in part on commands received from an operator computing device144 (e.g. a smartphone, personal computer or the like) connected to thenetwork140. Theserver136 is also, in some examples, configured to generate the control data based on additional information retrieved from other data sources, typically in the form of other servers (not shown) connected to thenetwork140. Such servers can store weather data, sunset and sunrise data, and the like.
• As will become apparent in the discussion below,control gateway132, effector hosts120, sensors hosts124 andsensors128 are specific to a givensite102 and a given delivery subsystem.Server136, on the other hand, can store and transmit control data to a plurality of control subsystems, for use in controlling the operation of various corresponding delivery subsystems disposed at different sites. To that end, theserver136 is also configured, for each control subsystem (that is, for each site102), to store identifiers of the components of the control subsystem and corresponding delivery subsystem, and to cooperate with theoperator device144 and thehub132 at each site in order to facilitate the reconfiguration of the control and delivery subsystems as needed. Examples of reconfiguration include the addition or removal of aswitch112, the addition or removal of aneffector host120, and the like.
• Before a more detailed discussion of the functions performed by the components ofsystem100, and particularly the functions performed by the control subsystem, certain internal components of the effector and sensor hosts120 and124, as well as thehub132 and theserver136 will be discussed.
• Turning toFIG. 2A, certain internal components of aneffector host120 are depicted. The components of theeffector host120 are typically housed in a substantially watertight enclosure (not shown), to protect the components from the elements at the deployed location within thesite102 of theeffector host120. Theeffector host120 includes a central processing unit (CPU)200, also referred to herein as aprocessor200, interconnected with amemory204. Thememory204 stores computer readable instructions executable by theprocessor200 to configure theprocessor200 to perform various functions discussed herein. Theprocessor200 and thememory204 are generally comprised of one or more integrated circuits (ICs), and can have a variety of structures, as will now occur to those skilled in the art.
• Theeffector host120 also includes acommunications interface208 interconnected with theprocessor200, which allows theeffector host120 to communicate with thehub132, for example via a wireless link such as a Bluetooth™ Low Energy (BLE) link or a LoRa link. Thecommunications interface208 thus includes the necessary hardware, such as network interface controllers and the like, to communicate with thehub132. Further, theeffector host120 includes aneffector control interface212 interconnecting theprocessor200 with effectors. In the present example, the effectors areswitches112; theinterface212 therefore includes a plurality of physical connections (e.g. ports, slots for receiving circuit boards or the like), each configured to connect to oneswitch112. Theinterface212 can also establish wireless connections; thus, in some embodiments one or more ports can be provided by a transceiver (e.g. a Bluetooth transceiver). Three ports are illustrated, although it is contemplated that a variety of port configurations can be deployed. For example, as will be seen below,system100 employs a combination of eight-port host effectors and single-port host effectors.
• In the example ofFIG. 2A, one of the three illustrated ports is currently active (i.e. connected with a switch112), while another two ports are inactive. Theinterface212 can therefore include any suitable combination of components for supplying power and control signals to switches112. For example, when theswitches212 are solenoid-activated, theinterface212 can be configured to receive solenoid driver boards each configured to connect to and power a valve.
• Theeffector host120 also includes a power supply (not shown) for supplying electrical power to the above-mentioned components. The power supply can be any one of or combination of a variety of suitable power supplies, including batteries, solar panels and the like.
• Thememory204 stores effectorcontrol data216, including an identifier of theeffector host120 itself (typically preprogrammed at the time of manufacture, e.g. a MAC address or any other suitable identifier to distinguish theeffector host120 from the other components of the system100). Thecontrol data216 also includes a host type indicator. Further, thecontrol data216 includes, for each port of theinterface212, a status indicator (i.e. whether the port is active or inactive). Examples ofeffector control data216 for effector hosts120-1 and120-3 are shown below in Tables 1 and 2.

• TABLE 1
  Example Effector Control Data - Effector Host 120-1

  	Field	Value
  	Host ID	EH-120-1
  	Host Type	Valve
  	Port 0 Status	Active
  	Port 1 Status	Active
  	Port 1 Type	Flow

• TABLE 2
  Example Effector Control Data - Effector Host 120-3

  	Field	Value
  	Host ID	EH-120-3
  	Host Type	Valve
  	Port 0 Status	Active
  	Port 1 Status	Inactive
  	Port
  2 Status	Inactive
  	Port 3 Status	Inactive
  	Port 4 Status	Active
  	Port 5 Status	Inactive
  	Port 6 Status	Inactive
  	Port 7 Status	Inactive

• Theeffector control data216 of Table 1 indicates that the effector host120-1 is a valve host with a single valve port and a single sensor port, which are both currently active (that is, the valve port has a solenoid driver or other wired or wireless valve actuator connected thereto; and the sensor port has the flow sensor128-0 connected thereto). The effector control data of Table 2, meanwhile, indicates that the effector host120-3 is a valve host with eight ports, two of which (corresponding to the switches112-3 and112-4 seen inFIG. 1) are currently active. Eacheffector host120 is configured, upon startup, to assess the status of each port identified in theeffector control data216 in thememory204, and to update the status values as needed. As a result, effectors (e.g. switches112) can be added and removed by rebooting the correspondingeffector host120. In other examples, effectors may also be hot-swapped, negating the need to restart theeffector host120.
• Referring now toFIG. 2B, certain internal components of asensor host124 are depicted. The components of thesensor host124 are typically housed in a substantially watertight enclosure (not shown), to protect the components from the elements at the deployed location within thesite102 of thesensor host124. Thesensor host124 includes aCPU250, also referred to herein as aprocessor250, interconnected with amemory254. Thememory254 stores computer readable instructions executable by theprocessor250 to configure theprocessor250 to perform various functions discussed herein. Theprocessor250 and thememory254 are generally comprised of one or more integrated circuits (ICs), and can have a variety of structures, as will now occur to those skilled in the art.
• Thesensor host124 also includes acommunications interface258 interconnected with theprocessor250, which allows thesensor host124 to communicate with thehub132, for example via a wireless link such as a BLE link or a LoRa link. Thecommunications interface258 thus includes the necessary hardware, such as network interface controllers and the like, to communicate with thehub132. Further, thesensor host124 includes asensor control interface262 interconnecting theprocessor250 withsensors128. In particular, theinterface262 includes a plurality of wired or wireless connections (e.g. ports, slots for receiving circuit boards or the like), each configured to connect to onesensor128. As noted earlier in connection with theinterface212, the ports, as they are referred to below, may be physical connections or may permit the establishment of wireless connections via a transceiver. In the example ofFIG. 2B, one port is currently active (i.e. connected with a sensor128), while another two ports are inactive. Theinterface262 can therefore include any suitable combination of components for supplying power to thesensors128 and receiving sensor data from thesensors128.
• Thesensor host124 also includes a power supply (not shown) for supplying electrical power to the above-mentioned components. The power supply can be any one of or combination of a variety of suitable power supplies, including batteries, solar panels and the like.
• Thememory254 storessensor control data266, including an identifier of thesensor host124 itself (typically preprogrammed at the time of manufacture, e.g. a MAC address or any other suitable identifier to distinguish thesensor host124 from the other components of the system100). Thecontrol data266 also includes a host type indicator, and for each port of theinterface262, a status indicator (i.e. whether the port is active or inactive) and a type indicator identifying the type of sensor connected to the port. The sensor type indicators can be provided by the sensors themselves. In other examples, eachsensor host124 is configured to handle only a single type of sensor; in such embodiments, the host type indicates the type of sensor, and the port-specific fields include only status indicators. Examplesensor control data266 forsensor host124 is shown below in Table 3.

• TABLE 3
  Example Sensor Control Data -Sensor Host 124

  	Field	Value
  	Host ID	SH-124
  	Host Type	Sensor
  	Port 0 Status	Active
  	Port 0 Type	Flow
  	Port 1 Status	Active
  	Port 1 Type	Moisture

• As seen in Table 3,sensor host124 is identified as a sensor host by the type indicator, and the port status data indicates not only whether or not each port is active, but also what type of sensor is connected to each port. Eachsensor host124 is configured, upon startup, to assess the status of each port identified in thesensor control data266 in thememory254, and to update the status and sensor type values as needed. As a result,sensors128 can be added and removed by rebooting the correspondingsensor host124. In other examples, sensors may also be hot-swapped, negating the need to restart thesensor host124.
• Turning now toFIG. 3A, certain internal components of ahub132 are depicted. The components of thehub132 are typically housed in a substantially watertight enclosure (not shown), to protect the components from the elements at the deployed location within thesite102 of thehub132. As will be apparent to those skilled in the art, in the present example of an irrigation system, the effector and sensor hosts120 and124 are deployed in physical proximity to the corresponding portions of the water delivery subsystem, and are therefore exposed to wind, rain and the like. Thehub132 may be installed at a greater remove from the elements of the water delivery subsystem, but may still be deployed outdoors at thesite102 to ensure reliable communications are established between thehub132 and thehosts120 and124.
• Thehub132 includes aCPU300, also referred to herein as aprocessor300, interconnected with amemory304. Thememory304 stores computer readable instructions executable by theprocessor300 to configure theprocessor300 to perform various functions discussed herein. Theprocessor300 and thememory304 are generally comprised of one or more integrated circuits (ICs), and can have a variety of structures, as will now occur to those skilled in the art.
• Thehub132 also includes alocal communications interface308 interconnected with theprocessor300, which allows thehub132 to communicate with the effector and sensor hosts120 and124, for example via a wireless link such as a BLE link or a LoRa link. Thecommunications interface308 thus includes the necessary hardware, such as network interface controllers and the like, to communicate with thehosts120 and124. Thehub132 also includes aremote communications interface310 interconnected with theprocessor300, which allows thehub132 to communicate with theserver136 via thenetwork140. Theinterface310 can be based on any suitable wireless or wired link, and therefore includes any necessary hardware (e.g. transceivers and the like) to implement such a link. In the present example, theinterface310 is configured to establish a connection with a mobile network (e.g. GSM, 3G or the like). In other examples, theinterface310 can enable, instead of or in addition to the above-mentioned mobile link, a WiFi link.
• Further, thehub132 includes adisplay312 and aninput device316, such as a keypad, touch screen, button panel or the like. In other examples,display312 andinput device316 can be omitted. Thehub132 also includes a power supply (not shown) for supplying electrical power to the above-mentioned components. The power supply can be any one of or combination of a variety of suitable power supplies, including batteries, solar panels and the like.
• Thememory254 storeshub control data320, including an identifier and type for thehub132 itself. The control data230 also includes control data corresponding to any effector hosts120 and sensor hosts124 to which thehub132 has been configured to connect (as will be discussed in greater detail below). In the present example, thecontrol data320 also includes a preconfigured network address (e.g. a MAC address, IP address, domain or the like) of theserver136.
• The control data corresponding to effector and sensor hosts120 and124 includes the above-mentioned host type, port status and (if applicable) port type fields. Further, thecontrol data320 includes schedule data for controlling the underlying utility delivery subsystem. An example of the portion of thecontrol data320 corresponding to effector and sensor hosts120 and124 is shown below in Table 4. As will be apparent to those skilled in the art, a wide variety of formats and data structures can be employed to store thecontrol data320; the tabular format shown below is simply for illustrative purposes.

• TABLE 4
  Example Hub Control Data

  	Host ID	Host Type	Port/Status/Type	Schedule
  	EH-120-1	Valve	0/Active	9:30pm-
  				1:30am
  			1/Active/Flow	N/A
  	EH-120-3	Valve	0/Active	10pm-1am
  			1/Inactive	N/A
  			2/Inactive	N/A
  			3/Inactive	N/A
  			4/Active	10pm-1am
  			5/Inactive	N/A
  			6/Inactive	N/A
  			7/Inactive	N/A
  	SH-124	Sensor	0/Active/Flow	N/A
  			1/Active/	N/A
  			Moisture

• As seen in Table 4, thecontrol data320 includes the host types and port status and (where applicable) type data as stored in thememories204 and254 discussed in connection with theeffector host120 and thesensor host124. In addition, thecontrol data320 includes schedule data for each active effector port. Thehub132 is configured to enable thecorresponding switch112 during the specified time periods. To enable aswitch112, thehub320 is configured to send an instruction, via theinterface310, to theeffector host120 corresponding to theswitch112. The instruction specifies the port to be controlled, and an indication of whether to enable or disable the port (i.e. to turn the delivery of water on or off). The schedule data shown above is received at thehub132 from theserver136, as will be discussed in greater detail below.
• Turning now toFIG. 3B, certain internal components ofserver136 are depicted. Theserver136 includes aCPU350, also referred to herein as aprocessor350, interconnected with amemory354. Thememory354 stores computer readable instructions executable by theprocessor350 to configure theprocessor350 to perform various functions discussed herein. Theprocessor350 and thememory354 are generally comprised of one or more integrated circuits (ICs), and can have a variety of structures, as will now occur to those skilled in the art.
• Theserver136 also includes acommunications interface358 interconnected with theprocessor350, which allows theserver136 to communicate with other computing devices, including thehub132, via thenetwork140. Thecommunications interface358 thus includes the necessary hardware, such as network interface controllers and the like, to communicate over thenetwork140.
• Theserver136 also includes a power supply (not shown) for supplying electrical power to the above-mentioned components. The power supply can be any one of or combination of a variety of suitable power supplies; typically theserver136 is supplied from a source of mains electricity, although the power supply can also include any other suitable source, including batteries, solar panels and the like.
• Thememory354 storesserver control data362. As will be seen below, thecontrol data362 includes the control data stored by thehosts120 and124 and thehub132, as well as additional control data employed by theserver136 to control the operation of thehosts120 and124 and thehub132. Thecontrol data362 also includes an account identifier; the identifiers of the control subsystem elements (hubs132, effector hosts120 and sensor hosts124) are stored in association with an account identifier; although a single account identifier is discussed herein, it is contemplated that theserver136 can store data for a plurality of distinct accounts (e.g. corresponding to distinct, separately operated sites102). In the example below, the account identifier also identifies theoperator device144. In other examples, separate account and device identifiers can be stored in association with each other. Table 5 includes an example of thecontrol data362.

• TABLE 5
  Example Control Data 362

  		Host	Host	Port/
  Account	Hub ID/	ID/	Type/	Status/
  ID	Location	Location	Subtype	Type	Schedule
  144	H132/	EH-120-1/	Valve/	0/Active	9:30pm-
  	[x, y]	[x, y]	Master		1:30am
  				1/Active/	N/A
  				Flow
  		EH-120-3/	Valve/	0/Active	10pm-1am
  		[x, y]	Standard
  				1/Inactive	N/A
  				2/Inactive	N/A
  				3/Inactive	N/A
  				4/Active	10pm-1am
  				5/Inactive	N/A
  				6/Inactive	N/A
  				7/Inactive	N/A
  		SH-124/	Sensor	0/Active/	N/A
  		[x, y]		Flow
  				1/Active/	N/A
  				Moisture

• As seen above, thecontrol data362 includes the identifiers and types of the effector hosts discussed earlier (the effector host120-2 is omitted for simplicity of illustration; in practice, thecontrol data362 includes identifier and type data for everyhost120 and124 in the control subsystem). Thecontrol data362 also includes the port status and (where applicable) type data for thehosts120 and124 as discussed above, as well as the schedule data.
• In addition, thecontrol data362 includes the locations of eachhub132 andhost120 and124. The locations can be stored in a variety of manners, including as GPS coordinates, coordinates in a frame of reference specific to thesite102, and the like. Although not shown above, thecontrol data362 can also include locations for each individual port on thehosts120 and124. As will now be apparent, such locations indicate not the physical location of the ports themselves, but rather of the delivery subsystem components connected to the ports. More generally, theserver136 can store a graphical map of thesite102 with the locations of theconduits108,switches112 and output devices116 indicated thereon. Locations for the ports can be specified within thecontrol data362 by storing coordinates from the map within thecontrol data362 for each port.
• Further, thecontrol data362 includes a subtype value for the effector hosts120. In the present example, two effector host subtypes are contemplated: a master effector host, and a standard effector host. In brief, a master effector host is aneffector host120 that is connected (via the interface212) to amaster switch112 enabling or disabling the delivery of water from thesource104 into the site102 (e.g. the switch112-1 inFIG. 1). Thus, the effector host120-1 inFIG. 1 is considered of the “master” type. A standard effector host, on the other hand, is aneffector host120 connected toswitches112 that control the flow of water (or any other utility) to distal conduits and output devices116. Thus, for example, the effector hosts120-2 and120-3 inFIG. 1 are standard effector hosts. There need not be any structural differences between the subtypes of effector host. Rather, the subtype can be configured (and reconfigured as necessary) within thecontrol data362; theserver136 is then configured to update the schedule data and propagate the schedule data as necessary.
• Having discussed the components of the major elements of the control subsystem, a description of the operation of those major components, and of thehub132 and theserver136 in particular, will now be provided. In brief, thehub132 is configured to monitor the status of the effector and sensor hosts120 and124 and report such status to theserver136. Thehub132 is also configured to receive schedule data from theserver136 and implement the schedule defined by the schedule data via the above-mentioned instructions to the effector hosts120. Theserver136, meanwhile, is configured to perform various functions related to account administration and communication with theoperator device144, generation of the schedule data and dissemination of the schedule data to thehub132.
• Turning toFIG. 4, amethod400 of local subsystem control is illustrated. Themethod400 is performed by thehub132, via the execution of computer-readable instructions stored in thememory304. Following startup, atblock405 thehub132 is configured to establish a communications link with theserver136. For example, thehub132 is configured to retrieve the preconfigured network address of theserver136 from thememory304, and transmit a connection request to theserver136. Thehub132 can be configured to present an error message on thedisplay312 if the attempt to establish a connection atblock405 fails. In some examples, thehub132 can also be configured to transmit the error message to theoperator device144, e.g. via Bluetooth or any other suitable peer-to-peer communications link, when theoperator device144 is within range of thehub132.
• Atblock410, thehub132 is configured to receive, via theinterface308, and store inmemory304 schedule and device data from theserver136. More specifically, thehub132 is configured to receive the control data shown in Table 4 from the server136 (which stores that data as a subset of the control data362). In general, the data received atblock410 informs thehub132 of which devices thehub132 is responsible for controlling (as asite102 may includemultiple hubs132, and eachhost120 or124 is assigned to only one hub132). The data received atblock410 also specifies the schedule according to which thehub132 is required to control those devices.
• Atblock415, thehub132 is configured to retrieve the host identifiers from thememory304 and establish network connections with each of the identified hosts120 and124 via theinterface310. The nature of the connections and the specific processes to establish those connections will be apparent to those skilled in the art based on the communications protocol implemented by the interface308 (e.g. BLE, LoRa). If any connections cannot be established (e.g. if the host effector120-2 is identified in thecontrol data320 but cannot be reached via the interface308), thehub132 is configured to report to the server136 (via the connection established at block405) the identifier of the device for which no connection has been established. Theserver136 can then be configured to transmit an alert to theoperator device144.
• Atblock420, having established connections with the devices identified in thecontrol data320, thehub132 is configured to receive and store port status data from each of the connected devices. For example, thehub132 can be configured to send a request to each of thehosts120 and124 for the status data stored inmemory204 and254. The performance ofblock420 can be repeated periodically during the operation of thehub132.
• At block425, thehub132 is configured to determine whether the port status data received atblock420 differs from the port status data received from theserver136 atblock410. When the determination at block425 is negative, the performance of themethod400 proceeds to block430, at which thehub132 is configured to send operational commands to the effector hosts120 based on the schedule data stored in thememory304. It is also contemplated that during the performance ofblock430, thehub132 is configured to receive sensor data from thesensor host124 and transmit the sensor data to theserver136. Thehub132 can also be configured to implement the schedule according to the sensor data. For example, more complex implementations of the schedule may specify that a given valve is to be enabled during a specified time period only if a threshold environmental condition is met (e.g. a temperature, soil moisture level, or the like).
• As noted earlier, the operational instructions sent by thehub132 to the effector hosts120 during implementation of the schedule include the identifier of therelevant effector host120, as well as the identifier of the relevant port to be enabled. Thehub132 can also be configured to listen for a confirmation message from theeffector host120 following each operational instruction. If no confirmation is received, or if the confirmation indicates that theeffector host120 has encountered an error (e.g. the solenoid driver connected to the specified port did not respond), thehub132 can be configured to report the error condition to theserver136 for subsequent transmission to theoperator device144.
• Returning to the determination at block425, when the determination is affirmative, the hub instead proceeds to block435. An affirmative determination at block425 indicates that there are effectors (e.g. valves) or sensors connected to thehosts120 and124 that are not accounted for in the schedule data received atblock410. Alternatively, the affirmative determination may indicate that an effector or sensor for which thehub132 does have control data is no longer present at site102 (or has ceased to operate normally if present).
• Atblock435, thehub132 is configured to transmit a message to theserver136 including an identifier of theaffected host120 or124, and an identifier of the port for which the status data has changed. If the port is a port of asensor host124, the message can also include the type of sensor associated with that port. As will be discussed in greater detail below, theserver136 is configured, responsive to the above-mentioned message, to notify theoperator device144 of the change and obtain updated control data.
• Atblock440, thehub132 is configured to receive updated schedule and device data from theserver136, to store the updated data in the memory304 (i.e. to update the control data320), and to then proceed to block430. As will now be apparent, there may be a delay between the transmission of the message atblock435 and the receipt of the updated data atblock440. During that time, thehub132 can be configured to performblock430. That is, thehub132 can be configured to implement the currently available schedule, ignoring effectors for which no schedule data is available.
• Turning now toFIG. 5, amethod500 of generating and disseminating control data for a control subsystem is depicted. Themethod500 is performed by theserver136, via the execution (by the processor350) of computer-readable instructions stored in thememory354.
• More specifically, themethod500 illustrates the actions taken by theserver136 to incorporate an additional device (e.g. an effector orsensor host120 or124, an individual effector or sensor, or even a hub132) into a control subsystem, and to provide therelevant hub132 with control data for the device. More generally, it will be appreciated in the discussion below that through the performance ofmethod500, theserver136 is enabled to ascertain the current population of devices in each control subsystem identified in thecontrol data362, and to prepare and disseminate schedule data for that current population.
• Atblock505, theserver136 is configured to receive, via thenetwork140 from theoperator device144, an identifier and a type of a device in a control subsystem. As mentioned above, theoperator device144 is associated with an account stored in thecontrol data362. If a request is received from an operator device that is not associated with an account, theserver136 is configured to prompt the operator device to create an account or authenticate with an existing account (e.g. by supplying a username and password) before continuing.
• The identifier and type received atblock505 can be obtained by theoperator device144 in a variety of ways. For example, theoperator device144 can be configured to scan a graphical indicator, such as a QR code, imprinted on the device (such as an effector host120) and decode the identifier and type from the captured graphical indicator. In other examples, theoperator device144 can receive the identifier and type via an input device such as a keyboard, or by connecting with the device via a peer-to-peer link (e.g. BLE) to obtain the identifier and type.
• Responsive to receiving the identifier and type atblock505, theserver136 is configured to retrieve the account record corresponding to theoperator device144 for further processing. Atblock510, theserver136 is configured prompt theoperator device144 for control parameters for the device identified atblock505, based on the type of the device. More specifically, theserver136 stores a list of device types (e.g. valve hosts, sensor hosts, hubs and the like) and corresponding lists of control parameters required for each device type. Therefore, theserver136 is configured to retrieve the list of control parameters corresponding to the type received atblock505, and to prompt theoperator device144 for values for those control parameters. Certain illustrative examples of the above-mentioned control parameters are discussed below.
• For ahub132, the control parameters include an assignment of host devices (i.e. the third column of Table 5); theserver136 is therefore configured to retrieve the identifiers of each host device in the control subsystem (regardless of the hubs to which they are currently assigned) and present those identifiers to theoperator device144 for selection. The control parameters for a hub also include a location (e.g. GPS coordinates, a selected location on a graphical representation of thesite102, and the like).
• For avalve effector host120, the control parameters include a subtype as described above (specifying whether the valve effector host is to be configured as a master valve controller or a standard valve controller), port status data indicating which ports on theinterface212 are active, and a location (e.g. GPS coordinates, a selected location on a graphical representation of thesite102, and the like). Theserver136 is further configured to prompt theoperator device144 for additional control parameters when the “master” subtype is selected. The additional control parameters include selections of which standard effector hosts120 control valves associated with the master valve (that is, valves connected to the master valve via conduits108). As will now be apparent, asite102 may have a plurality of master valves each admitting water to a distinct set ofconduits108. Theserver136 may also prompt for selection of a flow meter (e.g. sensor128-0) when the effector subtype is “master”.
• For asensor effector host124, the control parameters include port status and sensor type indicators. The control parameters can also include a location (e.g. GPS coordinates, a selected location on a graphical representation of thesite102, and the like). Further, for flow sensor types, the control parameters can additionally include an identifier of a valve associated with the flow sensor. For example, referring toFIG. 1, the flow sensor128-1 is shown as being immediately downstream of the switch112-4. In other words, the flow sensor128-1 measures the performance of the switch112-4. Thus, the control parameters for thesensor host124 can include, for the sensor128-1, an identifier of the port of the effector host120-3 to which the switch112-4 is connected. Theserver136 can be configured to prompt theoperator device144 to select from a list of currently configured effectors. In other examples, theserver136 can automatically select an effector having the same location as the relevant flow sensor. Theserver136 can also be configured to prompt theoperator device144 for other sensor parameters, such as flow sensor model numbers, calibration coefficients, pipe diameters and the like.
• Following the performance ofblock510, atblock515 theserver136 is configured to receive and store control parameters from theoperator device144, via thenetwork140. That is, theserver136 is configured to populate the control data362 (for example, as shown in Table 5) based on the selections and other data received from theoperator device144.
• Atblock520, theserver136 is configured to generate or update the schedule data for the control subsystem associated with the same account as theoperator device144. A wide variety of processes can be implemented by theserver136 to generate schedule data. In general, theserver136 is configured to select time periods of activity for at least a subset of the active ports of at least oneeffector host120, and preferably for each active port of eacheffector host120. Theserver136 can also select sensor data thresholds associated with at least one of the effector ports (e.g. a soil moisture or temperature threshold). The time periods can be specified via input data transmitted to theserver136 from theoperator device144, or determined automatically by theserver136. Such automatic determinations can also be based on data retrieved by theserver136 from other sources (e.g. servers storing meteorological data, not shown inFIG. 1).
• Theserver136 can also be configured to generate the schedule data based on previous flow measurements, where available. For example, theserver136 can be configured (e.g. responsive to instructions from the operator device144) to generate schedule data that enables effectors for sufficient time periods to deliver a predetermined target volume of water to thesite102, making use of the above-mentioned pipe diameters and historical measurements from flow sensors. As is evident from the example schedule data shown above, the any valves denoted as master valves are treated differently during schedule generation: theserver136 selects active time periods for any master valve that begin at least a configurable interval before the first standard valve downstream of the master valve is scheduled to open, and end at least a configurable interval (not necessarily the same configurable interval) before the last standard valve downstream is scheduled to close.
• Atblock525, theserver136 is configured to transmit the schedule data to the hub132 (ormultiple hubs132, if there is more than onehub132 associated with the site102) for storage and implementation. As will now be apparent, when the identifier and type for anew hub132 were received atblock505, theserver136 may not have a network address corresponding to the new hub. This may be remedied, for example, by the performance ofblock405 as described above by the new hub. More specifically, everyhub132 may be configured to establish a connection with the server132 (using the preconfigured network address of the server136). When an unconfigured hub132 (i.e. ahub132 that has not yet been associated with an account) contacts theserver136, theserver136 can be configured to store the identifier and network address of the hub in thememory354, but to take no further action with respect to that hub until a request associated with an account is received, as atblock505. Therefore, upon arriving atblock525, theserver136 can retrieve the network address of the hub from memory and employ that network address to transmit the schedule data.
• The example performance ofmethod500 described above sets out the mechanism insystem100 for deploying a new host (120 or124) orhub132 on thesite102. It may also be desirable, however, to add new effectors or sensors to existing hosts. As noted earlier, eachhost120 or124 is configured, upon startup, to assess the status of the ports of theinterfaces212 or262, respectively. When a change in the port status data is detected (e.g. a previously inactive port has become active), the host is configured to inform thehub132 of the newly activated port. Thehub132, in turn, is configured to transmit a report to theserver136 including the identifier of thehost120 or124 and an identifier of the activated port. Theserver136 is configured to receive the above-mentioned report at block505 (the type of the host device can be retrieved from the memory362), and to then proceed throughmethod500 to configure the newly added effector or sensor.
• Thehub132, theserver136 or both can also be configured to perform additional functions. For example, if the control subsystem includes a flow sensor, one or both of thehub132 and theserver136 can be configured to assess valve performance during schedule implementation. For instance, thehub132 can be configured to monitor flow data received from thesensor host124 beginning a configurable interval after the corresponding valve (in the example ofFIG. 1, switch112-4) has opened, and for a configurable period of time. The average flow during the period of time can be compared to a target flow stored in memory, and if the average flow does not meet the target flow (indicating a leak in a conduit, incomplete opening of the valve, or the like), thehub132 can report an error to theserver136, for transmission to theoperator device144. Flow measurements can also be monitored after all switches have been closed, to determine whether any switches have not properly closed.
• Example implementations of certain components of thesystem100 have been discussed above. Various other implementations are also contemplated, as will be discussed below.
• Turning toFIG. 6, ahub132ais illustrated according to another example implementation. The processor of thehub132amay include amaster MCU18. Themaster MCU18 may comprise an event-driven firmware architecture configured to enable all attached peripherals to run asynchronously. For instance, in various embodiments, themaster MCU18 comprises a 16-bit Microchip PIC24HJ128GP204 microprocessor. In various embodiments, themaster MCU18 runs at 40 MIPS, although any microprocessor at any speed may be implemented to achieve any desired metric, such as sufficient I/O throughput, power consumption, and peripheral support.
• Themaster MCU18 may compriseserial buses16 and22. Aserial bus16,22 may comprise a data communication bus configured to exchange data with a peripheral according to a serial data protocol. For instance, a cellular modem36 may be in operative communication with themaster MCU18 via aserial bus16. Moreover, a Bluetooth low energy (“BLE”)module20 may be in operative communication with themaster MCU18 via aserial bus22.
• The cellular modem36 may comprise a radio transceiver configured to communicate via cellular technology. In various embodiments, the cellular modem36 comprises a bidirectional communication device configured to send data to theserver136 via thenetwork140, and receive data and commands therefrom. Moreover, the cellular modem36 may receive commands via SMS messaging, which may override standing commands, may change parameters, and may perform internal maintenance tasks. In various embodiments, the cellular modem36 comprises a FCC pre-certified modem, for instance a GL865-Quad modem available from Telit. The modem may interface to a contracted cellular network provider and communicate directly with theserver136, thus, in certain instances, at least a portion of thenetwork140 may comprise a cellular communications network.
• The Bluetoothlow energy module20 may comprise a transceiver configured to send and receive data via Bluetooth radio technology. For instance, the Bluetoothlow energy module20 may enable thehub132ato communicate withhosts120,124, or directly with user devices such as theoperator device144, or to detect the presence of proximate assets, such as golf carts having Bluetooth transponders. The Bluetoothlow energy module20 may be a FCC pre-certified module. For instance, the Bluetoothlow energy module20 may be available from Bluegiga and/or Silicon Labs. Themodule20 may include an 8051 MCU and may be utilized as a scanner for all BLE modules broadcasting advertising packets. The Bluetoothlow energy module20 may receive commands from a compatible application running on a smart phone or other device, for instance, overriding current commands, changing parameters, and performing maintenance tasks. Moreover, theBLE module20 may be used for initial configuration of thehub132. For instance, in various instances, Wi-Fi credentials may be passed via theBLE module20.
• Themaster MCU18 may comprise anI2C bus24. An I2C bus comprises a communication bus operating according to the I2C protocol and configured to permit multiple slave devices to communicate with a master device on a shared bus. For instance, theI2C bus24 may interconnect themaster MCU18, aslave MCU26, a real-time clock and calendar (“RTCC”)32, and amemory34.
• TheRTCC32 may comprise a real-time clock and calendar device. TheRTCC32 may provide themaster MCU18 with data representative of the time of day and date. Themaster MCU18 may direct various communications with other aspects of the control subsystem in response to the passage of time.
• Thememory34 may comprise an electronic data storage mechanism. In various embodiments, thememory34 comprises a non-volatile ferro-electric random access memory device. Thememory34 may retain scheduling data and other variables that themaster MCU18 may access periodically. The memory may comprise 32 kilobytes of storage capacity, though any type and capacity may be chosen as desired.
• Theslave MCU26 may connect to themaster MCU18 and may be configured to asynchronously manage various communication devices such as aLoRa module30 and/or a GPS module42 via its own SPI bus28 andserial bus40, respectively. Theslave MCU26 may appear to themaster MCU18 as an external memory unit, so that data coming in from the peripherals of the slave MCU26 (such as theLoRa module30 and/or GPS module42) may be retrieved upon request by themaster MCU18. In various embodiments, theslave MCU26 comprises firmware having event driven architecture, and may manage theLoRa module30 and GPS module42 independently of each other.
• Theslave MCU26 may compriseserial bus40. Theserial bus40 may comprise a data communication bus configured to exchange data with a peripheral according to a serial data protocol. For instance, GPS module42 may be in operative communication with theslave MCU26 viaserial bus40.
• The GPS module42 may comprise a global positioning system receiver. For instance, the GPS module42 may comprise a Hornet Nano GPS available from OriginGPS. The GPS module42 may provide location data to theslave MCU26 whereby the positioning of different aspects of the system may be determined.
• Theslave MCU26 may comprise a SPI bus28. A SPI (Serial Protocol Interface) bus28 may comprise a synchronous serial communication protocol configured to enable a single master device to communicate with one or more slave device via selection of various slave select lines. The master device configures the clock polarity and phase. As such, the devices on the bus advantageously do not necessitate synchronized clocks. In various embodiments, aLoRa module30 connects to theslave MCU26 via the SPI bus28.
• TheLoRa module30 may comprise a radio transceiver configured to communicate according to a LoRa protocol. For example, a Low Power Wide Area Network (LPWAN) specification may be implemented, such as LoRa WAN, available from the Lora Alliance of San Ramon, Calif. In various embodiments, the radio transceiver communicates via a RF center frequency of 915 MHz, although any selected frequency, bandwidth, modulation, and protocol may be implemented as desired. In some examples, either or both of theslave MCU26 and the GPS module may be omitted. Further, one of theLoRa module30 and theBLE module20 may be omitted.
• Turning toFIG. 7, aneffector host120ais illustrated according to another example implementation. Theeffector host120aincludes amaster MCU18,BLE module20,slave MCU26,LoRa module30, GPS module50,RTCC32, andFRAM34 substantially as discussed above. In addition, theeffector host120aincludes, as an example implementation of theinterface212, a general-purpose input output controller (“GPIO”)44. For example, a GPIO controller44 may be in operative communication with the12C bus24 and may be configured to allow themaster MCU18 to control valves and other devices, such as via one ormore solenoid driver46A,46B, connected via a plug-incontrol line sub-bus48. For example, the GPIO controller44 may comprise two 16-bit GPIO expanders. Thus, in various embodiments, each plug-incontrol line sub-bus48 may comprise four control lines. In various embodiments, theeffector host120a, thus achieves control of eightperipheral solenoid drivers46A,46B or other devices. In various embodiments, theeffector host120aachieves control ofsuch solenoid drivers46A,46B while also achieving efficient power consumption by actuatingsolenoid drivers46A,46B sequentially rather than simultaneously. For example, themaster MCU18 may actuate multiple valves controlled bysolenoid drivers46A,46B to turn on or off multiple irrigation circuits. Themaster MCU18 may direct the GPIO controller44 to sequentially trigger thesolenoid drivers46A,46B. In this manner, the instantaneous current draw is reduced compared to the instantaneous current draw otherwise associated with simultaneous actuation ofmultiple solenoid drivers46A,46B.
• Thesolenoid driver46A,46B comprises a plug—in daughter board installable to theeffector host120a. Thesolenoid driver46A,46B is configured to provide control of power to latching solenoids that trigger valves. Thus, as noted earlier theeffector host120amay be reconfigurable by adding or removingsolenoid driver46A,46B from receptacle slots disposed in theeffector host120aand configured to receive the plug-in daughter board.
• Further discussion of the daughter boards is provided below with reference toFIG. 8A. A host controller52 may comprise a logical process running within aneffector host120 or120a. The host controller52 may power up thesolenoid driver46A with a nominal operating voltage of 3.3 VDC in order to drive a latching solenoid68 from between different latched positions, and thus move a valve from different positions. To transition the latching solenoid68 between positions, thesolenoid driver46A receive a nominal circuit voltage of 3.3 VDC from the host controller52, and boosts the voltage to 25 VDC via a DC-DC boost converter56. The DC-DC boost converter56 may be in electrical communication with an inductor54. The inductor54 boosts the flow of electrons that enter one end of the coil. The inductor54 normally resists electron flow until it builds up a sufficient magnetic field. Once the field is built the electrons flows freely until the field collapses and the electrons once again stop flowing. Thus, the DC-DC boost converter56 in combination with the inductor54 rapidly switches the voltage/current on and off (oscillation) to maintain the cycle of rebuilding/collapsing the magnetic field to maintain the flow of electrons and having the effect of boosting the voltage/current.
• The DC-DC boost converter56 may charge a storage device62. The storage device62 may integrate charge over time, for instance, permitting a lesser current over time, to accumulate charge so that loads drawing higher current may be actuated. For instance, the storage device62 may comprise a capacitor. Following the charging of the storage device62, the host controller52 may direct a first control circuit58 to drive a first MOSFET60 and second control circuit66 to drive a second MOSFET64. The first MOSFET60 and the second MOSFET64 may then connect the storage device62 to the latching solenoid68, releasing the stored charge and causing the latching solenoid68 to transition between positions.
• Finally, thesolenoid driver46A may comprise a daughter board ID memory57. The daughter board ID memory57 may comprise a non-volatile storage memory in which a unique number is stored. The unique number may identify thesolenoid driver46A so that the host controller52 of theeffector host120,120amay distinguish among multipleconnected solenoid drivers46A.
• FIG. 8B illustrates another example daughter board, configured to drive high loads (for instance, greater than 5 Amps at 25 VDC. In various embodiments, such solenoid driver46B may include an electrical double layer capacitor (“EDLC”)76, whereby a current may be provided, such as a greater current than provided by storage device62 ofsolenoid driver46A. The slave MCU72 may manage a voltage comparator70, which detects when the voltage is less than target voltage. When that occurs the slave MCU72 turns on the first MOSFET switch (control circuit74) to charge an EDLC76 to the target voltage. When the EDLC76 is fully charged the comparator70 signals the slave MCU72 to shut off the first MOSFET switch (control circuit74). When a request is made to the slave MCU72 to release the energy stored in the EDLC76, the slave MCU72 responds by turning on the second MOSFET switch (control circuit78), releasing all of its stored energy—which is the target voltage at the demand current. The current can be significantly larger than what is normally available in the nominal circuit. For a few milliseconds, the current can be as much as 5 to 50 times higher (or more) because of the rapid release of energy from the EDLC76. The voltage is throttled to the voltage rating of the EDLC76 but the current can be much higher during the substantially instantaneous release of energy.
• Referring now toFIG. 9, asensor host124ais illustrate according to another example implementation. Thesensor host124aincludes a Bluetoothlow energy module20, as discussed earlier, as well as a sensor hub controller86. The sensor hub controller86 may comprise a microprocessor. For example, the microprocessor may comprise an event-driven firmware architecture configured to enable all attached peripherals to run asynchronously. For instance, in various embodiments, the microprocessor comprises a 16-bit Microchip PIC24HJ128GP204 microprocessor. In various embodiments, the microprocessor runs at 40 MIPS, although any microprocessor at any speed may be implemented to achieve any desired metric, such as sufficient I/O throughput, power consumption, and peripheral support. Thesensor host124amay also have one or more sensing element in operative communication with the sensor hub controller86 and configured to determine an environmental variable. For instance, the NOID sensor8 may include a shallowdepth moisture sensor88, a salinity sensor90, a pH sensor92, and/or a deep moisture sensor94.
• With reference toFIGS. 10 and 11,power supplies1000 and1100 are depicted, which may be employed to power any of the components on site102 (depicted inFIGS. 10 and 11 as a DC load96). For example, with reference toFIG. 10 thepower supply1000 may comprise a DC boost converter and storage capacitor98. The DC boost converter and storage capacitor98 may receive electrical power and boost the voltage of the power, and may further store the power so that it may be consumed by the DC load96. The DC boost converter and storage capacitor98 may receive the electrical power from a pair of electrodes. For instance, acathode102 and ananode100 may be disposed in the soil proximate to thepower supply1000. Thecathode102 and theanode100 may, along with the soil, form a circuit whereby a difference in electrical potential is developed across thecathode102 andanode100. The difference in electrical potential may cause an electrical current to flow into the DC boost converter and storage capacitor98 for storage, conditioning (e.g., boosting the voltage), and provision to the DC load96.
• For further example, with reference toFIG. 11, thepower supply1100 may comprise asolar panel104. Thesolar panel104 may generate a difference in electrical potential in response to exposure to sunlight. Thesolar panel104 may be connected to acharge controller106. Thecharge controller106 may receive an electrical current from thesolar panel104 and control the charging of a lithiumion backup battery108, as well as control the delivery of the electrical current to DC load96.
• Further variations to the embodiments discussed above are contemplated. For example, in some embodiments, thehub132 and theserver136 can be implemented as a single computing device. In further embodiments, thehub132,server136 andoperator device144 can be implemented as a single computing device.
• The scope of the claims should not be limited by the embodiments set forth in the above examples, but should be given the broadest interpretation consistent with the description as a whole.

Claims (18)

1. A control subsystem for a utility delivery subsystem having an effector for enabling or disabling delivery of a utility from a source to an output device via a conduit; the control subsystem comprising:

an effector host having an effector wireless communications interface and a port configured to receive the effector; the effector host configured to operate the effector via the port in response to an instruction received via the wireless communications interface;

a control gateway having a first communications interface configured to establish a connection with the effector host, and a second communications interface configured to connect to a network; the control gateway further including a memory storing schedule data received via the second communications interface, and a processor configured to send the instruction to the effector host via the first communications interface, based on the schedule data; and

a server having a memory storing the schedule data and a server communications interface for transmitting the schedule data to the control gateway.

2. The control subsystem ofclaim 1, further comprising:

a sensor host having a sensor wireless communications interface and a port configured to receive a sensor; the sensor host configured to receive sensor data via the port and to transmit the sensor data via the sensor wireless communications interface.

3. The control subsystem ofclaim 2, the sensor host configured to transmit the sensor data to one of the control gateway and the effector host via the sensor wireless communications interface.

4. The control subsystem ofclaim 1, the effector host having a plurality of ports each configured to receive one of a plurality of effectors; the effector host further configured to:

monitor the status of each of the ports;

store, in a memory, status data including an indication for each port of whether the port is active or inactive; and

transmit the status data to the control gateway.

5. The control subsystem ofclaim 4, the control gateway further configured to:

compare the status data to the schedule data;

when the status data does not match the schedule data, send the status data to the server.

6. The control subsystem ofclaim 5, the server further configured to:

receive the status data; and

prompt an operator computing device for configuration data corresponding to the effectors identified in the status data.

7. The control subsystem ofclaim 1, the server further configured to:

receive an identifier and a device type from an operator computing device via a network, the identifier and device type corresponding to a further effector host;

retrieve a set of configuration parameters from the memory;

prompt the operator computing device for values corresponding to the configuration parameters; and

update the schedule data based on the values.

8. The control subsystem ofclaim 1, further comprising:

a sensor connected to the effector host; the effector host further configured to receive sensor data from the sensor and to relay the sensor data to the control gateway.

9. A method of controlling a utility delivery subsystem having an effector for enabling or disabling delivery of a utility from a source to an output device via a conduit; the method comprising:

storing, in a memory of a server, schedule data for controlling the utility delivery subsystem;

at a first communications interface of a control gateway, establishing a connection with the server and receiving the schedule data from the server;

storing the schedule data at the control gateway;

at a second communications interface of the control gateway, establishing a connection with an effector host having a port configured to receive the effector; and

transmitting an instruction to the effector host based on the schedule data;

at the effector host, operating the effector via the port in response to the instruction.

10. The method ofclaim 9, further comprising:

at a sensor host:

receiving sensor data from a sensor; and

transmitting the sensor data to the control gateway via the connection.

11. The method ofclaim 10, wherein transmitting the sensor data comprises:

establishing a connection with the second communications interface of the control gateway; and

transmitting the sensor data via the connection.

12. The method ofclaim 10, wherein transmitting the sensor data comprises:

establishing a connection with the effector host; and

transmitting the sensor data via the connection.

13. The method ofclaim 12, further comprising:

receiving the sensor data at the effector host; and

transmitting the sensor data from the effector host to the control gateway.

14. The method ofclaim 9, further comprising, at the effector host:

receiving one of a plurality of effectors at each of a plurality of effectors;

monitoring the status of each of the ports;

storing, in a memory, status data including an indication for each port of whether the port is active or inactive; and

transmitting the status data to the control gateway.

15. The method ofclaim 14, further comprising, at the control gateway:

comparing the status data to the schedule data; and

when the status data does not match the schedule data, sending the status data to the server.

16. The method ofclaim 15, further comprising, at the server:

receiving the status data; and

prompting an operator computing device for configuration data corresponding to the effectors identified in the status data.

17. The method ofclaim 9, further comprising, at the server:

receiving an identifier and a device type from an operator computing device via a network, the identifier and device type corresponding to a further effector host;

retrieving a set of configuration parameters from the memory;

prompting the operator computing device for values corresponding to the configuration parameters; and

updating the schedule data based on the values.

18. The method ofclaim 9, further comprising, at the effector host:

receiving sensor data from a sensor connected to the effector host; and

relaying the sensor data to the control gateway.

Images