Patent Publication Number: US-2021168579-A1

Title: Wireless Apparatus, System, and Method for Controlling a Valve

Description:
FIELD OF THE INVENTION 
     The present invention relates to a Wi-Fi watering system which includes a valve unit designed to wirelessly communicate with a control unit that is connected to a Wi-Fi network and configured to be programed by a user via the Internet. 
     SUMMARY OF THE INVENTION 
     A wireless water timer and valve control system includes a control unit in wireless WiFi communication with a router and a valve unit in wireless communication with the control unit and designed to connect to a faucet. The valve unit includes a valve that is operated wirelessly via a signal received by the control unit. The valve unit may also be configured to wirelessly communicate with a moisture sensor and relay a moisture sensor status received from the moisture sensor to the control unit in order to operate the valve unit based on the moisture sensor status. The control unit may also be configured to operate the valve unit based at least on a schedule sent to the control unit over the Internet. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention will be described with reference to the accompanying drawings, wherein: 
         FIG. 1  is a block diagram of an Internet controlled sprinkler system according to one embodiment; 
         FIG. 2  is a block diagram of the control unit illustrated in  FIG. 1 ; 
         FIG. 3  is a block diagram of the valve unit illustrated in  FIG. 1 ; 
         FIG. 4  is a diagram of a routine check-in data exchange that occurs periodically between the valve unit and the control unit of the system illustrated in  FIG. 1 ; 
         FIG. 5  is a diagram illustrating the architecture for communication between control unit(s) and Internet server of the system illustrated in  FIG. 1 ; 
         FIG. 6  is an exploded view of one example of a control unit illustrated in  FIG. 1 ; 
         FIG. 7  is an exploded view of one example of a valve unit illustrated in  FIG. 1 ; 
         FIG. 8  is an exploded view of another example of a valve unit illustrated in  FIG. 1 ; and 
         FIG. 9  is an example of a screenshot of a valve program grid according to one embodiment. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     An embodiment of the present invention will hereinafter be described with reference to the aforementioned drawings. The sprinkler system illustrated and described in this application is configured to utilize a home owner&#39;s private Wi-Fi network. 
     In one embodiment, shown in  FIG. 1 , the system consists of two units, Control Unit  10  (herein after, “CU”) (e.g., located inside the house or in a location where it is within Wi-Fi range of home router  20  and is within range of the outside-located VUs) that incorporates the Wi-Fi interface, and Valve Unit  30  (hereinafter, “VU”) (e.g., located outside the house near faucets and within RF link rage of the CU) that incorporates and controls one or more valves. The CU  10  is connected to the router  20  (e.g., local Internet access point) through a Wi-Fi connection, not an Ethernet cable. Disadvantages of an Ethernet setup include connection limitations (e.g., limited number of ports at local access point or hub), location limitations (e.g., location possibilities of CU determined by length of Ethernet cable), and general consumer dislike of unnecessary cables. Wi-Fi connection improves communication between the CU  10  and the VU  30 , because the CU  10  can be positioned in a desirable location to enable communication with the VU  30  via ISM Band RF Link  40 , as discussed below. Most preferably, the CU  10  is positioned in an area that has a strong Wi-Fi signal (e.g. walls, electrical equipment and other material may affect the signal) as well as within 200 feet of the VU  30 . 
     In this embodiment, for example, communication between the CU  10  and the VU  30  is made by the ISM Band (e.g., 910 MHz for US and 833 MHz for Europe) RF link  40 , however other known communication mediums may be used. The CU  10  is configured to control multiple VU&#39;s  30 . In this embodiment, the CU  10  controls two VUs  30 , each of which has four valves  50  incorporated in it. However, it is known that the VU  30  can incorporate more or less than four valves  50 . Each VU  30  is configured to wirelessly communicate with a moisture sensor  60  possibly via a moisture sensor receiver  65  (e.g., one of Melnor&#39;s existing moisture sensors and/or the “Smart Water Timer” described in U.S. Pat. No. 7,810,515), and relay the moisture sensor&#39;s status to the CU  10 , which will control the VU  30  based on the status (e.g., make the water/not water decision based on user settings). The CU  10  may be powered from a readily available “wall wart” type power supply and the VUs may be powered by standard AA batteries. 
     In operation of the water system described above, a user will program via mobile device, tablet, or personal computer, a watering schedule using a web-based GUI interface. The CU  10  will contact the web server  20  via Wi-Fi to update its schedule (e.g., continuously, time intervals, on command, etc.). The server  20  extracts the essential information from the GUI settings  200  for the CU  10  to run the programmed watering schedule and sends it to the CU  10 . The CU  10  then performs the programmed watering cycle(s) by commanding valve operations  400  to each VU  40 . The CU  10  may be configured to maintain, for example, a seven day program and run it continuously until it is modified by the user. Thus if the Internet connection is lost for any reason, the CU  10  will continue watering according to the last schedule downloaded to it. 
     The CU  10  may be configured to upload a current valve status  410  and if available, moisture sensor status  420  so that the user can see what is happening via simple status indicators. The CU  10  may be configured to upload this information every time the CU  10  contacts the server  20 , or at other desired intervals. 
     During operation the VU  30  is configured to contact the CU  10  (e.g., using the ISM radio) to receive the latest settings for each of the valves  50  of the VU  30 . The VU  30  does not maintain any of schedule settings and is essentially “dumb” (e.g., switching valves on or off as commanded for that minute). If the VU  30  loses contact with the CU  10 , then after a certain number of attempts (e.g., after 5 attempts) or certain amount of time (e.g., 5 minutes), the VU  30  will shut off all valves  50  as a safety measure. 
     On command from the CU  10 , the VU  30  will determine whether the moisture sensor  60  is connected to the system  1 , and if so, the VU  30  will relay received sensor information to the CU  10 . Controlling the moisture sensor  60  (e.g., switching it on and off, and waiting for the signal) is under control of the CU  10 , which will use it before and during a watering cycle if the user has programmed it to do so. 
     In one embodiment, in order to secure the CU  10  and its associated VUs  30  so that, for example, a neighbor with a similar system cannot access components that are not part of the neighbor&#39;s system, each of the CUs  10  and VUs  30  will have an identifier, such as a serial number. For example, the identifier of the CU  10  may be based on a unique MAC address (e.g., required by all devices that can connect to the internet), and the VUs  30  may be identified with a 16 bit number. This will allow 64 k valve units be manufactured with unique serial numbers. Other known identifiers may be used to uniquely identify each of these devices. 
     One embodiment of the CU  10  is shown in  FIGS. 2 and 6  and described below. 
     As shown in the embodiment illustrated in  FIG. 6 , the CU  10  assembly comprises a front housing  100 , a back housing  110 , a PCB assembly  120  arranged in a space provided between the front and back housing. The front housing includes a front label portion  105  and one or more openings configured to emit light produced, for example, by an LED. The PCB assembly  120  includes LED(s)  122  (e.g., indicator/status lights), power connector  124  configured to accommodate a power adaptor  126 , and LED spacer(s)  128 . The front housing is attached to the back housing and is designed to secure the PCB assembly therebetween. 
     As shown in the embodiment illustrated in  FIG. 2 , the CU  10  includes a wireless module  150  for communicating with the home router or server  20 , microcontroller  160 , and communication means  170  (e.g., ISM band radio) for communication with the VU  30 . 
     In this embodiment, the microcontroller  160  to wireless SPI-based interface includes information to let the microcontroller  10  know what kind of interface it has—this can be as simple as hard-wired I/O bits, when a different wireless module is detected, the microcontroller will run the appropriate software to support that wireless format. 
     A Real Time Clock (RTC) keeps track of the time and schedules watering operations according to predetermined user interface settings. The RTC is updated/synchronized every time the CU  10  checks in to the server  20 . 
     In this embodiment, the CU  10  functions include at least the following: support all Wi-Fi communications; run timing functions based on external user/webpage input; relay manual valve control commands to external VU(s)  30  when the latter requests; send valve status  410  to the web GUI when requested; update local status indicators as/when appropriate. In another embodiment, the CU  10  functions to support all required Z-Wave or Zigbee device and command classes when required and to support all Z-Wave, Zigbee functions required for inclusion in a home automation network. 
     In this embodiment, the hardware for the CU  10  may include: input power filtering/conditioning—regulation from wall-wart type DC supply  180 ; microcontroller  160 , such as Texas Instruments PN MSP430G2955; Wi-Fi module  150 , such as Texas Instruments PN CC3000; an ISM radio chip  170 , such as SiLabs Si4455; known local status indicator(s); and a PCB, such as a 4-layer PCB incorporating 2.5 GHz and 910 MHz antenna in PCB traces. 
     The selected microcontroller may include flash memory, RAM, and all the necessary support functions such a CPU clock, Power On Reset circuit etc, to be self-contained, needing no addition support devices. The selected microcontroller may also include a wide range of peripherals, including several serial interfaces, of which two are SPI (e.g., one of these is required to interface to the CC3000 WiFi module, another to interface to the ISM band radio). 
     The status indicators  162  are designed to show the status of the various communication functions in the CU  10 , such as power indicator (e.g., red light), web interface status (e.g., blinking red light when attempting to establish a connection to the user&#39;s home router  20 ), and web service status (e.g., blinking green light when not registered, solid otherwise). 
     The momentary contact switches include, for example, a reset switch  164  and a configuration switch  166 . The reset switch  164  is configured to cause a hard reset of the microcontroller  160  to restore the CU  10  to its initial condition. In this state, for example, all router configuration information will be lost and the user may be required to re-register the CU  10  with the server per the first time use. The reset switch  164  may be arranged so that it is difficult to access, e.g., accessible via a small hole in the front panel and can only be actuated by a paper clip or similar. The configuration switch  166  is configured to initiate a “Smart Configuration” process which the user may be required to perform so that the CU  10  gains access to the home router  20  and internet (e.g., configuration process for connecting CC3000 module using the Texas Instruments Smart Config app on a smartphone or PC). In one embodiment, the configuration switch  166  consists of PCB contacts shorted by a conductive elastomeric pad when pushed (e.g., similar to that used on Melnor&#39;s Model 3012 timer.) 
     Different embodiments of the VU  30  are described below and illustrated in the exploded views of  FIGS. 7 and 8 . 
       FIG. 7  illustrates one embodiment of the VU  30  assembly, which comprises front housing  310 , back housing  320 , and PCB assembly  340  and valve assembly  350  arranged in a space defined by the front and back housing. Side covers  330  may also be included to define the space. In this embodiment, the valve assembly  350  includes four solenoid valves arranged in parallel and extending lengthwise within the VU. The valve assembly  350  connects to a faucet (either directly or via a quick connect) to communicate water from the faucet to each of the valves  50 . In this embodiment, the PCB assembly  340  includes four PCB touch pads  342  arranged in parallel and extending lengthwise within the VU  30 , e.g., one touch pad  342  corresponding to each valve  50  of the valve assembly  350 . A PCB locator bracket  360  is sandwiched between the PCB assembly  340  and the valve assembly  350  and extends lengthwise within the VU  30 . The front housing  310  includes a front surface extending lengthwise. In this embodiment, the front surface includes four on/off touch pads  342 , corresponding to the number of valves  50  in the valve unit  30 . Each of the touch pads  342  is arranged such that if a user touches area A, contact is made with corresponding touch pad A, which turns on/off valve unit A. The back housing  320  is configured to secure battery terminals  370  and a battery (e.g., four AA batteries in this embodiment). The back housing is also configured to accommodate a moisture sensor socket  380  (e.g., the socket could also be configured on another portion of the VU.) 
     In this embodiment, the VU  30  is battery operated and includes at least one capacitive switch  402  associated with each valve  50  inside the VU  30  (e.g., to activate the valves manually). Two (or more) capacitive switches  402  may be used for each valve  50  in order to provide additional sensing that can be used to prevent false activation (e.g., 4 valves and 8 capacitive switches). The VU  30  “wakes up” periodically, such as every 100 ms to scan the switches, and every minute it will enable communication means  410  (e.g., ISM band radio) to get valve status  410  from the CU  10  to maintain one minute timing resolution. The “wake up” period can be set for different periods. During operation, if a valve  50  illustrated in the embodiment shown in  FIG. 3  needs to be switched on or off it will activate a voltage booster  404 , and enable a valve driver  406  when the voltage is high enough or reaches a predetermined threshold. In this embodiment, when a valve has been switched ON—either under program (described above) or manual control (e.g., capacitive switch)—an appropriate LED status indicator light  408  will flash. 
     According to this embodiment, the VU  30  is configured to only open and close valves when the CU  10  commands it or the user “pushes” or “touches” one of the manual capacitive switches  402 . This configuration (e.g., “dumb”) requires a smaller and less expensive microcontroller than a more intelligent configuration. 
     One advantage of this PCB-based capacitive touch switch design is that it reduces the number of external components normally found on a VU  30 , which can break off or become damaged because of use and other elements. Another advantage is ease of control. The user simply touches the switch to open the valve and then touches it again to close the valve. Another advantage relates to the aesthetics, namely the relative simplicity of the exterior design. 
       FIG. 8  illustrates another embodiment of the VU  30  assembly, which comprises a plurality of contact push buttons  3420  instead of the capacitive touch switches  402  or touchpads  342  described above and illustrated in  FIGS. 3 and 7 . According to this embodiment, the VU  30  is configured to open and close valves when the CU  10  commands it or the user “pushes” one of the plurality of push buttons. 
     The VU  30  is configured to detect RF Link failure and shut off all programmed ON valves in the event of such failure. In this condition, for example, only the user can set a valve ON using local control via the capacitive switches  342  or push buttons  3420 . RF link failure and valve shutoff occurs when the VU  30  cannot talk to the CU  10  for a predetermined period (e.g., duration of several one-minute check-in communication attempts). 
     In this embodiment, the VU  30  functions include at least the following: support all system setup and initialization requirements; receive current moisture sensor data from the optional moisture sensor receiver  65 ; receive valve control data from the CU  10 ; scan the capacitive switches  342  or push buttons  3420  for local manual operation; actuate valves  5  as required by the CU  10  or locally by the user; transmit moisture condition, battery and valve status  410  to the CU  10 ; control the voltage booster circuit  404  for actuating the valve solenoids; control the valve driver  406  to open and close the valves  50 ; update local valve status indicators; and detect a CU  10  communication failure (e.g., due to power outage, intermittent RF link, or hardware fault). 
     In this embodiment, the hardware for the VU includes: microcontroller  400 , such as Texas Instruments PN MSP430G2755; battery or battery pack; ISM band RF transceiver chip  410 , such as SiLabs PN Si4455; antenna, such as a helical coil antenna, possibly implemented in PCB etch; voltage booster circuit components  404 ; valve driver components  406 ; capacitive switches  402  for manual valve control; valve status indicators  408 ; a moisture sensor receiver connector  410 , such as a 3-pin connector; a PCB, such as a 2 or 4-layer PCB. 
     During system setup and operation of the sprinkler system described herein, data is exchanged between the server  20 , the CU  10 , and the VUs  30 . The following is a brief description of the data transferred between the parts of the system. 
     First, is a description of data transferred between the server  20  and the CU  30 . This data includes setup data and schedule data. 
     In one example, during the beginning of the setup process, the user registers CU serial number or ID code before being able to access the web-based GUI interface. Registration may require logging onto a web site that supports the GUI interface using the CU serial number associated with the user&#39;s CU  10  (e.g., may be marked on its housing). If the serial number is valid, the user will have access to a GUI interface where the user will enter, or register, the VU(s)  30  serial numbers or ID codes (e.g., similarly marked on the VU housing) to be used with the CU  10 . Next, on the GUI interface, the user will be able to enter desired watering schedule details (e.g., schedule data) for the valve(s)  50  of each of the VU(s)  30 . An additional VU  30  can be registered at the same time, or later if not purchased at the same time as the CU  10 . The GUI interface itself is described below. The CU  10  may not store the VU ID code(s). Instead, each time the server  20  downloads schedule data, at the beginning of the schedule data is the VU ID code the user entered for the target VU  30 . The CU  10  checks this against a request from a VU  30  to confirm that they are the same code, if not (e.g., for example if it has received a request from a neighbor&#39;s VU), the CU  10  will ignore the request. When the CU  10  receives a request from a VU  30  with a matching ID code, the CU  10  will send the valve or zone commands to the VU  20 . According to another embodiment, the GUI interface will maintain a database of permissible ID codes assigned by the manufacturer of the CU and VU. 
     When the CU  10  is powered, the user may perform a “Smart Configuration” operation using a smartphone, PC or tablet, after which the CU  10  will be connected, for example, to the user&#39;s home Wi-Fi router  20 . The CU  10  will then connect to the GUI server automatically, and obtain the schedule data, using the CU ID code for identification. If the CU  10  has been registered as described above, the GUI interface will download the schedule data for the VU(s)  30  associated with the CU  10 . The schedule data is described next. 
     During operation the CU  10  is configured to periodically contact the GUI server, for example, to ask if there has been any changes made to the schedule. The GUI server will download a new schedule if necessary. In addition, the CU  10  will upload the current valve and moisture sensor  60  (if present) status. The data downloaded to the CU  10  may include the following: CU ID code; VU ID code(s); Sunday (Day 0) schedule and settings for 6 cycles for VU 1 , Zone (or valve #) 1, Zone 2 etc; Monday (Day 1) schedule and settings for 6 cycles for VU 1 , Zone (or valve #) 1, Zone 2 etc; Etc for the remaining days of the week for VU 1 ; Sunday (Day 0) schedule and settings for 6 cycles for VU 2 , Zone (or valve #) 1, Zone 2 etc; Etc. 
     Thus there is a block of data associated with each zone for each cycle for each day of the week. Here is one example: 
     
       
         
           
               
               
               
             
               
                   
               
               
                 Field Description 
                 Range 
                 # of bytes 
               
               
                   
               
             
            
               
                 Cycle Start Time 
                 0-1439 mins 
                 2 
               
               
                 Cycle Stop Time 
                 0-1439 mins 
                 2 
               
               
                 Continuous/Misting 
                 1-15 mins On, 1-30 mins Off 
                 2 
               
               
                   
                 (0 in both fields = continuous) 
               
               
                   
               
            
           
         
       
     
     If the Cycle Start and Stop times are the same, then that cycle is inactive. This example includes 6 bytes/cycle/zone, or 6×6×4=144 bytes/day per zone. In addition there may be rain delay or sensor usage data associated with each day for each zone (but not cycle-related): 
     
       
         
           
               
               
               
               
             
               
                   
                   
               
               
                   
                 Field Description 
                 Range 
                 # of bytes 
               
               
                   
                   
               
             
            
               
                   
                 Rain Delay 
                 0 or 1 
                 1 
               
               
                   
                 Sensor Usage 
                 0 or 1 
                 1 
               
               
                   
                   
               
            
           
         
       
     
     This is an example in which a Rain Delay starts at the following midnight after the user “called” it, and extends in 24 hour increments. So for each day there will be a rain delay flag indicating to the CU  10  that regardless of the schedule for that day, no watering will occur. There is also an additional byte to indicate if a sensor attached is to be used for that zone. 
     This is an additional 2 bytes per zone per day, or 8 bytes/day total. In this example, the total schedule requirement for 4 valves (1 VU) for one day is 152 (=144+8), and for one week is 1064 bytes (=7×152). So the total week&#39;s schedule data for 2 valve units will be 2128 bytes. 
     Next, is a description of data transferred from the CU  10  to the GUI server. This data includes setup data and schedule data. 
     In one example, after the user has initiated a download with the CU and/or VU ID codes, the CU  10  responds with an “acknowledge.” In this example, after successfully receiving the schedule data, the CU responds by sending the current status directly to the web service hosting the GUI. Whenever it performs it routine “heartbeat” contact with the pusher service, the latter will respond with the schedule. According to one embodiment, the CU will upload the current system status to the GUI web server as follows: 
     
       
         
           
               
               
               
             
               
                   
               
               
                 Field Description 
                 Range 
                 # of bytes 
               
               
                   
               
             
            
               
                 CU ID # 
                 MAC address 
                 6 
               
               
                 VU ID # 
                 0x0001 to 0xFFFF 
                 2 
               
               
                 Valve Status 
                 On/Off bits for each valve 
                 1 
               
               
                 VU RF Link Status 
                 Good/Lost Contact 
                 1 
               
               
                 VU Battery Level 
                 0-3.0 V (0-255 steps) 
                 1 
               
               
                 Sensor Water and Battery Flags 
                 0/1 for each flag 
                 1 
               
               
                   
               
            
           
         
       
     
     Next, is a description of data transferred from the CU to the VU. This data includes command data. 
     The VU is configured to respond to commands from the CU and send back data regarding its battery status and relay sensor status. As soon as the VU receives a command packet containing its own ID, the VU will respond. According to one embodiment, the commands available are: 
     
       
         
           
               
               
               
             
               
                   
               
               
                 Field Description 
                 Range 
                 # of bytes 
               
               
                   
               
             
            
               
                 VU ID # 
                 0x0001 to 0xFFFF 
                 2 
               
               
                 Valve and Sensor Commands 
                 On/Off for each valve 
                 1 
               
               
                   
                 and 1 sensor 
               
               
                   
               
            
           
         
       
     
     Next, is a description of data transferred from the VU to the CU. This data includes VU status data. 
     According to one embodiment, the VU periodically wakes up and checks in to the CU (e.g., every minute). The CU responds by sending the valve and moisture sensor commands to the VU. The VU acknowledges receipt of the commands by repeating back the commands, and adding its battery and moisture sensor status. This data includes: 
     
       
         
           
               
               
               
               
             
               
                   
                   
               
               
                   
                 Field Description 
                 Range 
                 # of bytes 
               
               
                   
                   
               
             
            
               
                   
                 VU ID 
                 0x0001 to 0xFFFF 
                 2 
               
               
                   
                 Valve Status 
                 On/Off for each valve 
                 1 
               
               
                   
                 VU Battery Level 
                 0-3.0 V (0-255 steps) 
                 1 
               
               
                   
                 Sensor Status 
                 — 
                 1 
               
               
                   
                   
               
            
           
         
       
     
     The Sensor Flag status may also include bits to indicate if a sensor receiver is connected, and its functional status along with the sensor water and battery flags. 
     Next is described a GUI to CU packet description. 
     As described above, schedule data one VU for a week requires 1064 bytes, or 152 bytes for each day. The data may be downloaded in packets of one day, e.g., requiring 14 packets for one week with a two valve unit system. There is more than one type of packet sent from the GUI to the CU, but most of the time they will be schedule updates. Other possible packet types may include instructions to update the CU software code, and new code to be flashed, etc. The schedule update packet types will contain the valve unit ID number and day number. An example of a protocol and data flow between the GUI and Pusher is described in a later section. 
     Next is described CU to VU and VU to CU packet descriptions. One embodiment is shown in  FIG. 4 . 
     Packet types CU to VU include routine valve operation in response to “check in” packet from VU. Packet types VU to CU include routine check-in and “acknowledgment” receipt of check-in packet. 
     According to one embodiment, the VU  30  lets the CU  10  know if it has a moisture sensor  60  connected so that it can modify its watering schedule as necessary. The additional data that need to be conveyed includes, for example: (1) the VU  30  has a moisture sensor receiver  65  attached; (2) the CU  10  needs to tell the VU  30  to switch it on and listen for the sensor data; (3) the VU  30  needs to tell the CU  10  what the moisture sensor flags are; and (4) the CU  10  needs to tell the VU  30  to switch off the receiver  65 . 
     The Command packet length from CU  10  to VU  30  may differ from either of the VU to CU packets so that a VU  30  will not mistakenly try to read another VUs  30  transmission as coming from the CU  10  (e.g., the VU ID numbers won&#39;t match anyway). 
     In this system, several devices may be using the same frequency as the CU to VU RF link, and since their proximity to one another is unknown it is assumed according to one embodiment that all receivers can hear all transmitters. According to the following example, there are two VUs  30  (e.g., each transmitting one minute update requests); two moisture sensors (e.g., each transmitting status approximately every 15 seconds); one CU (e.g., which only transmits when requested for information by the VUs). In this example, the moisture sensors  60  do not directly talk to any receivers  65  other than the matching ID one. However, the moisture sensors  60  generate RF signals that may be picked up by the other receiver, which will reject any signal that does not comply with its format and ID. Nonetheless, while any one transmitter at their frequency is transmitting, no other RF communication can take place, which is known as a collision is accommodated for in the following manner. 
     According to one embodiment, since the receiver chips are configured to detect when another transmitter is active, collision avoidance may be implemented by checking for an existing transmission and if one is detected, delaying before making another transmission attempt. For example, several transmission attempts will be made, possibly up to 10 attempts, after which a VU  30  will wait (e.g., until the next minute or set time) and try again. 
     One collision possibility may include two or more VUs  30  transmitting at the same time, which can occur if they both coincidentally start a transmission attempt, or if one makes an attempt when the CU  10  is responding to an earlier request, or if a neighbor happens to have a similar system installed and one of those VUs  30  are within range of the “home” VU  30  and just happens to transmit at the same time. 
     Another collision possibility may include one or more sensors  60  transmitting simultaneously. The sensors cannot detect collisions and so do not have the capability of waiting (e.g., however may be designed to retransmit the same data after a delay, for example 15 seconds) 
     The probability of collisions depends in part on the number of transmitters and the transmission duration. Since there are not many devices that can try to communicate simultaneously, and the data being communicated is very small, collisions in this system should be fairly infrequent and data throughput not particularly affected. 
       FIG. 5  is a diagram illustrating the architecture for CU  10  to Web Server  20  and vice versa communication. 
     In this embodiment, the Pusher is a bidirectional communication channel that uses web sockets to talk to the client and direct HTTP POST using REST API for sending data from server to client. All the messages are routed through Pusher&#39;s server. The Pusher is configured to compartmentalize communication channels so that data is contained within a container called Application. To receive/send message, the receiver/sender needs to subscribe to an Application. 
     The Application is created from the Pusher&#39;s web front. Creating an Application creates some application specific credentials, e.g., an application id, key and a secret key. The credentials are used by both Receiver/Sender to send messages in a particular Application. 
     Each Application can further have Channels. Channels may be created on demand by the users and the Receiver may subscribe to the Channel and the Sender may publish messages on these channels. Only receivers who are subscribed to the channel may receive the message meant for that channel. Each channel may have multiple receivers. Multiple Senders can send a message to each channel 
     Each Channel may have different Event Names to which a sender can send a message, e.g., CONTROL Event, DATA Event, MSG Event. These events may be user definable, and each event may have a message associated with it. Plus, there are some Pusher internal housekeeping events that the end units may need to service from time to time, e.g., pusher subscription messages, pusher keep alive messages, etc. 
     Each End Unit of the Pusher may need to login to an Application and Subscribe to a Channel to listen for messages. 
     Next is a description of one example of data flow from CU to Web and vice versa (e.g., assuming that server is running, Pusher account is created with an Application, and Webhooks are configured in the Pusher such that it reports to server whenever a Channel subscribes in the Pusher Application.) 
     First, the CU  10  connects to the Router  20 . Next, the CU  10  connects to the Pusher and subscribes to a Channel name that is same as its ID. As the Channel is occupied by the CU  10  that just subscribed, the Pusher will send a Webhook to server saying the Channel is occupied. The sever will then generate, for example, a hash key for the channel, store the hash key in its database and send the hash key to the CU  10  via Pusher. 
     Once the CU  10  gets the hash key, the CU  10  will (a) store the hash key for the current session, (b) create a status message, (c) append its CU ID code to message, (d) encode the entire message for transmission, and (e) create a GET message to post to the server and send the message. 
     Once the server will accept the message, the server (a) checks the hash key to determine which CU the message originated from, (b) decodes the encoded message and retrieves the CU ID code and message, and (c) matches the CU ID code with the owner of the hash key. If the hash key owner and CU ID code matches, the message is valid, queues the message for further processing. If the hash key does not match, ignores the message. 
     When the sever sends a message to a particular CU  10 , the server encodes the message from binary data and triggers the message for the Pusher using the defined Application and CU ID code as channel name. On CU  10 , the Pusher will deliver the message and the CU  10  will read the message in a buffer, decode the buffer, read the binary data into structure, and update the Scheduler. 
     Next, is described one example of a method for connecting the CU  10  to a Wi-Fi network using a mobile device. After the initial setup, the system is designed to be programmed from a mobile device or computer. 
     The user plugs the CU  10  into an electrical power outlet via a power adaptor  126 . It is preferable to position the CU  10  in an area that has a strong Wi-Fi signal as well as within 200 feet of the VU  30 . 
     The user confirms that their mobile device (e.g., smartphone or tablet) is connected to a desired Wi-Fi network before downloading (e.g., from App Store or Google Play) and installing a wireless water timer and sprinkler system mobile application (“Wi-Fi CU App”). 
     The user launches the downloaded Wi-Fi CU App and confirms that it is connected to the desired Wi-Fi network (e.g., home network) before connecting the system  1  to the network. 
     The user accesses a GUI website, creates a personal account, and registers the system, for example, by entering a serial number of the CU  10  (e.g., located on back cover of the CU  10  or packaging material provided with system). The user may also enter location specific information (e.g., area code, zip code, city/state, etc.) to enable local weather information to be provided. The user may also enter the serial number of each VU  30  connected to the CU  10  as part of this registration. 
     The user connects the VU(s)  30  to an outside faucet(s) and turns the faucet(s) “on.” 
     The user connects a first end of a hose to a desired outlet of the VU  30  and a second end of the hose to a sprinkler device. 
     The user inserts a moisture sensor  60  in an area proximate to the sprinkler device and configures the moisture sensor  60  to communicate with the system  1 . 
     The user may also program the controller by accessing their personal account associated with the system on a GUI interface (webpage) via a computer or mobile device. One example of a webpage associated with the system is shown in  FIG. 9 , which is a screenshot of a valve program grid. The grid is configured to enable the user to enter valve specific program information, such as start time of the first watering cycle, watering time (minutes), time between watering cycle (e.g., water once every 4, 6, 8, or 12 hours, or once every 1, 2, 3, 4, 5, 6, or 7 days), and economy mode (e.g., saves water by repeatedly opening and closing the valves during the watering cycle, allowing more soak-in and less run-off. Each valve can have its own watering program. 
     In view of the above, it will be seen that the several objects of the invention are achieved and other advantageous results are obtained. As various changes could be made in the above constructions without departing from the scope of the invention, it is intended that all matter contained in the above description or shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.