U.S. patent application number 15/413174 was filed with the patent office on 2017-07-27 for systems and methods for providing network connectivity and remote monitoring, optimization, and control of pool/spa equipment.
This patent application is currently assigned to Hayward Industries, Inc.. The applicant listed for this patent is Hayward Industries, Inc.. Invention is credited to Bruce Aubrey, David Blaine, James Carter, Jason DeBruin, Ray Denkewicz, Gregory Fournier, Arthur W. Johnson, III, James Murdock, Jason Parcell, Scott Petty, Kevin Potucek, Douglas Sawyer, JR., Vance Willis.
Application Number | 20170212532 15/413174 |
Document ID | / |
Family ID | 59358840 |
Filed Date | 2017-07-27 |
United States Patent
Application |
20170212532 |
Kind Code |
A1 |
Potucek; Kevin ; et
al. |
July 27, 2017 |
Systems and Methods for Providing Network Connectivity and Remote
Monitoring, Optimization, and Control of Pool/Spa Equipment
Abstract
Systems and methods for providing network connectivity and
remote monitoring, optimization, and control of pool/spa equipment
are provided. "Internet-of-Things" (IoT) functionality is provided
for pool and spa equipment in a flexible and cost-effective manner.
Network connectivity and remote monitoring/control of pool and spa
equipment is provided by various components such as a network
communication and local control subsystem installed in pool/spa
equipment, and other components. Also disclosed are various control
processes ("pool logic") which can be embodied as software code
installed in any of the various embodiments of the present
disclosure.
Inventors: |
Potucek; Kevin; (Far Hills,
NJ) ; Murdock; James; (Wakefield, RI) ;
Carter; James; (Warwick, RI) ; Fournier; Gregory;
(West Kingston, RI) ; Johnson, III; Arthur W.;
(Stoughton, MA) ; Denkewicz; Ray; (East Greenwich,
RI) ; Blaine; David; (Uxbridge, MA) ; DeBruin;
Jason; (Brick, NJ) ; Willis; Vance; (Nunnelly,
TN) ; Aubrey; Bruce; (Nashville, TN) ; Petty;
Scott; (Clemmons, NC) ; Parcell; Jason;
(Winston-Salem, NC) ; Sawyer, JR.; Douglas;
(Seekonk, MA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Hayward Industries, Inc. |
Elizabeth |
NJ |
US |
|
|
Assignee: |
Hayward Industries, Inc.
Elizabeth
NJ
|
Family ID: |
59358840 |
Appl. No.: |
15/413174 |
Filed: |
January 23, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62286272 |
Jan 22, 2016 |
|
|
|
62310510 |
Mar 18, 2016 |
|
|
|
62381903 |
Aug 31, 2016 |
|
|
|
62412504 |
Oct 25, 2016 |
|
|
|
62414545 |
Oct 28, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
E04H 4/1245 20130101;
F04D 15/0218 20130101; G05B 19/042 20130101; H04L 61/609 20130101;
A61H 2033/0008 20130101; E04H 4/1281 20130101; H04L 67/20 20130101;
G05B 2223/06 20180801; H04L 67/125 20130101; A61H 2033/0083
20130101; G05B 2219/25268 20130101; A61H 2201/5012 20130101; A61H
2201/5082 20130101; B25J 9/161 20130101; E04H 4/12 20130101; H05B
47/11 20200101; G05B 2219/2642 20130101; G05D 21/02 20130101; E04H
4/129 20130101; A61H 2201/5087 20130101; F16K 37/0041 20130101;
G05B 15/02 20130101; G05B 2219/25032 20130101; H02J 13/0017
20130101; H04L 43/0817 20130101; H05B 47/19 20200101; A61H 2201/501
20130101; A61H 2201/5097 20130101; E04H 4/148 20130101; F04D
15/0066 20130101; A61H 2201/5079 20130101; H04Q 2209/84 20130101;
Y04S 40/18 20180501; E04H 4/16 20130101; G05D 7/0635 20130101; A61H
2201/5048 20130101; B05B 17/08 20130101; A61H 2201/5058 20130101;
F04D 29/708 20130101; B25J 9/1694 20130101; A61H 2201/5061
20130101; F04D 15/0077 20130101; H04Q 9/00 20130101; E04H 4/1654
20130101; F04D 15/0281 20130101; A61H 33/0087 20130101; H04L 67/12
20130101; A61H 2201/5071 20130101; F04D 15/0088 20130101; G05B
19/0423 20130101; H05B 47/105 20200101; G05D 7/0629 20130101; G08B
25/08 20130101; H04L 61/2007 20130101; A61H 33/005 20130101; A61H
2201/5007 20130101; E04H 4/10 20130101; E04H 4/1272 20130101; G05B
2219/25022 20130101; H04L 67/025 20130101; H04L 67/10 20130101;
G05B 2219/13 20130101; G08B 21/182 20130101; H04L 67/04 20130101;
H04Q 2209/40 20130101; A61H 33/0095 20130101; F16K 37/005 20130101;
G08C 17/02 20130101 |
International
Class: |
G05D 7/06 20060101
G05D007/06; E04H 4/12 20060101 E04H004/12; F16K 37/00 20060101
F16K037/00; E04H 4/16 20060101 E04H004/16; G08C 17/02 20060101
G08C017/02; E04H 4/10 20060101 E04H004/10; E04H 4/14 20060101
E04H004/14 |
Claims
1. A water feature comprising: a valve for allowing flow of water
through the water feature; a processor in communication with the
valve, said processor controlling operation of said valve; a
housing enclosing the valve and the processor; and a network
communication subsystem in communication with the processor, the
network communication subsystem (i) assigning an Internet Protocol
(IP) address to the water feature and establishing a network
connection between the processor and a remote device; (ii)
providing for remote monitoring of operational parameters
associated with the water feature from the remote device over the
network connection; and (iii) providing for remote control of the
water feature from the remote device over the network
connection.
2. The water feature of claim 1, wherein the network communication
subsystem is positioned within the housing.
3. The water feature of claim 1, wherein the network communication
subsystem establishes one or more of a wired or a wireless network
connection with the processor.
4. The water feature of claim 1, wherein the remote device
comprises one or more of a chlorinator, a pump, a underwater light,
a pool cleaner of a pool or a spa, a heater, a chemical dispenser,
a valve actuator, a pool cover system, a pool control system, a spa
control system, or a water slide controller.
5. The water feature of claim 1, further comprising one or more
sensors in communication with said processor, the one or more
sensors including one or more of debris sensor, water temperature
sensor, motion sensor, or ambient noise sensor.
6. The water feature of claim 1, wherein the processor receives
user input data over the network connection and alters operation of
the water feature in response to the user input data.
7. The water feature of claim 6, wherein the user input data
comprises one or more of timer data or schedule data.
8. The water feature of claim 1, wherein the processor transmits
operational data to the remote device over the network
connection.
9. The water feature of claim 8, wherein the operational data
comprises one or more of pressure data, water flow rate data,
debris sensing data, or actuator position data.
10. The water feature of claim 1, wherein the processor transmits
factory specification data to the remote device over the network
connection.
11. The water feature of claim 1, wherein the processor stores
configuration parameter data and transmits the configuration
parameter data to the remote device over the Internet.
12. The water feature of claim 11, wherein the configuration
parameter data includes one or more of an IP address, a GPS
coordinate, a Zip code, a date, or a time.
13. The water feature of claim 1, wherein the processor receives
remote data from the remote device over the network connection
including one or more of location data, time, date, sunrise data,
sunset data, weather data, wind speed, or wind direction.
14. The water feature of claim 1, wherein the processor stores
configuration parameters remotely set by the remote device over the
Internet, the configuration parameters including one or more of
connected pool devices pool surface area, pool geometry, pool liner
color, pool cover information, or a pool cover schedule.
15. The water feature of claim 1, wherein the processor transmits
health monitoring data to the remote device over the Internet.
16. A method for remotely monitoring and controlling a water
feature for a pool or a spa, comprising the steps of: assigning by
a processor of the water feature an Internet Protocol (IP) address
to the water feature; establishing a network connection between the
processor of the water feature and a remote device; providing for
remote monitoring of operational parameters associated with the
water feature from the remote device over the network connection;
and providing for remote control of the water feature from the
remote device over the network connection.
17. The method of claim 16, further comprising determining by the
processor whether a flow rate provided to the water feature is
above a setpoint minimum.
18. The method of claim 17, further comprising transmitting an
instruction to increase the pump flow to the water feature if the
flow rate is below the setpoint minimum.
19. The method of claim 18, further comprising transmitting an
instruction to activate the valve of the water feature if the flow
rate is above the setpoint minimum.
20. The method of claim 19, further comprising transmitting an
error if the flow rate to the water feature cannot be increased
above the setpoint minimum.
21. The method of claim 16, further comprising transmitting an
instruction to activate the water feature if at least one other
water feature in the pool or spa environment is active.
22. The method of claim 21, further comprising transmitting an
instruction to activate the at least one other water feature if the
at least one other water feature is not active.
23. The method of claim 16, further comprising transmitting an
instruction to activate the water feature of a chemistry automation
system within the pool or spa environment is active.
24. The method of claim 16, further comprising transmitting an
instruction for a chiller and the water feature to activate if the
processor determines that a temperature is above a setpoint.
25. The method of claim 24, further comprising transmitting an
instruction to deactivate the chiller and the water feature if the
processor determines that a temperature is not above a
setpoint.
26. The method of claim 16, further comprising transmitting an
instruction to activate the water feature if the processor
determines that a motion sensor is triggered.
27. The method of claim 26, further comprising transmitting an
instruction to deactivate the water feature if the processor
determines that a motion sensor is not triggered.
28. The method of claim 16, further comprising transmitting an
instruction to decrease the throughput of the valve of the water
feature if the processor determines through an ambient noise sensor
that the ambient noise is above a maximum setpoint.
29. The method of claim 28, further comprising transmitting an
instruction to increase the throughput of the valve of the water
feature if the processor determines through the ambient noise
sensor that the ambient noise is below a maximum setpoint.
Description
RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional Patent
Application No. 62/286,272 filed on Jan. 22, 2016, U.S. Provisional
Patent Application No. 62/310,510 filed on Mar. 18, 2016, U.S.
Provisional Patent Application No. 62/381,903 filed on Aug. 31,
2016, U.S. Provisional Patent Application No. 62/412,504 filed on
Oct. 25, 2016, and U.S. Provisional Patent Application No.
62/414,545 filed on Oct. 28, 2016, the entire disclosures of these
applications hereby expressly incorporated by reference.
BACKGROUND OF THE INVENTION
[0002] Field of the Invention
[0003] The present disclosure relates to systems and methods for
providing network connectivity and remote monitoring, optimization
and control of pool/spa equipment.
[0004] Related Art
[0005] Swimming pool equipment is conventionally controlled by an
electronic pool controller at an equipment pad. Power is supplied
from the controller and electrical subpanel to the pool equipment
through an electrical conduit (e.g., hardwire). Alternatively,
swimming pool equipment can be controlled by electrical circuit
breakers in a subpanel at an equipment pad. Power is supplied from
the subpanel to the pool equipment through an electrical conduit
(e.g., hardwire). Without an electronic pool controller, any
time-based control is typically an electro-mechanical clock wired
in series between the subpanel and the pool equipment, thereby
breaking one or both legs of the power supply to the pool
equipment. To monitor or maintain conditions of pool equipment, the
pool, pool water, or the pool environment, sensors or other data
collection means typically reside at the equipment pad or the
pool.
[0006] Remote control of the pool and related equipment typically
requires hard-wired communication between the pool controller (at
the pad) and pool equipment, as well as wired or wireless
communication between the pool controller and user interface. More
recent remote control systems feature communication between the
controller at the pad and a cloud server (e.g., via a home router),
as well as communication between the user interface and the cloud
server by cell or wifi router.
[0007] Adding control features to an existing pool and equipment
pad is typically costly because of the required electrical
competence necessary to install new conduits to provide power from
the subpanel to the controller, and from the controller to the pool
equipment. Further, pool monitoring and maintenance can be
confusing and time consuming for pool owners, which often leads to
the employment of pool servicers. The lack of connectivity and
subsequent lack of understanding of the status and condition of the
pool and pool equipment requires costly and sometimes unnecessary
visits by pool professionals.
[0008] Accordingly, what is needed is a system and method to
provide pool owners and pool servicers with enhanced control of,
and connectivity between, pool equipment devices, and which reduces
hardware and/or installation costs.
SUMMARY OF THE INVENTION
[0009] The present disclosure relates to systems and methods for
providing network connectivity and remote monitoring, optimization,
and control of pool/spa equipment. "Internet-of-Things"
functionality is provided for pool and spa equipment in a flexible
and cost-effective manner, in various embodiments. For example, in
one embodiment, network connectivity and remote monitoring/control
of pool and spa equipment is provided by a network communication
and local control subsystem installed in pool/spa equipment. In
another embodiment, network connectivity and remote
monitoring/control of pool and spa equipment is provided by a
pool/spa system controller interconnected with pool/spa equipment
operating in conjunction with local and/or remote pool/spa control
logic. In another embodiment, network connectivity and remote
monitoring and control of pool and spa equipment is provided by way
of a pool "hub" interconnected with pool/spa equipment operating in
conjunction with remote pool/spa control logic. In yet another
embodiment, network connectivity and remote monitoring and control
of pool and spa equipment is provided by way of a pool "translator"
interconnected with pool/spa equipment operating in conjunction
with local and/or remote pool/spa control logic. In still another
embodiment, network connectivity and remote monitoring and control
of pool and spa equipment is provided by way of a plurality of pool
connectivity modules that communicate with pool/spa equipment,
operating in conjunction with remote pool/spa control logic. In a
further embodiment, network connectivity and remote monitoring and
control of pool and spa equipment is provided by way of wireless
communications provided directly in the pool/spa equipment and
operating in conjunction with remote pool/spa control logic. In yet
another embodiment, network connectivity and remote monitoring and
control of pool and spa equipment is provided by way of a
reduced-size "hub" interconnected with pool/spa equipment operating
in conjunction with remote pool/spa control logic. In still another
embodiment, network connectivity and remote monitoring and control
of pool and spa equipment is provided by way of pool/spa
chlorination system and controller that is interconnected with
pool/spa equipment operating in conjunction with remote pool/spa
control logic. Also disclosed are various control processes ("pool
logic") which can be embodied as software code installed in any of
the various embodiments of the present disclosure.
[0010] Communication between devices, the controller, the router,
the cloud, and/or the user interfaces can use a number of
technologies, where each technology could provide an advantage in
cost or reliability for each communication segment. Data for
managing the pool and pool equipment (e.g., relating to wind, time,
temperature, humidity to manage heating, water features, skimmer
operation, approaching storms, sunrise, sunset, etc.) could be
gathered from the cloud, in addition to or instead of data gathered
through sensors and datacom cables at the pool or pad. Sensors
dedicated to specific pool equipment (e.g., pressure sensors, flow
sensors or temp sensors in the heater used to manage pump speed,
control valve positions, etc.) could share data with the controller
to manage other pool equipment (e.g., to optimize performance),
rather than requiring dedicated sensors for each device. Smart
switches could be installed between an existing conduit and the
subpanel or device by a user (e.g., pool owner or pool
professional), because installation of a new hard conduit is
unnecessary (reducing the need for an electrician), or smart
switches could be integrated into pool or spa equipment. For
example, a heater with an integrated smart switch could act as a
hub for connectivity to the home router.
[0011] In still further embodiments, the system of the present
disclosure provides a modular relay, a wiring hub, and/or a control
module that can be conveniently installed near pool/spa equipment,
and which provides Internet-enabled remote control and connectivity
of pool/spa components without requiring installation of complete
(e.g., pad-mounted) pool/spa system controller. Conveniently, the
modular relay, wiring hub, and/or control module allow owners of
existing pool/spa equipment who do not currently own a pool/spa
control system to enjoy the benefits of such a control system
without requiring the installation, equipment, and expense
associated with conventional pool/spa control systems.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The foregoing features of the disclosure will be apparent
from the following Detailed Description of the Invention, taken in
connection with the accompanying drawings, in which:
[0013] FIG. 1 is a diagram illustrating the system of the present
disclosure;
[0014] FIG. 2 is a block diagram illustrating components of the
subsystems of FIG. 1;
[0015] FIG. 3 is a diagram illustrating various types of control
logic in accordance with the present disclosure;
[0016] FIG. 4 is a diagram illustrating processing steps carried
out by the system of FIGS. 1-2;
[0017] FIG. 5 is a diagram illustrating another embodiment of the
present disclosure;
[0018] FIG. 6 is a flowchart illustrating processing steps carried
out by the system of FIG. 5;
[0019] FIG. 7 is a diagram illustrating another embodiment of the
system of the present disclosure;
[0020] FIG. 8 is a flowchart illustrating processing steps carried
out by the system of FIG. 7;
[0021] FIG. 9 is a diagram illustrating another embodiment of the
system of the present disclosure;
[0022] FIG. 10 is a flowchart showing processing steps carried out
by the system of FIG. 9;
[0023] FIG. 11 is a diagram illustrating another embodiment of the
system of the present disclosure;
[0024] FIG. 12 is a diagram illustrating processing steps carried
out by the system of FIG. 11;
[0025] FIG. 13 is a diagram illustrating another embodiment of the
system of the present disclosure;
[0026] FIG. 14 is a flowchart illustrating processing steps carried
out by the system of FIG. 13;
[0027] FIG. 15 is a diagram illustrating another embodiment of the
system of the present disclosure;
[0028] FIGS. 16A-16B are diagram illustrating another embodiment of
the system of the present disclosure;
[0029] FIG. 17 is a diagram illustrating another embodiment of the
system of the present disclosure;
[0030] FIG. 18 is a diagram illustrating the pump control logic of
FIG. 3;
[0031] FIGS. 19A-19AU are flowcharts illustrating processing steps
of the pump control logic of FIG. 3;
[0032] FIG. 20 is a diagram illustrating chemistry automation
control logic of FIG. 3;
[0033] FIGS. 21A-21I are flowcharts illustrating processing steps
of the chemistry automation control logic of FIG. 3;
[0034] FIG. 22 is a diagram illustrating the heater control logic
of FIG. 3;
[0035] FIGS. 23A-23J are flowcharts illustrating processing steps
of the heater control logic of FIG. 3;
[0036] FIG. 24 is a diagram illustrating the lighting control logic
of FIG. 3;
[0037] FIGS. 25A-25AB are flowcharts illustrating processing steps
of the lighting control logic of FIG. 3;
[0038] FIG. 26 is a diagram illustrating the pool cleaner control
logic of FIG. 3;
[0039] FIGS. 27A-27O are flowcharts illustrating processing steps
of the pool cleaner control logic of FIG. 3;
[0040] FIG. 28 is a diagram illustrating the valve actuator control
logic of FIG. 3;
[0041] FIGS. 29A-29I are flowcharts illustrating processing steps
of the valve actuator control logic of FIG. 3;
[0042] FIG. 30 is a diagram illustrating water feature control
logic of FIG. 3;
[0043] FIGS. 31A-31F are flowcharts illustrating processing steps
of the water feature control logic of FIG. 3;
[0044] FIG. 32 is a diagram illustrating pool control logic of FIG.
3;
[0045] FIGS. 33A-33AH are flowcharts illustrating processing steps
of the pool control logic of FIG. 3;
[0046] FIGS. 34A-34J are diagrams illustrating another embodiment
of the system of the present disclosure;
[0047] FIG. 35 is a diagram illustrating another embodiment of the
system of the present disclosure; and
[0048] FIGS. 36-40 are diagrams illustrating further embodiments of
the system of the present disclosure.
DETAILED DESCRIPTION OF THE INVENTION
[0049] The present disclosure relates to systems and methods for
providing network connectivity and remote monitoring, optimization
and control of pool/spa equipment, as discussed in detail below in
connection with FIGS. 1-40.
[0050] FIG. 1 is a diagram illustrating the system 10 of the
present disclosure. The system 10 includes, but is not limited to,
a plurality of network communication and local control subsystems
12a-12h which could be installed in or connected to a plurality of
pool and spa equipment 14a-14h, so as to provide network
connectivity and remote monitoring and control of the pool and spa
equipment 14a-14h. The subsystems 12a-12h could communicate with
each other over a network 16, which could include, but is not
limited to, the Internet. Importantly, the subsystems 12a-12h
provide "Internet-of-Things" functionality for the plurality of
pool and spa equipment 14a-14h. It is noted that subsystems 12a-12h
could further include a "big data" subsystem, subsystems for
receiving input from manufacturers/factories, subsystems for
receiving external data/input (e.g., data from the Internet), and
subsystems for receiving input from customers. As will be discussed
in greater detail below, the subsystems 12a-12h could include
control logic for allowing each of the devices 14a-14h to interact
with each other (e.g., to exchange data and commands for
controlling each other), as well as to be remotely controlled by
another system such as a remote server, a "cloud" based control
system, a remote computer system, a smart device (e.g., smart
phone, smart speaker, smart chip embedded in the body), etc., and
combinations thereof as will be discussed in greater detail
below.
[0051] As can be seen, the pool and spa equipment 14a-14h could
include various types of pool and spa equipment, such as a pump
14a, a heating/cooling system 14b, a sanitization system 14c, a
water feature or miscellaneous subsystem 14d, a valve actuator 14e,
a pool/spa control system 14f, a pool cleaner 14g, and/or a
lighting system 14h. It is noted that, as described herein, the
heating/cooling system 14b may also describe, or be described as, a
heating system, heater, cooling system, cooler, or any combination
thereof. Additionally, as can be seen in FIG. 1, the subsystems
12a-12h could also communicate with one or more servers 18, and/or
with one or more smart devices 20 (e.g., phone, tablet, computer
systems, etc.), via the network 16. Still further, an on-site
control processor 19 could be in communication with the various
systems shown in FIG. 1. The on-site control processor 19 could be
a pool/spa control system installed at the location of a pool or
spa, a reduced-functionality pool/spa control system, or another
type of control system. Examples of such systems will be described
in detail below.
[0052] FIG. 2 is a block diagram illustrating components of the
subsystems 12a-12h in greater detail. As can be seen, a variety of
subsystem components could be provided for providing network
connectivity for pool and spa equipment via a multitude of wired
and wireless means. As noted above, the subsystems 12a-12h could be
installed in pool/spa equipment (e.g., within the physical housings
of the equipment 14a-14h), or connected thereto, to provide network
connectivity to each device. Advantageously, the subsystems 12a-12h
can be provided as "after-market" components that provide network
connectivity and remote monitoring and control for pool/spa
equipment that does not ordinarily include such connectivity.
Importantly, the subsystems 12a-12h allow for a wide variety of
wired and wireless connections to the pool/spa equipment. For
example, a smart telephone could directly connect with pool or spa
equipment via a Bluetooth, WiFi, RF mesh (e.g., ZWave, Zigbee,
Thread, Weave, etc.), or satellite connection, via the subsystems
12a-12h. Moreover, a home computer could connect to pool/spa
equipment using a home WiFi network, via the subsystems 12a-12h or
by way of a wired Ethernet connection to the pool/spa equipment.
Still further, a remote server or "cloud" platform could connect to
the pool/spa equipment via the subsystems 12a-12h, to allow for
remote and/or web-based control.
[0053] A processor 22 provides local processing capability for each
of the subsystems 12a-12h. The processor 22 is in communication
with a random access memory 24, and one or more non-volatile
memories 28. The non-volatile memory 28 could store one or more
local control programs 30 for providing local control of the pool
or spa equipment in which the subsystem is installed. A TCP/IP
stack 26 is provided for allowing each of the subsystems to obtain
an Internet protocol address, and to provide Internet connectivity
for each of the subsystems. The processor 22 could communicate with
a wired communication subsystem 36, a wireless communication
subsystem 34, a sensor interface subsystem 38, and an actuator
interface subsystem 40 via a bus 32. The wired communication
subsystem 36 could include an Ethernet transceiver 42, and a serial
transceiver 44. The serial transceiver could support one or more
suitable serial communication protocols, such as RS-485, RS-232,
USB, etc. The wireless communication subsystem 34 could include a
Wi-Fi transceiver 46, a Bluetooth (or Bluetooth LE) transceiver 48,
a cellular data transceiver 50, a satellite transceiver 52, and
infrared transceiver 54, and a radiofrequency/RF mesh transceiver
56. The cellular data transceiver 50 could support one or more
cellular data communications protocols, such as 4G, LTE, 5G, etc.
The radiofrequency/RF mesh transceiver 56 could support one or more
RF mesh network protocols, such as ZWave, Zigbee, Thread, Weave,
etc. The sensor interface subsystem 38 could include analog
connection interfaces, digital connection interfaces, and one or
more analog-to-digital converters 58. The actuator interface
subsystem 40 could include analog connection interfaces, digital
connection interfaces, and one or more digital-to-analog converters
60. The sensor interface subsystem allows the network communication
and local control subsystem to obtain information from a wide
variety of sensors associated with pool/spa equipment, as well as
other types of sensors. The actuator interface subsystem 40 allows
the network communication and local control subsystem to control
one or more pieces of pool/spa equipment connected to the
subsystem. The wired and wireless communication subsystems 34, 36
allow the network communication and local control subsystem to
connect via various wired and wireless communication means to the
Internet. This allows a piece of pool or spa equipment to transmit
operational and status information to one or more remote devices,
as well as to be remotely controlled by such devices.
[0054] FIG. 3 is a diagram illustrating various types of control
logic in accordance with the present disclosure, for controlling
various types of pool and spa equipment. The control logic,
indicated generally as pool control logic 70, could be embodied as
programmed instructions (software code) stored on a non-transitory
computer-readable medium, and could include water feature control
logic 72, valve actuator control logic 74, cleaner control logic
76, lighting control logic 78, heater control logic 80, chemistry
automation control logic 82, and pump control logic 84. Such logic
could be installed locally (e.g., in one or more of the subsystems
12a-12h), on a remote server or computer system (e.g., in the
server 18 or the smart phone/computer system 20), in the "cloud,"
or in any combination of such systems. The functions provided by
the logic 70-84 is described in greater detail below. As will be
discussed in greater detail below the various logic operations
disclosed herein (including the operational instruction disclosed
herein) could be trigged by (e.g., receive and a signal from)
various sensors and/or inputs to the system, as needed. Such inputs
could be periodically monitored by the pool control logic 70 of the
system 10.
[0055] FIG. 4 is a diagram illustrating processing steps, indicated
generally at 90, carried out by the system of FIGS. 1-2. It is
noted that the term "IoT devices" (shown in the drawings) refers to
pool/spa equipment having Internet-of-Things functionality provided
in accordance with the present disclosure, such as the equipment
14a-14h of FIG. 1. Beginning in step 92, the system monitors IoT
devices for incoming operational data. In step 94, a decision is
made as to whether incoming operational data has been received. If
a negative determination has been made, control returns to step 92.
Otherwise, step 96 occurs, wherein the system receives incoming
operational data. In step 98, the system processes instructions,
operational data, and external data, discussed hereinbelow. Then,
in step 100, the system optimizes operational set points. In step
102, the system transmits setpoints to one or more devices (one or
more of the pool/spa equipment 14a-14h) for use thereby.
[0056] In step 104, the system also monitors for incoming
instructions. A determination is made in step 105 as to whether an
incoming instruction has been received. If a negative determination
has been made, control returns to step 104. Otherwise, in step 106,
the system receives one or more incoming instructions. Then,
control proceeds to step 98, discussed above. Additionally, in step
107, the system also monitors for updated external data (e.g., web
data). In step 108, a decision has been made as to whether updated
external data is available. If a negative determination has been
made, control returns to step 107. Otherwise, step 109 occurs,
wherein the system receives the updated external data. Then,
control proceeds to step 98, discussed above.
[0057] FIG. 5 is a diagram illustrating another embodiment of the
present disclosure, indicated generally at 110. In this embodiment,
network connectivity and remote monitoring/control of pool and spa
components is provided by way of a central pool/spa system
controller 114f. The pool/spa system controller 114f could be the
OMNILOGIC pool/spa system controller manufactured and sold by
Hayward Industries Inc. The pool/spa system controller 114f could
communicate with one or more valve actuators 114e, a single speed
pump 113, a variable speed pump 114a, pool/spa lighting systems
114h, a pool/spa heating or cooling system 114b, and/or a pool/spa
chlorination system 114c, such as a salt chlorinator. Additionally,
the pool/spa control system 114f could receive input from one or
more external sensors 126 and could provide "personality" by way of
remotely provisioned logic for the devices. The pool/spa control
system 114f communicates with a remote server, such as the server
118, via a Wi-Fi router 122 and the Internet. The server 118 could
communicate with one or more remote control systems 120, such as a
smart device (e.g., smart phone, smart speaker, smart TV, embedded
device), a computer system, a tablet computer, etc. The control
system 114f could also receive external web data 131 via the
Internet and Wi-Fi router 122 (e.g., time & date,
sunrise/sunset data, regional and local weather forecasts, wind,
UV, sunlight) for use by pool control logic 170, described
hereinbelow. Additionally, the Wi-Fi router 122 could communicate
with a home management system 125 in a peer-to-peer arrangement, if
desired. The server 118 could also access big data 127 and perform
analytics 129 in connection with various types of information
relating to the pool/spa equipment, usage thereof, and status
information relating thereto. Further, the server 118 communicate
with one or more third-party smart devices 124 via a suitable cloud
application programming interface (API). The third-party smart
devices 124 could also remotely communicate with and control the
pool/spa equipment shown in FIG. 5. Additionally, the pool/spa
control system 114f could include pool logic 170 stored therein for
allowing central control and monitoring of pool/spa equipment at
the pool/spa site. The pool logic 170 could include any of the
various pool control logic described herein. Additionally, such
logic 170 could also be stored in the server 118, or at another
location.
[0058] FIG. 6 is a flowchart, indicated generally at 130,
illustrating processing steps carried out by the system of FIG. 5.
In step 132, the pool/spa system controller 114f of FIG. 5 monitors
connected devices for incoming operational data. Then, in step 134,
a decision is made as to whether incoming operational data has been
received. If not, control returns to step 132. Otherwise, step 136
occurs, wherein the pool/spa system controller receives incoming
operational data. Then, in step 138, the pool/spa system controller
114f processes instructions, operational data, and external data,
discussed hereinbelow. Then, in step 140, the pool/spa system
controller 114f optimizes operational set points. In step 142, the
pool/spa system controller transmits set points to the connected
devices, such as the pool/spa equipment 113, 114a, 114h, 114b, and
114c shown in FIG. 5. In step 144, the pool/spa system controller
114f could also transmit such setpoint information to other
devices, such as the smart devices 124 illustrated in FIG. 5.
[0059] In step 150, the pool/spa system controller monitors for
incoming instructions. In step 152, a determination is made as to
whether an incoming instruction has been received. If not, control
returns to step 150. Otherwise, step 150 occurs, wherein the
pool/spa system controller 114f receives incoming instructions.
Then, processing proceeds to step 138, discussed above. In step
156, the pool/spa system controller 114f monitors for updated
external data (e.g., web-supplied data, such as weather information
and other information from remote data sources). In step 158, the
system determines whether updated external data is available. If
not, control returns to step 156. Otherwise step 160 occurs,
wherein the pool/spa system controller receives the updated
external data. Then, control proceeds to step 138, discussed
above.
[0060] FIG. 7 is a diagram illustrating another embodiment of the
system of the present disclosure, wherein remote connectivity is
provided by way of a pool "hub" component 230. The pool hub
component 230 includes a subset of the functional features of the
pool/spa system controller 114f of FIG. 5, such as basic on/off
control relays, the ability to select a pump speed, the ability to
select heater temperature, the ability to control pool light colors
and shows, the ability to set equipment schedules, and the ability
to interlock one pool/spa component with another pool/spa
component. The pool hub communicates with and controls a number of
pool/spa components, such as a single speed pump 213, a variable
speed pump 214a, pool/spa lighting systems 214h, a pool/spa heating
system 214b, and a pool/spa chlorination system 214c. Additionally,
the pool hub 230 can control a valve actuator 214e and can receive
various sensor inputs 226 and 228, such as temperature sensors,
wind speed sensors, runtime sensors, current/voltage usage sensors,
flow sensors, heater pressure sensors, water temperature sensors,
chlorine sensors, pH/ORP sensors, etc. Such sensors could be
positioned internally within the hub, external thereto, or a
combination thereof. Additionally, the pool hub 230 could be
powered by electrical current supplied by a breaker panel 217 or by
photovoltaic (e.g., solar) cells and/or systems. Breaker panel 217
could also be a smart circuit breaker (e.g., a circuit breaker that
can be controlled via wired or wireless communication) used to
provide and/or to interrupt power to the devices disclosed herein.
The pool hub 230 could communicate with a remote server 218 via a
Wi-Fi router 222 and a network connection such as the Internet. The
server to 218 could include pool logic 270 which can be used to
remotely monitor and control operation of the devices to 213, 214a,
214h, 214b, and 214c. The pool logic 270 could include any of the
pool logic discussed herein. Additionally, the server 218 could
communicate with one or more remote control devices 220, such as a
smart cellular telephone, a remote computer, a tablet computer,
etc. The server 218 could also receive external web data 231 via
the Internet (e.g., time & date, sunrise/sunset data, regional
and local weather forecasts, wind, UV, sunlight) for use by pool
logic 270. Further, the server 218 could communicate with one or
more third-party devices 224 via an appropriate cloud API. Further,
the server 218 could process big data 232 and perform analytics 234
on various pool/spa data. Still further, the server 218 could
communicate with a home management system 225, if desired.
[0061] FIG. 8 is a flowchart illustrating processing steps,
indicated generally at 240, carried out by the system of FIG. 7. In
step 242, the pool hub 230 monitors connected devices for incoming
operational data. In step 244, a determination is made as to
whether an incoming operational data has been received. If not,
control returns to step 242. Otherwise, step 246 occurs, wherein
the pool hub 230 receives incoming operational data. Then, in step
248, the pool 230 transmits incoming instructions and operational
data to the server 218. Then, in step 250, the server 218 receives
the incoming instructions and operational data from the pool hub
230. In step 252, the server 218 processes the incoming
instructions, operational data, and external data, discussed
hereinbelow. In step 254, the server 218 optimizes operational set
points. Then, in step 256, the server 218 transmits operational
setpoints to the pool hub 230. In step 258, the pool hub 230
receives the operational set points. Then, in step 260, the pool
hub 230 transmits the operational setpoints to the connected
devices. In step 262, the pool hub 230 optionally transmits the
operational setpoints to one or more smart devices, such as the
third-party smart devices 224 of FIG. 7.
[0062] In step 263, the pool hub 230 monitors smart devices for
incoming operational data. In step 265, a decision is made as to
whether incoming operational data has been received. If not,
control returns to step 263. Otherwise, step 246 occurs, where in
the incoming operational data is received at the pool hub 230.
Then, control passes to step 248, discussed above.
[0063] In step 264, the pool hub 230 monitors for incoming
instructions. Then, in step 266, a determination is made as to
whether an incoming instruction has been received. If a negative
determination has been made, control returns to step 264.
Otherwise, step 268 occurs, wherein the pool hub 230 receives the
incoming instructions. Then, control passes to step 248, discussed
above.
[0064] In step 272, the server 218 monitors for updated external
data, such as web-supplied data including weather data and other
data. In step 274, a determination is made as to whether updated
external data is available. If not, control returns to step 272.
Otherwise, step 276 occurs, wherein the updated external data is
received at the server 218. Then, control passes to step 252,
discussed above.
[0065] FIG. 9 is a diagram illustrating another embodiment of the
system of the present disclosure, indicated generally at 310. In
this embodiment, a pool command "translator" module 330 is
provided, which includes a complete set of pool logic 370. The pool
logic 370 could include any of the pool logic discussed herein. The
translator 330 could communicate with one or more external relays
329. Additionally, the translator 330 could communicate with a
plurality of pool/spa components, including valve actuators 314e, a
single speed pump 313, a variable speed pump 314a, pool/spa
lighting systems 314h, a pool/spa heating system 314b, and a
pool/spa chlorination system 314c. The translator 330 could receive
electrical power from a breaker panel 317 or from photovoltaic
(e.g., solar) cells and/or systems. Breaker panel 317 could also be
a smart circuit breaker (e.g., a circuit breaker that can be
controlled via wired or wireless communication) used to provide
and/or to interrupt power to the devices disclosed herein.
Additionally, the translator 330 could receive information from
various sensors such as external sensors 326 and internal sensors
328. Such sensors could include, but are not limited to,
temperature sensors, wind speed sensors, runtime sensors,
current/voltage usage sensors, flow sensors, heat pressure sensors,
water temperature sensors, chlorine sensors, PH/ORP sensors, etc.
The translator 330 could also receive external web data 331 via the
Internet and Wi-Fi router 322 (e.g., time & date,
sunrise/sunset data, regional and local weather forecasts, wind,
UV, sunlight) for use by pool logic 370.
[0066] The translator 330 could communicate with the remote server
318 via a Wi-Fi router 322 and a network connection such as the
Internet. The server 318 could communicate with the remote control
system 320, such as a smart cellular telephone, a remote computer,
a tablet computer, etc. Additionally, the server 318 could process
big data 332 and perform analytics 334 on pool/spa data, using a
suitable API. Further, the server 318 could communicate with one or
more third-party smart devices 324, using a suitable cloud API.
Still further, the server 318 could communicate with a home
management system 325, if desired.
[0067] FIG. 10 is a flowchart showing processing steps, indicated
generally at 340, carried out by the system of FIG. 9. In step 342,
the translator 330 monitors connected devices for incoming
operational data. In step 334, a decision is made as to whether
incoming operational data has been received. If not, control
returns to step 342. Otherwise, step 346 occurs, wherein the
translator 330 receives the incoming operational data. Then, step
360 occurs, wherein the translator processes instructions,
operational data, and external data, discussed hereinbelow. In step
362, the translator optimizes operational set points. Then, in step
364, the translator transmits the setpoints to the connect devices
(e.g., to the components 313, 314a, 314e, 314h, 314b, and 314c).
Optionally, in step 366, the translator could transmit the
setpoints to one or more smart devices, such as the third-party
smart devices 324.
[0068] In step 348, the translator 330 monitors smart devices for
incoming operational data. In step 350, a decision is made as to
whether incoming operational data has been received. If not,
control returns to step 348. Otherwise, step 352 occurs, wherein
the translator 330 receives incoming operational data. Then,
control passes to step 360, discussed above.
[0069] In step 354, the translator 330 monitors for incoming
instructions. In step 356, a decision is made as to whether
incoming instructions have been received. If not, control returns
to step 354. Otherwise, step 358 occurs, wherein the translator 330
receives incoming instructions. Then, control passes to step 360,
discussed above.
[0070] In step 368, the translator 330 monitors for updated
external data, such as web data. Such data could include, but is
not limited to, remote weather data, etc. In step 372, a decision
is made as to whether updated external data is available. If not,
control returns to step 368. Otherwise, step 374 occurs, wherein
the translator 330 receives the updated external data. Then,
control passes to step 360, discussed above.
[0071] FIG. 11 is a diagram illustrating another embodiment of the
system, indicated generally at 410. In this embodiment, remote
connectivity is provided by way of a plurality of connectivity
modules 430a-430e. Each of these modules could include a
combination of high and/or low voltage relays for connection to
various pool and spa equipment, such as valve actuators 414e, a
single speed pump 413, a variable speed pump 414a, pool/spa
lighting systems 414h, pool/spa heating system 414b, and/or
pool/spa chlorination system 414C. Connectivity could be provided
to the pool/spa equipment additionally using Wi-Fi, Bluetooth, or
RF mesh (e.g., ZWave, Zigbee, Thread, Weave, etc.) connectivity.
The connectivity modules could provide Wi-Fi for every unit, could
adapt for usage with legacy devices, could provide "personality" by
way of remotely provisioned logic for the devices, could remember
limp mode schedules during a Wi-Fi outage, and could also include
start/stop buttons and an LS bus gate way, if desired. The modules
could be powered by a breaker panel 427 or by photovoltaic (e.g.,
solar) cells and/or systems. Breaker panel 427 could also be a
smart circuit breaker (e.g., a circuit breaker that can be
controlled via wired or wireless communication) used to provide
and/or to interrupt power to the devices disclosed herein.
Additionally, each of the modules could communicate with a remote
server 418 by a Wi-Fi router 422 and a network connection, such as
the Internet. The pool/spa control logic 470 could be provided in
the server 418 for remotely controlling and monitoring the pool/spa
equipment. The pool logic 470 could include any of the pool logic
discussed herein. The server 418 could also receive external web
data 431 via the Internet (e.g., time & date, sunrise/sunset
data, regional and local weather forecasts, wind, UV, sunlight) for
use by pool logic 470. Additionally, the server 418 could
communicate with one or more remote control devices 420, such as a
smart phone, a remote computer, a tablet computer, etc. The server
418 could access big data 432 and perform analytics 434 on pool/spa
data, if desired. Additionally, the server 418 could also
communicate with one or more third-party smart devices 424, via a
suitable cloud API. Still further, the server 418 could communicate
with a home management system 425, if desired.
[0072] FIG. 12 is a diagram illustrating processing steps,
indicated generally at 440, carried out by the system of FIG. 11.
In step 442, the pool connectivity modules 430a-430e monitor smart
devices for incoming operational data. In step 444, a determination
is made as to whether incoming operational data has been received.
If not, control returns to step 442. Otherwise, step 446 occurs,
wherein the pool connectivity modules each receive the incoming
operational data. Then, and step 448, the pool conductivity modules
430a-430e transmit operational data to the server 418. In step 450,
the operational data is received at the server 418. In step 452,
the server 418 processes the incoming instructions, operational
data, and external data, discussed hereinbelow. Then, in step 454,
the server 418 optimizes operational support. In step 456, the
server 418 transmits the operational set points to the connected
devices (e.g., to the devices 413, 414a, 414e, 414h, 414b, and
414c). In step 458, the server transmits operational set points for
the smart devices to the pool connectivity modules 430a-430e. In
step 460, the pool conductivity modules 430a-430e receive the
operational setpoints for the smart devices. Then, in step 462, the
modules transmit the operational set points to the smart
devices.
[0073] In step 464, the server for 18 monitors connected devices
for incoming operational data. In step 466, a determination is made
as to whether incoming operational data has been received. If not,
control returns to step 464. Otherwise, step 450 occurs, wherein
the server 418 receives the operational data. Control then passes
to step 452, discussed above.
[0074] In step 468, the server 418 monitors for incoming
instructions. In step 470, a determination is made as to whether
the incoming instructions have been received. If not, control
returns to step 468. Otherwise, step 472 occurs, wherein the server
418 receives the incoming instructions. Then, control passes to
step 452, discussed above.
[0075] In step 474, the server 418 monitors for updated external
data, such as web data including, but not limited to, remote
weather information, etc. Then, in step 476, a determination is
made as to whether updated external data is available. If not,
control passes to step 474. Otherwise, step 478 occurs, wherein the
updated external data is received at the server 418. Then, control
passes to step 452, discussed above.
[0076] FIG. 13 is a diagram illustrating another embodiment of the
system of the present disclosure, indicated generally at 510. In
this embodiment, wireless connectivity is provided directly within
pool/spa equipment, allowing such equipment to communicate directly
to the Internet. As shown, pool spa equipment, such as a single
speed pump 513, a variable speed pump 5148, pool/spa lighting
system 514h, heater 514b, and/or chlorinator 514c, in addition to
valve actuators 514e, each have built-in wireless communications
subsystems, such as Wi-Fi, Bluetooth, radiofrequency/RF mesh (e.g.,
ZWave, Zigbee, Thread, Weave, etc.), and or cellular wireless
communication subsystems. Each of these devices can communicate
directly with the Internet via a Wi-Fi router 522. Additionally,
external sensors 526 could also communicate with the Wi-Fi router
522, and could also include built-in wireless communications such
as Wi-Fi, Bluetooth, radiofrequency/RF mesh (e.g., ZWave, Zigbee,
Thread, Weave, etc.), and cellular communications. The sensors 526
could include, but are not limited to, heater pressure sensors,
water temperature sensors, chlorine sensors, pH/aware pressure
sensors, etc. It is noted that each of the pool/spa components
could include the ability to remember schedules during a Wi-Fi
outage (limp mode) as provisioned by remote pool logic.
Additionally, each of these devices could include start/stop
buttons, if desired, for stand-alone operation. A breaker panel 527
could provide electrical power to each of the pool/spa components.
Breaker panel 527 could also be a smart circuit breaker (e.g., a
circuit breaker that can be controlled via wired or wireless
communication) used to provide and/or to interrupt power to the
devices disclosed herein. In some embodiments, photovoltaic (e.g.,
solar) cells and/or systems could provide electrical power to one
or more of the pool/spa components.
[0077] Each of the pool/spa components discussed above, including
the sensors 526, could communicate with a remote server 518. The
server 518 could include pool logic 570 for remotely controlling
and/or monitoring the pool/spa equipment. The pool logic 570 could
be any of the pool logic discussed herein. The server 518 could
receive external web data 531 via the Internet (e.g., time &
date, sunrise/sunset data, regional and local weather forecasts,
wind, UV, sunlight) for use by pool logic 570. The server 518 could
also communicate with one or more remote control devices 520, such
as smart telephones, remote computer systems, tablet computers,
etc. The server 518 could also access big data 532 and perform
analytics 534 on pool/spa data, if desired. Additionally, the
server 518 could communicate with one or more third-party smart
devices 524, via a suitable cloud API. Still further, the server
518 could communicate with a home management system 525, if
desired.
[0078] FIG. 14 is a flowchart illustrating processing steps,
indicated generally at 540, carried out by the system of FIG. 13.
In step 542, the server 518 monitors connected devices for incoming
operational data. Then, in step 544, a determination is made as to
whether incoming operational data has been received. If not,
control returns to step 542. Otherwise, step 546 occurs, wherein
the server 518 receives incoming operational data. Then, in step
548, the server 518 processes the instructions, the operational
data, and external data, discussed hereinbelow. In step 550, the
server 518 optimizes operational set points. Then, in step 552, the
server transmits the setpoints to the connected pool/spa devices,
such as those devices shown in FIG. 13.
[0079] In step 554, the server 518 monitors for incoming
instructions. Then, in step 556, a determination is made as to
whether incoming instructions have been received. If not, control
returns to step 554. Otherwise, step 558 occurs, wherein the server
518 receives incoming instructions. Then, step 548, discussed
above, is invoked.
[0080] In step 560, the server 518 monitors for updated external
data, such as web data including, but not limited to remote weather
data, etc. In step 562, a decision is made as to whether updated
external data is available. If not, control returns to step 560.
Otherwise, step 564 occurs, wherein the server 518 receives the
updated external data. Then, control passes to step 548, discussed
above.
[0081] FIG. 15 is a diagram illustrating another embodiment of the
system of the present disclosure, indicated generally at 610. In
this embodiment, network connectivity and remote monitoring/control
is provided by way of a reduced-size hub 646 which can be easily
wall-mounted. The hub 646 provides wired and wireless connections
for various pool and spa equipment, such as a variable speed pump
614a, a single-speed pump 613, a smart heater 614b, a legacy heater
615, a chlorination system 617, any other type of chlorinator 614c,
a booster pump 619, and a third-party pump 621. Various relays 648,
650, 652, and 654 could also be provided for controlling the pumps,
if desired. Also, the hub 646 could communicate with and control a
smart valve actuator 614e, and/or lighting system 614h. Optional
control relays 656 and power supplies 658 could also be in
communication with the hub 646.
[0082] As can be seen, the hub 646 could provide a WiFi hotspot for
allowing a homeowner's cellular telephone, tablet computer, or
personal computer 644 to communicate with the hub 646, and to
control the pool/spa equipment shown in FIG. 15. A breaker panel
627 provides electrical power to the various devices shown in FIG.
15. Breaker panel 627 could also be a smart circuit breaker (e.g.,
a circuit breaker that can be controlled via wired or wireless
communication) used to provide and/or to interrupt power to the
devices disclosed herein. In some embodiments, photovoltaic (e.g.,
solar) cells and/or systems could provide electrical power to one
or more of the various devices shown in FIG. 15. A wall-mounted
light controller 640 could communicate by Bluetooth and/or RF mesh
(e.g., ZWave, Zigbee, Thread, Weave, etc.) to the hub 646 for
remotely controlling the lights 614h. Additionally, a third-party
Bluetooth and/or RF mesh-enabled switch 642 could also communicate
with the hub 646. The hub 646 could also communicate with the
homeowner's WiFi router 622 for providing an Internet connection to
the pool/spa components. A remote pool/spa server 618 could
communicate with the router 622 via the Internet, to provide remote
monitoring and control of the pool/spa equipment, if desired.
Additionally, the server 618 could communicate with one or more
remote computer systems 620 such as a smart phone, a tablet
computer, a remote computer system, etc., if desired. The pool/spa
control logic discussed herein could be installed in the server
618, in the remote computer 620, and/or in the smart phone 644
(e.g., by way of a pool control "app"), if desired. Further, the
server 618 could communicate with one or more third-party smart
devices 624 by a suitable cloud API, and the server 618 could
access big data 632 and perform analytics 634 on pool/spa data, if
desired. The server 618 could also communicate with a home
management system 638, if desired.
[0083] FIG. 16A is a diagram illustrating another embodiment of the
system of the present disclosure, indicated generally at 710. In
this embodiment, network connectivity and remote monitoring/control
is provided by way of a Wi-Fi-enabled pool/spa chlorination system
and controller 717. The controller 717 provides connections for
various pool and spa equipment, such as a variable speed pump 714a,
a single-speed pump 713, a smart heater 714b, a legacy heater 715,
a chlorination system 717c, a booster pump 719, and a third-party
pump 721. Various relays 749, 750, and 754 could also be provided
for controlling the pumps, if desired. Also, the controller 717
could communicate with and control a smart valve actuator 714e,
and/or lighting system 714h. Optional control relays 756 and power
supplies 758 could also be in communication with the controller
717.
[0084] A breaker panel 727 provides electrical power to the various
devices shown in FIG. 16A. Breaker panel 727 could also be a smart
circuit breaker (e.g., a circuit breaker that can be controlled via
wired or wireless communication) used to provide and/or to
interrupt power to the devices disclosed herein. In some
embodiments, photovoltaic (e.g., solar) cells and/or systems could
provide electrical power to one or more of the various devices
shown in FIG. 16A. The controller 717 could also communicate with
the homeowner's WiFi router 722 for providing an Internet
connection to the pool/spa components. A remote pool/spa server 718
could communicate with the router 722 via the Internet, to provide
remote monitoring and control of the pool/spa equipment, if
desired. Additionally, the server 718 could communicate with one or
more remote computer systems 720 such as a smart phone, a tablet
computer, a remote computer system, etc., if desired. The pool/spa
control logic discussed herein could be installed in the server
718, in the remote computer 720, or elsewhere, if desired. Further,
the server 718 could communicate with one or more third-party smart
devices 724 by a suitable cloud API, and the server 718 could
access big data 732 and perform analytics 734 on pool/spa data, if
desired. Still further, the server 718 could communicate with a
home management system 738 if desired.
[0085] FIG. 16B is a diagram illustrating another embodiment of the
system of the present disclosure, indicated generally at 4510. In
this embodiment, network connectivity and remote monitoring/control
is provided by way of a Wi-Fi-enabled pool/spa variable speed
pumping system and controller (also referred to herein in
connection with FIG. 16B as "variable speed pumping system,"
"pumping system," or "controller"), indicated generally at 4514a.
As referred to herein, a variable speed pumping system can include
a variable speed pump, a possessor/controller, memory,
communications interface(s), and an input device, so that the
variable speed pumping system can communicate with and/or control
additional installed pool/spa equipment. Accordingly, pump control
logic 84, as described hereinbelow, could be installed/reside in
variable speed pumping system 4514a. For example, any of the
various processes in the embodiments described herein in connection
with FIGS. 19A-19AU could be incorporated into pump control logic
84 and installed in variable speed pumping system 4514a, either
alone or in any combination. Further, any additional processes
disclosed herein in connection with pool control logic 70 (e.g.,
water feature control logic 72, valve actuator control logic 74,
cleaner control logic 76, lighting control logic 78, heater control
logic 80, chemistry automation control logic 82) could also be
incorporated into pump control logic 84 and installed in variable
speed pumping system 4514a, either alone or in any combination.
[0086] The controller 4514a provides connections for various pool
and spa equipment, such as a pool/spa chlorination system 4517, a
single-speed pump 4513, a smart heater 4514b, a legacy heater 4515,
a chlorination system 4514c, a booster pump 4519, and a third-party
pump 4521. Various relays 4549, 4550, and 4554 could also be
provided for controlling the pumps, if desired. Variable speed
pumping system and controller 4514a could include on-board or
modularly upgradeable pool control components (e.g., communication
modules, relays, temperature sensors, pressure sensors, flow
sensors, etc.). For example, the variable speed pumping system
4514a could control existing heaters (or heat pumps) using on-board
or modularly upgradeable relays and temperature sensors. Pump
control logic 84, discussed in greater detail hereinbelow, could
also utilize multiple sensors for parallel plumbing circuits (e.g.,
branch plumbing). Also, the controller 4514a could communicate with
and control a smart valve actuator 4514e, and/or lighting system
4514h. Optional control relays 4556 and power supplies 4558 could
also be in communication with the controller 4514a. Accordingly,
variable speed pumping system and controller 4514a could use the
modularly upgradeable smart relays to control a variety of existing
installed pool/spa equipment including single speed pumps, pressure
cleaner booster pumps, LED and incandescent pool lights, and
landscape lights. The modularly upgradeable control components can
be used by pump control logic 84 to provide pump or system
performance reporting and diagnostic functions (present and
historical) including, but not limited to, phase current, torque,
speed, horsepower, run time, and ramp rate. Pump control logic 84
could provide the system performance and diagnostic information to
the cloud, or to a smart to a smart device via a Bluetooth or any
of the other communication protocols disclosed herein.
[0087] A breaker panel 4527 provides electrical power to the
various devices shown in FIG. 16B. Breaker panel 4527 could include
one or more smart circuit breakers (e.g., a circuit breaker that
can be controlled via wired or wireless communication) used to
provide and/or to interrupt power to the devices disclosed herein,
and/or conventional circuit breakers. In some embodiments,
photovoltaic (e.g., solar) cells and/or systems could provide
electrical power to one or more of the various devices shown in
FIG. 16B. The controller 4514a could also communicate with the
homeowner's WiFi router 4522 for providing an Internet connection
to the pool/spa components. A remote pool/spa server 4518 could
communicate with the router 4522 via the Internet, to provide
remote monitoring and control of the pool/spa equipment, if
desired. Additionally, the server 4518 could communicate with one
or more remote computer systems 4520 such as a smart phone, a
tablet computer, a remote computer system, etc., if desired. The
pool/spa control logic discussed herein could be installed in the
variable speed pumping system and controller 4514a, in the server
4518, in the remote computer 4520, or elsewhere, if desired.
Further, the server 4518 could communicate with one or more
third-party smart devices 4524 by a suitable cloud API, and the
server 4518 could access big data 4532 and perform analytics 4534
on pool/spa data, if desired. Still further, the server 4518 could
communicate with a home management system 4538 if desired. It is
also further complicated that any of the functions described herein
could also be performed by the variable speed pumping system and
controller 4514a.
[0088] As illustrated in FIG. 16B, the pumping system and
controller 4514a can be provided with a human machine interface or
user interface device, indicated generally at 4560. The user
interface could include physical keys, a digital display, and/or a
touchscreen 4562, as shown in FIG. 16B, any other suitable input
technologies, or any combination thereof. It is also contemplated
that any of the pool/spa equipment described herein could be
provided with a similar user interface device. Providing a user
interface device 4562 on pumping system and controller 4514a
enables the delivery of existing or enhanced features of local
pool/spa equipment control and control of remote devices (e.g.,
beyond the pool area) to the pool owner via the pool pump, while
also reducing costs to the pool owner (e.g., reducing hardware
costs, installation expenses, etc.). Because every pool/spa must
include at least one pump, providing control of and communication
with additional equipment, connectivity, and monitoring (e.g.,
status and condition of pool and equipment) functionality of the
pool environment via the pool pump can further reduce pool owner
cost and significantly improve usability. By leveraging information
obtained at the equipment pad, from remote/external devices, and/or
via a connection to the internet, operation of the pumping system
4514a and other devices can be further optimized.
[0089] FIG. 17 is a diagram illustrating another embodiment of the
system of the present disclosure, indicated generally at 810. In
this embodiment, network connectivity and remote monitoring/control
is provided by way of a reduced-size hub 860 which can be easily
wall-mounted. The hub 860 provides wired and wireless connections
for various pool and spa equipment, such as a variable speed pump
814a, a single-speed pump 813, a smart heater 814b, a legacy heater
815, a chlorination system 817c, and other equipment (e.g.,
lighting equipment).
[0090] As can be seen, the hub 860 could provide a WiFi hotspot for
allowing a homeowner's cellular telephone, tablet computer, or
personal computer 844 to communicate with the hub 846, and to
control the pool/spa equipment shown in FIG. 17. A breaker panel
827 provides electrical power to the various devices shown in FIG.
17. Breaker panel 827 could also be a smart circuit breaker (e.g.,
a circuit breaker that can be controlled via wired or wireless
communication) used to provide and/or to interrupt power to the
devices disclosed herein. In some embodiments, photovoltaic (e.g.,
solar) cells and/or systems could provide electrical power to one
or more of the various devices shown in FIG. 17. A wall-mounted
light controller 840 could communicate by Bluetooth and/or RF mesh
(e.g., ZWave, Zigbee, Thread, Weave, etc.) to the hub 860 for
remotely controlling lights. Additionally, a third-party Bluetooth
and/or RF mesh-enabled switch 842 could also communicate with the
hub 860. The hub 860 could also communicate with the homeowner's
WiFi router 822 for providing an Internet connection to the
pool/spa components. A remote pool/spa server 818 could communicate
with the router 822 via the Internet, to provide remote monitoring
and control of the pool/spa equipment, if desired. Additionally,
the server 818 could communicate with one or more remote computer
systems 820 such as a smart phone, a tablet computer, a remote
computer system, etc., if desired. In this embodiment, the server
818 is a cloud-based, virtual server, and the pool/spa control
logic discussed herein is installed in the server 818. The pool
logic could be any of the pool logic discussed herein. Further, the
server 818 could communicate with one or more third-party smart
devices 824 by a suitable cloud API, and the server 818 could
access big data 832 and perform analytics 834 on pool/spa data, if
desired. The server 818 could also communicate with a home
management system 838, if desired.
[0091] FIG. 18 is a diagram 900 illustrating pump control logic 84.
Pump control logic 84 could incorporate and/or be in communication
with a variety of types of data and/or data sources. More
specifically, pump control logic 84 can communicate with, or
receive, user input data 902, pump operational data 904, pump
factory specifications 906, pump configuration parameters 908, web
data 910, pool configuration parameters 912, data from related
devices 914, health monitoring data 916 and/or external sensor data
918.
[0092] Pump control logic 84 can control variable speed pumps,
designed for residential and commercial pool applications (as well
as additional installed pool/spa equipment), providing flow and
pressure for water circulation and operation of pool equipment.
Variable speed pumps, as described herein, could include a pump wet
end, a motor, a variable frequency/speed drive, and a user
interface (see FIG. 16B). The variable speed pump is used anytime a
pool is in operation, which may be year-round and/or all-day based
on a particular application (e.g. residential vs. commercial) or
location. The pump control logic 84 can control the variable speed
drive to operate in stand-alone mode, relay control mode, or via
communication with Hayward automation, described hereinbelow.
[0093] In stand-alone mode, the pump operates independently of the
pool control logic 70. Stand-alone mode is programmable with
respect to functions such as timers and preset speeds. In relay
control mode, the pump operates according to inputs received from
third party systems and devices using low voltage digital inputs.
For example, the digital inputs could be used to select discrete
timer speeds set in the pump user interface. When communicating
with Hayward automation, the pump is controlled by a variety of
Hayward automation systems such as, but not limited to:
OmniLogic.RTM., ProLogic.RTM., and OnCommand.RTM.. The pump could
communicate with Hayward automation systems using RS485 and
associated Hayward automation communication protocols, or any other
suitable communication protocol disclosed herein.
[0094] In addition to operating in the modes described previously,
the pump can also serve as a pool control system. The user
interface could utilize a color LCD touch screen with resistive
and/or capacitive touch capability, or any other suitable input
technology. The user interface could provide a user with
information such as ambient air and pool water temperatures,
providing true freeze protection capability, as well as thermostat
control of a pool heater or heat pump. The user interface could
also be used to communicate with and to control one or more smart
relays and smart actuators, allowing the pump to coordinate
operation of other pieces of pool equipment. For example, the user
interface can be used for interlock control of other installed
pool/spa equipment. The pump could also be provided with a
communication module (e.g., Wi-Fi, ethernet, Bluetooth, ZWave,
Zigbee, Thread, Weave, etc.) allowing remote application control of
the pump and/or pool pad equipment, and to allow remote data
collection of site specific information.
[0095] Pump control logic 84 can be controlled remotely with a
personal computer, smart phone, tablet, or other device via wired
or wireless communication, including but not limited to, Bluetooth,
Wi-Fi, powerline transmission, etc. Accordingly, the pump can have
a full-featured local interface (see FIG. 16B), minimal local user
interface, or no local user interface at all. Nevertheless, all
aspects of the pump operational data and pump control logic 84 can
be available for review and adjustment if necessary. The pump
control logic 84 can report multiple pieces of information to a
user, the system, or a central server for data collection, storage
and analysis. The information can include, but is not limited to,
date of installation, warranty registration, warranty possible
claims, feedback of problems daily operating conditions, usage
statistics, feedback of power supply conditions or quality,
detailed profiles of pool pad setups, and information related to
other equipment the pump may be controlling. The pump control logic
84 can also automatically register warranties and submit warranty
claims should there be an issue with any piece of equipment in the
system.
[0096] User input data 902 could include timers, schedules (e.g.,
on/off, speed, duration of operation, how much flow should be
provided), turnover goals, turbidity/water clarity goals, etc. Pump
operational data 904 could include power consumption, current draw,
input voltage, flow (rate), flow (yes/no), temperature, water
pressure, air cavitation, water detection, debris sensor, etc. Pump
factory specifications 906 could include power consumption current
draw, input voltage, life expectancy, etc. Pump configuration
parameters 908 could include IP address, GPS coordinates, zip code,
time and date, etc. Web data 910 could include location (based on
IP address), time and date, sunrise/sunset data, regional and local
weather forecast data, ambient temperature, ambient light,
humidity, season, elevation, dew point, etc. For example, the pump
control logic 84 could shift the pump timers based on weather
input. Pool configuration parameters 912 could include pool surface
area, pool geometry, pool liner color, pool cover (yes/no), pool
volume, etc. Data from related devices 914 could include data
relating to at least the following: strainer(s), pool cover(s),
filter(s), chlorinator(s), skimmer(s), pool cleaner(s), water
features (e.g., laminar, bubbler, sheer fall, deck jet, fountains,
scuppers, waterfall, etc.), heater(s) (gas/heat pump), heat
(solar), chemical dispenser(s), disinfectant system(s) (ultraviolet
ozone), secondary pump(s), tablet/liquid chlorine feeder(s),
valves, controller(s), spa(s), water slide(s), etc. For example,
the pump control logic 84 could receive input from an external
device to identify an operating profile. In another example, the
pump control logic 84 could determine the most efficient turn-over
rate based on the volume of the body of water. In yet another
example the pump control logic could lower the speed of the pump to
prevent a water feature from flooding a closed pool cover. Health
monitoring data 916 could include line-to-line balance, grounding,
bonding, leak current, runtime, operating temperature, power
consumption, predictive failure, operating noise, power cycles,
airflow sensor, temperature of cooling, efficiency, settings,
troubleshooting data, etc. External sensor data 918, could include
water level, water temperature, water flow speed, suction/vacuum
pressure, strainer basket load, airflow sensor or temperature of
cooling, pool cover detection, turbidity, valve position, etc.
Additionally, the pump control logic can receive heater and pump
data trends, learning data, time and speeds used per month, time
and duration that a pool cover is open, and various characteristics
of pump use. While it may be desirable for external sensors to
monitor/provide data on as many system parameters as possible
(thereby providing greater optimization, automation, and
user/operator comfort), it is contemplated that some systems need
not utilize an external sensor to monitor every system parameter.
For example, if a temperature sensor has not been installed in a
particular system, the user/operator can provide this information
by first determining the temperature (e.g., by checking a
thermometer, a thermocouple, a weather forecast, the Internet,
etc.) and then entering the temperature into the system via a user
interface. Using this data, the pump control logic 84 could
optimize the operation of the pump by, for example, running based
on whether conditions (e.g., windy conditions produce more leaves
and thus a need for more skimming), maximizing energy factor (or
best efficiency point), communicating errors to the
user/dealer/manufacturer, communicating performance to the
manufacturer (e.g., usage stats) to calculate system curve to
profile pools, providing feedback (e.g., basket is full, bearings
going bad, seal starting to leak, etc.), and responding to needs of
other equipment (e.g., pump/pump control logic could control
actuators or other devices for pool pads with limited equipment
(Low voltage control), lighting system, cleaner, high voltage
control for booster pump, and hub through direct control or bridge
to cloud for pool pad).
[0097] The pump could include a software application (accessible
via user interface 4562 or on a remote device having a similar user
interface), described in greater detail hereinbelow, that delivers
enhanced features to the user. For example, the application could
define a pool owner's usage and target modes for the user to select
from including but not limited to efficiency mode, spa mode, or
party mode. Selecting a mode will automatically adjust pump speed
or flow accordingly. The application can also allow for seasonal
adjustability which will adjust operation of the pump based on the
time of year. The application can also monitor the pump and send a
signal or message if the pump has been inoperative for a defined
period of time. Sending this message can remind a user to resume
operation of a pump if he/she manually stopped it. The application
can also report the energy consumption of the pump instantly or in
monthly or yearly reports. The application can also provide a
single push for pre-loaded programs for the pump. The application
can also allow for quick access dynamic language translation. The
application can also monitor pump usage, and display a number of
"favorite" speeds by the user. The amount of speeds shown can be
dependent on the user and does not have to show the maximum number
of possible preset speeds. The application can also allow for the
quick and easy ability to switch to the last selected program or
"last known good" program which is the last program that ran
without any errors. The application can send notifications of all
activities within the system via Wi-Fi, Bluetooth or similar means.
The notifications can include but is not limited to a blocked
filter, increase in RPM of the pump, or reporting of loss of
prime-protects system. The application can include a page for
frequently asked questions for service and troubleshooting of all
components in the system 10. The application can further include
links to service and troubleshooting videos.
[0098] The pumping system or application can also certify that
installation is correct and reliable. The application can provide a
"certification checklist" and wizard that guides the installer to
verify the entire pool pad after configuration. Some items on the
checklist can include, but is not limited to, checking whether the
correct pump is on the correct relay, verify simulated schedule
execution, confirm all equipment is working, confirm user
preferences, etc. Once the checklist is completed, the pool is
"certified" to be configured and tested and is now ready for
use.
[0099] FIGS. 19A-19G are flowcharts illustrating processing steps
of the pump control logic 84. FIG. 19A is a flowchart illustrating
processing logic of the pump control logic 84 communicating with a
pump. In step 1000, the pump control logic 84 receives an
instruction to activate the pump. In step 1002, the pump logic 84
retrieves data pertaining to factory specified power parameters
from memory, e.g., parameters relating to power consumption,
current draw, and line voltage. In step 1004, the pump logic 84
receives line power operational data. In step 1006, the pump logic
84 determines whether the line power operational data is within
factory specified operation parameters. If a positive determination
is made, the process proceeds to step 1012. If a negative
determination is made, the process proceeds to step 1008. In step
1012, the pump control logic 84 transmits an instruction to the
pump to activate, and the process ends. As referenced above, if a
negative determination is made at step 1006, then the process
proceeds to step 1008. In step 1008, the pump control logic 84
determines if there are any retries remaining. If a positive
determination is made, then the pump control logic 84 proceeds to
step 1004 and continues the process from that step. If a negative
determination is made, then the pump control logic 84 proceeds to
step 1010 and transmits an error condition signal, and then returns
to step 1004 to continue the process from that step. For example,
in step 1002, the line voltage can be measured, including but not
limited to, L1-L2, L1-GND, L2-GND, and in step 1010, pump control
logic 84 can report associated issues to the user. In another
example, pump control logic 84 can measure the line current in step
1002, and in step 1010, pump control logic 84 can report associated
issues to the user. In yet another example, pump control logic 84
can measure the ground leakage current in step 1002, monitor for
proper grounding in steps 1006 and 1008, and report associated
issues to the user in step 1010. The pump control logic 84 can also
check and verify proper bonding connection (e.g., checking for
electrical continuity between the pump and a known good bonding
point using a voltage measurement circuit or other known means) in
the aforementioned steps.
[0100] FIG. 19B is another flowchart illustrating processing logic
of the pump control logic 84 communicating with a pump in
connection with priming. In step 1020, the pump control logic 84
receives an instruction to activate the pump. In step 1022, the
pump logic 84 receives operational data from a pump water detection
sensor. In step 1024, the pump logic 84 determines whether water is
detected. If a positive determination is made, the process proceeds
to step 1029. If a negative determination is made, the process
proceeds to step 1025. In step 1029, the pump control logic 84
clears the priming period timer, and the process ends. As
referenced above, if a negative determination is made at step 1024,
then the process proceeds to step 1025. In step 1025, the pump
control logic 84 starts or continues the priming period timer and
then proceeds to step 1026 where it determines if there is any time
remaining. If a positive determination is made, then the pump
control logic 84 proceeds to step 1027 where it decrements the
priming timer and then continues to step 1022 to continue the
process from that step. If a negative determination is made, then
the pump control logic 84 proceeds to step 1028 and transmits an
error condition signal indicating that prime has failed, and the
process ends.
[0101] FIG. 19C is another flowchart illustrating processing logic
of the pump control logic 84 communicating with a pump. In step
1030, the pump control logic 84 receives an instruction to activate
the pump. In step 1032, the pump logic 84 receives operational data
from a debris sensor in a strainer basket. In steps 1034 and 1036,
the pump logic 84 determines whether the strainer basket is full.
If a positive determination is made, the process proceeds to step
1038 where the pump control logic 84 transmits a message to the
user to clean the strainer basket and then returns to step 1032. If
a negative determination is made in step 1036, then the pump
control logic 84 proceeds to step 1039 and transmits an instruction
to the pump to activate, and the process ends.
[0102] FIG. 19D is a flowchart illustrating processing logic of the
pump control logic 84 determining alert conditions of a pump and
subsequently notifying a user or pool professional (e.g., service
technician, builders, installers, etc.) of the alert condition. The
pump control logic 84 proceeds with four parallel routine sequences
that respectively begin with steps 1040, 1050, 1060, and 1070. Each
routine sequence is discussed sequentially, though it should be
understood that the routine loops could operate in parallel, or
alternatively, in series with each other. The sequence beginning
with step 1040 monitors the health of the pump (as well as other
installed pool equipment, discussed hereinbelow) by monitoring the
runtime of the pump and comparing the runtime of the pump with life
expectancy data. In step 1040 the pump control logic 84 retrieves
factory specified life expectancy data from memory. The factory
specified life expectancy data could be provided by the
manufacturer as a specified number of hour, days, years, etc. for
which the entire pump unit is expected to maintain optimal
performance. Alternatively, factory specified life expectancy data
could be provided for individual components of the pump unit (e.g.,
motor bearings, other motor components, etc.) in addition to, or in
place of, the entire pump unit, thereby providing users and service
providers greater granularity and predictability for maintenance
protocols. In step 1042, the pump control logic 84 determines an
alert threshold, e.g., less than 90% of pump life expectancy
remaining or runtime value. Alternatively, the alert threshold
could be provided by the user, by a pool professional (e.g.,
service technician, builders, installers, etc.), or by the
manufacturer. In step 1044, the pump control logic 84 receives
operational data on pump runtime and proceeds to step 1045 where it
displays an odometer indicating pump runtime. It is noted that the
odometer could also be configured to display the remaining life
expectancy of the pump and/or individual components. In step 1046,
the pump control logic 84 determines if the pump runtime is greater
than the threshold. If a negative determination is made, then the
process returns to step 1044 and continues to receive operational
data on pump runtime. If a positive determination is made, then the
process proceeds to step 1048 where an alert is transmitted to a
user, and the process ends. The alert could be a visual and/or
audio notification that could be displayed on a user's smart device
(e.g., phone, text, or email based). For example, if a user's
smartphone is in communication with pump control logic 84, the
alerts could be delivered via pop-up notification, text, etc. In
addition to describing the problem, the alerts could also suggest
possible remedies (e.g., "Excessive Motor Heating--Reduce
Speed").
[0103] The second sequence begins in step 1050 where the pump
control logic 84 retrieves factory specified operating temperature
data from memory. The process then proceeds to step 1051 and step
1052. In step 1051, the pump control logic 84 stores the
temperature rise (ambient to equipment) in the histogram counters,
and proceeds to step 1053. The histogram counters can be bands that
indicate temperature rise values, e.g., a first counter band can be
a temperature rise of 0-10 degrees, a second counter band can be a
temperature rise of 10-20 degrees, a third counter band can be a
temperature rise of 20-30 degrees, and a fourth counter band can be
a temperature rise of greater than 30 degrees. In step 1053, the
pump control logic 84 determines if the temperature rise is too
high. If a negative determination is made, then the process returns
to step 1051 and continues to store the temperature rise in the
histogram counters. If a positive determination is made, then the
process proceeds to step 1055 where an alert indicating "excessive
motor heating" is transmitted to a user, and the process ends. In
step 1052, the pump control logic 84 determines an alert threshold,
e.g., a temperature value that is 10% above or below operating
temperature. In step 1054, the pump control logic 84 receives
operational data on pump operating temperature. In step 1056, the
pump control logic 84 determines if the pump operating temperature
exceeds the threshold, or is outside of a threshold range. If a
negative determination is made, then the process returns to step
1054 and continues to receive operational data on pump operating
temperature. If a positive determination is made, then the process
proceeds to step 1058 where an alert is transmitted to a user, and
the process ends.
[0104] The third sequence begins in step 1060 where the pump
control logic 84 retrieves factory specified power consumption data
from memory. In step 1062, the pump control logic 84 determines an
alert threshold, e.g., a power value that is 110% of specified
power consumption. In step 1064, the pump control logic 84 receives
operational data on pump power consumption. In step 1066, the pump
control logic 84 determines if the pump power consumption is
greater than the threshold. If a negative determination is made,
then the process returns to step 1064 and continues to receive
operational data on pump power consumption. If a positive
determination is made, then the process proceeds to step 1068 where
an alert is transmitted to a user, and the process ends.
[0105] The fourth sequence begins in step 1070 where the pump
control logic 84 retrieves factory warranty data from memory, e.g.,
a warranty expiration date. In step 1072, the pump control logic 84
determines an alert threshold, e.g., days left on factory warranty.
In step 1074, the pump control logic 84 receives current date
information. In step 1075, the pump control logic 84 determines if
the current date is beyond the threshold date or the number of days
remaining is below the threshold date. If a negative determination
is made, then the process returns to step 1074 and continues to
receive current date information. If a positive determination is
made, then the process proceeds to step 1076 where an alert is
transmitted to a user, and the process ends. In addition to the
foregoing, it is contemplated that the pump control logic 84 could
also report additional information to the user, pool professional
(e.g., service technician, builders, installers, etc.), or
manufacturer including runtime, operating temperatures/profile,
power consumption, operating noise, number of power cycles,
temperature of cooling air (from a pump cooling fan), and
degradation of efficiency.
[0106] FIG. 19E is another flowchart illustrating processing logic
of the pump control logic 84 communicating with a pump. In step
1080, the pump control logic 84 receives an instruction to activate
the pump. In step 1082, the pump logic 84 retrieves maximum power
consumption setpoint data from pool devices from memory, e.g.,
maximum combined power consumption for all active devices. In step
1084, the pump logic 84 receives operational data on power
consumption from all active devices. In step 1086, the pump logic
84 determines the combined power consumption for active devices. In
step 1088, the pump logic 84 determines whether the combined power
consumption is below a setpoint. If a positive determination is
made, the process proceeds to step 1094. If a negative
determination is made, the process proceeds to step 1090. In step
1094, the pump control logic 84 transmits an instruction to the
pump to activate, and the process ends. As referenced above, if a
negative determination is made at step 1088, then the process
proceeds to step 1090. In step 1090, the pump control logic 84
determines if there are any retries remaining. If a positive
determination is made, then the pump control logic 84 proceeds to
step 1084 and continues the process from that step. If a negative
determination is made, then the pump control logic 84 proceeds to
step 1092 and transmits a power save notification, and the process
ends.
[0107] FIG. 19F is another flowchart illustrating processing logic
of the pump control logic 84 communicating with a pump. In step
1100, the pump control logic 84 receives an instruction to activate
the pump. In step 1102, the pump control logic 84 receives date and
time information. In step 1104, the pump control logic 84
determines the current season, e.g., summer. In step 1106, the pump
control logic 84 retrieves operational setpoint data for the
current season from memory, e.g., schedule, pump power, etc. In
step 1108, the pump control logic 84 transmits an instruction to
the pump to operate at seasonal operational setpoints.
[0108] FIG. 19G is another flowchart illustrating processing logic
of the pump control logic 84 communicating with the pump. In step
1110, the pump control logic 84 retrieves setpoint data on the
desired pool turnover rate from the memory (e.g., the desired
turnovers in a twenty-four hour period). While the desired pool
turnover rate can be specified by the user and stored in the
memory, it is noted that the turnover rate setpoint data it could
also be retrieved from the web based on the size, geometry,
location of the pool, or any combination thereof. In step 1112, the
pump control logic 84 retrieves pool configuration data on the
volume of the pool from the memory. The pump control logic 84 then,
in step 1114, receives operational data on flow rate from external
sensors. In step 1116, the pump control logic 84, using the
turnover rate setpoint data, the pool configuration data, and the
external sensor data, calculates the minimum flow rate to achieve
the desired pool turnover rate. In step 1118, the pump control
logic 84 transmits an instruction to the pump to operate at a
minimum speed to achieve the desired turnover rate, and the process
then returns to step 1114. It is noted that by this process, the
pump control logic 84 could continuously adjust the speed of the
pump throughout the twenty-four hour period based on repeated
minimum flow rate calculations.
[0109] FIG. 19H is another flowchart illustrating processing logic
of the pump control logic 84 communicating with the pump. In step
3700, the pump control logic 84 receives an instruction to activate
the pump. In step 3702, the pump control logic 84 retrieves data on
factory specified power parameters from memory. Some examples of
power parameters include, but is not limited to, power consumption,
current draw, line voltage, line current, ground leakage current,
proper bonding, etc. In step 3704, the pump control logic 84
received operational data of the pump, including but not limited
to, L1-L2, L1-GND, and L2-GND. In step 3706, the pump control logic
84 compares whether the operational data is within the specified
operating parameters of the pump. If a positive determination is
made, the pump control logic 84 proceeds to step 3708 where the
pump control logic 84 transmits an instruction to activate the pump
and the process ends. If a negative determination is made, the pump
control logic 84 proceeds to step 3710 where it decides whether
retries are remaining. If a positive determination is made, the
pump control logic 84 proceeds back to step 3704 where it receives
operational data on the pump. If a negative determination is made,
the pump control logic 84 proceeds to step 3712 where an error
condition is transmitted and the process proceeds back to step
3704. The above process can measure all parameters related to
electrical power of the pump and can indicate any type of issue to
the user.
[0110] FIG. 19I is another flowchart illustrating processing logic
of the pump control logic 84. In step 3714, the pump control logic
84 receives an instruction to monitor or measure the water level in
a pump. In step 3716, the pump control logic 84 retrieves data on
factory specified parameters from memory for the water level in a
pump. In step 3718, the pump control logic 84 receives operational
water level data in the pump and in the strainer housing. In step
3720, the pump control logic 84 decides whether the water level
data is within the factory specified operating parameters. If a
positive determination is made, the pump control logic 84 proceeds
to step 3722. If a negative determination is made, the pump control
logic 84 proceeds to step 3728. In step 3722, the pump control
logic 84 determines whether the water level has been an issue for a
set amount of time. If a negative determination is made, the pump
control logic 84 will proceed to step 3724 where the speed of the
pump is increased periodically. If a positive determination is
made, the pump control logic 84 will proceed to step 3726 where it
will indicate to the user that there is an air leak in the suction
side plumbing. In step 3728, the pump control logic 84 will
transmit a message to the user or system that the water level data
is within the factory specified parameters.
[0111] FIG. 19J is another flowchart illustrating processing logic
of the pump control logic 84. In step 3730, the pump control logic
84 receives an instruction to monitor or measure water flow in the
pump. In step 3732, the pump control logic 84 retrieves data on the
factory specified parameters from memory for the water flow in the
pump. In step 3740, the pump control logic 84 receives operational
flow data in the pump. In step 3742, the pump control logic 84
determines whether the flow data is within the range for the
factory specified operational parameters. Step 3742 can further be
associated with cavitation detection. If a negative determination
is made, the pump control logic 84 proceeds to steps 3744, and if a
positive determination is made, the pump control logic 84 proceeds
to step 3746. In step 3744, the pump control logic 84 determines
whether retries are remaining. If there are no retries remaining,
the pump control logic 84 proceeds to step 3748 to transmit an
error condition and if there are retries remaining, the pump
control logic 84 proceeds back to step 3740. In step 3746, the pump
control logic 84 transmits a message to the user or the system that
the flow data is within the factory specified parameters.
[0112] FIG. 19K is another flowchart illustrating processing logic
of the pump control logic 84. In step 3750, the pump control logic
84 receives an instruction to monitor or measure the water
temperature. In step 3752, the pump control logic 84 retrieves data
on the factory specified parameters from memory for the water
temperature. In step 3754, the pump control logic 84 receives
operational data of water temperature and set point temperature
data. In step 3756, the pump control logic 84 determines whether
the water temperature is within the set point and/or factory
parameters. If a positive determination is made, the pump control
logic 84 proceeds to step 3758 where the pump control logic 84
transmits a message to the user that the water temperature is
within the factory specified or set point parameters and the
process would end thereafter. If a negative determination is made,
the pump control logic 84 proceeds to step 3760 where the pump
control logic 84 performs a function or changes the pump operation
to maintain a factory or set point water temperature. In step 3762,
the pump control logic 84 transmits a message to the user or the
system that the pump control logic 84 has performed some function
or changed the pump operation to maintain a factory or set point
water temperature.
[0113] FIG. 19L is another flowchart illustrating the processing
logic of the pump control logic 84. In step 3764, the pump control
logic 84 receives an instruction to monitor or measure the water
chemistry. In step 3766, the pump control logic 84 retrieves data
on factory specified parameters from memory for the water
chemistry. In step 3768, the pump control logic 84 receives
operation data regarding the water chemistry. In step 3770, the
pump control logic 84 determines whether the water chemistry is
within factory specified operating parameters. If a positive
determination is made, the pump control logic 84 proceeds to step
3772 where the pump control logic 84 transmits a message to the
user that the water chemistry is within the specified operating
parameters. If a negative determination is made, the pump control
logic 84 proceeds to step 3774 where the pump control logic 84
determines whether the pool chemistry is maintained by a separate
device. If a positive determination is made, the pump control logic
84 proceeds to step 3776 where the pump control logic 84
communicates with the other device to determine what the device
needs for proper operation. If a negative determination is made,
the pump control logic 84 proceeds to step 3778 directly or after
step 3776. In step 3778, the pump control logic 84 performs a
function or changes operation of the pump to maintain the proper
water chemistry based on the step 3776 or the set point parameters
retrieved from memory. In step 3780, the pump control logic 84
transmits a message to the user or the system that attention may be
needed regarding the water chemistry.
[0114] FIG. 19M is another flowchart illustrating the processing
logic of the pump control logic 84. In step 3782, the pump control
logic 84 receives an instruction to detect a gasket leak or a shaft
seal leak. In step 3784, the pump control logic 84 receives
operational data from a sensor in the gasket or shaft seal. In step
3786, the pump control logic 84 determines if there is a gasket or
shaft seal leak. In step 3788, the determination is made whether
there is in fact a gasket or shaft seal leak. If a negative
determination is made, the pump control logic 84 proceeds to step
3790 and will transmit a message to the user or system that there
is no leak. If a positive determination is made, the pump control
logic 84 will transmit a message in step 3792 that the user should
fix the leak.
[0115] FIG. 19N is another flowchart illustrating the processing
logic of the pump control logic 84. In step 3794, the pump control
logic 84 retrieves factory specified life expectancy data of the
shaft seal from memory. In step 3796, the pump control logic 84
determines the alert threshold for the life expectancy of the shaft
seal. For example, a 90% threshold will alert the user when 90% of
the life expectancy of the shaft seal is reached. In step 3798, the
pump control logic 84 will receive operational data on the shaft
seal runtime. In step 3880, the pump control logic 84 will
determine whether the runtime is greater than the threshold with
regard to the life expectancy data. If a negative determination is
made, the pump control logic 84 will go back to step 3798. If a
positive determination is made, the pump control logic 84 will
proceed to step 3882 and transmit a message to the user regarding
the remaining shaft seal shelf life so that the user can
proactively address the shaft seal before a leak occurs.
[0116] FIG. 19O is another flowchart illustrating the processing
logic of the pump control logic 84. In step 3884, the pump control
logic 84 receives an instruction to determine the cleanliness of
the filter. In step 3886, the pump control logic 84 retrieves data
on the factory specified parameters from memory for debris in the
filter and energy consumption of the pump. In step 3888, the pump
control logic 84 receives operational data from the sensors in the
filter and energy consumption in the pump. In step 3890, the pump
control logic 84 determines the cleanliness of the filter based on
the debris in the filter. In step 3892, the pump control logic 84
makes a determination as to whether the filter needs to be
serviced. If a negative determination is made, the pump control
logic 84 in step 3894 will determine if the energy consumption of
the pump exceeds a factory or user set threshold, and if it does,
the process ends and if it does not, then in step 3896, the pump
control logic 84 can adjust the flow to maintain a flow rate based
on the amount of debris in the filter. If a positive determination
is made in step 3892, the pump control logic 84 in step 3898 will
transmit a message to the user or system to service the filter
(e.g., clean the cartridge). In step 3900, the pump control logic
84 will determine whether the user took action to service the
filter. If a negative determination is made, the pump control logic
84 will proceed to step 3902 to adjust the pump operation to
maintain a flow rate needed by the rest of the system 10. If a
positive determination is made, the pump control logic 84 will skip
step 3902 and will proceed directly back to step 3888.
[0117] FIG. 19P is a flowchart illustrating processing steps
carried out by the pump control logic 84 for periodically testing
and advising the user of the variance from a "clean filter" state.
For example, pump control logic 84 can periodically enter a "test"
filter system state where the pool/spa equipment go to
predetermined positions/states/speeds for testing the filter. In
step 3904, pump control logic 84 monitors for a "clean filter"
condition (e.g., operational data from filter or input from a user,
servicer, or installer, etc.). For example, a skimmer could
communicate (using and of the data communication protocols
disclosed herein) to pump control logic 84 that the filter has been
cleaned or replaced, or the user could utilize an input device to
indicate to pump control logic 84 that the filter has been cleaned
or replaced. In step 3906, pump control logic 84 determines if a
"clean filter" condition has been received. If a negative
determination is made in step 3906, pump control logic 84 returns
to step 3904. If a positive determination is made in step 3906,
pump control logic 84 proceeds to step 3908, where pump control
logic 84 retrieves "test" filter system state setpoints (e.g.,
valve position, pump speed, etc.) from the memory. In step 3910,
pump control logic 84 transmits an instruction to the installed
pool/spa equipment to operate at the "test" setpoints. In step
3912, pump control logic 84 receives current operational date from
the filter. In step 3914, pump control logic 84 determines if there
are (1) retries remaining. If a positive determination is made in
step 3914, pump control logic 84 proceeds to step 3916 and saved
the "clean filter" operational data to the memory. Thus, after pump
control logic 84 receives a "clean filter" condition, the pool/spa
equipment enters a "test" system state and records the current
operational data from the filter to the memory as a baseline
measurement for future comparison. If a negative determination is
made in step 3914, pump control logic 84 proceeds to step 3918,
where pump control logic 84 computes the variance from the "clean
filter" operational data. Optionally, in step 3920, pump control
logic 84 could transmit a message to (e.g., advise) the user (e.g.,
"Filter Health ## %). In step 3922, pump control logic 84 transmits
instructions to the installed pool/spa equipment to resume normal
operation. In step 3924, the logic is delayed for X seconds,
wherein X is any suitable integer (e.g., 5, 10, 3600, etc.), and
the process then reverts to step 3908.
[0118] FIG. 19Q is a flowchart illustrating processing steps
carried out by the pump control logic 84 for determining if debris
is interfering with operation of the pump. For example, in step
3926, pump control logic 84 retrieves setpoint data on the
acceptable debris level at a pump component(s) from memory. This
setpoint data could be provided by the pump manufacturer, or
alternatively, could be set by the user. In step 3928, pump control
logic 84 receives operational data on debris at the pump
component(s). It is noted that the pump control logic could monitor
one or more individual components (e.g., the impeller, shaft seal,
and motor shaft) of the pump and could further monitor one or more
parameters associated with each component (e.g., the level of
debris in the impeller and/or rotational speed of the impeller).
For example, pump control logic 84 could determiner if there is
debris trapped in the impeller by monitoring motor current, motor
power consumption, or by using an accelerometer to determine an
increase in motor vibration. In step 3930, pump control logic 84
determines if the level of debris at the pump component(s) is below
the setpoint. If a positive determination is made in step 3930,
pump control logic 84 returns to step 3928. If a negative
determination is made in step 3930, pump control logic 84 proceeds
to step 3932, where pump control logic 84 determines if there are
retries remaining. If a positive determination is made in step
3932, pump control logic 84 returns to step 3928. If a negative
determination is made in step 3932, pump control logic 84 proceeds
to step 3934, where pump control logic 84 transmits an instruction
to the user (e.g., "Clean Impeller"). While the foregoing process
has been discussed in terms of monitoring debris, it is also
contemplated that pump control logic 84 can monitor additional
parameters and alert the user when these parameters have exceeded
their respective setpoints using similar processing steps. For
example, in addition to monitoring the level of debris trapped in
the impeller, discussed above, pump control logic 84 could also
monitor rotational speeds of the components, determine whether
debris is causing physical interference with the rotation of the
impeller, shaft seal, or motor shaft, and then transmit an
instruction to the user to address the issue (e.g., "Binding in
Impeller--Clear Debris"). For example, pump control logic 84 could
monitor motor current, power consumption, and receive operational
data from an accelerometer to determine an increase in motor
vibration (thereby indicating physical interference/binding of the
impeller). Further still, instead of alerting the user when an
operational parameter has exceeded its respective operational
setpoint, pump control logic 84 could alter the operation of the
pump to restore normal operation. For example, in the case of a
variable speed drive, pump control logic 84 could monitor the
humidity of the air inside the variable speed drive enclosure and
adjust its operating condition to minimize humidity, thereby
increasing reliability. For example, pump control logic 84 could
receive operational data from a humidity sensor located within the
variable speed drive enclosure. If pump control logic 84 determines
that the humidity within the variable speed drive enclosure is
above a maximum setpoint value, pump control logic 84 could
transmit an instruction to the variable speed drive to increase the
speed of operation, thereby drying out the air within the enclosure
(due to increased temperature of certain electrical components
within the enclosure precipitated by the increase in operating
speed).
[0119] FIGS. 19R and 19S are flowcharts illustrating processing
steps carried out by the pump control logic 84 for assisting the
user in determining the pump setpoints that should be used based on
the user's installed equipment and preferences. It is contemplated
that pump control logic 84 could include a wizard-based application
that is accessible by the user via a human machine interface
installed on the pump, centralized pool/spa control system,
smartphone/device, web browser, or any other means for
communicating with the system, disclosed herein. For example, in
step 3936, pump control logic 84 prompts the user to specify
installed pool/spa equipment and operational parameters therefore
(e.g., minimum skimmer speed/flow, number of skimmers, minimum
heater speed/flow, has heater, heat pump, solar, etc.).
Alternatively, the application could utilize widely-known bar
scanning technology (e.g., utilizing/in combination with a camera
of smart device), enabling the user to simply scan the barcode of
each piece of installed equipment thereby avoiding the necessity of
manual entry. Pump control logic 84 could then retrieve additional
information (e.g., specifications, setpoints, warranty information,
etc.) on the scanned equipment from a remote location (e.g., a
remote server) using any suitable communication protocol described
herein (e.g., accessing the internet vial a home Wi-Fi router). In
step 3938, pump control logic 84 prompts the user to specify the
desired pool/spa activities (e.g., bathing, swimming, water sports,
etc.). For example, pump control logic 84 could present the user
with a list of pre-programmed activities from which to choose, the
user could search a database of pre-programmed activities, or the
user could program custom activities and save the same to memory
for later retrieval and use. In step 3940, pump control logic 84
determines an acceptable range of speed setpoints for the pump
(e.g., speed/flow for all pump related features). In step 3942,
pump control logic 84 presents the acceptable speed presets to the
user and then prompts the user to select desired/optimal setpoints
for the pump and in step 3944, pump control logic 84 stores the
user selected pump setpoints to memory and the process then ends.
Optionally, as shown in steps 3950-3954, the wizard could assist
the user in selecting the desired/optimal pump setpoints by
stepping through multiple actual pump speeds/flows so that the user
can "choose" a desired speed/flow while observing the effect of the
different speeds/flows on the actual pool/spa environment. For
example, after determining the acceptable speed setpoints for the
pump in step 3940, pump control logic 84 could then proceed to step
3950, where an instruction is transmitted to the pump to operate at
an (acceptable) first (1.sup.st) speed. In step 3952, pump control
logic 84 transmits an instruction to the pump to operate at an
(acceptable) second (2.sup.nd) speed. In step 3954, pump control
logic 84 transmits an instruction to operate the pump at another
(acceptable) speed. Pump control logic 84 then proceeds to step
3942, described hereinabove. It is noted that any number of
acceptable speeds can be presented to the user. Accordingly,
because the application could be run, viewed, or accessed on a
mobile device (e.g., not tethered to a specific location) the
wizard/application enables the user to stand poolside, watching
features as speeds/flows are automatically displayed by pump
control logic 84 or selected by the user/installer for each prompt.
The wizard/application also enables the user/installer to stand at
the equipment pad, watching equipment function (e.g., heater
ignition) as the pump steps through various speeds/flows.
Optionally, as shown in steps 3946 and 3948, pump control logic 84
could sense and/or advise of a maximum speed/flow beyond which the
pump cavitates or reaches an undesirable inflection point in energy
consumption/efficiency. For example, pump control logic 84 could
determine the maximum speed/flow beyond which the pump cavitates
using operational data received from an accelerometer, optical
sensor, or other means. In step 3946, pump control logic 84
determines if the user selected setpoints are causing pump
cavitation. If a negative determination is made in step 3946, pump
control logic 84 proceeds to step 3944, discussed hereinabove. If a
positive determination is made in step 3946, pump control logic 84
proceeds to step 3948, where an alert is transmitted to the user.
Alternatively, the system could determine speeds at which the pump
cavitates beforehand and remove the speeds at which the pump
cavitates from the acceptable setpoints that are presented to the
user in step 3942. Also optionally, pump control logic 84 could
suggest to the user alternative modes of operation (e.g., other
than that selected by the user) that either improve the reliability
of one or more pieces of installed pool/spa equipment, or improve
the efficiency of one or more pieces of installed pool/spa
equipment, individually, or as a whole system. For example, other
pieces of installed pool/spa equipment could communicate with the
pump control logic 84 and advise of optimum performance criteria.
This logic could reside in other installed pool/spa equipment and
be communicated to the pump, or the logic could be contained within
the pump itself.
[0120] FIG. 19S is a flowchart illustrating processing steps
carried out by the pump control logic 84 for automatically
determining the pump setpoints that should be used based on the
user's installed equipment and preferences. According to this
embodiment, pump control logic 84 is able to "auto detect"
equipment that is installed and automatically determine how the
system should be run based on a variety of optimization choices
(e.g., energy consumption, water feature performance, heating
preferences, etc.). In step 3956, pump control logic 84 prompts the
user to specify desired pool/spa activities (e.g., bathing,
swimming, water sports, etc.). As described above, pump control
logic 84 could present the user with a list of pre-programmed
activities from which to choose, the user could search a database
of pre-programmed activities, or the user could program custom
activities and save the same to memory for later retrieval and use.
In step 3958, pump control logic 84 receives operational data from
pool/spa equipment. In step 3960, pump control logic 84 determines
what pool/equipment has been installed, using the received
operational data therefrom. In step 3962, pump control logic 84
retrieves the installed equipment setpoints (e.g., minimum flow
and/or pressure for heater operation) from memory. Using the
equipment setpoints, in step 3964, pump control logic 84 then
determines the optimal speed setpoints for the pump based on all of
the installed equipment. For example, pump control logic 84 could
estimate the necessary pump speed. Alternatively, pump control
logic 84 could step through various speeds/flows and receive
operational data from the installed equipment (e.g., heaters, water
features, valves, etc.) when there is sufficient flow and/or
pressure for operation. Pump control logic 84 then proceeds to step
3966, where pump control logic 84 stores the pump setpoint data to
memory, and then the process ends. It is also contemplated that, in
addition to pump speed, pump control logic 84 could capture the
correct valve positions for delivering the required flow and/or
pressure. Pump control logic 84 could also search for signals from
any smart utility, radio frequency, Wi-Fi, cellular, Bluetooth,
geo-positioning, etc. that provides data for energy costs, energy
discount periods, peak demand, etc. (see FIG. 33T). Pump control
logic 84 could then use this data to optimize performance and/or
energy costs.
[0121] In addition to the foregoing, the application/wizard could
walk the user through multiple steps for different installation
modes, such as relay control or connection to pool/spa automation
controllers (e.g., Hayward automation), and could indicate
supported software levels of the pool/spa automation controllers.
The application could also access dealer-defined programs/schedules
via the cloud and then download the programs/scheduled to the pump
for local installation. Although pump control logic 84 could
operate according to a dealer-defined or user-defined schedule,
pump control logic 84 is capable of determining when pool/spa
equipment requires a flow that deviates from the normal schedule
(e.g., due to user interaction, weather patterns, addition of
pool/spa equipment, etc.) and automatically adjusting the pump
flow/speed therefore. The application could further provide the
user/installer with answers to frequently asked questions (i.e.,
FAQs) for the installation process as well as for individual pieces
of pool/spa equipment, installation videos (either stored locally
or as links accessible through communication protocols discussed
herein), and can serve as a dynamic "quick start guide." Pump
control logic 84 could also serve as an Automated Engineered pool
system solution for areas having regulations, such as in Florida
(e.g., reports and/or calculates total dynamic head and/or flow).
As described herein, an "Automated Engineered" pool system solution
is one that automatically derives Total Dynamic Head ("TDH") by
measuring key metrics. For example, it could measure suction head
(negative pressure) on the vacuum side of the pump and measure the
pressure head on the pressure side of pump, both measurement
devices being integral or adjacent to the pump, to derive Total
Dynamic Head. Further, an overall System Curve (TDH vs. flow) could
be estimated or calculated from a single point or generated when
measured at multiple speeds when using a multi-speed pump.
[0122] FIG. 19T is a flowchart illustrating processing steps
carried out by the pump control logic 84 for recording baseline
performance data for future reference. More specifically, once the
initial installation of the pool equipment is complete (see FIGS.
19R and 19S), pump control logic 84 can record initial operational
data from the installed equipment. For example, in step 3968, pump
control logic 84 determines if the user has completed the
installation wizard (see FIGS. 19R and 19S). If a negative
determination is made in step 3968, pump control logic 84 repeats
step 3968. If a positive determination is made in step 3968, pump
control logic 84 proceeds to step 3970, where pump control logic 84
receives operational data from installed pool/spa equipment (e.g.,
pump performance, motor performance, sound levels, etc.). In step
3972, pump control logic 84 saves the operational data to the
memory as baseline performance data. This baseline performance data
could be used, for example, in combination with the health
monitoring pump control logic 84 processing steps shown in FIG. 19D
or as illustrated in FIG. 19U, discussed hereinbelow.
[0123] FIG. 19U is a flowchart illustrating processing steps
carried out by the pump control logic 84 for determining pump
health by comparing baseline performance data and current
operational data. In step 3974, pump control logic 84 retrieves
baseline performance data (e.g., pump performance, motor
performance, sound levels, etc.) from the memory. In step 3976,
pump control logic 84 determines an alert threshold (e.g.,
performance down 10%, sound level increase 10%, etc.). In step
3978, pump control logic 84 receives current operational data from
the installed pool/spa equipment and/or other connected devices
(e.g., sound level from microphone located at the pump). In step
3980, pump control logic 84 calculates the change (e.g., delta)
from the baseline performance data. In step 3982, pump control
logic 84 determines if the change from baseline performance is
greater than the threshold. If a negative determination is made in
step 3982, pump control logic 84 returns to step 3978. If a
positive determination is made in step 3982, pump control logic 84
proceeds to step 3984, where pump control logic 84 determines if
there are retries remaining. If a positive determination is made in
step 3984, pump control logic 84 returns to step 3978. If a
negative determination is made in step 3984, pump control logic 84
proceeds to step 3986, where an alert is transmitted to the user
(e.g., "Service Pump"). The process then ends.
[0124] FIG. 19V is a flowchart illustrating processing steps
carried out by the pump control logic 84 for determining current
weather conditions. In step 3988, pump control logic 84 receives an
IP address from a smart device on a local network. In step 3990,
pump control logic 84 receives location data based on the IP
address (e.g., web data/geolocation provider). In step 3992, pump
control logic 84 receives web data on current weather conditions
(based on ZIP code, location/address, or GPS coordinates, discussed
hereinbelow). It is noted that pump control logic 84 can receive
web data through any wired and/or wireless communication protocols
disclosed herein. Current weather conditions can include, for
example, temperature, precipitation, wind speed, wind direction,
etc. Web data on current weather conditions could also include live
3.sup.rd party data, for example, live weather maps of
precipitation and cloud cover. In step 3994, pool pump control
logic 84 saves the current weather conditions to the memory for
later retrieval. In step 3996, pump control logic 84 is delayed by
X seconds, wherein X is any suitable integer (e.g., 5, 10, 3600,
etc.) and then the process returns to step 3988. Optionally, in
step 3998, pump control logic 84 could transmit an instruction to
the user to enter a ZIP code via a user interface device and in
step 4000, pump control logic 84 could receive the ZIP code data
from the user interface device. In step 4002, pump control logic 84
could also/alternatively receive GPS data from a smart device on
the local network (e.g., smart phone connected to home Wi-Fi).
While the foregoing is discussed in connection with pump control
logic 84 obtaining current weather information from a remote source
(e.g., the internet), it is contemplated that pump control logic 84
could obtain current weather information from local sources as well
(e.g., receive operational data from local temperature
sensors/thermocouples, wind meters/anemometers, rain
gauges/ombrometers, etc.).
[0125] Pump control logic 84 can receive web data on
future/forecasted weather conditions (e.g., 7-day forecasts,
almanacs, etc.), in addition to current weather forecasts. FIG. 19W
is a flowchart illustrating processing steps carried out by the
pump control logic 84 for determining forecasted weather
conditions. Although the processing steps shown in FIGS. 19V and
19W are discussed sequentially, it should be understood that the
processing steps carried out by pump control logic 84 in FIGS. 19V
and 19W could operate in parallel, or alternatively, in series with
each other. In step 4004, pump control logic 84 receives an IP
address from a smart device on a local network. In step 4006, pump
control logic 84 receives location data based on the IP address
(e.g., web data/geolocation provider). In step 4008, pump control
logic 84 receives web data on forecasted weather conditions (based
on ZIP code, location/address, or GPS coordinates, discussed
hereinbelow). It is noted that pump control logic 84 can access
receive web data through any wired and/or wireless communication
protocols disclosed herein. Forecasted weather conditions can
include, for example, temperature, precipitation, wind speed, wind
direction, etc. Web data on forecasted weather conditions could
also include live 3.sup.rd party data, for example, live weather
maps of precipitation and cloud cover. In step 4010, pool pump
control logic 84 saves the forecasted weather conditions to the
memory for later retrieval. In step 4012, pump control logic 84 is
delayed by X seconds, wherein X is any suitable integer (e.g., 5,
10, 3600, etc.) and then the process returns to step 4004.
Optionally, in step 4014, pump control logic 84 could transmit an
instruction to the user to enter a ZIP code via a user interface
device and in step 4016, pump control logic 84 could receive the
ZIP code data from the user interface device. In step 4018, pump
control logic 84 could also/alternatively receive GPS data from a
smart device on the local network (e.g., smart phone connected to
home Wi-Fi).
[0126] FIG. 19X is a flowchart illustrating processing steps
carried out by pump control logic 84 for instructing the pump to
run higher load operating modes during cooler times of the day if
higher than normal temperatures are expected. In step 4020, pump
control logic 84 receives current date and time data (e.g., from
internal clock, as web data, etc.). In step 4022, pump control
logic 84 retrieves forecasted weather conditions (e.g., hourly
forecast) for the current date. The forecasted weather conditions
can be obtained by way of the process described herein, in
connection with FIG. 19W. In step 4024, pump control logic 84
retrieves the pump schedule for the current date from the memory.
In step 4026, pump control logic 84 identifies periods (e.g., times
of day) of high load operating conditions in the pump schedule. In
step 4028, pump control logic 84 identifies periods of forecasted
high temperatures (e.g., times of day above 80.degree. F.). In step
4030, pump control logic 84 determines if the periods of forecasted
high temperatures and high load conditions coincide. If a negative
determination is made (e.g., the pump will not be running at a
high-load during periods of high temperature) in step 4030, pump
control logic 84 returns to step 4020. If a positive determination
is made (e.g., the pump will be running at a high-load during
periods of high temperature) in step 4030, pump control logic 84
proceeds to step 4032, where periods of forecasted low temperatures
(e.g., times of day below 70.degree. F.) are identified. Pump
control logic 84 then proceeds to step 4034, where the pump
schedule is modified so that the higher load operating modes run
during periods of forecasted low temperatures. In step 4036, pump
control logic 84 saves the modified pump schedule to the memory.
Pump control logic 84 then returns to step 4020.
[0127] FIG. 19Y is a flowchart illustrating processing steps
carried out by pump control logic 84 for automated operation of
pool devices based on current weather conditions (e.g., periods of
heavy rain). In step 4038, pump control logic 84 retrieves current
weather conditions (e.g., precipitation, wind speed, etc.) data
from the memory. The current weather conditions can be obtained by
way of the process described herein, in connection with FIG. 19V.
In step 4040, pump control logic 84 retrieves maximum precipitation
setpoint data from memory. In step 4042, pump control logic 84
determines if the current amount of precipitation is above the
maximum precipitation setpoint. If a positive determination is
made, the process proceeds to step 4044, where pump control logic
84 transmits an instruction to the pump to suspend operation (e.g.,
preventing damage due to water ingress). Optionally, in step 4046,
pump control logic 84 could transmit an instruction to disconnect
power to high voltage circuits. The process then reverts to step
4038. If a negative determination is made in step 4042, the process
proceeds to step 4048, where pump control logic 84 determines if
the operation of any pool devices (e.g., pump, smart relays, smart
circuit breaker, etc.) has been altered due to the weather
condition (e.g., heavy precipitation). If a negative determination
is made, the process reverts to step 4038. If a positive
determination is made, the process proceeds to step 4050, where
pump control logic 84 transmits an instruction to revert to regular
operation of the pool device(s). Optionally, in step 4052, pump
control logic 84 could transmit a message to the user (e.g.,
"precipitation subsided"). The process then reverts to step 4038.
In addition to the foregoing, it is also contemplated that pump
control logic 84 could suspend operation in advance of periods of
heavy precipitation by monitoring the forecasted weather conditions
and suspending operation before the precipitation begins.
[0128] FIG. 19Z is a flowchart illustrating processing steps
carried out by the pump control logic 84 for automated operation of
pool devices based on current weather conditions (e.g., high
winds). In step 4054, pump control logic 84 retrieves current
weather conditions (e.g., wind speed) data from the memory. The
current weather conditions can be obtained by way of the process
described herein, in connection with FIG. 19V. In step 4056, pump
control logic 84 retrieves maximum wind speed setpoint data from
memory. In step 4058, pump control logic 84 determines if the
current wind speed is above the maximum wind speed setpoint. If a
positive determination is made, the process proceeds to step 4060,
where pump control logic 84 transmits an instruction to the pump to
increase circulation, thereby providing better skimmer performance.
Optionally, in step 4062, pump control logic 84 could transmit an
instruction to actuate a smart valve(s). As referred to herein,
smart valves (or smart valve actuators) include an actuator which
rotates valves in response to a control signal from pool control
logic 70 (e.g., water feature control logic 72, valve actuator
control logic 74, cleaner control logic 76, lighting control logic
78, heater control logic 80, chemistry automation control logic
82). Accordingly, smart valves could be utilized in any application
that requires the automated operation of valves in a pool/spa
environment. For example, actuation of smart valves by pump control
logic 84 could thereby automatically engage pool/spa operation,
solar heating, pool cleaners, water features, provide additional
flow to the skimmer(s), and/or decrease flow from the suction
outlets during periods of high winds. Also optionally, in step
4064, pump control logic 84 could further detect accumulated debris
at pool/spa equipment (e.g., motor fan inlet) and in step 4066,
pump control logic 84 could transmit an alert to the user (e.g.,
"Remove Debris from Motor Fan Inlet"). The process then reverts to
step 4054. If a negative determination is made in step 4058, the
process proceeds to step 4068, where pump control logic 84
determines if the operation of any pool devices has been altered
due to the weather condition (e.g., high winds). If a negative
determination is made, the process reverts to step 4054. If a
positive determination is made, the process proceeds to step 4070,
where pump control logic 84 transmits an instruction to revert to
regular operation of the pool device(s). Optionally, in step 4072,
pump control logic 84 could transmit a message to the user (e.g.,
"Wind Has Subsided"). The process then reverts to step 4054.
[0129] FIG. 19AA is a flowchart illustrating processing steps
carried out by pump control logic 84 for automatically adjusting
pump speed/flow for cleaning a pool/spa in response to a weather
condition (e.g., high winds). More specifically, pump control logic
84 can manage and/or respond to heavy debris/particulate sources
(e.g., trees, vegetation, dust, etc.) up-wind of the pool/spa area
by adjusting the pump speed or flow, based on wind speed and/or
direction. For example, in step 4074, pump control logic 84
retrieves current weather conditions (e.g., wind speed, direction)
data from the memory. The current weather conditions can be
obtained by way of the process described herein, in connection with
FIG. 19V. In step 4076, pump control logic 84 retrieves maximum
wind speed setpoint data from memory. In step 4078, pump control
logic 84 determines if the current wind speed is above the maximum
wind speed setpoint. If a positive determination is made, the
process proceeds to step 4080, where pump control logic 84
retrieves skimmer location data from the memory. The skimmer
location data can be obtained by way of the process described
herein, in connection with FIG. 33A. In step 4082, pump control
logic 84 determines the most downwind skimmer(s). In step 4084,
pump control logic 84 transmits an instruction to increase the flow
to the downwind skimmer(s) and the process then reverts to step
4074. The flow to the downwind skimmer(s) can be increased in
various ways, including, but not limited to, transmitting an
instruction to the pump to increase the pump speed, and
transmitting an instruction to a smart valve to actuate, thereby
adjusting to a position that optimizes flow to the skimmer.
Optionally, in step 4086, pump control logic 84 could transmit an
instruction to deactivate or reduce water features (e.g., decrease
pump speed, adjust valve positions to reduce flow, etc.), thereby
preventing splash-out. If a negative determination is made in step
4078, the process proceeds to step 4088, where pump control logic
84 determines if the operation of any pool devices (e.g., pump,
smart valves, etc.) have been altered due to the weather condition
(e.g., high winds). If a negative determination is made in step
4088, the process reverts to step 4074. If a positive determination
is made in step 4088, pump control logic 84 proceeds to step 4090,
where pump control logic 84 transmits an instruction to revert to
regular operation of the pool device(s). Optionally, in step 4092,
pump control logic 84 could transmit a message to the user (e.g.,
"Wind Has Subsided"). The process then reverts to step 4074.
[0130] FIG. 19AB is a flowchart illustrating processing steps
carried out by pump control logic 84 for automatically adjusting
operation of the pump in response to weather conditions (e.g.,
ambient temperature, wind speed, and/or wind chill) to provide
freeze protection. This enables pump control logic 84 to provide a
lower, more energy efficient setpoint (e.g., minimum speed and
temperature). In step 4094, pump control logic 84 retrieves current
weather conditions data from memory (e.g., ambient temperature,
wind speed, and/or wind chill). The current weather conditions can
be obtained by way of the process described herein, in connection
with FIG. 19V. In step 4096, pump control logic 84 receives
operational data from the pump (e.g., pump speed/flow). In step
4098, pump control logic 84 determines if there is a freeze risk
based on the current weather conditions and the speed/flow of the
pump. If a negative determination is made (e.g., there is no freeze
risk) in step 4098, pump control logic 84 returns to step 4094. If
a positive determination is made (e.g., there is a freeze risk) in
step 4098, pump control logic 84 transmits an instruction to the
pump to increase speed/flow. Pump control logic 84 then reverts to
step 4094.
[0131] FIG. 19AC is a flowchart illustrating processing steps
carried out by pump control logic 84 for adjusting the operation of
the pump to meet the needs of other pool/spa equipment. For
example, pump control logic 84 could increase the speed/flow of the
pump in response to an increase in the output of the heater,
necessitated by a drop in ambient temperature (e.g., heater output
increased to maintain desired pool/spa temperature). In step 4102,
the heater output is increased (e.g., due to a drop in ambient
temperature). In step 4104, pump control logic 84 receives
operational data from the heater (e.g., current or requested BTU
output). In step 4106, pump control logic 84 determines if an
increase in pump speed/flow is required based on the operational
data received from the heater. If a negative determination is made
in step 4106, pump control logic 84 returns to step 4104. If a
positive determination is made in step 4106, pump control logic 84
proceeds to step 4108, where an instruction is transmitted to the
pump to increase speed/flow. Pump control logic 84 then returns to
step 4104. While the foregoing process steps are discussed in
connection with the pump control logic 84 adjusting the operation
of the pump in response to the needs of the heater during a drop in
ambient temperature, it is contemplated that pump control logic 84
can adjust the operation of the pump in response to the needs of
any of the installed pool/spa equipment disclosed herein.
[0132] FIG. 19AD is a flowchart illustrating processing steps
carried out by the pump control logic 84 for determining and
running a mode of operation based on the time of day (e.g., daytime
or evening) or time of year (e.g., season). In step 4110, pump
control logic 84 receives an IP address from a smart device on a
local network. In step 4112, pump control logic 84 receives
location data based on the IP address (e.g., web data/geolocation
provider). In step 4114, pump control logic 84 receives web data on
sunrise/sunset times (based on ZIP code, location/address, or GPS
coordinates, discussed hereinbelow). It is noted that pump control
logic 84 can receive web data through any wired and/or wireless
communication protocols disclosed herein. In step 4116, pump
control logic 84 saves the sunrise/sunset data to the memory for
later retrieval. In step 4118, pump control logic 84 receives
current time and date data (e.g., from web or internal clock). In
step 4120, pump control logic 84 determines if the current time is
between sunrise and sunset (e.g., daytime). If a positive
determination is made in step 4120, pump control logic 84 proceeds
to step 4122, where pump control logic 84 retrieves equipment
setpoints for a daytime operation mode (e.g., pump speed/flow
during the day). In step 4124, pump control logic 84 transmits
instructions to installed pool/spa equipment to operate at the
retrieved setpoints and then pump control logic 84 returns to step
4118. If a negative determination is made in step 4120, pump
control logic 84 proceeds to step 4126, where pump control logic 84
retrieves equipment setpoints for an evening operation mode (e.g.,
pump speed/flow during the evening) and then pump control logic 84
proceeds to step 4124, discussed hereinabove. While the foregoing
process steps have been discussed in terms of selecting a mode of
operation based on the time of day, it is also contemplated that
pump control logic 84 could select the mode of operation based on
the time of year (e.g., season). Furthermore the modes of operation
could be pre-programmed (e.g., default seasonal modes of
operation/programming provided by the manufacturer, pool
professional (e.g., service technician, builders, installers,
etc.)) or user-defined (e.g., customized modes of operation based
on the time of day or season). Optionally, in step 4128, pump
control logic 84 could transmit an instruction to the user to enter
a ZIP code via a user interface device and in step 4130, pump
control logic 84 could receive the ZIP code data from the user
interface device. In step 4132, pump control logic 84 could
also/alternatively receive GPS data from a smart device on the
local network (e.g., smart phone connected to home Wi-Fi).
[0133] FIG. 19AE is a flowchart illustrating processing steps
carried out by the pump control logic 84 for determining and
running a mode of operation based on the amount of sun exposure. In
step 4134, pump control logic 84 receives operational data from an
ambient light sensor (e.g., sun exposure). In step 4136, pump
control logic 84 retrieves ambient light setpoints (e.g., minimum
and/or maximum sun exposure for modes of operation) from the
memory. In step 4138, pump control logic 84 determines if the
current ambient light is above the minimum setpoint. Conversely,
pump control logic 84 could also determine if the current ambient
light is below the below the minimum setpoint or above or below the
maximum setpoint, thereby determining high or low sun exposure. If
a positive determination is made in step 4138, pump control logic
84 proceeds to step 4140, where pump control logic 84 retrieves
equipment setpoints (e.g., pump speed/flow) for a high sun exposure
operation mode. If a negative determination is made in step 4138,
pump control logic 84 proceeds to step 4144, where pump control
logic 84 retrieves equipment setpoints (e.g., pump speed/flow) for
a low sun exposure operation mode. In step 4142, pump control logic
84 transmits an instruction(s) to installed pool/spa equipment to
operate at the retrieved setpoints for the current operation mode
and then the process reverts to step 4134.
[0134] FIG. 19AF is a flowchart illustrating processing steps
carried out by pump control logic 84 for minimizing sound pressure
when pool occupants are in close proximity to a pumping system. In
step 4146, pump control logic 84 receives operational data from a
proximity sensor. In step 4148, pump control logic 84 determines if
there are pool occupants in close proximity. If a positive
determination is made in step 4148, pump control logic 84 proceeds
to step 4150, where pump control logic 84 retrieves maximum ambient
noise setpoint data for pump operation from the memory (e.g.,
maximum allowable decibels when occupants are in close proximity to
the pump). In step 4152, pump control logic 84 receives ambient
noise operational data (e.g., measured decibels from a microphone
positioned at or near the pump). In step 4154, pump control logic
84 determined if the measured ambient noise is above the maximum
ambient noise setpoint. If a positive determination is made at step
4154, pump control logic 84 proceeds to step 4156, where pump
control logic 84 transmits an instruction to the pump to decrease
output (e.g., reduce speed by 5%), thereby reducing the decibels
generated by the pump. Pump control logic 84 then reverts to step
4152. If a negative determination is made at step 4154, pump
control logic 84 reverts to step 4152. If a negative determination
is made at step 4148, pump control logic 84 proceeds to step 4158,
where pump control logic 84 determines if the operation of the
pumping system has been altered (e.g., the output of the pump was
previously reduced from normal operating levels). If a negative
determination is made in step 4158, pump control logic 84 reverts
to step 4146. If a positive determination is made in step 4158,
pump control logic 84 proceeds to step 4160, where pump control
logic 84 transmits an instruction to the pump system equipment to
resume normal operation. Thus, pump control logic 84 could reduce
the output of the pumping system to reduce decibel levels when pool
occupants are detected, but resume normal operation when pool
occupants are no longer present.
[0135] FIG. 19AG is a flowchart illustrating processing steps
carried out by pump control logic 84 for addressing alert
conditions. More specifically, pump control logic 84 could ask the
user if it should automatically address the issue and if it should
automatically address the issue in the future. In step 4162, pump
control logic 84 transmits an alert and recommendation to the user
(e.g., "Excessive Motor Heating--Reduce Speed"). The alert and
recommendation can be generated as described herein, in connection
with FIG. 19D. In step 4164, pump control logic 84 prompts the user
for automatic system implementation of the recommendation (e.g.,
"Reduce Motor Speed?--Y/N"). In step 4166, pump control logic 84
determines if the user elects automatic implementation of the
recommendation. If a negative determination is made in step 4166,
the process ends. If a positive determination is made in step 4166,
pump control logic 84 proceeds to step 4168, where pump control
logic 84 prompts the user for automatic implementation of the
recommendation for subsequent similar alerts (e.g., "Automatically
Address This Alert From Now On?"). In step 4170, pump control logic
84 determines if the user elects automatic implementation for
subsequent alerts. If a positive determination is made in step
4170, pump control logic 84 saves the user preference to memory. In
step 4174, pump control logic 84 transmits an instruction to the
installed pool/spa equipment to implement the recommendation (e.g.,
reduce motor speed). If a negative determination is made in step
4170, pump control logic 84 proceeds to step 7174 and the process
then ends.
[0136] FIG. 19AH is a flowchart illustrating processing steps
carried out by pump control logic 84 for automatically advising the
user of nearby pool service companies when the pumping system, or
any other installed pool/spa equipment, needs attention. It is
contemplated that pump control logic 84 could notify the user by
way of an on-board indicator provided on the pumping system and/or
by way of a notification "pushed" out to other devices (e.g., smart
devices) via any of the communication protocols disclosed herein.
Pump control logic 84 could also automatically notify a user's
preferred pool service provider when the pumping system, or any
other installed pool/spa equipment, needs attention. In step 4176,
pump control logic 84 receives operational data from the installed
pool/spa equipment (e.g., temperature of pump motor). In step 4178,
pump control logic 84 determines if any of the installed pool/spa
equipment is in need of service. Pump control logic 84 can
determine if any of the pool/spa equipment is in need of service by
way of a similar process as described herein, in connection with
FIG. 19D. If a negative determination is made in step 4178, pump
control logic 84 returns to step 4176. If a positive determination
is made in step 4178, pump control logic 84 proceeds to step 4186,
where pump control logic 84 determines the location of the
pool/spa. The location of the pool/spa can be determined by way of
a similar process as described herein, in connection with FIG. 19V.
In step 4188, pump control logic 84 receives web data on local pool
service providers (e.g., pool service providers in close proximity
to the pool/spa location). In step 4190, pump control logic 84
prompts the user to select a preferred service provider (e.g., from
a list of the local pool service providers. In step 4192, pump
control logic 84 stores the selected service provider to memory. In
step 4194, pump control logic 84 transmits an alert to the selected
service provider (e.g., skimmer filter at [address] requires
replacement). Optionally, pump control logic 84 could automatically
notify a previously selected preferred service provider when any of
the pool/spa equipment needs attention. For example, in step 4180,
pump control logic 84 could determine if a pool service provider
was previously selected. If a negative determination is made in
step 4180, pump control logic 84 proceeds to step 4186. If a
positive determination is made in step 4180, pump control logic 84
proceeds to step 4182, where pump control logic 84 retrieves the
previously selected service provider data from the memory. In step
4184, pump control logic 84 transmits an alert to the previously
selected service provider (e.g., skimmer filter at [address]
requires replacement). Pump control logic 84 then returns to step
4176. FIG. 19AI is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4300, the pump control
logic 84 receives an instruction to monitor the status of the
filter. In step 4302, the pump control logic 84 retrieves data on
the factory specified parameters from memory for flow and/or
pressure drop in the pump. In step 4304, the pump control logic 84
receives operational data from a sensor regarding the flow and/or
pressure drop in the pump. In step 4306, the pump control logic 84
determines the pressure drop and/or flow rate in the pump. In step
4308, the pump control logic 84 determines whether the pressure
and/or flow rate is within the factory specified parameters. If a
positive determination is made, the process ends, and if a negative
determination is made, the pump control logic 84 proceeds to step
4310 where the appropriate valves are actuated to initiate backwash
filtering.
[0137] FIG. 19AJ is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4312, the pump control
logic 84 receives an instruction to monitor the debris on the
surface of the pool. In step 4314, the pump control logic 84
receives operational data from the vision system which provides the
location and amount of debris in locations of the pool surface. In
step 4316, the pump control logic 84 determines the location of
high debris area on the pool surface. In step 4318, the pump
control logic 84 alters the position of return fittings and the
skimmers to remove debris from the pool surface in an efficient and
effective manner.
[0138] FIG. 19AK is another flowchart illustrating the processing
logic of the pump control logic 84. For example, pump control logic
84 could determine the correct water flow for water features by
communicating with other pieces of installed pool/spa equipment
which advise pump control logic 84 of optimum performance criteria.
This logic could reside in other installed pool/spa equipment and
be communicated to the pump, or the logic could be contained within
the pump itself. In step 4320, the pump control logic 84 receives
an instruction to determine the correct flow for a water feature.
In step 4322, the pump control logic 84 retrieves data for the
water features from memory. The data retrieved can include, but is
not limited to, type of water feature, size, capacity, water flow
capacity, water flow levels, etc. In step 4324, the pump control
logic 84 receives user input, if any, for water feature
customization to achieve a custom appearance. For example, a manual
mode could be provided to allow the user to specify the desired
water feature performance. If there is no user input, then the pump
control logic 84 can use the data retrieved in step 4322. In step
4326, the pump control logic 84 can calculate the optimal flow rate
based on the characteristics of the water feature. Such
characteristics, include but is not limited to, water feature,
size, capacity, water flow capacity, water flow levels, etc. In
step 4328, the pump control logic 84 receives a schedule for the
water features, if any. In step 4330, the pump control logic 84
adjusts the valves of the water feature so that the their operation
can be schedule based. In step 4332, the pump control logic 84
transmits the flow rate needed for the water feature. The type of
water features can include, but is not limited to, laminars,
bubblers, waterfalls, deck jets, fountains, and skuppers.
[0139] FIG. 19AL is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4334, the pump control
logic 84 receives an instruction to provide flow to a heater. In
step 4336, the pump control logic 84 retrieves water temperature
set point data for heater operation from memory. This data could
include minimum and maximum water temperatures set by a user or set
by factory specified operating parameters. In step 4338, the pump
control logic 84 receives operational temperature data. In step
4340, the pump control logic 84 determines whether the water
temperature is below a minimum set point. If a positive
determination is made, the pump control logic 84 proceeds to step
4342 to transmit an instruction to provide flow to the heater. If a
negative determination is made, the pump control logic 84 proceeds
to step 4344 to determine whether the water temperature is above a
maximum set point. If a negative determination is made, the process
ends. If a positive determination is made, the pump control logic
84 actuates valves to bypass the heater to improve hydraulic
efficiency in step 4346.
[0140] FIG. 19AM is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4348, the pump control
logic 84 receives an instruction to activate a heater or monitor or
address heating controls. In step 4350, the pump control logic 84
retrieves an optimum flow rate set point data for heater operation
from memory. In step 4352, the pump control logic 84 receives
operational flow rate and/or valve position data. In this step, the
pump control logic 84 receives data from the heat source
identifying when the heat source has adequate flow and/or pressure
to operate. In step 4354, the pump control logic 84 determines
whether the operational data is within the optimal set point range.
If a positive determination is made, the pump control logic 84
proceeds to step 4356 to store and/or update current optimal flow
rate for each heater device. The pump control logic 84 can store a
history of this data. If a negative determination is made, the pump
control logic 84 proceeds to step 4358 where a determination is
made regarding whether retries are remaining. If a positive
determination is made, the pump control logic 84 proceeds to step
4360, to transmit an instruction to increase flow to the heater by
five percent. Any other percentage increase could be used. If a
negative determination is made, the pump control logic 84 proceeds
to step 4362 to transmit an error condition and the process would
then end.
[0141] FIG. 19AN is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4364, the pump control
logic 84 receives an instruction to manage a pump. In step 4366,
the pump control logic 84 receives operational data from a pool
cover. In step 4368, the pump control logic 84 determines whether
the pool cover is closed. If a negative determination is made, the
pump control logic 84 reverts back to step 4366. If a positive
determination is made, the pump control logic 84 proceeds to step
4370 where it retrieves pool configuration parameters from memory
such as pool surface area, volume, geometry, water features, etc.
in step 4372, the pump control logic 84 determines proper operation
of the pump when the pool cover is closed based on the factors
retrieved above. In step 4374, the pump control logic 84 determines
proper pump speed to ensure the pool cover is not damaged by
flooding. In step 4376, the pump control logic 84 can determine the
decreased rate of chlorine reduction due to lack of direct sunlight
or less solar loading. In step 4378, the pump control logic 84
transmits instructions to pump of the foregoing calculations such
as proper pump speed.
[0142] FIG. 19AO is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4380, the pump control
logic 84 receives an instruction to manage the water level in the
pool. In step 4382, the pump control logic 84 retrieves pool water
level settings from memory. This setting can be user set or set by
factory default parameters. In step 4384, the pump control logic 84
receives operational data from a sensor monitoring the water level
in a pool. In step 4386, the pump control logic 84 determines
whether the water level is within the set point parameters. If a
positive determination is made, the pump control logic 84 proceeds
to step 4388 to transmit an appropriate message to the user or the
system. If a negative determination is made, the pump control logic
84 proceeds to step 4390 to adjust the operation of the pump to
allow the water level in the pool to reach the set point
parameters. In step 4392, the pump control logic 84 transmit an
appropriate message to the user or the system that the water level
is not in set point range and that the pump operation has been
adjusted to remedy the water level situation.
[0143] FIG. 19AP is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4394, the pump control
logic 84 receives an instruction to manage the operation of the
pump based on the number of bathers in the pool. In step 4396, the
pump control logic 84 receives operational data from motion
sensors. In step 4398, the pump control logic 84 determines the
number of bathers in the pool based on the data from the motion
sensors. In step 4400, the pump control logic 84 retrieves pool
configuration parameters from memory. Such parameters could
include, but is not limited to, pool surface area, volume,
geometry, etc. The parameters will assist the pump control logic 84
in step 4402 to determine proper pump speed based on the number of
bathers in the pool. The pump in step 4402 can adjust its operation
based on the number of bathers. Furthermore, the pump control logic
84 could also control other equipment that needs to be deactivated
or activated based on the presence and/or number of bathers in the
pool. For example, in step 4404, the pump control logic 84
determines whether to activate or deactivate other pool equipment
based on the number of bathers in the pool. In step 4406, the pump
control logic 84 transmits the deactivation or activation signal to
the other equipment.
[0144] FIG. 19AQ is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4408, the pump control
logic 84 receives an instruction to monitor system curve of the
pump which is the summation of the dynamic head. In step 4410, the
pump control logic 84 retrieves data regarding the pump from
memory. In step 4412, the pump control logic 84 receives
operational data from sensors monitoring the pump. In step 4414,
the pump control logic 84 estimates or calculates the system curve
based on the multiple speeds of the pump. Alternatively, pump
control logic 84 could estimate or calculate the overall system
curve based on a single point. In step 4416, the pump control logic
84 provides an indication of system efficiency rating and alerts
trade and/or consumers based on factory defined or selectable
changes. In step 4418, the pump control logic 84 provides an
indication of system efficiency such as "efficiency mode,"
"performance mode" etc. and assigns a push button to go to a
selected mode with one push of a button. In step 4420, the pump
control logic 84 calculates periods of hydraulic inefficiencies and
in step 4422, it recommends ways to improve hydraulic efficiency.
In step 4424, the pump control logic 84 auto-delivers the correct
flow or speed to make the equipment more efficient. For example,
pump control logic 84 could measure suction head (negative
pressure) on the vacuum side of the pump and measure pressure head
on the pressure side of pump, both measurement devices being
integral or adjacent to the pump, to derive Total Dynamic Head
("TDH"). An overall System Curve (TDH vs. flow) could also be
estimated or calculated from a single point, or generated when
measured at multiple speeds when using a multi-speed pump. Further
pump control logic 84 could compare the calculated system curve to
known industry system curves (e.g., "Curve A", "Curve C", etc.) and
determine a hydraulic efficiency "score." Pump control logic 84
could then determine how to improve the efficiency score and then
either provide general suggestions to the user to improve said
score, or automatically implement the suggestions. In one example,
pump control logic 84 could monitor the typical operating flow of
the pool/pump and suggest alternate schedules that would achieve
the same number of turnovers in a day with lower power
consumption.
[0145] FIG. 19AR is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4426, the pump control
logic 84 receives an instruction to monitor demand based operation
from local utility companies. In step 4428, the pump control logic
84 retrieves data on factory specified parameters from memory for
the utility company. In step 4430, the pump control logic 84
receives operation data of the pump flow. In step 4432, the pump
control logic 84 determines whether the pump operational data is
within the set point parameters set by the utility company. If a
positive determination is made, the pump control logic 84 proceeds
to step 4434 where a message is transmitted to the user regarding
the pump operational data being within the set point parameters of
the utility company and the process ends. If a negative
determination is made, the pump control logic 84 proceeds to step
4436 where the pump control logic 84 performs a function or changes
the pump operation to conform to the utility company set point
parameters. Then in step 4438, the pump control logic 84 transmits
a message that the pump operation has changed to conform to the
utility company standards.
[0146] FIG. 19AS is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4440, the pump control
logic 84 receives an instruction to provide flow to a selected pool
equipment. In step 4442, the pump control logic 84 retrieves data
on factory specified parameters from memory for the pumping needs
of a selected pool equipment. In step 4444, the pump control logic
84 determines whether the flow data is being defined by the
selected pool equipment. If a negative determination is made, the
pump control logic 84 proceeds to step 4446 where the pump itself
defines the flow parameters for the selected pool equipment based
on the flow provided by the pump. If a positive determination is
and after step 4446, the pump control logic 84 proceeds to step
4448 where it receives operational data for the flow of the pool
equipment. In step 4450, the pump control logic 84 determines
whether the flow data is within the set point parameters either
defined by the equipment or the pump. If a positive determination
is made, a message is transmitted to the user or the system that
the flow data is within operating parameters. If a negative
determination is made, the pump control logic 84 proceeds to step
4454 where the speed of the pump is increased periodically to meet
the demand of the pool equipment and the process again reverts to
step 4448 to receiver operational data and make the same
determination in step 4450.
[0147] FIG. 19AT is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4456, the pump control
logic 84 receives an instruction to measure the turbidity of the
water. In step 4458, the pump control logic 84 retrieves data on
factory specified parameters from memory regarding the turbidity of
the water. In step 4460, the pump control logic 84 receives
operational turbidity data. In step 4462, the pump control logic 84
determines whether the turbidity data is within the specified
operating parameters. If a positive determination is made, the pump
control logic 84 proceeds to step 4464 where a message is
transmitted regarding the turbidity data being within the operating
range. If a negative determination is made, the pump control logic
84 proceeds to step 4466 where a determination is made as to
whether the user wants to set a blackout time instead of a filter
time. If a negative determination is made, the pump control logic
84 proceeds to step 4468 where the pump control logic 84
automatically sets the filter schedule based on turbidity level. If
a positive determination is made, the pump control logic 84 sets a
blackout time period based on the user input in step 4470. Then in
step 4472, the pump control logic 84 adjusts the pump to pump only
what is needed to save energy and meet turbidity levels.
[0148] FIG. 19AU is another flowchart illustrating the processing
logic of the pump control logic 84. In step 4473, the pump control
logic 84 receives an instruction to prime the pump. In step 4474,
the pump control logic 84 can start the pump at the desired speed,
not the prime speed. In step 4476, the pump control logic 84
receives operation data from the pump regarding water detection. In
step 4478, the pump control logic 84 determines whether water is
detected. If a positive determination is made, the pump control
logic 84 proceeds to step 4480 where the priming period timer is
cleared and the process ends. If a negative determination is made,
the pump control logic 84 proceeds to step 4482 where a timer is
started or continued. In step 4484, the pump control logic 84 make
a determination as to whether there is time remaining in the timer
that was started. If a positive determination is made, the pump
control logic 84 decrements the timer and proceeds back to step
4476. If a negative determination is made, the pump control logic
84 proceeds to step 4484 where a determination is made as to
whether if the current try is a retry. If a positive determination
is made, the pump control logic 84 proceeds to step 4490 where an
error condition is transmitted alerting the system or user that the
priming failed and the process ends. If a negative determination is
made and the current try is the first try, then the pump control
logic 84 proceeds to step 4492 where the pump is stopped and
allowed to cool. Then in step 4494, the pump control logic 84
reprimes at the maximum rotations per minute until flow return,
then immediately the pump control logic 84 will return to the user
or firmware desired speed.
[0149] The above processes for the pump control logic 84 can also
be applied to a pumping system that is able to manage auxiliary
pumps used at any given site. Some of the management features can
include, but is not limited to, turning auxiliary pumps on/off
according to specific schedules, as well as changing the pump speed
for a variable speed pump. Indeed, all of the processes for the
pump control logic 84 as shown with respect to FIGS. 18-19AU can be
applied to auxiliary pumps. Auxiliary pumps can include, but are
not limited to, pressure cleaner booster pumps, waterfall pumps,
and pumps used for water features or spas.
[0150] It is contemplated that any of the various processes in the
embodiments described herein in connection with FIGS. 19A-19AU
could be incorporated into pump control logic 84 either alone or in
any combination. Further any additional processes disclosed herein
in connection with pool control logic 70 (e.g., water feature
control logic 72, valve actuator control logic 74, cleaner control
logic 76, lighting control logic 78, heater control logic 80,
chemistry automation control logic 82) could also be incorporated
into pump control logic 84 either alone or in any combination. For
example, the pump could include or be modularly upgradeable to
include any of the various processes in the embodiments described
herein in connection with FIGS. 19A-19AU. Further still, any of the
flowcharts illustrating processing steps disclosed in connection
with pump control logic 84 can be applied to pool control logic 70
(e.g., water feature control logic 72, valve actuator control logic
74, cleaner control logic 76, lighting control logic 78, heater
control logic 80, chemistry automation control logic 82).
[0151] As mentioned briefly above, embodiments may provide smart
valves/smart valve actuators that include an actuator which rotates
valves in response to a control signal. In one embodiment, the
smart valve actuator may function as a stand-alone control for its
associated valve or valves. In another embodiment, the smart valve
actuator may operate in conjunction with a control automation
system as described herein. In a further embodiments, the smart
valve actuator can operate according to a preset, preconfigured,
and/or modifiable schedule. The smart valve actuator as described
further below may provide for an easier installation and use by
untrained installers and users. Further, the smart valve actuator
may reduce the time and cost required when needing multiple pumps
and ball valves to attain a perfect balance of distributed or
shared water features. Additionally the smart valve actuator gives
the pool owner control over his water features, the ability to
articulate and balance them remotely, and the possibility of
providing varied effects on demand.
[0152] Traditional (non-smart) valve actuators have been used to
electrify a valve to enable remote control. Existing valve
actuators have internal or software driven limit switches that the
installer can use to program the valve actuator to stop turning the
valve at the desired point. This allows a valve to turn to a
desired point and deliver a desired effect on a water feature, and
prevents the actuator motor from turning the valve to inappropriate
positions that may `dead-head` the plumbing, blocking all water
flow. However, the installer of such a valve actuator must
carefully mount the valve actuator in one of four orientations on
top of the valve in order to place the existing 180 degrees of
control in the needed orientation with the valve. Then the
installer must disassemble the actuator body and carefully
re-position two cams so that when the shaft position reaches the
desired limit, the cam depresses an internal limit switch and
disconnects power to the motor. This installation procedure is time
consuming and requires skill.
[0153] Traditional (non-smart) valve actuators have also required
an AC low-volt power supply to power the actuator's motor. This
power source may require additional circuitry or power transformers
to generate this power source dedicated only for use to power the
actuator motor. Additionally, traditional valve actuators have only
one programmable limit for clockwise and one for counterclockwise
actuation. These programmable limits may be set to achieve a
particular effect on a water feature, for example causing a
pleasing flow on a fountain or a desired height on a deck jet.
However, if the water flow or pressure changes at the input port of
the valve, the desired effect is lost. Similarly, water flow will
change due to pump speed changes, filter media condition, and
interaction with the valve position of additional valves in the
system or booster pumps that may divert water. Having water
features that are influenced by interactions with other equipment
and valves results in undesired performance. Installers often add
completely isolated plumbing systems only for water features to
avoid this undesired behavior. An additional issue with traditional
valve actuators is that the cam setting of traditional valves is
limited in resolution to the splines present on the actuator drive
shaft, and is often too coarse to allow setting for an exact water
feature effect. This requires compromise in setting to the nearest
setting.
[0154] Embodiments provide a smart valve actuator that addresses
many of the drawbacks of traditional valve actuators. In one
embodiment, a smart valve actuator has the ability to be controlled
directly at the device or from the pool automation system in the
same manner as one would control a variable speed pump, for
example, by providing control of intermediate positions via
software control. In one embodiment the smart valve actuator may be
addressed automatically from the control. In another embodiment,
the control may be given an address of the smart valve actuator
that enables the control to transmit fixed and variable commands to
the smart valve actuator. Embodiments may provide a number of
additional features such as the ability to set minimum and maximum
settings for each smart valve actuator to allow for minimum and
maximum allowed flow and to set protection limits to prevent the
valve from turning to potentially damaging positions. Additional
features may enable the configuration/setting of high, medium and
low default flow settings and the ability to control positions
variably by using, as non-limiting examples, digital or analog +
and - buttons, a digital or analog slider, or a rotary knob on the
controller or on the actuator to control the flow. In one
embodiment LEDs may be provided that allow the pool owner or
servicer to identify settings, set points and flow at a glance. In
further embodiments, an added flow, temperature or pressure sensor
can monitor the water properties of the output flow and
automatically adjust the valve position to seek a programmed
setpoint and/or an absolute position sensor can allow manual valve
actuation without requiring re-synchronization after the motor is
re-connected to the shaft, thereby eliminating the need to mount
the smart valve actuator in a particular orientation because the
device can manage the valve angle over the entire 360 degree
rotation of the valve.
[0155] The smart valve actuator can be used manually or through
automation. The smart valve actuator may sit on an existing valve,
may have a valve integral to it on pool equipment plumbing or may
be located at a location in the backyard to control a flow of water
between one to many plumbed water ports. In one embodiment, the
smart valve actuator is capable of receiving from, or giving to, a
pool controller, a unique address that enables communication of
specific commands and settings between the actuator and its
controlling entity. In some embodiments, when controlled by the
pool automation system, the smart valve actuator may communicate by
communication protocols, including without limitation, RS485,
Ethernet, Wi-Fi, Bluetooth.TM., zwave, ZigBee.TM., thread, cellular
or another communication protocol. Wireless control of the smart
valve actuator from a web-enabled device or the pool controller may
occur in the following embodiments: when the Wi-Fi chip is on main
(intelligence) pcb, is attached/plugged into main pcb, is modularly
upgraded on the main pcb or in the pcb enclosure, is modularly
upgraded on/external to the main pcb enclosure, or is remote to the
main pcb enclosure. An antenna may be mounted with, or located
remote to, the Wi-Fi chip for all prescribed locations/methods
described above. The smart valve actuator may also allow pool
controlling devices to communicate directly with web-enabled
devices (e.g.: phone, tablets, phones, thermostats, voice enabled
devices, etc. . . . ) without the need to go through a home
router.
[0156] The smart valve actuator can be configured to set specific
open and close valve settings, and it can be defaulted or
configured with default settings for low flow, medium flow, high
flow, or programmable flow at varied angles. These flow rates can
be used to dial in settings when a pump is powering the water
associated with water features. In some cases these flow rates can
be used to achieve the desired outcome at the lowest flow
increasing the pool's energy efficiency. The smart valve actuator's
position may be variably controlled in a number of ways, such as
without limitation, by using push and hold digital or analog
buttons, digital or analog + and - buttons, a digital or analog
slider, and/or a rotary knob on the controller or on the actuator
to control the flow.
[0157] In one embodiment, the smart valve actuator may be used to
automate filter valves and their associated positions such as, for
example, filter, backwash, rinse, waste, closed, recirculate, and
winterize. An additional benefit of the smart valve actuator is
that it may allow filters and valves to be bypassed when not
required for certain applications, such as when operating an
attached spa, thereby improving flow and energy efficiency. In
another embodiments, the smart valve actuator could be used in
connection with the addition of chemicals (e.g., ORP, pH, free
chlorine, etc.) to the pool/spa. For example, the smart valve
actuator could be used to integrate the automation of various
positions for tablet feeding automation.
[0158] In an embodiment, the smart valve actuator may be used to
automatically manage water flow needed for operation of suction and
pressure cleaners. When a smart valve actuator is used in
conjunction with a variable speed pump, the pump may be able to
increase its speed to deliver the flow necessary for proper
operation of a suction or pressure cleaner, thereby maximizing
energy savings when compared to running the variable speed pump at
a higher speed throughout the day. In one embodiment, the smart
valve actuator control may set angles via commands. The commands
may be stored in the controller or the actuator processor. The
change in settings may be done automatically; may be done through
power interruption to move to the next setting, may be done through
time duration of the power interruption; and may be done with a
manual setting on the actuator.
[0159] Among its features, the smart valve actuator may have 1 to
many increments with increments set at 0.5 degrees for 180 degrees,
or other resolution or range. The smart valve actuator may measure
the angle set manually and store that position in memory for use as
one of its default settings. In one embodiment the smart valve
actuator may include sensor capabilities to measure the
temperature, flow rates and/or pressure of the input water or
output water when the valve is diverted and be able to use the
measured parameters to turn the motor to achieve a desired
setpoint. The flow sensing or pressure sensing may be built into
the smart valve actuator or may be attained by a secondary flow
sensor.
[0160] In one embodiment, a stored setpoint flow/pressure level may
be used by a PID loop (or other control algorithm) to turn the
valve to a needed position to achieve the flow and the smart valve
actuator may update the position if conditions (pressure, flow,
etc.) changes.
[0161] As noted, the smart valve actuator provides a number of
improvements over traditional (non-smart) valve actuators. For
example, the smart valve actuator may manage a fluid level in a spa
with a sensor or may manage return valves from a spa to prevent the
spa from emptying or overfilling via level sensing. The smart valve
actuator may block a water feature flow if ambient temperatures are
too low thus providing a valve-controlled freeze protection. For
example, the smart valve actuator may be operated by a bi-metallic
switch as an input that reverses the motor at low temperatures (no
circuit board needed). The smart valve actuator may communicate
with a pool cover sensor input that prevents activation of a water
feature if the pool cover is closed. Additionally, in some
embodiments, the smart valve actuator may open a solar panel return
if the solar panel temperature has reached a desired setpoint. In
one embodiment, the smart valve actuator may include a wind sensor
and block a water feature flow if forecasted wind (retrieved from
the web) is too high. For example, the smart valve actuator may
reverse the motor at higher wind speeds to stop water features from
dumping water out of the pool. The smart valve actuator may also
block a water feature if flooding is sensed by float or
conductivity sensing. In one embodiment, the smart valve actuator
may include a dual input power capability that can accept either AC
power inputs or DC power input to power the motor. Further, in some
embodiments, the smart valve actuator can include a handle, or the
like, to provide for manual operation of the smart valve actuator,
if necessary, during loss of power (e.g., power cable being cut) or
loss of communication (e.g., communications cable being cut,
electronics failure, etc.) to the smart valve actuator.
[0162] Among the improvements made possible through the use of the
smart valve actuator as described herein are increased efficiency
in the pool system. For example, in one embodiment, the smart valve
actuator may monitor energy saving interactions with a pump to
support a minimum required speed to achieve requested flows in all
of the active water features. This approach may enable all water to
go through the water features and none through the return jets
because of 100% efficiency. Similarly, the smart valve actuator may
request a higher RPM if the desired flow cannot be achieved (a pump
runs only at filtration speed, but if a water feature is turned on,
the smart valve actuator controller can request increased speed if
the flow setpoint cannot be achieved). The smart valve actuator
position may also be adjusted to see if a desired flow rate can be
achieved at the filtration flow rate. Calculations may be performed
to determine the most efficient pump speed to achieve the desired
results by algorithm or by communication from the pump of the power
draw. The use of the smart valve actuator may facilitate measuring
and reporting excess flow by comparing the controlled quantity to
the valve position and computing the margin available; i.e.
determining if the pump speed is higher than needed to achieve the
requested water feature flow. The computation may indicate what
reduction in pump speed may be implemented.
[0163] Embodiments may perform flow sensing and pressure sensing.
For example, flow may be measured with a paddle wheel or a turbine
and interpreted by a co-located processor or remotely located
processor. Flow may also be measured with ultrasonic doppler
methods, thermal mass/dispersion methods, magnetic/induction
methods, optical methods, etc. Pressure sensing may be performed
with a flow sensor mounted on a pipe, or a tube run from the pipe
to a sensor mounted on the circuit board. Methods for pressure
sensing include strain gage piezoresistive methods, capacitive
methods, magnetic diaphragm displacement methods, optical methods,
resonant frequency methods, etc. The smart valve actuator may also
utilize a temperature sensor. For example, temperature sensing can
determine ambient temperature, remote solar panel temperature, or
water temperature at the input or output ports.
[0164] In some embodiments, the smart valve actuator may include
protection features for the pool system. The protection features
may include stored limits of damaging valve positions and undesired
valve positions along with software to automatically restore
permitted valve positions after manual actuation of the valve or
understand its position upon power-up to assure that the valve is
in the correct position. Additionally, the smart valve actuator may
facilitate motor current monitoring and input voltage monitoring to
initiate scale-back or shutdown to protect life and prevent
internal damage to pool system components.
[0165] In one embodiment, the pool system may have a `legacy` mode
that can accept travel limit settings via pushbutton or power
interrupt signaling from the controller. This legacy mode can be
implemented by disconnecting the motor from the drive shaft and
signaling the software by timed direction reversals, wireless
communication, or a physical or magnetic pushbutton. In some
embodiments, software can learn the relationship between valve
angle and measured parameters and predict if a requested setting is
possible based on a simulation of what valve angle will be needed
to achieve the desired effect. In one embodiment the software may
contain methods to prevent `hunting` or needless motor activation
for minor fluctuations of the measured parameters. Further, the
motor drive software may generate stepper motor signals to drive
the motor faster or slower than current products based on
synchronous motors.
[0166] FIG. 20 is a diagram 1200 illustrating chemistry automation
control logic 82. Chemistry automation control logic 82 could
incorporate and/or be in communication with a variety of types of
data and/or data sources. More specifically, chemistry automation
control logic 82 can communicate with, or receive, user input data
1202, chemistry automation operational data 1204, chemistry
automation factory specifications 1206, chemistry automation
configuration parameters 1208, web data 1210, pool configuration
parameters 1212, data from related devices 124, health monitoring
data 1216, and/or external sensor data 1218.
[0167] User input data 1202 could include timers, schedules (e.g.,
on/off, what speed, operation duration, etc.), chlorination levels,
alternative sanitizers (e.g., liquid, chlorine, tablets, etc.),
etc. Chemistry automation operational data 1204 could include water
chemistry, water temperature, air temperature, water detection,
water flow (rate), water flow (yes/no), water pressure, air
cavitation, salt concentration, chemistry dispense rate, power
consumption, current draw, water conductivity, salinity, applied
voltage, water hardness, etc. Chemistry automation factory
specifications 1206 could include power consumption, current draw,
input voltage, etc. Chemistry automation configuration parameters
1208 could include IP address, GPS coordinates, zip code, time and
date, etc. Web data 1210 could include location (based on IP
address), time and date, sunrise/sunset data, regional and local
weather forecast data, temperature, ambient light, solar radiation,
humidity, season, elevation, dew point, etc. In one example the
chemistry automation logic 82 could shift operation based on
weather input. Pool configuration parameters 1212 could include
pool surface area, pool geometry, pool liner color, pool cover
(yes/no), volume, etc. Data from related devices 1214 could include
data relating to at least the following: pump(s), heater(s)
(gas/heat pump), heat (solar), pool covers, controller(s), spa(s),
water feature(s), secondary pump(s), valves/actuators/bypasses,
alternative sanitizers (agent, fill level, weight, feed rate,
etc.), etc. In one example, the chemistry automation control logic
82 could receive input from an external device to identify an
operating profile. Health monitoring data 1216 could include power
consumption, current monitoring, line-to-line balance, grounding,
bonding, leak current, runtime, operating temperatures, number of
power cycles, efficiency, pressure drop of scaling cell
(chlorinator), presence of gas pockets (chlorinator), ultraviolet
output (UV sanitizer), ozone suction (UV sanitizer), lamp
temperature (UV sanitizer), time to clean (chemistry dispenser),
age of dispense medium (chemistry dispenser), born on date
(chemistry dispenser), etc. External sensor data 1218, could
include water temperature, water flow rate, air temperature,
suction/vacuum pressure, water chemistry, turnover rate of pool,
ambient light, pool cover detection, motion sensors, bather
detection, salt concentration, pH, water hardness, cyanuric acid
levels, turbidity, ozone concentrations, algae, microbial
populations, phosphate levels, nitrate levels, water level, bather
load, etc. It is noted that, the chemistry automation control logic
82 could sample the water from various locations, including ports,
as well as offline sensing equipment. It is further noted that the
external sensor data 1218 (as well as external sensor data received
by any and/or all of the control logic systems 72-83) can be
received from sensors in a plurality of locations, including but
not limited to, the pool pad, in the pool itself, or remote from
the pool. Additionally, the chemistry automation control logic 82
can receive learned information and a pool cover schedule. While it
may be desirable for external sensors to monitor/provide data on as
many system parameters as possible (thereby providing greater
optimization, automation, and user/operator comfort), it is
contemplated that some systems need not utilize an external sensor
to monitor every system parameter. For example, if a particular
pool chemistry sensor has not been installed in a particular
system, the user/operator can provide this information by first
determining the pool chemistry (e.g., by manually testing the pool
chemistry by conventional means that are well known to the art) and
then entering the pool chemistry information into the system via a
user interface.
[0168] FIGS. 21A-21I are flowcharts illustrating processing steps
of the chemistry automation control logic 82. FIG. 21A is a
flowchart illustrating processing logic of the chemistry automation
control logic 82 communicating with a chemistry automation system.
In step 1300, the chemistry automation control logic 82 receives an
instruction to activate the chemistry automation system. In step
1302, the chemistry automation control logic 82 receives
operational data from the chemistry automation system water
detection sensor. The chemistry automation system water detection
sensor can be, for example, a flow switch, flow meter, current flow
("gas sensor"), etc. In step 1304, the chemistry automation control
logic 82 determines if water is detected. If a positive
determination is made, then the chemistry automation control logic
82 proceeds to step 1306 where it transmits an instruction to the
chemistry automation system to activate, and the process ends. If a
negative determination is made, then the chemistry automation
control logic 82 proceeds to step 1308 where it determines if there
are any retries remaining. For example, in step 1308 the chemistry
automation control logic 82 could determines if there are any
retries remaining for a timer (e.g., 1 hour, 6 hours, 24 hours, or
any other suitable time interval), or if there has been no flow
detected over the same period of time. If a positive determination
is made, e.g., the twenty-four hour timer has not expired, then the
process returns to step 1302 and continues from there. If a
negative determination is made, e.g., the twenty-four hour timer
has expired indicating that there has been no flow over a
twenty-four hour period, then the process proceeds to step 1310
where an error condition is transmitted, and the process ends.
[0169] FIG. 21B is another flowchart illustrating processing logic
of the chemistry automation control logic 82 communicating with a
chemistry automation system. In step 1312, the chemistry automation
control logic 82 receives an instruction to activate the chemistry
automation system. In step 1314, the chemistry automation control
logic 82 retrieves data on factory specified power parameters from
memory (e.g., power consumption, current draw, and line voltage).
In step 1316, the chemistry automation control logic 82 receives
line power operational data. In step 1318, the chemistry automation
control logic 82 determines if the line power is within factory
specifications. If a positive determination is made, then the
chemistry automation control logic 82 proceeds to step 1320 where
it transmits an instruction to the chemistry automation system to
activate, and the process ends. If a negative determination is
made, then the chemistry automation control logic 82 proceeds to
step 1322 where it determines if there are any retries remaining.
If a positive determination is made, then the process returns to
step 1316 and continues from there. If a negative determination is
made, then the process proceeds to step 1324 where an error
condition is transmitted, and the process ends.
[0170] FIG. 21C is another flowchart illustrating processing logic
of the chemistry automation control logic 82 communicating with a
chemistry automation system. In step 1326, the chemistry automation
control logic 82 retrieves user-specified chlorination levels from
memory. In step 1328, the chemistry automation control logic 82
retrieves pool configuration parameters from memory, e.g., pool
surface area, volume, geometry, etc. In step 1330, the chemistry
automation control logic 82 receives operational data from the
chemistry automation system, e.g., chlorination rate. In step 1332,
chemistry automation control logic 82 determines the length of
chlorination time to reach the user-specified level. In step 1334,
chemistry automation control logic 82 transmits an instruction to
the chemistry automation system to run for the determined length of
time, and then returns to step 1330.
[0171] FIG. 21D is another flowchart illustrating processing logic
of the chemistry automation control logic 82 communicating with a
chemistry automation system. In step 1336, the chemistry automation
control logic 82 retrieves user-specified chlorination levels from
memory. In step 1338, the chemistry automation control logic 82
receives pump operational data, e.g., turnover rate. In step 1340,
the chemistry automation control logic 82 receives water chemistry
operational data from external sensors. In step 1342, chemistry
automation control logic 82 transmits pump and water chemistry
operational data to memory. In step 1344, the chemistry automation
control logic 82 determines if the chlorine level is below the
user-specified level. If a negative determination is made, then the
chemistry automation control logic 82 returns to step 1338 and
continues from there. If a positive determination is made, then the
chemistry automation control logic 82 proceeds to step 1346 where
it determines the length of chlorination time required to reach the
user-specified chlorine level. In step 1348, the chemistry
automation control logic 82 transmits the determined chlorination
time to memory. In step 1350, the chemistry automation control
logic 82 transmits an instruction to the chemistry automation
system to run for the determined length of time, and then returns
to step 1338.
[0172] FIG. 21E is another flowchart illustrating processing logic
of the chemistry automation control logic 82 communicating with a
chemistry automation system. In step 1352, the chemistry automation
control logic 82 receives operational data from ambient light
sensors. In step 1354, the chemistry automation control logic 82
determines the amount of direct sunlight to a body of water. In
step 1356, the chemistry automation control logic 82 retrieves pool
configuration parameters from memory, e.g., pool surface area,
volume, geometry, etc. In step 1358, the chemistry automation
control logic 82 determines the rate of chlorine reduction due to
direct sunlight. In step 1360, the chemistry automation control
logic 82 transmits an instruction to the chemistry automation
system to increase dispensing rate of chlorine by rate of chlorine
reduction due to direct sunlight, and then returns to step
1352.
[0173] FIG. 21F is another flowchart illustrating processing logic
of the chemistry automation control logic 82 communicating with a
chemistry automation system. In step 1362, the chemistry automation
control logic 82 receives an instruction to activate the chemistry
automation system. In step 1364, the chemistry automation control
logic 82 receives operational data from the pool cover. In step
1366, the chemistry automation control logic 82 determines if the
pool cover is closed. If a negative determination is made, then the
chemistry automation control logic 82 returns to step 1364 and
continues from there. If a positive determination is made, then the
chemistry automation control logic 82 proceeds to step 1368 where
it retrieves pool configuration parameters from memory, e.g., pool
surface area, volume, geometry, etc. In step 1370, the chemistry
automation control logic 82 determines the decreased rate of
chlorine reduction due to lack of direct sunlight. In step 1372,
the chemistry automation control logic 82 transmits an instruction
to the chemistry automation system to decrease the dispensing rate
of chlorine by the decreased rate of chlorine reduction due to lack
of direct sunlight, and then returns to step 1364.
[0174] FIG. 21G is another flowchart illustrating processing logic
of the chemistry automation control logic 82 communicating with a
chemistry automation system. In step 1374, the chemistry automation
control logic 82 receives an instruction to activate the chemistry
automation system. In step 1376, the chemistry automation control
logic 82 receives operational data from the motion sensors. In step
1378, the chemistry automation control logic 82 determines the
number of bathers in the pool. In step 1380, the chemistry
automation control logic 82 retrieves pool configuration parameters
from memory, e.g., pool surface area, volume, geometry, etc. In
step 1382, the chemistry automation control logic 82 determines an
increased chlorine demand based on the number of bathers. In step
1384, the chemistry automation control logic 82 transmits an
instruction to the chemistry automation system to increase the
dispensing rate of chlorine by the increased chlorine demand based
on the number of bathers, and then returns to step 1376.
[0175] FIG. 21H is a flowchart illustrating processing logic of the
chemistry automation control logic 82 determining alert conditions
of a chemistry automation system. The chemistry automation control
logic 82 proceeds with four parallel routine sequences that
respectively begin with steps 1386, 1396, 1406, 1416. Each routine
sequence is discussed sequentially, though it should be understood
that the routine loops could operate in parallel, or alternatively,
in series with each other. The first sequence begins in step 1386
where the chemistry automation control logic 82 retrieves factory
specified life expectancy data from memory. In step 1388, the
chemistry automation control logic 82 determines an alert
threshold, e.g., less than 90% of chemistry automation life
expectancy remaining or runtime value. In step 1390, the chemistry
automation control logic 82 receives operational data on chemistry
automation runtime. In step 1392, the chemistry automation control
logic 82 determines if the chemistry automation runtime is greater
than the threshold. If a negative determination is made, then the
process returns to step 1390 and continues to receive operational
data on chemistry automation runtime. If a positive determination
is made, then the process proceeds to step 1394 where an alert is
transmitted to a user, and the process ends.
[0176] The second sequence begins in step 1396 where the chemistry
automation control logic 82 retrieves factory specified operating
temperature data from memory. In step 1398, the chemistry
automation control logic 82 determines an alert threshold, e.g., a
temperature value that is 10% above or below operating temperature.
In step 1400, the chemistry automation control logic 82 receives
operational data on chemistry automation system operating
temperature. In step 1402, the chemistry automation control logic
82 determines if the chemistry automation system operating
temperature exceeds the threshold, or is outside of a threshold
range. If a negative determination is made, then the process
returns to step 1400 and continues to receive operational data on
chemistry automation system operating temperature. If a positive
determination is made, then the process proceeds to step 1404 where
the chemistry automation control logic 82 reduces the output of the
chemistry automation system.
[0177] The third sequence begins in step 1406 where the chemistry
automation control logic 82 retrieves factory specified power
consumption data from memory. In step 1408, the chemistry
automation control logic 82 determines an alert threshold, e.g.,
power value that is 110% of specified power consumption. In step
1410, the chemistry automation control logic 82 receives
operational data on chemistry automation system power consumption.
In step 1412, the chemistry automation control logic 82 determines
if the chemistry automation system power consumption is greater
than the threshold. If a negative determination is made, then the
process returns to step 1410 and continues to receive operational
data on chemistry automation system power consumption. If a
positive determination is made, then the process proceeds to step
1414 where the chemistry automation control logic 82 reduces the
output of the chemistry automation system.
[0178] The fourth sequence begins in step 1416 where the chemistry
automation control logic 82 retrieves factory warranty data from
memory, e.g., a warranty expiration date. In step 1418, the
chemistry automation control logic 82 determines an alert
threshold, e.g., days left on factory warranty. In step 1420, the
chemistry automation control logic 82 receives current date
information. In step 1422, the chemistry automation control logic
82 determines if the current date is beyond the threshold date or
the number of days remaining is below the threshold date. If a
negative determination is made, then the process returns to step
1420 and continues to receive current date information. If a
positive determination is made, then the process proceeds to step
1424 where an alert is transmitted to a user, and the process
ends.
[0179] FIG. 21I is another flowchart illustrating processing logic
of the chemistry automation control logic 82 communicating with a
chemistry automation system. In step 1426, the chemistry automation
control logic 82 retrieves factory specified servicing data from
memory, e.g., service intervals. In step 1428, the chemistry
automation control logic 82 retrieves date of previous service from
memory. In step 1430, the chemistry automation control logic 82
determines the time to the next service and then proceeds to steps
1432 and 1438. In step 1438, the chemistry automation control logic
82 transmits an instruction to the human-machine interface device
to display the time to the next service. In step 1432, the
chemistry automation control logic 82 determines the alert
threshold, e.g., 30 days to next service. In step 1434, the
chemistry automation control logic 82 determines if the time to the
next service is less than the threshold. If a negative
determination is made, then the process returns to step 1428 and
continues to receive the date of pervious service from memory. If a
positive determination is made, then the process proceeds to step
1436 where the chemistry automation control logic 82 transmits an
alert to the user.
[0180] FIG. 22 is a diagram 1500 illustrating heater control logic
80. Heater control logic 80 could incorporate and/or be in
communication with a variety of types of data and/or data sources.
More specifically, heater control logic 80 can communicate with, or
receive, user input data 1502, heater operational data 1504, heater
factory specifications 1506, heater configuration parameters 1508,
web data 1510, pool configuration parameters 1512, data from
related devices 1514, health monitoring data 1516, and/or external
sensor data 1518.
[0181] User input data 1502 could include heating and/or cooling
temperature set points, heating or cooling mode, pool/spa mode,
heater x or cooler x, where "x" is an index referring to one or
more heating and/or cooling devices, countdown to heat, etc. Heater
operational data 1504 could include line voltage, power
consumption, gas pressure, air pressure or vacuum, air temperature,
humidity, other environmental conditions, flow rate, water level,
state (e.g., on/off), temperature setpoint, duration setpoint,
operating noise, etc. Heater factory specifications 1506 could
include gas heater input rating, gas heater thermal efficiency,
heat pump output & COP (coefficient of performance) at T1
(reference test temperature 1), RH1 (reference test relative
humidity 1), heat pump output & COP at T1, RH2 (reference test
relative humidity 2), heat pump output & COP at T2 (reference
test temperature 2), RH1, heat pump output & COP at T2, RH2,
power consumption, current draw, input voltage, etc. Heater
configuration parameters 1508 could include IP address, GPS
coordinates, zip code, etc. Web data 1510 could include regional
solar irradiance data, regional weather forecast data, regional
fuel cost data, direct solar irradiance--modeled clear-sky, diffuse
solar irradiance--modeled clear-sky, air temperature, relative
humidity, wind speed, cloud cover, cost of natural gas, cost of
propane gas, cost of electricity, etc. Pool configuration
parameters 1512 could include pool surface area, pool volume,
emissivity of pool, absorptivity of pool, pool solar exposure,
fraction of weather station wind speed at pool surface, desired
water temperature, pump schedule, type of pool cover (solar
transmittance, thermal conductivity, emissivity, absorptivity),
pool cover use schedule, etc. Data from related devices 1514 could
include data relating to at least the following: pump(s), secondary
pump(s), filter bypass, water feature(s), chemical dispensers,
valves/actuators/bypass, pool cover(s), controller(s), spa(s), etc.
The following relationships could exist between the heater control
logic 80 the related devices: water features (used to assist loss
of heat/coolers), chemical dispensers (logic 80 could open bypass
to prevent off balance chemistry from entering the heater),
secondary pump (affects overall system flow), tablet/liquid
chlorine feeder (if present in system should not be used on the
same loop as the heater), and external sensors (could have shared
flow switch and water temperature sensors). Health monitoring data
1516 could include runtime, operating temperatures/profile, power
consumption, predictive failure, number of cycles, degradation of
efficiency, pool chemistry, fuel gas pressure, refrigerant
pressures, refrigerant temperatures, exhaust temperature, carbon
monoxide, freeze and condensation warnings, motor speed (RPM),
other operating conditions, settings, troubleshooting data, etc.
External sensor data 1518, could include air temperature, humidity,
ambient noise, pool chemistry, fuel gas pressure, exhaust
temperature, carbon monoxide, carbon dioxide, oxygen, vibration,
bather detection, etc. Additionally, the heater control logic 80
can receive information pertaining to time limits on setting block
heater schedules, maximum allowable temperatures, password
protection, scheduled heating, and setback schedules. While it may
be desirable for external sensors to monitor/provide data on as
many system parameters as possible (thereby providing greater
optimization, automation, and user/operator comfort), it is
contemplated that some systems need not utilize an external sensor
to monitor every system parameter. For example, if a temperature
sensor has not been installed in a particular system, the
user/operator can provide this information by first determining the
temperature (e.g., by checking a thermometer, a thermocouple, a
weather forecast, the internet, etc.) and then entering the
temperature into the system via a user interface.
[0182] FIGS. 23A-23J are flowcharts illustrating processing steps
of the heater control logic 80. FIG. 23A is a flowchart
illustrating processing logic of the heater control logic 80
communicating with a heater. In step 1520, the heater control logic
80 receives an instruction to activate the heater. In step 1522,
the heater logic 80 retrieves data pertaining to factory specified
power parameters from memory, e.g., parameters relating to power
consumption, current draw, and line voltage. In step 1524, the
heater logic 80 receives line power operational data. In step 1526,
the heater logic 80 determines whether the line power operational
data is within factory specifications. If a positive determination
is made, the process proceeds to step 1528. If a negative
determination is made, the process proceeds to step 1530. In step
1528, the heater control logic 80 transmits an instruction to the
heater to activate, and the process ends. As referenced above, if a
negative determination is made at step 1526, then the process
proceeds to step 1530. In step 1530, the heater control logic 80
determines if there are any retries remaining. If a positive
determination is made, then the heater control logic 80 proceeds to
step 1524 and continues the process from that step. If a negative
determination is made, then the heater control logic 80 proceeds to
step 1532 and transmits an error condition signal, and then ends
the process.
[0183] FIG. 23B is another flowchart illustrating processing logic
of the heater control logic 80 communicating with a heater. In step
1534, the heater control logic 80 receives an instruction to
activate the heater. In step 1536, the heater logic 80 retrieves
minimum fuel setpoint data for heater operation from memory, e.g.,
minimum gas pressure. In step 1538, the heater logic 80 receives
operational data on fuel, e.g., current gas pressure. In step 1540,
the heater logic 80 determines whether the gas pressure is above a
minimum setpoint. If a positive determination is made, the process
proceeds to step 1542. If a negative determination is made, the
process proceeds to step 1541. In step 1542, the heater control
logic 80 transmits an instruction to the heater to activate, and
the process ends. As referenced above, if a negative determination
is made at step 1540, then the process proceeds to step 1541. In
step 1541, the heater control logic 80 logs the error timestamp. In
step 1543, the heater control logic 80 determines if the number of
error logs for the week exceeds the allowable amount. If a positive
determination is made, the process proceeds to step 1545. If a
negative determination is made, the process proceeds to step 1544.
In step 1545, the heater control logic 80 transmits an alert to the
user, and the process ends. As referenced above, if a negative
determination is made at step 1543, then the process proceeds to
step 1544 where the heater control logic 80 determines if there are
any retries remaining. If a positive determination is made, then
the heater control logic 80 proceeds to step 1538 and continues the
process from that step. If a negative determination is made, then
the heater control logic 80 proceeds to step 1546 and transmits an
error condition signal, and then ends the process.
[0184] FIG. 23C is another flowchart illustrating processing logic
of the heater control logic 80 communicating with a heater. In step
1548, the heater control logic 80 receives an instruction to
activate the heater. In step 1550, the heater logic 80 retrieves
blower setpoint data for heater operation from memory, e.g.,
minimum air pressure. In step 1552, the heater logic 80 receives
blower operational data, e.g., air pressure. In step 1554, the
heater logic 80 determines whether the air pressure is above the
minimum setpoint. If a positive determination is made, the process
proceeds to step 1556. If a negative determination is made, the
process proceeds to step 1558. In step 1556, the heater control
logic 80 transmits an instruction to the heater to activate, and
the process ends. As referenced above, if a negative determination
is made at step 1554, then the process proceeds to step 1558. In
step 1558, the heater control logic 80 determines if there are any
retries remaining. If a positive determination is made, then the
heater control logic 80 proceeds to step 1560 and transmits an
instruction to the blower to increase the air pressure by 5%, and
proceeds to step 1552 and continues the process from that step. It
is noted that while the blower could increase air pressure in 5%
increments it is contemplated that any satisfactory incremental
value could be chosen for optimization of the system (e.g., 1%, 2%,
5%, 10%, etc.). If a negative determination is made, then the
heater control logic 80 proceeds to step 1562 and transmits an
error condition signal, and then ends the process.
[0185] FIG. 23D is another flowchart illustrating processing logic
of the heater control logic 80 communicating with a heater. In step
1564, the heater control logic 80 receives an instruction to
activate the heater. In step 1566, the heater logic 80 retrieves
water temperature setpoint data for heater operation from memory,
e.g., minimum and maximum water temperatures. In step 1568, the
heater logic 80 receives operational temperature data, e.g., water
temperature read by a sensor. In step 1570, the heater logic 80
determines whether the water temperature is below the minimum
setpoint. If a positive determination is made, the process proceeds
to step 1572. If a negative determination is made, the process
returns to step 1568. In step 1572, the heater control logic 80
transmits an instruction to the heater to activate. In step 1574,
the heater control logic 80 receives operational temperature data.
In step 1576, the heater control logic 80 determines if the water
temperature is above a maximum setpoint. If a positive
determination is made, then the heater control logic 80 proceeds to
step 1578 and transmits an instruction to the heater to switch to
standby mode, and the process ends. If a negative determination is
made, then the heater control logic 80 returns to step 1574.
[0186] FIG. 23E is another flowchart illustrating processing logic
of the heater control logic 80 communicating with a heater. In step
1582, the heater control logic 80 receives an instruction to
activate the heater. In step 1584, the heater logic 80 retrieves
minimum flow rate setpoint data for heater operation from memory,
e.g., gallons per minute. In step 1586, the heater logic 80
receives operational flow rate data. In step 1588, the heater logic
80 determines whether the flow rate is above the minimum setpoint.
If a positive determination is made, the process proceeds to step
1590. If a negative determination is made, the process proceeds to
step 1592. In step 1590, the heater control logic 80 transmits an
instruction to the heater to activate, and the process ends. As
referenced above, if a negative determination is made at step 1588,
then the process proceeds to step 1592. In step 1592, the heater
control logic 80 determines if there are any retries remaining. If
a positive determination is made, then the heater control logic 80
proceeds to step 1594 and transmits an instruction to the pump to
increase the flow by 5%, and proceeds to step 1586 and continues
the process from that step. It is noted that while the pump could
increase flow in 5% increments it is contemplated that any
satisfactory incremental value could be chosen for optimization of
the system (e.g., 1%, 2%, 5%, 10%, etc.). If a negative
determination is made, then the heater control logic 80 proceeds to
step 1596 and transmits an error condition signal, and then ends
the process.
[0187] FIG. 23F is another flowchart illustrating processing logic
of the heater control logic 80 communicating with a heater. In step
1598, the heater control logic 80 receives an instruction to
activate the heater. In step 1600, the heater logic 80 retrieves
runtime setpoint data for heater operation from memory, e.g.,
duration of operation. In step 1602, the heater logic 80 transmits
an instruction to the heater to activate. In step 1604, the heater
logic 80 sets a countdown timer for a predefined number ("x") of
seconds, where "x" is the desired runtime of the heater, and
activates the timer. In step 1606, the heater logic 80 determines
if the timer has reached "0." If a positive determination is made,
the process proceeds to step 1608. If a negative determination is
made, the process returns to step 1604. In step 1608, the heater
control logic 80 transmits an instruction to deactivate the heater,
and the process ends.
[0188] FIG. 23G is another flowchart illustrating processing logic
of the heater control logic 80 communicating with a heater. In step
1610, the heater control logic 80 retrieves maximum ambient noise
setpoint data for heater operation from memory. In step 1612, the
heater logic 80 receives ambient noise operational data. In step
1614, determines if the ambient noise is above the maximum allowed
value. If a positive determination is made, the process proceeds to
step 1616. If a negative determination is made, the process returns
to step 1612. In step 1616, the heater control logic 80 determines
if there are any retries remaining. If a positive determination is
made, then the heater control logic 80 proceeds to step 1618 and
transmits an instruction to the heater to decrease the output by
5%, and proceeds to step 1612 and continues the process from that
step. It is noted that while the heater could decrease output in 5%
increments it is contemplated that any satisfactory incremental
value could be chosen for optimization of the system (e.g., 1%, 2%,
5%, 10%, etc.). If a negative determination is made, then the
heater control logic 80 proceeds to step 1620 and transmits an
error condition signal, and then ends the process.
[0189] FIG. 23H is another flowchart illustrating processing logic
of the heater control logic 80 communicating with a heater. In step
1622, the heater logic 80 receives operational data from ambient
noise sensors. In step 1624, the heater logic 80 transmits
operational data from ambient noise sensors to memory. In step
1626, the heater logic 80 determines the average ambient noise
setpoint based on operational data from the sensors. In step 1628,
the heater logic 80 receives operational data from heater noise
sensors. In step 1630, the heater logic 80 determines if the
decibel level is above the average ambient setpoint. If a positive
determination is made, the process proceeds to step 1632. If a
negative determination is made, the process returns to step 1628.
In step 1632, the heater control logic 80 determines if there are
any retries remaining. If a positive determination is made, then
the heater control logic 80 proceeds to step 1634 and transmits an
instruction to the heater to decrease performance by 5%, and
proceeds to step 1628 and continues the process from that step. It
is noted that while the heater could decrease performance in 5%
increments it is contemplated that any satisfactory incremental
value could be chosen for optimization of the system (e.g., 1%, 2%,
5%, 10%, etc.). If a negative determination is made, then the
heater control logic 80 proceeds to step 1636 and transmits an
error condition signal, and then ends the process.
[0190] It is noted that the processing logic of the heater control
logic 80 shown in FIGS. 23G and 23H could be combined into a
process that determines the average ambient noise level over a
given period of time and then saves the average ambient noise level
to the memory for later retrieval as the maximum ambient noise
setpoint data for heater operation, illustrated in step 1610 of
FIG. 23G. The process could then proceed according to the steps as
illustrated in FIG. 23G as described above.
[0191] FIG. 23I is a flowchart illustrating processing logic of the
heater control logic 80 determining alert conditions of a heater.
The heater control logic 80 proceeds with four parallel routine
sequences that respectively begin with steps 1638, 1648, 1658, and
1668. Each routine sequence is discussed sequentially, though it
should be understood that the routine loops could operate in
parallel, or alternatively, in series with each other. The first
sequence begins in step 1638 where the heater control logic 80
retrieves factory specified life expectancy data from memory. In
step 1640, the heater control logic 80 determines an alert
threshold, e.g., less than 90% of heater life expectancy remaining
or runtime value. In step 1642, the heater control logic 80
receives operational data on heater runtime. In step 1642, the
heater control logic 80 determines if the heater runtime is greater
than the threshold. If a negative determination is made, then the
process returns to step 1642 and continues to receive operational
data on heater runtime. If a positive determination is made, then
the process proceeds to step 1646 where an alert is transmitted to
a user, and the process ends.
[0192] The second sequence begins in step 1648 where the heater
control logic 80 retrieves factory specified operating temperature
data from memory. In step 1650, the heater control logic 80
determines an alert threshold, e.g., a temperature value that is
10% above or below operating temperature. In step 1652, the heater
control logic 80 receives operational data on heater system
operating temperature. In step 1654, the heater control logic 80
determines if the heater system operating temperature exceeds the
threshold, or is outside of a threshold range. If a negative
determination is made, then the process returns to step 1652 and
continues to receive operational data on heater system operating
temperature. If a positive determination is made, then the process
proceeds to step 1656 where an alert is transmitted to a user, and
the process ends.
[0193] The third sequence begins in step 1658 where the heater
control logic 80 retrieves factory specified power consumption data
from memory. In step 1660, the heater control logic 80 determines
an alert threshold, e.g., power value that is 110% of specified
power consumption. In step 1662, the heater control logic 80
receives operational data on heater system power consumption. In
step 1664, the heater control logic 80 determines if the heater
system power consumption is greater than the threshold. If a
negative determination is made, then the process returns to step
1662 and continues to receive operational data on heater system
power consumption. If a positive determination is made, then the
process proceeds to step 1666 where an alert is transmitted to a
user, and the process ends.
[0194] The fourth sequence begins in step 1668 where the heater
control logic 80 retrieves maximum carbon monoxide output setpoint
from memory, e.g., the maximum permitted carbon monoxide output for
the heater. In step 1670, the heater control logic 80 determines an
alert threshold, e.g., 905 of maximum carbon monoxide output. In
step 1672, the heater control logic 80 receives operational data on
heater system carbon monoxide output. In step 1674, the heater
control logic 80 determines if the heater system carbon monoxide
output is greater than the threshold. If a negative determination
is made, then the process returns to step 1672 and continues to
receive operational data on heater system carbon monoxide output.
If a positive determination is made, then the process proceeds to
step 1676 where it transmits an instruction to the heater to
deactivate. The process then proceeds to step 1678 and transmits an
alert to a user, and the process ends.
[0195] FIG. 23J is a flowchart illustrating the procedure
implemented when heat is being requested by a user. In step 1680,
the heater control logic 80 receives an instruction that heat is
called for. In step 1682, the heater control logic 80 proceeds to
check if the heater has power. In step 1684, the heater control
logic determines if the heater has power. If a negative
determination is made, then the process proceeds to step 1714. If a
positive determination is made, then the process proceeds to step
1686. In step 1714, the heater control logic 80 determines if there
are any retries remaining. If a positive determination is made then
the process returns to step 1682, but if a negative determination
is made then the process proceeds to step 1716 where the heater
control logic 80 indicates an error condition and the process ends.
As referenced above, if a positive determination is made in step
1684, then the process proceeds to step 1686. In step 1686, the
heater control logic 80 checks the gas pressure. In step 1688, the
heater control logic 80 determines if the pressure is within the
specified range. If a positive determination is made, then the
process proceeds to step 1690. If a negative determination is made,
then the process proceeds to step 1718. In step 1718, the heater
control logic 80 determines if there are any retries remaining. If
a positive determination is made then the process returns to step
1686. If a negative determination is made then the process proceeds
to step 1720 where the heater control logic 80 indicates an error
condition and the process ends. As referenced above if a positive
determination is made in step 1688, then the process proceeds to
step 1690. In step 1690, the heater control logic 80 checks the
blower operation. In step 1692, the heater control logic 80
determines if the air pressure is within the specified range. If a
positive determination is made, then the process proceeds to step
1694. If a negative determination is made, then the process
proceeds to step 1722. In step 1722, the heater control logic 80
determines if there are any retries remaining. If a positive
determination is made then the process returns to step 1690. If a
negative determination is made then the process proceeds to step
1724 where the heater control logic 80 indicates an error condition
and the process ends. As referenced above if a positive
determination is made in step 1692, then the process proceeds to
step 1694. In step 1694, the heater control logic 80 checks the
water flow. In step 1696, the heater control logic 80 determines if
the flow rate (GPM) is within the specified range. If a positive
determination is made, then the process proceeds to step 1698. If a
negative determination is made, then the process proceeds to step
1726. In step 1726, the heater control logic 80 determines if there
are any retries remaining. If a positive determination is made then
the process proceeds to step 1728 where it sends an electronic
signal to the pump to increase or decrease the flow by 5%, and then
returns to step 1694. It is noted that while the pump could
increase or decrease flow in 5% increments it is contemplated that
any satisfactory incremental value could be chosen for optimization
of the system (e.g., 1%, 2%, 5%, 10%, etc.). If a negative
determination is made in step 1726 then the process proceeds to
step 1730 where the heater control logic 80 indicates an error
condition and the process ends. As referenced above if a positive
determination is made in step 1696, then the process proceeds to
step 1698. In step 1698, the heater control logic 80 queries for an
operation temperature setpoint. In step 1700, the heater control
logic 80 determines if the operation temperature setpoint has been
received. If a positive determination is made, then the process
proceeds to step 1702. If a negative determination is made, then
the process proceeds to step 1732. In step 1732, the heater control
logic 80 determines if there are any retries remaining. If a
positive determination is made then the process proceeds to step
1734 where it prompts the heater for a desired water temperature,
and then returns to step 1698. If a negative determination is made
in step 1732 then the process proceeds to step 1736 where the
heater control logic 80 indicates an error condition and the
process ends. As referenced above if a positive determination is
made in step 1700, then the process proceeds to step 1702. In step
1702, the heater control logic 80 electronically receives data
relating to the water temperature. In step 1704, the heater control
logic 80 determines if the operation temperature setpoint is
greater than the water temperature. If a positive determination is
made, then the process proceeds to step 1706. If a negative
determination is made, then the process proceeds to step 1740. In
step 1740, the heater control logic 80 places the heater in standby
and returns to step 1702. As referenced above if a positive
determination is made in step 1704, then the process proceeds to
step 1706. In step 1706, the heater control logic 80 engages the
heater. In step 1708, the heater control logic 80 starts a timer.
In step 1710, the heater control logic 80 determines if the
temperature setpoint is lower than the water temperature. If a
positive determination is made, then the process proceeds to step
1712 where it deactivates the heater and the process ends. If a
negative determination is made, then the process proceeds to step
1742. In step 1742, the heater control logic 80 determines if the
operation duration has exceeded the threshold. If a positive
determination is made, then the process proceeds to step 1712 where
it deactivates the heater and the process ends. If a negative
determination is made then the process returns to step 1706.
[0196] FIG. 24 is a diagram 1800 illustrating lighting control
logic 78. Lighting control logic 78 could incorporate and/or be in
communication with a variety of types of data and/or data sources.
More specifically, lighting control logic 78 can communicate with,
or receive, user input data 1802, lighting operational data 1804,
lighting factory specifications 1806, lighting configuration
parameters 1808, web data 1810, pool configuration parameters 1812,
data from related devices 1814, health monitoring data 1816 and/or
external sensor data 1818.
[0197] User input data 1802 could include lighting color, lighting
intensity, lighting duration, timers, schedule, default program(s),
pool temperature setpoint(s), etc. Lighting operational data 1804
could include status (on/off), cycles (on/off), line voltage,
current draw, power consumption, environment (water/air),
temperature (lights), ambient light, light color, light intensity,
etc. Lighting factory specifications 1806 could include lumen
output, life expectancy, current draw, input voltage, power
consumption, operating environment, etc. Lighting configuration
parameters 1808 could include IP address, GPS coordinates, zip
code, time and date, etc. Web data 1810 could include location
(based on IP address), time and date, sunrise/sunset data, local
lighting code, regional and local weather forecast data, etc. Pool
configuration parameters 1812 could include pool surface area, pool
geometry, pool liner color, pool cover (yes/no), pool cover
schedule, etc. Data from related devices 1814 could include data
relating to at least the following: additional lights/systems,
chlorinator(s), pump(s), cleaner(s), water feature(s), heater
(gas), heater (solar), chemical dispenser, valve(s), pool cover
(various), controller, spa, water slide, etc. For example, the
following relationships could exist between the lighting control
logic 78 the related devices: valves (activate water features,
solenoid, dancing waters, etc.), and water slide (shows path,
auto-on). Health monitoring data 1816 could include errors,
runtime, estimated lumen output, average power consumption, line
voltage, line current, percent of light output, operating
environment, warranty countdown, water pressure, etc. External
sensor data 1818, could include ambient light, lighting output,
motion/occupancy, bather detection, temperature (pool), moisture,
chlorine content, pH level, etc. While it may be desirable for
external sensors to monitor/provide data on as many system
parameters as possible (thereby providing greater optimization,
automation, and user/operator comfort), it is contemplated that
some systems need not utilize an external sensor to monitor every
system parameter. For example, if a pool temperature sensor has not
been installed in a particular system, the user/operator can
provide this information by first determining the pool temperature
(e.g., by checking a thermometer, thermocouple, etc.) and then
entering the pool temperature into the system via a user interface.
FIGS. 25A-25AB are flowcharts illustrating processing steps of the
lighting control logic 78. FIG. 25A is a flowchart illustrating
processing logic of the lighting control logic 78 communicating
with a lighting system. In step 1820, the lighting control logic 78
receives an instruction to activate the lighting system. In step
1822, the lighting control logic 78 retrieves data pertaining to
factory specified power parameters from memory, e.g., parameters
relating to power consumption, current draw, and line voltage. In
step 1824, the lighting control logic 78 receives line power
operational data. In step 1826, the lighting logic 78 determines
whether the line power operational data is within factory
specifications. If a positive determination is made, the process
proceeds to step 1828. If a negative determination is made, the
process proceeds to step 1830. In step 1828, the lighting control
logic 78 transmits an instruction to the lighting system to
activate, and the process ends. As referenced above, if a negative
determination is made at step 1826, then the process proceeds to
step 1830. In step 1830, the lighting control logic 78 determines
if there are any retries remaining. If a positive determination is
made, then the lighting control logic 78 proceeds to step 1824 and
continues the process from that step. If a negative determination
is made, then the lighting control logic 78 proceeds to step 1832
and transmits an error condition signal, and the process ends.
[0198] FIG. 25B is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 1832, the lighting control logic 78 receives an
instruction to activate the lighting system. In step 1834, the
lighting control logic 78 retrieves factory specified operating
environment data from memory, e.g., is the light in air or water.
In step 1836, the lighting control logic 78 receives data from
lighting fixture moisture sensor. In step 1838, the lighting
control logic 78 determines the environment of the lighting
fixture, e.g., is the fixture in air or water. In step 1840, the
lighting control logic 78 determines if the lighting fixture is in
the environment specified by the factory specified operating
environment. If a positive determination is made, the process
proceeds to step 1842. If a negative determination is made, the
process proceeds to step 1844. In step 1842, the lighting control
logic 78 transmits an instruction to the lighting system to
activate, and the process ends. As referenced above, if a negative
determination is made at step 1840, then the process proceeds to
step 1844. In step 1844, the lighting control logic 78 determines
if there are any retries remaining. If a positive determination is
made, then the lighting control logic 78 proceeds to step 1836 and
continues the process from that step. If a negative determination
is made, then the lighting control logic 78 proceeds to step 1846
and transmits an error condition signal, and the process ends.
[0199] FIG. 25C is a flowchart illustrating a process for a user to
define a light show. In step 1848, the lighting control logic 78
prompts the user for a desired lighting color. In step 1850, the
lighting control logic 78 receives the desired lighting color data
from the user. In step 1852, the lighting control logic 78 prompts
the user for a desired lighting speed. In step 1854, the lighting
control logic 78 receives the desired lighting speed data from the
user. In step 1856, the lighting control logic 78 prompts the user
for a desired lighting motion profile. In step 1858, the lighting
control logic 78 receives desired lighting motion profile data from
the user. In step 1860, the lighting control logic 78 retrieves
pool geometry data from memory. In step 1862, the lighting control
logic 78 processes the data received from the user and the pool
geometry data. In step 1864, the lighting control logic 78
generates a virtual preview of a light show from the user data and
pool geometry data. In step 1866, the lighting control logic 78
transmits the virtual preview of the light show to the user. In
step 1868, the lighting control logic 78 prompts the user to save
virtual preview parameters to the memory. In step 1870, the
lighting control logic 78 determines if the user has saved the
parameters. If a positive determination is made then the process
proceeds to step 1872 where the lighting control logic 78 transmits
the parameters to memory as a stored light show, and the process
ends. If a negative determination is made, then the process
proceeds to step 1874 where the lighting control logic 78 prompts
the user to enter new parameters, and then proceeds to step 1876.
In step 1876, the lighting control logic 78 determines if the user
has elected to enter new parameters. If a positive determination is
made then the process returns to step 1848. If a negative
determination is made then the process ends.
[0200] FIG. 25D is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 1878, the lighting control logic 78 determines the
geographic location of the pool, e.g., based on IP address or
configuration parameters. In step 1880, the lighting control logic
78 receives sunrise/sunset data from the web based on the
geographic location. In step 1882, the lighting control logic 78
receives current time data. In step 1886, the lighting control
logic 78 determines if the current time is after sunset. If a
positive determination is made, the process proceeds to step 1888.
If a negative determination is made, the process proceeds to step
1884 where the lighting control logic 78 delays operation for a
predetermined period of time, and after the expiration of the
predetermined period of time returns to step 1882. As referenced
above, if a positive determination is made at step 1886, then the
process proceeds to step 1888. In step 1888, the lighting control
logic 78 determines if the current time is before sunrise. If a
positive determination is made, then the lighting control logic 78
proceeds to step 1890 where it transmits an instruction to activate
the lighting system, and the process ends. If a negative
determination is made, then the lighting control logic 78 proceeds
to step 1892 where it delays operation for a predetermined period
of time, and after the expiration of the predetermined period of
time returns to step 1882.
[0201] FIG. 25E is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 1894, the lighting control logic 78 determines the
geographic location of the pool, e.g., based on IP address or
configuration parameters. In step 1896, the lighting control logic
78 receives sunrise/sunset data from the web based on the
geographic location. In step 1898, the lighting control logic 78
receives current time data. In step 1900, the lighting control
logic 78 determines if the current time is after sunset. If a
positive determination is made, the process proceeds to step 1902.
If a negative determination is made, the process proceeds to step
1910 where the lighting control logic 78 delays operation for a
predetermined period of time, and after the expiration of the
predetermined period of time returns to step 1898. As referenced
above, if a positive determination is made at step 1900, then the
process proceeds to step 1902. In step 1902, the lighting control
logic 78 determines if the current time is before sunrise. If a
positive determination is made, then the lighting control logic 78
proceeds to step 1904. If a negative determination is made, then
the lighting control logic 78 proceeds to step 1892 where it delays
operation for a predetermined period of time, and after the
expiration of the predetermined period of time returns to step
1898. As referenced above, if a positive determination is made at
step 1902, then the process proceeds to step 1904. In step 1904,
the lighting control logic 78 receives operational data from a pool
cleaner. In step 1906, the lighting control logic 78 determines if
the pool cleaner is running. If a negative determination is made,
then the process returns to step 1898. If a positive determination
is made, then the process proceeds to step 1908 where the lighting
control logic 78 transmits an instruction to activate the lighting
system.
[0202] FIG. 25F is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 1914, the lighting control logic 78 receives
operational data from a water feature. In step 1916, the lighting
control logic 78 determines the operational status of the water
feature. In step 1918, the lighting control logic 78 determines if
the water feature is running. If a negative determination is made,
then the process returns to step 1914. If a positive determination
is made, then the process proceeds to step 1920 where the lighting
control logic 78 interlocks with the water feature. In step 1922,
the lighting control logic 78 transmits an instruction to the
lighting system to activate.
[0203] FIG. 25G is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 1924, the lighting control logic 78 receives
operational data from a pool cover. In step 1926, the lighting
control logic 78 determines the operational status of the pool
cover, e.g., is the pool cover open or closed. In step 1928, the
lighting control logic 78 determines if the pool cover is open. If
a positive determination is made, then the process returns to step
1924. If a negative determination is made, then the process
proceeds to step 1930 where the lighting control logic 78 transmits
an instruction to the lighting system to deactivate, and then
returns to step 1924.
[0204] FIG. 25H is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 1932, the lighting control logic 78 receives an
instruction to activate the lighting system. In step 1934, the
lighting control logic 78 receives operational data from a pool
cover. In step 1936, the lighting control logic 78 determines the
operational state of the pool cover, e.g., is the pool cover open
or closed. In step 1938, the lighting control logic 78 determines
if the pool cover is open. If a positive determination is made,
then the process proceeds to step 1940 where the lighting control
logic 78 transmits an instruction to the lighting system to
activate and then returns to step 1934. If a negative determination
is made, then the process proceeds to step 1942 where the lighting
control logic 78 determines if there are any retries remaining. If
a positive determination is made, then the process returns to step
1934. If a negative determination is made, then the process
proceeds to step 1944 where an error condition is transmitted, and
the process ends.
[0205] FIG. 25I is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 1946, the lighting control logic 78 receives an
instruction to activate the lighting system. In step 1948, the
lighting control logic 78 receives operational data from a pool
cover. In step 1950, the lighting control logic 78 determines the
operational state of the pool cover, e.g., is the pool cover open
or closed. In step 1952, the lighting control logic 78 determines
if the pool cover is open. If a positive determination is made,
then the process proceeds to step 1960 where the lighting control
logic 78 transmits an instruction to the lighting system to
activate, and the process ends. If a negative determination is
made, then the process proceeds to step 1954 where the lighting
control logic 78 prompts a user to open the pool cover. In step
1956, the lighting control logic 78 determines if the user has
issued an instruction to open the pool cover. If a negative
determination is made, then the process returns to step 1948. If a
positive determination is made, then the process proceeds to step
1958 where the lighting control logic 78 transmits an instruction
to the pool cover to open, and the process ends.
[0206] FIG. 25J is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 1962, the lighting control logic 78 receives a
minimum ambient light setpoint value. In step 1964, the lighting
control logic 78 receives a maximum ambient light setpoint value.
In step 1966, the lighting control logic 78 receives a current
ambient light value from an external sensor. In step 1968, the
lighting control logic 78 determines if the current ambient light
value is below the minimum ambient light setpoint. If a negative
determination is made, then the process returns to step 1966. If a
positive determination is made, then the process proceeds to step
1970 where the lighting control logic 78 transmits an instruction
to the lighting system to activate the lights. In step 1972, the
lighting control logic 78 receives a current ambient light value
from an external sensor. In step 1974, the lighting control logic
78 determines if the current ambient light value is below a minimum
ambient light setpoint. If a positive determination is made, then
the process proceeds to step 1980 where the lighting control logic
78 transmits an instruction to the lighting system to increase the
lumen output by 5% and then returns to step 1972. It is noted that
while the lighting system could increase lumen output in 5%
increments it is contemplated that any satisfactory incremental
value could be chosen for optimization of the system (e.g., 1%, 2%,
5%, 10%, etc.). If a negative determination is made, then the
process proceeds to step 1976. In step 1976, the lighting control
logic 78 determines if the current ambient light value is above the
maximum ambient light setpoint. If a negative determination is made
(e.g., the ambient light is in the acceptable range--above the
minimum setpoint and below the maximum setpoint), then the process
proceeds to step 1978 where it delays for a predetermined time
period and then returns to step 1972. If a positive determination
is made, then the process proceeds to step 1984 where the lighting
control logic 78 determines if there are any retries remaining. If
a negative determination is made, then the process proceeds to step
1986 where the lighting control logic 78 transmits an instruction
to the lighting system to deactivate the lights and then returns to
step 1966. If a positive determination is made, then the process
proceeds to step 1982 where the lighting control logic 78 transmits
an instruction to the lighting system to decrease lumen output by
5% and then returns to step 1972. It is noted that while the
lighting system could increase lumen output in 5% increments it is
contemplated that any satisfactory incremental value could be
chosen for optimization of the system (e.g., 1%, 2%, 5%, 10%,
etc.).
[0207] FIG. 23K is a flowchart illustrating processing logic of the
lighting control logic 78 determining an error condition and
preventative maintenance reminders for a lighting system. The
lighting control logic 78 proceeds with six parallel routine
sequences that respectively begin with steps 1988, 1994, 2004,
2014, 2024, 2034. Each routine sequence is discussed sequentially,
though it should be understood that the routine loops could operate
in parallel, or alternatively, in series with each other. The first
sequence begins in step 1988 where the lighting control logic 78
monitors for an error condition. In step 1990, the lighting control
logic 78 determines if there is an error condition. If a negative
determination is made, then the process returns to step 1988. If a
positive determination is made, then the process proceeds to step
1992 where the lighting control logic 78 transmits an error
condition. In step 1993, the lighting control logic 78 determines
if the user has snoozed the error condition. If a negative
determination is made, then the process ends. If a positive
determination is made, then the process proceeds to step 1995 where
it delays for a predetermined period of time and then returns to
step 1992.
[0208] The second sequence begins at step 1994, where the lighting
control logic 78 retrieves factory specified life expectancy data
from memory. In step 1996, the lighting control logic 78 determines
a preventative maintenance threshold, e.g., less than 90% of light
life expectancy remaining or runtime value. In step 1998, the
lighting control logic 78 receives operational data on lighting
system runtime. In step 2000, the lighting control logic 78
determines if the lighting system runtime is greater than the
threshold. If a negative determination is made, then the process
returns to step 1998 and continues to receive operational data on
lighting system runtime. If a positive determination is made, then
the process proceeds to step 2002 where a preventative maintenance
reminder is transmitted to a user, and the process ends.
[0209] The third sequence begins in step 2004 where the lighting
control logic 78 retrieves factory specified lumen output data from
memory. In step 2006, the lighting control logic 78 determines a
maintenance threshold, e.g., a lumen output value that is 90% of a
specified lumen output. In step 2008, the lighting control logic 78
receives operational data on lighting system lumen output. In step
2010, the lighting control logic 78 determines if the lighting
system operating lumen output is less than the threshold. If a
negative determination is made, then the process returns to step
2008 and continues to receive operational lumen output data for the
lighting system. If a positive determination is made, then the
process proceeds to step 2012 where a preventative maintenance
reminder is transmitted to a user, and the process ends.
[0210] The fourth sequence begins in step 2014 where the lighting
control logic 78 retrieves factory specified power consumption data
from memory. In step 2016, the lighting control logic 78 determines
a maintenance threshold, e.g., power value that is 110% of
specified power consumption. In step 2018, the lighting control
logic 78 receives operational data on lighting system power
consumption. In step 2020, the lighting control logic 78 determines
if the lighting system power consumption is greater than the
threshold. If a negative determination is made, then the process
returns to step 2018 and continues to receive operational data on
lighting system power consumption. If a positive determination is
made, then the process proceeds to step 2022 where a preventative
maintenance reminder is transmitted to a user, and the process
ends.
[0211] The fifth sequence begins in step 2024 where the lighting
control logic 78 retrieves factory specified input voltage data
from memory. In step 2026, the lighting control logic 78 determines
a maintenance threshold, e.g., an input voltage value that is
+/-10% of specified line voltage. In step 2028, the lighting
control logic 78 receives operational data on lighting system line
voltage. In step 2030, the lighting control logic 78 determines if
the lighting system line voltage is greater than the threshold. If
a negative determination is made, then the process returns to step
2028 and continues to receive operational data on lighting system
line voltage. If a positive determination is made, then the process
proceeds to step 2032 where a preventative maintenance reminder is
transmitted to a user, and the process ends.
[0212] The sixth sequence begins in step 2034 where the lighting
control logic 78 retrieves factory warranty data from memory. In
step 2036, the lighting control logic 78 determines a maintenance
threshold, e.g., 90% of the time period of the factory warranty has
expired. In step 2038, the lighting control logic 78 receives
operational data on lighting system runtime. In step 2040, the
lighting control logic 78 determines if the lighting system runtime
is greater than the threshold. If a negative determination is made,
then the process returns to step 2038 and continues to receive
operational data on lighting system runtime. If a positive
determination is made, then the process proceeds to step 2042 where
a preventative maintenance reminder is transmitted to a user, and
the process ends.
[0213] FIG. 25L is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2044, the lighting control logic 78 receives
lighting system temperature operational data. In step 2046, the
lighting control logic 78 determines if the lighting system needs
to scale back lumen output due to temperature. If a negative
determination is made, then the process returns to step 2044. If a
positive determination is made, then the process proceeds to step
2048 where the lighting control logic 78 receives pool temperature
operational data. In step 2050, the lighting control logic 78
determines the required reduction in pool temperature to return the
lighting system to full lumen output. In step 2052, the lighting
control logic 78 transmits an instruction to the heater to reduce
the temperature by the required amount, and then returns to step
2044.
[0214] FIG. 25M is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2054, the lighting control logic 78 receives
lighting system temperature operational data. In step 2056, the
lighting control logic 78 determines if the lighting system needs
to scale back lumen output due to temperature. If a negative
determination is made, then the process returns to step 2054. If a
positive determination is made, then the process proceeds to step
2058 where the lighting control logic 78 transmits an instruction
to the heater instructing it to decrease output by 5%, and then
returns to step 2054. It is noted that while the heater could
decrease output in 5% increments it is contemplated that any
satisfactory incremental value could be chosen for optimization of
the system (e.g., 1%, 2%, 5%, 10%, etc.).
[0215] FIG. 25N is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2060, the lighting control logic 78 retrieves pool
temperature setpoint data from memory. In step 2062, the lighting
control logic 78 receives pool temperature operational data. In
step 2064, the lighting control logic 78 determines the range
between temperature setpoint and temperature operational data. In
step 2066, the lighting control logic 78 retrieves RGB color table
from memory. In step 2068, the lighting control logic 78 generates
a lookup table including desired RGB color spectrum and associated
temperature range (e.g., from blue at measured temperature to white
at setpoint). In step 2070, the lighting control logic 78 receives
pool temperature operational data. In step 2072, the lighting
control logic 78 determines the RGB color associated with
temperature operational data. In step 2074, the lighting control
logic 78 transmits an instruction to the lighting system to display
the RGB color associated with the pool temperature, and then
returns to step 2070.
[0216] FIG. 25O is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2076, the lighting control logic 78 retrieves
chlorine level setpoint data from memory. In step 2078, the
lighting control logic 78 receives chlorine level operational data.
In step 2080, the lighting control logic 78 determines the range
between chlorine level setpoint and chlorine level operational
data. In step 2082, the lighting control logic 78 retrieves RGB
color table from memory. In step 2084, the lighting control logic
78 generates a lookup table including desired RGB color spectrum
and associated chlorine level range (e.g., from green at measured
temperature to purple at setpoint). In step 2086, the lighting
control logic 78 receives chlorine level operational data. In step
2088, the lighting control logic 78 determines the RGB color
associated with chlorine level operational data. In step 2090, the
lighting control logic 78 transmits an instruction to the lighting
system to display the RGB color associated with the chlorine level.
In step 2092, the lighting control logic 78 determines if the
chlorine level operational data is equal to the chlorine level
setpoint. If a positive determination is made, then the process
proceeds to step 2094 where the lighting control logic 78 transmits
a message stating that the pool chemistry is "OK," and the process
ends. If a negative determination is made, then the process
proceeds to step 2096 where the lighting control logic 78 transmits
a message stating that chlorine should be added to the pool. The
process then proceeds to step 2098 where it delays for a
predetermined period of time before returning to step 2086.
[0217] FIG. 25P is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2100, the lighting control logic 78 retrieves
chlorine level setpoint data from memory. In step 2102, the
lighting control logic 78 receives chlorine level operational data.
In step 2104, the lighting control logic 78 determines if the
chlorine level operational data is equal to the chlorine level
setpoint. If a positive determination is made, then the process
returns to step 2102. If a negative determination is made then the
process proceeds to step 2106 where it retrieves a lighting program
associated with a chlorine imbalance from memory, e.g., activate
yellow or flashing yellow light to alert a user to a chlorine
imbalance. In step 2108, the lighting control logic 78 transmits an
instruction to the lighting system to display the program
associated with a chlorine imbalance, and then returns to step
2102.
[0218] FIG. 25Q is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2110, the lighting control logic 78 monitors for
user-selected light shows and colors. In step 2112, the lighting
control logic 78 determines if the user has selected a light show
or colors. If a negative determination is made, then the process
returns to step 2110. If a positive determination is made, then the
process proceeds to step 2114 where the lighting control logic 78
receives parameters of the user-selected light show or color. In
step 2116, the lighting control logic 78 receives a timestamp for
the user-selected light show or colors. In step 2118, the lighting
control logic 78 transmits the parameters and timestamp to memory.
In step 2120, the lighting control logic 78 determines the most
commonly selected light show or colors. In step 2122, the lighting
control logic 78 saves the most commonly selected light show or
colors to memory as a default lighting program, and then returns to
step 2110.
[0219] FIG. 25R is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. This process includes two parallel branches for defining a
lighting program for pool features and displaying a lighting
program for a specific pool features. The process begins at steps
2124 and 2144. In step 2124, the lighting control logic 78 monitors
for user-selected light shows and colors. In step 2126, the
lighting control logic 78 determines if the user has selected a
light show or colors. If a negative determination is made, then the
process returns to step 2124. If a positive determination is made,
then the process proceeds to step 2128 where the lighting control
logic 78 determines if additional pool features are currently
active, e.g., pool/spa spillover features. If a negative
determination is made, then the process proceeds to step 2142 where
the lighting control logic 78 displays the user-selected light show
or colors, and the process ends. If a positive determination is
made, then the process proceeds to step 2130 where it receives
operational data of the currently active pool features. In step
2132, the lighting control logic 78 receives parameters of the
user-selected light show or color. In step 2134, the lighting
control logic 78 receives a timestamp for the currently active pool
features and lightshow. In step 2136, the lighting control logic 78
transmits the pool feature operational data, light show parameters,
and timestamp to memory. In step 2138, the lighting control logic
78 determines the most commonly selected light show or colors
associated with the additional pool feature. In step 2140, the
lighting control logic 78 saves the most commonly selected light
show or colors to memory as a default lighting program for the
additional pool features, and then returns to step 2124.
[0220] In step 2144, the lighting control logic 78 monitors for
currently active pool features. In step 2146, the lighting control
logic 78 determines if there are any currently active pool
features. If a negative determination is made, then the process
returns to step 2144. If a positive determination is made, then the
process proceeds to step 2148 where the lighting control logic 78
determines if there is a stored default lighting program for the
pool feature. If a negative determination is made, then the process
proceeds to step 2124, where it goes through the process of having
a user define a light show for that pool feature. If a positive
determination is made, then the process proceeds to step 2150,
where the lighting control logic 78 retrieves the stored default
program for the pool feature from memory. In step 2152, the
lighting control logic 78 transmits an instruction to the lighting
system to display the default program for the pool feature, and the
process ends.
[0221] FIG. 25S is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2154, the lighting control logic 78 receives
operational data from a motion sensor. In step 2156, the lighting
control logic 78 determines if the motion sensor has been
triggered. If a negative determination is made, then the process
returns to step 2154. If a positive determination is made, then the
process proceeds to step 2158 where the lighting control logic 78
receives sunrise/sunset data from the Internet. In step 2160, the
lighting control logic 78 receives the current time data. In step
2162, the lighting control logic 78 determines if the current time
is after sunset. If a negative determination is made, then the
process returns to step 2154. If a positive determination is made,
then the process proceeds to step 2164. In step 2164, the lighting
control logic 78 determines if the current time is before sunrise.
If a negative determination is made, then the process returns to
step 2154. If a positive determination is made then the process
proceeds to steps 2166 and 2168, where the lighting control logic
78 transmits a signal to activate the lighting system, transmits an
alert to the user, and then ends the process.
[0222] FIG. 25T is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2170, the lighting control logic 78 receives
operational data from a motion sensor. In step 2172, the lighting
control logic 78 determines if the motion sensor has been
triggered. If a negative determination is made, then the process
returns to step 2170. If a positive determination is made, then the
process proceeds to step 2174 where the lighting control logic 78
retrieves a minimum ambient light setpoint value from memory. In
step 2176, the lighting control logic 78 receives ambient light
operational data. In step 2178, the lighting control logic 78
determines if the ambient light operational data is below the
minimum setpoint. If a negative determination is made, then the
process returns to step 2170. If a positive determination is made,
then the process proceeds to steps 2180 and 2182, where the
lighting control logic 78 transmits a signal to activate the
lighting system, transmits an alert to the user, and then ends the
process.
[0223] FIG. 25U is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2184, the lighting control logic 78 receives
operational data from a motion sensor. In step 2186, the lighting
control logic 78 determines if the motion sensor has been
triggered. If a negative determination is made, then the process
returns to step 2184. If a positive determination is made, then the
process proceeds to step 2188 where the lighting control logic 78
retrieves a minimum ambient light setpoint value from memory. In
step 2190, the lighting control logic 78 receives ambient light
operational data. In step 2192, the lighting control logic 78
determines if the ambient light operational data is below the
minimum setpoint. If a negative determination is made, then the
process returns to step 2184. If a positive determination is made,
then the process proceeds to step 2194 where it determines if a
light show is in progress. If a negative determination is made,
then the process proceeds to step 2202. If a positive determination
is made then the process proceeds to step 2196. In step 2196, the
lighting control logic 78 transmits an instruction to the lighting
system to discontinue showing the current show. As referenced
above, if a negative determination is made in step 2194, then the
process proceeds to step 2202. In step 2202, the lighting control
logic 78 transmits an instruction to activate the lighting system.
Step 2196 and 2202 both proceed to step 2198 where the lighting
control logic 78 transmits an instruction to the lighting system to
display white light at the maximum lumen value. In step 2200, the
lighting control logic 78 transmits an alert to the user, and the
process ends.
[0224] FIG. 25V is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2204, the lighting control logic 78 receives
operational data from light sensors. In step 2206, the lighting
control logic 78 saves operational data from the light sensors to
memory. In step 2208, the lighting control logic 78 determines the
average setpoint based on operational data from the light sensors.
In step 2210, the lighting control logic 78 determines if there is
remaining time to establish the setpoint. If a positive
determination is made, then the process returns to step 2204 and
the setpoint continues to be established. If a negative
determination is made, then the process proceeds to step 2212 where
the lighting control logic 78 determines the acceptable deviation
from the setpoint, e.g., 90% of the setpoint. In step 2214, the
lighting control logic 78 receives operational data from the light
sensors. In step 2216 the lighting control logic 78 determines if
the operational data from the light sensors is within the
acceptable deviation. If a positive determination is made, then the
process returns to step 2214. If a negative determination is made,
then the process proceeds to step 2218 where the lighting control
logic 78 transmits an instruction to the pump to activate. In step
2220, the lighting control logic 78 transmits an instruction to the
chlorinator to activate and then proceeds to step 2222 where it
delays for a predetermined period of time before returning to step
2204.
[0225] FIG. 25W is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2224, the lighting control logic 78 determines the
geographic location of the pool, e.g., based on IP address or
configuration parameters. In step 2226, the lighting control logic
78 receives local weather forecast data from the Internet/Web. In
step 2228, the lighting control logic 78 processes the weather
forecast and identifies impending inclement weather. In step 2230,
the lighting control logic 78 determines if there is any impending
inclement weather. If a negative determination is made, then the
process returns to step 2226. If a positive determination is made,
then the process proceeds to step 2232 where the lighting control
logic 78 retrieves a weather alert lighting program from memory and
then proceeds to steps 2234 and 2236. In step 2234, the lighting
control logic 78 transmits an instruction to the lighting system to
display the weather alert program, e.g., a flashing white light at
maximum lumen output. In step 2236, the lighting control logic 78
transmits an instruction to the pool devices to shield against
lightning strike.
[0226] FIG. 25X is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2238, the lighting control logic 78 receives
operational data from external moisture sensors. In step 2240, the
lighting control logic 78 determines the presence of precipitation,
e.g., versus a splash of water, for example. In step 2242, the
lighting control logic 78 determines if there is precipitation. If
a negative determination is made, then the process proceeds to step
2246. If a positive determination is made, then the process
proceeds to step 2244 where the lighting control logic 78 transmits
an instruction to the lighting system to activate, and then returns
to step 2238. In step 2246, the lighting control logic 78 receives
operational data from the lighting system. In step 2248, the
lighting control logic 78 determines if the lighting system is
active. If a negative determination is made, then the process
returns to step 2238. If a positive determination is made, then the
process proceeds to step 2250 where the lighting control logic 78
transmits an instruction to the lighting system to deactivate, and
returns to step 2238.
[0227] FIG. 25Y is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2252, the lighting control logic 78 monitors safety
alarms for incoming operational data. In step 2254, the lighting
control logic 78 receives incoming operational data from the safety
alarms. In step 2256, the lighting control logic 78 determines if a
safety alarm has been triggered. If a negative determination is
made, then the process returns to step 2252. If a positive
determination is made, then the process proceeds to step 2258 where
the lighting control logic 78 receives parameters of the
user-selected light show or color. In step 2116, the lighting
control logic 78 retrieves a safety alarm lighting program from the
memory. In step 2260, the lighting control logic 78 transmits an
instruction to the lighting system to display the safety alarm
program, e.g., a flashing red light at maximum lumen output, and
the process ends.
[0228] FIG. 25Z is another flowchart illustrating processing logic
of the lighting control logic 78 communicating with a lighting
system. In step 2262, the lighting control logic 78 determines the
geographic location of the pool, e.g., based on IP address or
configuration parameters. In step 2264, the lighting control logic
78 receives regional sea turtle migratory and nesting data from the
Internet/Web. In step 2266, the lighting control logic 78
determines the proximity of the pool to sea turtle nesting areas.
In step 2268, the lighting control logic 78 determines if the pool
is located in a sea turtle nesting area. If a negative
determination is made, then the process returns to step 2264. If a
positive determination is made, then the process proceeds to step
2270 where the lighting control logic 78 receives the current data.
In steps 2272 and 2274, the lighting control logic 78 determines if
the current date is during the sea turtle nesting season. If a
negative determination is made then the process returns to step
2270. If a positive determination is made, then the process
proceeds to step 2276 where the lighting control logic 78 transmits
an instruction to the lighting system to lock out all colors other
than amber, and the process ends.
[0229] FIG. 25AA is a flowchart illustrating processing logic of
the lighting control logic 78 for controlling multiple light
sources. The lighting control logic 78 proceeds with four parallel
routine sequences that respectively begin with steps 2278, 2288,
2298, 2308. Each routine sequence is discussed sequentially, though
it should be understood that the routine loops could operate in
parallel, or alternatively, in series with each other. The first
sequence begins in step 2278 where the lighting control logic 78
transmits an instruction to a first light source to display a
color. In step 2280, the lighting control logic 78 monitors a first
motion sensor for incoming operational data. In step 2282, the
lighting control logic 78 receives incoming operational data from
the first motion sensor. In step 2284, the lighting control logic
78 determines if motion has been detected. If a negative
determination is made then the process returns to step 2280. If a
positive determination is made then the process proceeds to step
2286 where the lighting control logic 78 transmits an instruction
to the first light source to change the color, and then returns to
step 2284.
[0230] The second sequence begins in step 2288 where the lighting
control logic 78 transmits an instruction to a second light source
to display a color. In step 2290, the lighting control logic 78
monitors a second motion sensor for incoming operational data. In
step 2292, the lighting control logic 78 receives incoming
operational data from the second motion sensor. In step 2294, the
lighting control logic 78 determines if motion has been detected.
If a negative determination is made then the process returns to
step 2290. If a positive determination is made then the process
proceeds to step 2296 where the lighting control logic 78 transmits
an instruction to the second light source to change the color, and
then returns to step 2294.
[0231] The third sequence begins in step 2298 where the lighting
control logic 78 transmits an instruction to a third light source
to display a color. In step 2300, the lighting control logic 78
monitors a third motion sensor for incoming operational data. In
step 2302, the lighting control logic 78 receives incoming
operational data from the third motion sensor. In step 2304, the
lighting control logic 78 determines if motion has been detected.
If a negative determination is made then the process returns to
step 2300. If a positive determination is made then the process
proceeds to step 2306 where the lighting control logic 78 transmits
an instruction to the third light source to change the color, and
then returns to step 2304.
[0232] The n.sup.th sequence begins in step 2308 where the lighting
control logic 78 transmits an instruction to an n.sup.th light
source to display a color. In step 2310, the lighting control logic
78 monitors an n.sup.th motion sensor for incoming operational
data. In step 2312, the lighting control logic 78 receives incoming
operational data from the n.sup.th motion sensor. In step 2314, the
lighting control logic 78 determines if motion has been detected.
If a negative determination is made then the process returns to
step 2310. If a positive determination is made then the process
proceeds to step 2316 where the lighting control logic 78 transmits
an instruction to the n.sup.th light source to change the color,
and then returns to step 2314.
[0233] FIG. 25AB is another flowchart illustrating processing steps
of the lighting control logic 78 communicating with the lighting
system 14h. In step 2318, the lighting control logic 78 receives
water pressure operational data from external sensor(s) at a first
time. In step 2320, the lighting control logic 78 delays for x
seconds, where "x" refers to any suitable integral value (e.g., 30,
60, 3600, 7200, etc.). In step 2322, the lighting control logic 78
receives water pressure operational data from external sensor(s) at
a second time. In step 2324, the lighting control logic 78
determines the change (e.g., delta (A)) in water pressure. In step
2326, the lighting control logic 78 retrieves setpoint data for the
acceptable drop, or increase, in water pressure from the memory. In
step 2328, the lighting control logic 78 determines if the change
in water pressure is acceptable (e.g., by comparing the actual
change in water pressure to the acceptable change in water
pressure). If a positive determination is made, then the process
returns to step 2318. If a negative determination is made, then the
process proceeds to step 2230 where the lighting control logic 78
retrieves a lighting program associated with a drop, or increase,
in water pressure from the memory (e.g., red lights, red flashing
lights, fast pulsing lights for pressure increase, slow pulsing
lights for pressure decrease, etc.). In step 2332, the lighting
control logic 78 transmits instructions the lighting system 14h to
display the lighting program associated with the drop, or increase,
in pressure. Optionally, in step 2334, the lighting control system
78 could also for example, transmit a "Backwash" message to the
user/operator. The processing control logic 78 then returns to step
2318.
[0234] The lighting control logic 78 can also manage and/or control
the brightness of a plurality of lights in response to noise or
sound. An ambient noise or sound sensor can be used to detect a
plurality of bathers ingress and egress from the swimming pool and
even the bathers voices. For example, the ambient noise sensor can
detect voice commands and/or noise levels and control the lights
based such voice commands and noise levels. Furthermore, the
lighting control logic 78 can modulate the plurality of lights
color, tempo, etc. if the control logic senses music, games,
voices, etc. Further, the noise sensor could also sense for games
being played by bathers, for example, "Marco Polo," and adjust
output of the lights accordingly.
[0235] The lighting control logic 78 can also receive input from a
pressure sensor for effectively determining depth of the water
above the sensor. This sensor can be located in a light or any
other suitable location in a pool or spa environment. The lighting
control logic 78 can trigger an automatic water fill routine or
draining routine to adjust the water level based on any set level
in the system.
[0236] FIG. 26 is a diagram 2400 illustrating pool cleaner control
logic 76. Pool cleaner control logic 76 could incorporate a variety
of types of data and/or data sources. More specifically, pool
cleaner control logic 76 could incorporate user input data 2402,
pool cleaner operational data 2404, pool cleaner factory
specifications 2406, pool cleaner configuration parameters 2408,
web data 2410, pool configuration parameters 2412, data from
related devices 2414, health monitoring data 2416, and/or external
sensor data 2418. While it may be desirable for external sensors to
monitor/provide data on as many system parameters as possible
(thereby providing greater optimization, automation, and
user/operator comfort), it is contemplated that some systems need
not utilize an external sensor to monitor every system parameter.
For example, if a pool cover detection sensor has not been
installed in a particular system, the user/operator can provide
this information by first determining if the pool cover has been
deployed (e.g., by visual inspection) and then entering the pool
cover deployment status into the system via a user interface.
[0237] User input data 2402 could include timers, schedules (e.g.,
on/off and what speed), cleaning patterns (e.g., orientation of
cleaner), etc. Pool cleaner operational data 2404 could include
submersion (e.g., float switch and/or moisture sensor), debris
level (e.g., collection bag), debris weight, power consumption,
current draw, speed of motor (RPM), speed of turbine (RPM), speed
of cleaner, orientation of cleaner, etc. In one example, the pool
cleaner control logic 76 could make a determination as to whether
energy can be supplied to the cleaner via an integral turbine. Pool
cleaner factor specifications 2406 could include motor speed, power
consumption, current draw, input voltage, life expectancy, etc.
Pool cleaner configuration parameters 2408 could include IP
address, GPS coordinates, zipcode, time and date, etc. Web data
2410 could include location (e.g., based on IP address), time and
date, sunrise/sunset data, ambient light, season, etc. Pool
configuration parameters 2412 could include connected pool devices,
pool surface area, pool geometry, pool liner color, pool cover
(e.g., yes or no), pool cover schedule, etc. Data from related
devices 2414 could include the pump, booster pump, changeover
valve, valve actuator, vision system, pool cover, controller, power
supply, etc. Health monitoring data 2416 could include line-to-line
balance, grounding, bonding, leak current, runtime, operating
temperature, power consumption, etc. External sensor data 2418
could include water circulation, water flow rate, water pressure
water turbidity, power consumption, current draw, line voltage,
valve actuation, ambient light, debris location, pool cover
detection, etc. Using this data, the pool cleaner control logic 76
could optimize the operation of the pool cleaner. Examples include,
anti-kink/hose un-tangle, adjust performance based on internal
sensors, cleaner and/or cleaner circuit pressure sensing, time of
day sensing, and send cleaner to dirty/high debris area of the
pool.
[0238] FIGS. 27A-27O are flowcharts illustrating processing steps
of the pool cleaner control logic 76. FIG. 27A is a flowchart
illustrating processing logic of the pool cleaner control logic 76
communicating with a pump. In step 2420, the pool cleaner control
logic 76 receives instruction to activate a pool cleaner. In step
2422, the pool cleaner control logic 76 receives operation data
from a pump. In step 2424, the pool cleaner control logic 76
determines whether the pump is on. If a positive determination is
made, the process proceeds to step 2426. If a negative
determination is made, then in step 2425 the pool cleaner control
logic 76 transmits instructions to the pump to activate, and then
proceeds to step 2426. In step 2426, the pool cleaner control logic
76 retrieves minimum flow rate setpoint data for the pool cleaner
operation from a memory (e.g., gallons per minute. In step 2428,
the pool cleaner control logic 76 receives operational flow rate
data 2428. In step 2430, the pool cleaner control logic 76
determines whether the flow rate is above a minimum setpoint. If a
positive determination is made, then the process proceeds to step
2432, where the pool cleaner control logic 76 transmits
instructions to the pool cleaner to activate, and then the process
ends. If a negative determination is made in step 2430, then the
process proceeds to step 2434, where the pool cleaner control logic
76 determines whether there are retries remaining. If a positive
determination is made, then in step 2436, the pool cleaner control
logic 76 transmits instructions to the pump to increase the flow
rate (e.g., by 5%), and the process reverts back to step 2428. If
instead, a negative determination is made in step 2434, then in
step 2438, the pool cleaner control logic 76 transmits an error
condition, and the process ends.
[0239] FIG. 27B is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a booster pump. In
step 2440, the pool cleaner control logic 76 receives instructions
to activate the pool cleaner. In step 2442, the pool cleaner
control logic 76 retrieves pool configuration data from memory
(e.g., connected pool devices). In step 2444, the pool cleaner
control logic 76 receives operational data from a pump. In step
2446, the pool cleaner control logic 76 determines whether the pump
is on. If a positive determination is made, the process proceeds to
step 2448. If a negative determination is made, in step 2456, the
pool cleaner control logic 76 transmits instructions to the pump to
activate, and the proceeds to step 2448. In step 2448, the pool
cleaner control logic 76 determines whether there is a booster
pump. If a positive determination is made, then in step 2450 the
pool cleaner control logic 76 receives operational data from the
booster pump. In step 2452, the pool cleaner control logic 76
determines whether the booster pump is on. If a positive
determination is made in step 2452, then in step 2454, the pool
cleaner control logic 76 transmits instructions to the pool cleaner
to activate. If a negative determination is made in step 2452, then
in step 2458 the pool cleaner control logic 76 transmits
instructions to the booster pump to activate, and then proceeds to
step 2454. If a negative determination is made in step 2448, then
the process proceeds to step 2454 (as discussed above).
[0240] FIG. 27C is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a valve actuator.
In step 2460, the pool cleaner control logic 76 receives
instructions to activate a pool cleaner. In step 2462, the pool
cleaner control logic 76 receives operational data from a
changeover valve actuator (e.g., orientation). In step 2464, the
pool cleaner control logic 76 determines whether the valve actuator
is in the correct orientation (e.g., valve is open). If a positive
determination is made, then the process proceeds to step 2466,
where the pool cleaner control logic 76 transmits instructions to
the pool cleaner to activate, and then the process ends. If a
negative determination is made in step 2464, then the process
proceeds to step 2468, where the pool cleaner control logic 76
determines whether there are retries remaining. If a positive
determination is made, then in step 2470, the pool cleaner control
logic 76 transmits instructions to the valve actuator to move to
the correct orientation (e.g., open), and the process reverts to
step 2462. If instead, a negative determination is made in step
2468, then in step 2472, the pool cleaner control logic 76
transmits an error condition (e.g., valve seized), and the process
ends.
[0241] FIG. 27D is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a pressure sensor.
In step 2474, the pool cleaner control logic 76 receives
instructions to activate a pool cleaner. In step 2476, the pool
cleaner control logic 76 retrieves pressure setpoint data for pool
cleaner operation from memory (e.g., minimum pressure). In step
2478, the pool cleaner control logic 76 receives operational data
from a pressure sensor. In step 2480, the pool cleaner control
logic 76 determines whether the pressure is sufficient. If a
negative determination is made in step 2480, then in step 2490, the
pool cleaner control logic 76 determines whether there are any
retries remaining. If a positive determination is made in step
2490, then in step 2492, the pool cleaner control logic 76
transmits instructions to the pump to increase output (e.g., by
5%), and the process reverts back to step 2478. If a negative
determination is made in step 2490, then in step 2494, the pool
cleaner control logic 76 transmits an error condition (e.g., leak),
and the process ends. If a positive determination is made in step
2480, then in step 2482, the pool cleaner control logic 76
retrieves flow rate setpoint data for pool cleaner operation from a
memory (e.g., minimum flow rate). In step 2484, the pool cleaner
control logic 76 receives operational data from a flow sensor. In
step 2486, the pool cleaner control logic 76 determines whether the
flow rate is sufficient. If a positive determination is made in
step 2486, then in step 2488, the pool cleaner control logic 76
transmits instructions to the pool cleaner to activate, and then
the process ends. If a negative determination is made in step 2486,
then in step 2496, the pool cleaner control logic 76 determines
whether there are any retries remaining. If a positive
determination is made, then in step 2498, the pool cleaner control
logic 76 transmits instructions to the pump to increase output
(e.g., by 5%), and the process reverts to step 2484. If instead, a
negative determination is made in step 2496, then in step 2500, the
pool cleaner control logic 76 transmits an error condition (e.g.,
blockage), and the process ends. It should be noted that the above
process can apply to actuate valves to control the pool cleaner.
The valve actuation algorithms are explained in greater detail
below.
[0242] FIG. 27E is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a valve. In step
2502, the pool cleaner control logic 76 receives instructions to
activate a pool cleaner. In step 2504, the pool cleaner control
logic 76 retrieves pressure setpoint data for a pool cleaner
operation from a memory (e.g., minimum circuit pressure). In step
2506, the pool cleaner control logic 76 receives operational data
from a pressure sensor. In step 2508, the pool cleaner control
logic 76 determines whether the circuit pressure is sufficient. If
a positive determination is made, then in step 2510, the pool
cleaner control logic 76 transmits instructions to the pool cleaner
to activate, and the process ends. If a negative determination is
made in step 2508, then in step 2512, the pool cleaner control
logic 76 determines whether there are any retries remaining. If a
positive determination is made, then in step 2514, the pool cleaner
control logic 76 receives operational data from an input valve
(e.g., valve position). In step 2516, the pool cleaner control
logic 76 determines required valve actuation to achieve pressure
setpoint (e.g., open 90%). In step 2518, the pool cleaner control
logic 76 transmits instructions to the valve to actuate by a
determined amount. If a negative determination is made in step
2512, then in step 2520, the pool cleaner control logic 76
transmits an error condition (e.g., valve seized), and the process
ends.
[0243] FIG. 27F is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a pool cleaner
submersion sensor. In step 2522, the pool cleaner control logic 76
receives instruction to activate a pool cleaner. In step 2524, the
pool cleaner control logic 76 receives operational data from the
pool cleaner submersion sensor (e.g., float switch or moisture
sensor). In step 2526, the pool cleaner control logic 76 determines
whether the pool cleaner is submerged. If a positive determination
is made, then in step 2528, the pool cleaner control logic 76
transmits instructions to the pool cleaner to activate. If a
negative determination is made in step 2526, then in step 2530, the
pool cleaner control logic 76 determines whether there are any
retries remaining. If a positive determination is made, then the
process reverts to step 2524. If a negative determination is made,
then the process proceeds to step 2532, where the pool cleaner
control logic 76 transmits an error condition, and the process
ends.
[0244] FIG. 27G is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a debris sensor of
the pool cleaner collection bag. In step 2534, the pool cleaner
control logic 76 receives instructions to activate a pool cleaner.
In step 2536, the pool cleaner control logic 76 receives
operational data from a debris sensor for a collection bag. In step
2538, the pool cleaner control logic 76 determines the debris level
of the collection bag. In step 2546, the pool cleaner control logic
76 could optionally transmit instruction to an HMI device to
display the debris level of the collection bag. In step 2540, the
pool cleaner control logic 76 determines whether the collection bag
is full. If a positive determination is made, then in step 2544,
the pool cleaner control logic 76 transmits a message to the user
to empty the collection bag, and the process reverts to step 2536.
Optionally, in step 2541 the pool cleaner logic 76 could transmit
an instruction to the pool cleaner to swim to a pool skimmer and
purge the collection bag so that the debris from the collection bag
is emptied without user intervention and quickly removed from the
pool via the skimmer. If a negative determination is made in step
2540, then in step 2542, the pool cleaner control logic 76
transmits instructions to the pool cleaner to activate, and the
process ends.
[0245] FIG. 27H is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a pool cleaner
regarding a motor speed threshold. In step 2548, the pool cleaner
control logic 76 retrieves factory specified pool cleaner motor
speed data from memory. In step 2550, the pool cleaner control
logic 76 determines the motor speed threshold for a full collection
bag (e.g., 95% of factory specified speed). In step 2552, the pool
cleaner control logic 76 receives operational data from the pool
cleaner (e.g., motor speed). In step 2554, the pool cleaner control
logic 76 determines whether the motor speed is below a threshold.
If a negative determination is made, the process reverts to step
2552. If a positive determination is made, the process proceeds to
step 2556, where the pool cleaner control logic 76 transmits a
message to the user to empty the collection bag, and the process
reverts to step 2552.
[0246] FIG. 27I is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating regarding line power
operational data. In step 2558, the pool cleaner control logic 76
receives instructions to activate a pool cleaner. In step 2560, the
pool cleaner control logic 76 retrieves data on factory specified
power parameters from a memory (e.g., power consumption, current
draw, and/or line voltage). In step 2562, the pool cleaner control
logic 76 receives line power operational data. In step 2564, the
pool cleaner control logic 76 determines whether the line power is
within factory specifications. If a positive determination is made,
then in step 2566, the pool cleaner control logic 76 transmits
instructions to the pool cleaner to activate. If a negative
determination is made in step 2564, then in step 2568, the pool
cleaner control logic 76 determines whether there are any retries
remaining. If a positive determination is made in step 2568, then
the process reverts to step 2562. If a negative determination is
made in step 2570, then in step 2570, the pool cleaner control
logic 76 transmits an error condition, and the process ends.
[0247] FIG. 27J is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with an internal
tachometer. In step 2572, the pool cleaner control logic 76
receives instructions to activate a pool cleaner. In step 2580, the
pool cleaner control logic 76 transmits instructions to the pool
cleaner to activate. In step 2574, the pool cleaner control logic
76 retrieves turbine setpoint data for a pool cleaner operation
from memory (e.g., minimum RPMs). In step 2576, the pool cleaner
control logic 76 receives operational data from an internal
tachometer. In step 2578, the pool cleaner control logic 76
determines whether the speed of the turbine is sufficient. If a
positive determination is made in step 2578, the process reverts to
step 2576. If a negative determination is made in step 2578, then
in step 2582, the pool cleaner control logic 76 determines whether
there are any retries remaining. If a positive determination is
made in step 2582, then in step 2584, the pool cleaner control
logic 76 transmits instructions to the pump to increase output
(e.g., by 5%), and the process reverts to step 2576. If a negative
determination is made in step 2582, then in step 2586, the pool
cleaner control logic 76 transmits an error condition (e.g.,
obstruction), and the process ends.
[0248] FIG. 27K is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with an internal
tachometer. In step 2588, the pool cleaner control logic 76
receives instructions to activate a pool cleaner. In step 2596, the
pool cleaner control logic 76 transmits instructions to the pool
cleaner to activate. In step 2590, the pool cleaner control logic
76 retrieves turbine setpoint data for a pool cleaner operation
from a memory (e.g., minimum RPMs). In step 2592, the pool cleaner
control logic 76 receives operational data from an internal
tachometer. In step 2594, the pool cleaner control logic 76
determines whether the speed of the turbine is sufficient. If a
positive determination is made, the process reverts to step 2592.
If in step 2594, a negative determination is made, then in step
2598, the pool cleaner control logic 76 determines whether there
are any retries remaining. If a positive determination is made in
step 2598, then in step 2600, the pool cleaner control logic 76
receives operational data from a flow rate sensor. In step 2602,
the pool cleaner control logic 76 determines the required increase
in flow rate to achieve the turbine speed setpoint. In step 2604,
the pool cleaner control logic 76 determines the required increase
in pump speed to achieve a required flow rate. In step 2606, the
pool cleaner control logic 76 transmits the instruction to the pump
to increase output by the determined amount, and the process
reverts to step 2592. If a negative determination is made in step
2598, then in step 2608, the pool cleaner control logic 76
transmits an error condition (e.g., obstruction), and the process
ends.
[0249] FIG. 27L is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a pump. In step
2610, the pool cleaner control logic 76 retrieves scheduling data
for a pool cleaner operation from a memory (e.g., operating hours,
duration, schedule, weather conditions, upcoming events at the
site, etc.). In step 2612, the pool cleaner control logic 76
receives time data from a clock (e.g., current time). In step 2614,
the pool cleaner control logic 76 determines whether the current
time is within hours of operation. If a negative determination is
made, then the process reverts to step 2612. If a positive
determination is made, then in step 2616, the pool cleaner control
logic 76 receives operational data from a pump. In step 2618, the
pool cleaner control logic 76 determines whether the pump is on. If
a positive determination is made in step 2618, then in step 2620,
the pool cleaner control logic 76 transmits instructions to the
pool cleaner to activate. If a negative determination is made in
step 2618, then in step 2622, the pool cleaner control logic 76
transmits instructions to the pump to activate, and the process
proceeds to step 2620.
[0250] FIG. 27M is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with an ambient light
sensor. In step 2624, the pool cleaner control logic 76 receives
operational data from an ambient light sensor. In step 2626, the
pool cleaner control logic 76 determines the time of day (e.g.,
day, night, etc.). In step 2628, the pool cleaner control logic 76
determines whether it is nighttime. If a negative determination is
made, the process reverts to step 2624. If a positive determination
is made, then in step 2630, the pool cleaner control logic 76
receives operational data from a pump. In step 2632, the pool
cleaner control logic 76 determines whether the pump is on. If a
positive determination is made in step 2632, then in step 2634, the
pool cleaner control logic 76 transmits instructions to the pool
cleaner to activate, and the process ends. If a negative
determination is made in step 2632, then in step 2636, the pool
cleaner control logic 76 transmits instructions to the pump to
activate, and the process proceeds to step 2634.
[0251] FIG. 27N is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a vision system.
In step 2638, the pool cleaner control logic 76 receives
instructions to activate a pool cleaner. In step 2640, the pool
cleaner control logic 76 receives operational data from a vision
system (e.g., location of debris). In step 2642, the pool cleaner
control logic 76 determines the location of a high debris area. In
step 2644, the pool cleaner control logic 76 determines the
location and orientation of the pool cleaner. In step 2646, the
pool cleaner control logic 76 transmits instructions to the pool
cleaner to traverse the high debris area. The process then reverts
to step 2640.
[0252] FIG. 27O is a flowchart illustrating processing steps of the
pool cleaner control logic 76 communicating with a software
application. In step 2639 the application displays a graphical
representation or image of the pool on the device on which the
software application is installed. While step 2639 shows the
software application installed on a smartphone, it is to be
appreciated that the software application can be installed on
various devices of the system 10, including but not limited to, the
computer system 20 or the pool/spa control system 14f. In step
2641, the user indicates (e.g., by touching the smartphone screen
in the appropriate location) where debris is observed in the pool.
In step 2643 the software application marks each spot that the user
has indicated with a graphical overlay (e.g., a box is placed
around each indicated debris area). In step 2645 the software
application transmits an instruction to the cleaner 14g to navigate
to the debris areas indicated by the user and clean the same. The
process then ends.
[0253] It is noted that the pool cleaner control logic illustrated
in FIGS. 27A-27O and discussed above could be used to control a
pool/spa cleaner that does not have on-board electronic controls,
such as, for example, a conventional suction or pressure cleaner.
In such instances, control of the cleaner could be implemented by
way of a valve actuator that has an associated processor and
network connectivity, such as the valve actuator discussed herein
in connection with FIGS. 28-29I. The valve actuator would be in
fluid communication with the cleaner, and the control logic
discussed in connection with FIGS. 27A-27O would be applied to
control the valve actuator to correspondingly control operation of
the cleaner.
[0254] FIG. 28 is a diagram 2700 illustrating valve actuator
control logic 74. Valve actuator control logic 74 could incorporate
a variety of types of data and/or data sources. More specifically,
valve actuator control logic 76 could incorporate user input data
2702, valve actuator operational data 2704, valve actuator factory
specifications 2706, valve actuator configuration parameters 2708,
web data 2710, pool configuration parameters 2712, data from
related devices 2714, health monitoring data 2716, and/or external
sensor data 2718.
[0255] User input data 2702 could include schedule information
(e.g., on/off and what orientation, duration of power on/off for
specific orientation, open/close), etc. Valve actuator operational
data 2704 could include line voltage, operation (e.g., on, off,
etc.), orientation (e.g., open, close, etc.), power duration, etc.
Valve actuator factor specification 2706 could include source
voltage, power consumption, current draw, etc. Valve actuator
configuration parameters 2708 could include IP address, GPS
coordinates, zipcode, time and date, etc. Web data 2710 could
include location (e.g., based on IP address), time and date,
sunrise/sunset data, temperature, ambient light, season, etc. Pool
configuration parameters 2712 could include pool surface area, pool
geometry, pool line color, pool cover (e.g., yes, no, etc.), pool
cover schedule, etc. Data from related devices 2714 could include
additional valves, pump, heater (e.g., gas, heat pump, etc.), heat
(e.g., solar), spa, UV ozone, cleaner, controller, chlorinator,
water features, water slide, skimmer, filter, etc. Health
monitoring data 2716 could include power consumption, current
monitoring, source voltage, etc. External sensor data 2718 could
include water flow rate, water pressure, etc. While it may be
desirable for external sensors to monitor/provide data on as many
system parameters as possible (thereby providing greater
optimization, automation, and user/operator comfort), it is
contemplated that some systems need not utilize an external sensor
to monitor every system parameter. For example, if a water pressure
sensor has not been installed in a particular system, the
user/operator can provide this information by first determining the
water pressure (e.g., by visually inspecting an analog water
pressure gauge) and then entering the water pressure information
into the system via a user interface.
[0256] FIGS. 29A-29I are flowcharts illustrating processing steps
of the valve actuator control logic 74. FIG. 29A is a flowchart
illustrating processing steps of the valve actuator control logic
74 communicating with a valve actuator. In step 2720, the valve
actuator control logic 74 receives instructions to actuate a valve.
In step 2722, the valve actuator control logic 74 retrieves data on
factory specified power parameters from a memory (e.g., line
voltage). In step 2724, the valve actuator control logic 74
receives line voltage operational data. In step 2726, the valve
actuator control logic 74 determines whether the line voltage is
within the factory specifications. If a positive determination is
made, then in step 2728, the valve actuator control logic 74
transmits instructions to the valve actuator to actuate. If a
negative determination is made in step 2726, then in step 2730, the
valve actuator control logic 74 determines whether there are any
retries remaining. If a positive determination is made in step
2730, then the process reverts to step 2724. If a negative
determination is made in step 2730, then in step 2732, the valve
actuator control logic 74 transmits an error condition (e.g.,
undervoltage, overvoltage, etc.), and the process ends.
[0257] FIG. 29B is a flowchart illustrating processing steps of the
valve actuator control logic 74 communicating with a heater. In
step 2734, the valve actuator control logic 74 receives
instructions to activate a heater. In step 2736, the valve actuator
control logic 74 receives operational data from a pump. In step
2740, the valve actuator control logic 74 receives operational data
from a heater valve actuator (e.g., orientation) 14e. In step 2742,
the valve actuator control logic 74 determines whether the heater
valve actuator 14e is in the correct orientation (e.g., valve is
open). If a positive determination is made in step 2742, then in
step 2750 a determination is made as to whether the pump 14a is on.
If a positive determination is made in step 2750, in step 2744, the
valve actuator control logic 74 transmits instructions to the
heater 14b to activate, and the process ends. If a negative
determination is made in step 2750 the valve actuator control logic
74 transmits an instruction to the pump 14a to activate and the
process then proceeds to step 2744. If a negative determination is
made in step 2742, then in step 2738, a determination is made as to
whether the pump 14a is on. If a positive determination is made in
step 2738, the valve actuator control logic 74 transmits an
instruction to the pump 14a to deactivate. If a negative
determination is made in step 2738, the process proceeds to step
2754. In step 2752, the valve actuator control logic 74 determines
whether there are any retries remaining. If a positive
determination is made in step 2752, then in step 2754, the valve
actuator control logic 74 transmits instructions to the heater
valve actuator 14e to move to the correct orientation (e.g., open)
and the process then reverts to step 2736. If a negative
determination is made in step 2752, then in step 2756, the valve
actuator control logic 74 transmits an error condition (e.g., valve
seized), and the process ends.
[0258] FIG. 29C is a flowchart illustrating processing steps of the
valve actuator control logic 74 communicating with a heater. In
step 2758, the valve actuator control logic 74 receives
instructions to activate a heater. In step 2760, the valve actuator
control logic 74 receives operational data from a pump. In step
2762, the valve actuator control logic 74 determines whether the
pump is active. If a negative determination is made in step 2762,
then in step 2776, the valve actuator control logic 74 determines
whether there are any retries remaining. If a positive
determination is made in step 2776, then the process reverts to
step 2760. If a negative determination is made in step 2776, then
in step 2778, the valve actuator control logic 74 transmits an
error condition (e.g., interlock), and the process ends. If a
positive determination is made in step 2762, then in step 2764, the
valve actuator control logic 74 receives operational data from a
heater valve actuator (e.g., orientation). In step 2766, the valve
actuator control logic 74 determines whether the heater valve
actuator is in the correct orientation (e.g., valve is open). If a
positive determination is made in step 2766, then in step 2768, the
valve actuator control logic 74 transmits instructions to the
heater to activate, and the process ends. If a negative
determination is made in step 2766, then in step 2770, the valve
actuator control logic 74 determines whether there are any retries
remaining. If a positive determination is made in step 2770, then
in step 2772, the valve actuator control logic 74 transmits
instructions to the heater valve actuator to move to the correct
orientation (e.g., open). If a negative determination is made in
step 2770, then in step 2774, the valve actuator control logic 74
transmits an error condition (e.g., valve seized), and the process
ends.
[0259] FIG. 29D is a flowchart illustrating processing steps of the
valve actuator control logic 74 communicating with a water feature
valve actuator. In step 2780, the valve actuator control logic 74
receives instructions to increase the output of the water stream
feature (e.g., new flow rate setpoint). In step 2782, the valve
actuator control logic 74 receives operational data from a water
feature (e.g., flow rate). In step 2784, the valve actuator control
logic 74 determines whether the water feature is active. If a
positive determination is made in step 2784, then in step 2786, the
valve actuator control logic 74 determines whether the flow rate is
sufficient. If a positive determination is made in step 2786, then
the process ends. If a negative determination is made in step 2786,
then in step 2794, the valve actuator control logic 74 determines
whether there are any retries remaining. If a positive
determination is made in step 2794, then in step 2796, the valve
actuator control logic 74 transmits instructions to the water
feature valve actuator to increase throughput (e.g., by 5%), and
the process reverts to step 2782. If a negative determination is
made in step 2794, then in step 2798, the valve actuator control
logic 74 transmits an error condition (e.g., blockage), and the
process ends. If a negative determination is made in step 2784,
then in step 2788, the valve actuator control logic 74 determines
whether there are any retries remaining. If a positive
determination is made in step 2788, then in step 2790, the valve
actuator control logic 74 transmits instructions to the water
feature valve actuator to open, and the process reverts to step
2782. If a negative determination is made in step 2788, then in
step 2792, the valve actuator control logic 74 transmits an error
condition (e.g., blockage), and the process ends. It is to be
appreciated that while flow rate operational data is received from
the water feature in the process described above, similar process
steps could be followed should pressure, or other, operational data
be received from the water feature.
[0260] FIG. 29E is a flowchart illustrating processing steps of the
valve actuator control logic 74 communicating with a water feature
valve actuator. In step 2800, the valve actuator control logic 74
receives instructions to activate a water feature. In step 2802,
the valve actuator control logic 74 retrieves flow rate setpoint
data for water feature operation from a memory (e.g., minimum flow
rate). In step 2804, the valve actuator control logic 74 receives
operational data from a water feature (e.g., flow rate). In step
2806, the valve actuator control logic 74 determines whether the
water feature is active. If a positive determination is made in
step 2806, then in step 2808, the valve actuator control logic 74
determines whether the flow rate is sufficient. If a positive
determination is made in step 2808, then the process ends. If a
negative determination is made in step 2808, then in step 2816, the
valve actuator control logic 74 determines whether there are any
retries remaining. If a positive determination is made in step
2816, then in step 2818, the valve actuator control logic 74
transmits instructions to the water feature valve actuator to
increase throughput (e.g., by 5%), and the process reverts to step
2804. If a negative determination is made in step 2816, then in
step 2820 the valve actuator control logic 74 transmits an error
condition (e.g., blockage), and the process ends. If a negative
determination is made in step 2806, then in step 2810, the valve
actuator control logic 74 determines whether there are any retries
remaining. If a positive determination is made in step 2810, then
in step 2812, the valve actuator control logic 74 transmits
instructions to the water feature valve actuator to open, and the
process reverts to step 2802. If a negative determination is made
in step 2810, then in step 2814, the valve actuator control logic
74 transmits an error condition (e.g., blockage), and the process
ends.
[0261] FIG. 29F is a flowchart illustrating processing steps of the
valve actuator control logic 74 communicating with a heater valve
actuator. In step 2822, the valve actuator control logic 74
receives instructions to activate the heater. In step 2824, the
valve actuator control logic 74 receives operational data from a
heater valve actuator (e.g., orientation). In step 2826, the valve
actuator control logic 74 determines whether the heater valve
actuator is in the correct orientation (e.g., valve is open). If a
negative determination is made in step 2826, then in step 2834, the
valve actuator control logic 74 determines whether there are any
retries remaining. If a positive determination is made in step
2834, then in step 2836, the valve actuator control logic 74
transmits instructions to the heater valve actuator to move to the
correct orientation (e.g., open), and the process reverts to step
2824. If a negative determination is made in step 2834, then in
step 2838, the valve actuator control logic 74 transmits an error
condition (e.g., valve seized), and the process ends. If a positive
determination is made in step 2826, then in step 2828, the valve
actuator control logic 74 receives operational data from a pump
valve actuator (e.g., orientation). In step 2830, the valve
actuator control logic 74 determines whether the pump valve
actuator is in the correct orientation (e.g., valve is open). If a
positive determination is made in step 2830, then in step 2832, the
valve actuator control logic 74 transmits instructions to the
heater to activate. If a negative determination is made in step
2830, then in step 2840, the valve actuator control logic 74
determines whether there are any retries remaining. If a positive
determination is made in step 2840, then in step 2842, the valve
actuator control logic 74 transmits instructions to the pump valve
actuator to move to the correct orientation (e.g., open), and the
process reverts to step 2828. If a negative determination is made
in step 2840, then in step 2844, the valve actuator control logic
74 transmits an error condition (e.g., valve seized), and the
process ends.
[0262] FIG. 29G is a flowchart illustrating processing steps of the
valve actuator control logic 74. In step 2846, the heater valve
actuator receives instructions to open. In step 2848, the heater
valve actuator sends instructions to the pump valve actuator to
open. In step 2850, the heater valve actuator receives operating
data from the pump valve actuator. In step 2852, the heater valve
actuator determines if the pump valve actuator is open. In step
2854, the heater valve actuator moves to the open orientation.
[0263] FIG. 29H is a flowchart illustrating processing steps of the
valve actuator control logic 74. In step 2856, the valve actuator
control logic 74 receives instructions to actuate a valve. In step
2858, the valve actuator control logic 74 receives an input from a
timer for x seconds. In step 2860, the valve actuator control logic
74 transmits instructions to the valve actuator to move to a
desired orientation.
[0264] FIG. 29I is a flowchart illustrating processing steps of the
valve actuator control logic 74 communicating with a pump. In step
2862, the valve actuator control logic 74 retrieves operational
setpoint data on valve actuator orientation for a given pump speed
(e.g., actuate valve at a given speed). In step 2864, the valve
actuator control logic 74 receives operational data from a pump
(e.g., RPMs). In step 2866, the valve actuator control logic 74
determines the correct valve actuator orientation for a speed of
the pump. In step 2868, the valve actuator control logic 74
receives operational data from a valve actuator (e.g.,
orientation). In step 2870, the valve actuator control logic 74
determines whether the valve actuator is in the correct
orientation. If a positive determination is made in step 2870, then
the process reverts to step 2864. If a negative determination is
made in step 2870, then in step 2872, the valve actuator control
logic 74 determines whether there are any retries remaining. If a
positive determination is made in step 2872, then in step 2874, the
valve actuator control logic 74 transmits instructions to the valve
actuator to move to the correct orientation, and the process
reverts to step 2868. If a negative determination is made in step
2872, then in step 2876, the valve actuator control logic 74
transmits an error condition (e.g., valve seized), and the process
ends.
[0265] FIG. 30 is a diagram 2900 illustrating water feature control
logic 72. Water feature control logic 72 could incorporate a
variety of types of data and/or data sources. More specifically,
water feature control logic 72 could incorporate user input data
2902, water feature operational data 2904, water feature factory
specifications 2906, water feature configuration parameters 2908,
web data 2910, pool configuration parameters 2912, data from
related devices 2914, health monitoring data 2916, and/or external
sensor data 2918.
[0266] User input data 2902, could include timers, schedules,
feature parameters (e.g., how high, how much flow for effect), etc.
Water feature operational data 2904 could include pressure, water
flow rate, debris sensing, actuator position, etc. Water feature
configuration parameters 2908 could include IP address, GPS
coordinates, zipcode, time and date, etc. Web data 2910 could
include location (e.g., based on IP address), time and date,
sunrise/sunset data, regional/local weather forecast, wind speed,
wind direction, etc. Pool configuration parameters 2912 could
include connected pool devices, pool surface area, pool geometry,
pool line color, pool cover (e.g., yes, no, etc.), pool cover
schedule, etc. Data from related devices 2914 could include
additional water features, pump, chemistry dispenser, heater (e.g.,
gas pump, heat pump, etc.), heat (e.g., solar), chiller, spa, UV
sanitizer, pool cleaner, controller, chlorinator, water slide,
skimmer, filter, voice recognition/activation system, etc. External
sensor data 2918 could include debris sensor, water temperature,
motion sensor, ambient noise, etc. While it may be desirable for
external sensors to monitor/provide data on as many system
parameters as possible (thereby providing greater optimization,
automation, and user/operator comfort), it is contemplated that
some systems need not utilize an external sensor to monitor every
system parameter. For example, if a water temperature sensor has
not been installed in a particular system, the user/operator can
provide this information by first determining the water temperature
(e.g., by checking a thermometer, thermocouple, etc.) and then
entering the water temperature into the system via a user
interface. Using this data, the water feature control logic 76
could optimize the operation of the water features by, for example,
determining if the feature has been degraded due to debris by
receiving data from a pressure sensor in the unit, determining
appropriate operation by receiving weather data (e.g., wind
location, direction, and speed) and modifying operating parameters,
not running the water feature or altering the operation thereof if
users are present (e.g., auto-home, or auto-away), enhance
turn-over and make pH adjustments, varying the height of water from
a water feature by using a variable position actuator,
self-leveling the water feature using an actuator and level
sensor.
[0267] FIGS. 31A-31F are flowcharts illustrating processing steps
of the water feature control logic 72. FIG. 31A is a flowchart
illustrating processing steps of the water feature control logic
72. In step 2920, the water feature control logic 72 receives
instructions to activate a water feature. In step 2922, the water
feature control logic 72 retrieves minimum flow rate setpoint data
for water feature operation from a memory (e.g., gallons per
minute). In step 2924, the water feature control logic 72 receives
operational flow rate data. In step 2926, the water feature control
logic 72 determines whether the flow rate is above a minimum
setpoint. If a positive determination is made in step 2926, then in
step 2928, the water feature control logic 72 transmits
instructions to the water feature actuator valve to move to an open
orientation, and the process ends. If a negative determination is
made in step 2926, then in step 2930, the water feature control
logic 72 determines whether there are any retries remaining. If a
positive determination is made in step 2930, then in step 2932, the
water feature control logic 72 transmits instructions to the pump
to increase flow (e.g., by 5%), and the process reverts to step
2924. If a negative determination is made in step 2930, then in
step 2934, the water feature control logic 72 transmits an error
condition, and the process ends.
[0268] FIG. 31B is a flowchart illustrating processing steps of the
water feature control logic 72. In step 2936, the water feature
control logic 72 receives instructions to activate a water feature.
In step 2938, the water feature control logic 72 receives
operational data from connected pool devices (e.g., additional
water features). In step 2940, the water feature control logic 72
determines whether there are additional water features. If a
positive determination is made in step 2940, then in step 2942, the
water feature control logic 72 determines whether additional water
features are active. If a positive determination is made in step
2942, then in step 2944, the water feature control logic 72
transmits instructions to the water feature actuator valve to move
to an open orientation, and the process ends. If a negative
determination is made in step 2942, then in step 2946, the water
feature control logic 72 transmits instruction to additional water
feature actuator valves to move to the open orientation, and the
process ends. If a negative determination is made in step 2940,
then the process proceeds to step 2944 (as discussed above).
[0269] FIG. 31C is a flowchart illustrating processing steps of the
water feature control logic 72. In step 2948, the water feature
control logic 72 receives operational data from chemistry
automation system. In step 2950, the water feature control logic 72
determines if the chemistry automation system is active. If a
negative determination is made in step 2950, then the process
reverts to step 2948. If a positive determination is made in step
2950, then in step 2952, the water feature control logic 72
transmits instructions to the water feature actuation valve to move
to the open orientation.
[0270] FIG. 31D is a flowchart illustrating processing steps of the
water feature control logic 72. In step 2954, the water feature
control logic 72 retrieves water temperature setpoint data from
memory (e.g., desired pool temperature). In step 2956, the water
feature control logic 72 receives operational data from a
temperature sensor. In step 2958, the water feature control logic
72 determines whether the temperature is above a setpoint. If a
positive determination is made in step 2958, then in step 2960, the
water feature control logic 72 transmits instructions to the
chiller to activate. In step 2962, the water feature control logic
72 transmits instructions to the water feature actuation valve to
move to the open orientation, and the process reverts to step 2956.
If a negative determination is made in step 2958, then in step
2964, the water feature control logic 72 receives operational data
from chiller and water feature. In step 2966, the water feature
control logic 72 determines whether the chiller and water feature
are active. If a negative determination is made in step 2966, then
the process reverts to step 2956. If a positive determination is
made in step 2966, then in step 2968, the water feature control
logic 72 transmits instruction to deactivate the chiller and water
feature.
[0271] FIG. 31E is a flowchart illustrating processing steps of the
water feature control logic 72. In step 2970, the water feature
control logic 72 receives operational data from a motion sensor. In
step 2972, the water feature control logic 72 determines whether
the motion sensor is triggered. If a positive determination is made
in step 2972, then in step 2980, the water feature control logic 72
transmits instruction to the water feature valve actuator to move
to the open position, and the process reverts to step 2970. If a
negative determination is made in step 2972, then in step 2974, the
water feature control logic 72 receives operational data from a
water feature valve actuator (e.g., orientation). In step 2976, the
water feature control logic 72 determines whether the valve
actuator is in the open orientation. If a negative determination is
made in step 2976, the process reverts to step 2970. If a positive
determination is made in step 2976, then in step 2978, the water
feature control logic 72 transmits instruction to the water feature
valve actuator to move to the closed position, and the process
reverts to step 2970.
[0272] FIG. 31F is a flowchart illustrating processing steps of the
water feature control logic 72. In step 2982, the water feature
control logic 72 retrieves ambient noise setpoint data from memory
(e.g., maximum ambient noise value). In step 2984, the water
feature control logic 72 receives operational data from an ambient
noise sensor. In step 2986, the water feature control logic 72
determines whether the ambient noise is above a maximum setpoint.
If a positive determination is made in step 2986, then in step
2988, the water feature control logic 72 transmits instruction to
water feature valve actuator to decrease throughput (e.g., by 5%),
and the process reverts to step 2984. If a negative determination
is made in step 2986, then in step 2990, the water feature control
logic 72 transmits instruction to the water feature valve actuator
to increase throughput (e.g., by 5%), and the process reverts to
step 2984.
[0273] It is noted that the water feature control logic illustrated
in FIGS. 31A-31F and discussed above could be used to control a
pool/spa water feature that does not have on-board electronic
controls, such as, for example, a conventional water feature. In
such instances, control of the water feature could be implemented
by way of a valve actuator that has an associated processor and
network connectivity, such as the valve actuator discussed herein
in connection with FIGS. 28-29I. The valve actuator would be in
fluid communication with the water feature, and the control logic
discussed in connection with FIGS. 27A-27O would be applied to
control the valve actuator to correspondingly control operation of
the water feature.
[0274] FIG. 32 is a diagram 3000 illustrating another embodiment of
pool control logic 70. Pool control logic 70 could incorporate a
variety of types of data and/or data sources in addition to those
discussed hereinabove. More specifically, pool control logic 70
could process user input data 3002, operational data 3004,
equipment factory specifications 3006, equipment configuration
parameters 3008, web data 3010, pool configuration parameters 3012,
data from related devices 3014, health monitoring data 3016, and/or
external sensor data 3018.
[0275] User input data 3002, could include maximum sun exposure
(e.g., UV, intensity, etc.), minimum sun exposure, device operation
setpoints, preferred pool/spa area, contact means (e.g., SMS/text),
user profiles, zip code, maximum wind speed setpoint, lighting
programs, mode selection, override code, and desired actions (e.g.,
pump speed up, spa on, lights on, etc.). Operational data 3004
could include GPS coordinates, compass bearing, accelerometer
information, image data, IP address, timers, energy usage, and
video monitoring data. Equipment factory specifications 3006 could
include device maximum wind speed, device operation setpoints,
device power requirements, and device critical requirements (e.g.,
plumbing size, flow rate, clearance, etc.). Equipment configuration
parameters 3008 could include IP address, GPS coordinates, ZIP
code, time and date, lighting programs, etc. Web data 3010 could
include location (based on IP address), time & date, sun
position, maximum sun exposure, sunrise/sunset data, local lighting
code, regional & local weather, forecast data, wind speed and
direction, historic weather conditions, live weather maps, local
noise ordinance, local traffic conditions, local energy providers,
local energy costs, energy rebates and discounts, video monitoring
data, device/equipment information, etc. Pool configuration
parameters 3012 could include, pool surface area, pool geometry,
pool cover (e.g., yes, no), etc. Related devices/systems 3014 could
include smart devices, user interface devices, shading devices,
skimmers, pumps, water features, fire features, pool covers,
lighting systems, heaters or coolers, pool cleaners, sanitization
systems, chemical dispensing systems, alarm systems, garage doors,
interior (home) lights, maintenance system/application, etc. Health
monitoring data 3016 could include ambient temperature, water
temperature, wind speed, warranty countdown, maintenance schedule,
past equipment issues, service history, etc. External sensor data
3018 could include motion sensors (e.g., bather detection), ambient
temperature sensors, water temperature sensors, ambient noise
sensors, light sensors (home/interior), video (home/interior), bar
code scanners, etc. While it may be desirable for external sensors
to monitor/provide data on as many system parameters as possible
(thereby providing greater optimization, automation, and
user/operator comfort), it is contemplated that some systems need
not utilize an external sensor to monitor every system parameter.
For example, if a temperature sensor has not been installed in a
particular system, the user/operator can provide this information
by first determining the temperature (e.g., by checking a
thermometer, a thermocouple, a weather forecast, the internet,
etc.) and then entering the temperature into the system via a user
interface.
[0276] FIGS. 33A-33AH are flowcharts illustrating additional
processing steps of the pool control logic 70 carried out with
respect to related devices, systems, and applications. FIG. 33A is
a flowchart illustrating processing steps of the pool control logic
70 for determining locations of skimmers and/or the pool/spa to
account for wind, sun, or other external factors. In step 3100, the
pool control logic 70 transmits an instruction to the user to
traverse the perimeter of the pool while holding the smart device.
In step 3102, the pool control logic 70 receives positioning data
(e.g., GPS coordinates, compass bearing, etc.) from the smart
device as the user traverses the pool. In step 3104, the pool
control logic 70 transmits an instruction to the user to place the
smart device at a skimmer location. In step 3106, the pool control
logic 70 receives positioning data (e.g., GPS coordinates, compass
bearing, accelerometer information, etc.) from the smart device
placed at the skimmer location. Optionally, to enable higher
accuracy in locating the skimmer and/or pool/spa, in step 3108, the
pool control logic 70 transmits an instruction to the user to
photograph the skimmer and pool using the smart device and in step
3110, the pool control logic 70 receives image data from the smart
device. In step 3112, the pool control logic 70 determines the
location of the skimmer relative to the pool (e.g., using GPS,
compass, accelerometer information, and/or image data provided by
the smart device). In step 3114, pool control logic 70 saves the
location of the skimmer to memory for later retrieval, described
hereinbelow in connection with FIG. 33G. Optionally, in step 3116
pool control logic can also determine the location, geometry, and
orientation of the pool/spa (e.g., using GPS, compass,
accelerometer information, and/or image data from the smart device)
and in step 3118, pool control logic 70 could save the location,
geometry, and orientation of the pool/spa to memory for later
retrieval, described hereinbelow in connection with FIG. 33L.
[0277] FIG. 33B is a flowchart illustrating processing steps
carried out by the pool control logic 70 for estimating sun
exposure and alerting the user to the same. In step 3120, pool
control logic 70 transmits an instruction to the user to photograph
the pool/spa using a smart device. In step 3122, pool control logic
70 receives data from the smart device (e.g., GPS, compass, image,
date and time data, etc.). In step 3124, pool control logic 70
determines if additional photographs are needed (e.g., multiple
photographs could be taken at various times during the day). If a
positive determination is made, pool control logic 70 proceeds to
step 3126, where the logic is delayed for X seconds, wherein X is
any suitable integer (e.g., 5, 10, 3600, etc.), and the process
then reverts to step 3120. If a negative determination is made, the
process proceeds to step 3128, where pool control logic 70 receives
data on sun position (e.g., from sun tracking application or web
data) based on location data from the smart device. In step 3130,
pool control logic 70 receives current date and time data (e.g.,
from internal clock or as web data). In step 3132, pool control
logic estimates the current sun exposure (e.g., ultraviolet "UV"
index) based on location, image, sun position, and date and time
data. In step 3134, pool control logic 70 retrieves a maximum UV
exposure setpoint from the memory. The maximum UV exposure setpoint
could be provided by the user, or retrieved as web data provided by
a recognized health organization. In step 3136, pool control logic
70 determines if the current sun exposure is above the maximum UV
exposure setpoint. If a positive determination is made, the process
proceeds to step 3138, where pool control logic 70 transmits an
alert to the user (e.g., "Caution--High UV Index"). If a negative
determination is made, the process reverts to step 3130.
[0278] FIG. 33C is a flowchart illustrating processing steps
carried out by the pool control logic 70 for automatically
deploying shading devices (e.g., umbrellas, awnings, shades, etc.)
based on estimated sun exposure. In step 3140, pool control logic
70 transmits an instruction to the user to photograph the pool/spa
using a smart device. In step 3142, pool control logic 70 receives
data from the smart device (e.g., GPS, compass, image, date and
time data, etc.). In step 3144, pool control logic 70 determines if
additional photographs are needed (e.g., multiple photographs could
be taken at various times during the day). If a positive
determination is made, pool control logic 70 proceeds to step 3146,
where the logic is delayed for X seconds, wherein X is any suitable
integer (e.g., 5, 10, 3600, etc.), and the process then reverts to
step 3140. If a negative determination is made, the process
proceeds to step 3148, where pool control logic 70 receives data on
sun position (e.g., from sun tracking application or web data)
based on location data from the smart device. In step 3150, pool
control logic 70 receives current date and time data (e.g., from
internal clock or as web data). In step 3152, pool control logic 70
estimates the current sun exposure (e.g., ultraviolet "UV" index,
sun intensity, etc.) based on location, image, sun position, and
date and time data. In step 3154, pool control logic 70 retrieves a
shading device setpoint from the memory. The shading device
setpoint is a sun exposure value for triggering operation of the
shading devices, and could be provided by the user, as a
configuration parameter, or retrieved as web data. In step 3156,
pool control logic 70 determines if the current estimated sun
exposure is above the shading device setpoint. If a positive
determination is made, the process proceeds to step 3158, where
pool control logic 70 transmits an instruction to the shading
devices to deploy and then reverts to step 3150. If a negative
determination is made, the process proceeds to step 3160, where
pool control logic 70 determines if the shading devices are
deployed. If a negative determination is made, the process reverts
to step 3150. If a positive determination is made, the process
proceeds to step 3162, where pool control logic 70 transmits an
instruction to the shading devices to retract and then reverts to
step 3150.
[0279] FIG. 33D is a flowchart illustrating processing steps
carried out by the pool control logic 70 for notifying a user of
sun conditions at a preferred area of the pool (e.g., lounging
area). In step 3164, pool control logic 70 transmits an instruction
to the user to photograph the pool/spa using a smart device. In
step 3166, pool control logic 70 receives data from the smart
device (e.g., GPS, compass, image, date and time data, etc.). In
step 3168, pool control logic 70 determines if additional
photographs are needed (e.g., multiple photographs could be taken
at various times during the day). If a positive determination is
made, pool control logic 70 proceeds to step 3170, where the logic
is delayed for X seconds, wherein X is any suitable integer (e.g.,
5, 10, 3600, etc.), and the process then reverts to step 3164. If a
negative determination is made, the process proceeds to step 3172,
where pool control logic 70 receives data on sun position (e.g.,
from sun tracking application or web data) based on location data
from the smart device. In step 3174, pool control logic 70
retrieves location data of a preferred area of the pool from the
memory. The location data of the preferred area of the pool can be
obtained by way of a similar process, as described herein, in
connection with FIG. 33A (e.g., process for determining skimmer
location). In some embodiments, multiple users could specify one or
more preferred areas of the pool/spa area. In step 3176, the pool
control logic 70 receives current date and time data (e.g., from
internal clock, or as web data). In step 3178, pool control logic
70 estimates the current sun exposure at the preferred area (e.g.,
using GPS, compass, image, and sun positioning data). In step 3180,
pool control logic 70 retrieves a minimum sun exposure setpoint
(e.g., minimum UV index or sun intensity) from the memory. In step
3182, pool control logic 70 determines if the current estimated sun
exposure is above the minimum sun exposure setpoint. If a negative
determination is made, the process reverts to step 3176. If a
positive determination is made, the process proceeds to step 3184,
where pool control logic 70 transmits an alert to the user (e.g.,
"Lounge Area is Sunny"). In some embodiments, multiple users can
create profiles containing their preferred areas of the pool and a
means for receiving alerts. For example, a user could create a
profile with two preferred areas of the pool, name the preferred
areas of the pool (e.g., "lounge area," "spa area," etc.) and pool
control logic 70 could sent the user a SMS/text message when either
of the preferred areas are sunny. It is also noted that pool
control logic 70 could collect historical usage data for each user
and save the data (e.g., to the memory) to individual user profiles
for later retrieval and use.
[0280] FIG. 33E is a flowchart illustrating processing steps
carried out by the pool control logic 70 for planning the optimal
placement of a pool/spa prior to installation. In step 3186, pool
control logic 70 transmits an instruction to the user to photograph
a desired pool/spa location using a smart device. In step 3188,
pool control logic 70 receives desired location data from the smart
device (e.g., GPS coordinates, compass bearing, image data, etc.).
In step 3190, pool control logic 70 receives data on sun position
(e.g., data from sun tracking application or as web data), based on
the location data from the smart device. In step 3192, pool control
logic 70 determines the optimal location and orientation of the
pool/spa for ideal sun exposure (e.g., using GPS, compass, and
image data from smart device). Optionally, in step 3194, pool
control logic 70 receives data on historic weather conditions
(e.g., prevailing winds, speed, direction, etc.) based on the
location data from the smart device and in step 3196, pool control
logic 70 determines the optimal location of a skimmer (e.g., based
on historic wind conditions/direction). In step 3197, pool control
logic 70 transmits the optimized location and orientation data to
the user (e.g., in the form of architectural drawings, renderings,
etc.). In step 3198, pool control logic 70 saves the optimized
location data to the memory for later retrieval.
[0281] FIG. 33F is a flowchart illustrating processing steps
carried out by the pool control logic 70 for determining current
weather conditions. In step 3200, pool control logic 70 receives an
IP address from a smart device on a local network. In step 3202,
pool control logic 70 receives location data based on the IP
address (e.g., web data/geolocation provider). In step 3204, pool
control logic 70 receives web data on current weather conditions
(based on ZIP code, location/address, or GPS coordinates, discussed
hereinbelow). Current weather conditions can include, for example,
temperature, precipitation, wind speed, wind direction, etc. Web
data on current weather conditions could also include live 3.sup.rd
party data, for example, live weather maps of precipitation and
cloud cover. In step 3206, pool control logic 70 saves the current
weather conditions to the memory for later retrieval. In step 3208,
pool control logic 70 is delayed by X seconds, wherein X is any
suitable integer (e.g., 5, 10, 3600, etc.) and then the process
returns to step 3200. Optionally, in step 3210, pool control logic
70 could transmit an instruction to the user to enter a ZIP code
via a user interface device and in step 3212, pool control logic 70
could receive the ZIP code data from the user interface device. In
step 3214, pool control logic 70 could also/alternatively receive
GPS data from a smart device on the local network (e.g., smart
phone connected to home Wi-Fi.
[0282] FIG. 33G is a flowchart illustrating processing steps
carried out by the pool control logic 70 for selecting a skimmer
based on current weather conditions. In step 3216, pool control
logic 70 retrieves current weather conditions (e.g., wind
direction) data from the memory. The current weather conditions can
be obtained by way of the process described herein, in connection
with FIG. 33F. In step 3218, pool control logic 70 retrieves
skimmer location data from the memory. The skimmer location data
can be obtained by way of the process described herein, in
connection with FIG. 33A. In step 3220, pool control logic 70
determines if there are multiple skimmers. If a negative
determination is made, the process ends. If a positive
determination is made, the process proceeds to step 3222, where
pool control logic 70 determines the most downwind skimmer (using
the location data). In step 3224, pool control logic 70 transmits
an instruction to the most downwind skimmer to activate. Pool
control logic 70 could also sent an instruction to all other
skimmers to deactivate. The process then reverts to step 3216. In
some embodiments, pool control logic 70 could transmit an
instruction to increase the suction of an upwind skimmer to
compensate for the wind conditions or pool control logic 70 could
transmit an instruction to decrease the suction of a downwind
skimmer to compensate for the increased debris flowing therethrough
due to the wind condition. In further embodiments, pool control
logic 70 could transmit an instruction to alter the skimmer suction
relative to main drain suction.
[0283] FIG. 33H is a flowchart illustrating processing steps
carried out by the pool control logic 70 for automated operation of
pool devices based on current weather conditions. In step 3226,
pool control logic 70 retrieves current weather conditions (e.g.,
wind speed, up-wind debris source direction) data from the memory.
The current weather conditions can be obtained by way of the
process described herein, in connection with FIG. 33F. In step
3228, pool control logic 70 retrieves maximum wind speed setpoint
data from memory. In step 3230, pool control logic 70 determines if
the current wind speed is above the maximum wind speed setpoint. If
a positive determination is made, the process proceeds to step
3238, where pool control logic 70 transmits an instruction to the
pump to increase circulation. Optionally, in step 3240, pool
control logic 70 could transmit an instruction to deactivate or
reduce water features (e.g., fountains). Optionally, in step 3242,
pool control logic 70 could transmit an instruction to deactivate
or reduce fire features. Optionally, in step 3224, pool control
logic 70 could transmit an instruction to retract shading devices
(e.g., umbrellas, awnings, shades, etc.). Alternatively, in the
event of pool devices that are not capable of being
automated/receiving control signals/are not connected to the system
10, in step 3246, pool control logic 70 could transmit a message to
the user (e.g., "Caution--High Winds"). The process then reverts to
step 3226. If a negative determination is made in step 3230, the
process proceeds to step 3232, where pool control logic 70
determines if the operation of any pool devices has been altered
due to the weather condition (e.g., high winds). If a negative
determination is made, the process reverts to step 3226. If a
positive determination is made, the process proceeds to step 3234,
where pool control logic 70 transmits an instruction to revert to
regular operation of the pool device(s). Optionally, in step 3236,
pool control logic 70 could transmit a message to the user (e.g.,
"Wind Has Subsided"). The process then reverts to step 3226. The
above process can also be used to configure the skimmer locations
with respect to the up-wind debris direction.
[0284] FIG. 33I is a flowchart illustrating processing steps
carried out by the pool control logic 70 for automated operation of
a pool cover based on current weather conditions. In step 3248,
pool control logic 70 retrieves current weather conditions (e.g.,
wind speed) data from the memory. The current weather conditions
can be obtained by way of the process described herein, in
connection with FIG. 33F. In step 3250, pool control logic 70
retrieves maximum wind speed setpoint data from memory. In step
3252, pool control logic 70 determines if the current wind speed is
above the maximum wind speed setpoint. If a positive determination
is made, the process proceeds to step 3260, where pool control
logic 70 receives operational data from a pool motion sensor (e.g.,
bather detection, as described hereinabove). In step 3262, pool
control logic 70 determines if an active bather has been detected.
If a positive determination is made, the process could optionally
proceed to step 3264, where pool control logic 70 transmits an
instruction to the lighting system to display a weather alert
program (e.g., flashing white lights) and the process then reverts
to step 3248. If a negative determination is made, the process
proceeds to step 3266, where pool control logic 70 transmits an
instruction to close the pool cover (e.g., 90% closed, allowing for
safety egress). If a negative determination is made in step 3252,
the process proceeds to step 3254, where pool control logic 70
determines if the operation of any pool devices (e.g., pool cover,
lighting system) has been altered due to the weather condition
(e.g., high winds). If a negative determination is made, the
process reverts to step 3248. If a positive determination is made,
the process proceeds to step 3256, where pool control logic 70
transmits an instruction to revert to regular operation of the pool
device(s). Optionally, in step 3258, pool control logic 70 could
transmit a message to the user (e.g., "Wind Has Subsided"). The
process then reverts to step 3248.
[0285] FIG. 33J is a flowchart illustrating processing steps
carried out by the pool control logic 70 for compensating heat loss
due to current weather conditions. In step 3268, pool control logic
70 retrieves current weather conditions (e.g., wind speed) data
from the memory. The current weather conditions can be obtained by
way of the process described herein, in connection with FIG. 33F.
In step 3270, pool control logic 70 retrieves maximum wind speed
setpoint data from memory. In step 3272, pool control logic 70
determines if the current wind speed is above the maximum wind
speed setpoint. If a positive determination is made, the process
proceeds to step 3280, where pool control logic 70 retrieves pool
configuration parameters from memory (e.g., pool surface area,
geometry, volume, etc.). In step 3282, pool control logic 70
receives data on the ambient temperature (e.g., from sensor or web
data). In step 3284, pool control logic 70 receives operational
data on water temperature (e.g., from sensor). In step 3286, pool
control logic 70 determines heat loss due to the current weather
condition (e.g., prevailing winds). In step 3288, pool control
logic 70 transmits an instruction to the heater to increase output
(e.g., compensating for the heat loss) and the process reverts to
step 3268. If a negative determination is made in step 3272, the
process proceeds to step 3274, where pool control logic 70
determines if the operation of any pool devices (e.g., heater) has
been altered due to the weather condition (e.g., high winds). If a
negative determination is made, the process reverts to step 3268.
If a positive determination is made, the process proceeds to step
3276, where pool control logic 70 transmits an instruction to
revert to regular operation of the pool device(s). Optionally, in
step 3278, pool control logic 70 could transmit a message to the
user (e.g., "Wind Has Subsided"). The process then reverts to step
3268.
[0286] FIG. 33K is a flowchart illustrating processing steps
carried out by the pool control logic 70 for determining if a
freeze risk exists and if so, taking appropriate action. In step
3290, pool control logic 70 retrieves current weather conditions
(e.g., wind speed) data from the memory. The current weather
conditions can be obtained by way of the process described herein,
in connection with FIG. 33F. In step 3292, pool control logic 70
retrieves maximum wind speed setpoint data from memory. In step
3294, pool control logic 70 determines if the current wind speed is
above the maximum wind speed setpoint. If a positive determination
is made, the process proceeds to step 3302, where pool control
logic 70 receives data on the ambient temperature (e.g., from
sensor or web data). In step 3304, pool control logic 70 determines
heat loss due to the current weather condition (e.g., prevailing
winds). Heat loss due to the weather conditions (e.g., wind) can be
obtained by way of the process described herein, in connection with
FIG. 33J. In step 3306, pool control logic 70 determines if a
freeze risk exists (e.g., due to ambient temperature, heat loss,
wind chill, etc.). If a negative determination is made, the process
reverts to step 3290. If a positive determination is made, the
process proceeds to step 3308, where pool control logic 70
transmits an instruction to the pump to increase speed. Optionally,
in step 3310, pool control logic 70 could transmit an instruction
to the heater to increase output, in step 3312, pool control logic
70 could transmit an instruction to the lighting system to display
a freeze risk program (e.g., flashing blue lights), and in step
3314, pool control logic 70 could transmit a message to the user
(e.g., "Freeze Risk"). The process then reverts to step 3290. If a
negative determination is made in step 3294, the process proceeds
to step 3296, where pool control logic 70 determines if the
operation of any pool devices (e.g., pump, heater, lighting system,
etc.) has been altered due to the weather condition (e.g., high
winds). If a negative determination is made, the process reverts to
step 3290. If a positive determination is made, the process
proceeds to step 3298, where pool control logic 70 transmits an
instruction to revert to regular operation of the pool device(s).
Optionally, in step 3300, pool control logic 70 could transmit a
message to the user (e.g., "Wind Has Subsided"). The process then
reverts to step 3290.
[0287] FIG. 33L is a flowchart illustrating processing steps
carried out by the pool control logic 70 for cleaning a pool/spa in
response to a weather condition (e.g., high winds). In step 3316,
pool control logic 70 retrieves current weather conditions (e.g.,
wind speed, direction) data from the memory. The current weather
conditions can be obtained by way of the process described herein,
in connection with FIG. 33F. In step 3318, pool control logic 70
retrieves maximum wind speed setpoint data from memory. In step
3320, pool control logic 70 determines if the current wind speed is
above the maximum wind speed setpoint. If a positive determination
is made, the process proceeds to step 3328, where pool control
logic 70 retrieves pool geometry and orientation data from the
memory. The pool geometry and orientation data can be obtained by
way of the process described herein, in connection with FIG. 33A.
In step 3330, pool control logic 70 determines the downwind area of
the pool/spa. In step 3332, pool control logic 70 transmits an
instruction to a pool cleaner to traverse the downwind area of the
pool and the process then reverts to step 3316. If a negative
determination is made in step 3320, the process proceeds to step
3322, where pool control logic 70 determines if the operation of
any pool devices (e.g., pool cleaner) has been altered due to the
weather condition (e.g., high winds). If a negative determination
is made, the process reverts to step 3316. If a positive
determination is made, the process proceeds to step 3324, where
pool control logic 70 transmits an instruction to revert to regular
operation of the pool device(s). Optionally, in step 3326, pool
control logic 70 could transmit a message to the user (e.g., "Wind
Has Subsided"). The process then reverts to step 3316.
[0288] FIG. 33M is a flowchart illustrating processing steps
carried out by the pool control logic 70 for sanitizing a pool/spa
in response to a weather condition (e.g., high winds). In step
3334, pool control logic 70 retrieves current weather conditions
(e.g., wind speed) data from the memory. The current weather
conditions can be obtained by way of the process described herein,
in connection with FIG. 33F. In step 3336, pool control logic 70
retrieves maximum wind speed setpoint data from memory. In step
3338, pool control logic 70 determines if the current wind speed is
above the maximum wind speed setpoint. If a positive determination
is made, the process proceeds to step 3346, where pool control
logic 70 retrieves pool configuration parameters (e.g., pool
surface area, geometry, volume, etc.) from the memory. In step
3348, pool control logic 70 determines the increased sanitization
needs of the pool due to the weather condition (e.g., high winds
causing increased debris in pool). In step 3350, pool control logic
70 transmits an instruction to a sanitization system to increase
operation by the determined amount and the process then reverts to
step 3334. If a negative determination is made in step 3338, the
process proceeds to step 3340, where pool control logic 70
determines if the operation of any pool devices (e.g., sanitization
system) has been altered due to the weather condition (e.g., high
winds). If a negative determination is made, the process reverts to
step 3334. If a positive determination is made, the process
proceeds to step 3342, where pool control logic 70 transmits an
instruction to revert to regular operation of the pool device(s).
Optionally, in step 3344, pool control logic 70 could transmit a
message to the user (e.g., "Wind Has Subsided"). The process then
reverts to step 3334.
[0289] FIG. 33N is a flowchart illustrating processing steps
carried out by the pool control logic 70 for operating pool devices
based on timers triggered by sunrise/sunset times. In step 3352,
pool control logic 70 receives an IP address from a smart device on
a local network. In step 3354, pool control logic 70 receives
location data based on the IP address (e.g., web data/geolocation
provider). In step 3356, pool control logic 70 receives web data on
sunrise/sunset times (based on ZIP code, location/address, or GPS
coordinates, discussed hereinbelow). In step 3358, pool control
logic 70 receives time and date data (e.g., via an internal clock
or as web data). In step 3360, pool control logic 70 determines if
the current time is the sunrise or sunset time. If a negative
determination is made, the process reverts to step 3358. If a
positive determination is made, the process proceeds to step 3362,
where pool control logic 70 begins a timer for X seconds, wherein X
is any suitable integer (e.g., 5, 10, 3600, etc.). In step 3364,
pool control logic 70 transmits an instruction to a pool device to
activate/alter operation. For example, pool control logic 70 could
transmit an instruction to the pump 14a to increase speed upon
sunrise, for a specified duration of time, or pool control logic 70
could transmit an instruction to display a countdown to sundown. In
step 3366, pool control logic 70 determines if the timer has
reached zero (0) seconds. If a negative determination is made, the
process repeats step 3366. If a positive determination is made, the
process proceeds to step 3368, where pool control logic 70
transmits an instruction to the pool device to deactivate/resume
normal operation. The process then reverts to step 3352.
Optionally, in step 3370, pool control logic 70 could transmit an
instruction to the user to enter a ZIP code via a user interface
device and in step 3372, pool control logic 70 could receive the
ZIP code data from the user interface device and then the process
could proceed to step 3356. In step 3374, pool control logic 70
could also/alternatively receive GPS data from a smart device on
the local network (e.g., smart phone connected to home Wi-Fi) and
then the process could proceed to step 3356.
[0290] FIG. 33O is a flowchart illustrating processing steps
carried out by the pool control logic 70 for operating pool devices
based on sunrise/sunset times (e.g., activate at sunrise,
deactivate at sunset). For example, the pool control logic 70 could
transmit an instruction to the pump 14a to increase speed upon
sunrise and decrease speed upon sunset, the pool control logic 70
could transmit an instruction to increase the filtration rate or
hours based on sunlight hours, or the pool control logic 70 could
transmit an instruction to the lighting system 14h to activate upon
sundown and deactivate upon sunrise. In step 3376, pool control
logic 70 receives an IP address from a smart device on a local
network. In step 3378, pool control logic 70 receives location data
based on the IP address (e.g., web data/geolocation provider). In
step 3380, pool control logic 70 receives web data on
sunrise/sunset times (based on ZIP code, location/address, or GPS
coordinates, discussed hereinbelow). In step 3382, pool control
logic 70 receives time and date data (e.g., via an internal clock
or as web data). In step 3384, pool control logic 70 determines if
the current time is the sunrise or sunset time. If a negative
determination is made, the process reverts to step 3382. If a
positive determination is made, the process proceeds to step 3386,
where pool control logic 70 transmits an instruction to a pool
device to activate/alter operation. In step 3388, pool control
logic 70 receives time and date data (e.g., via an internal clock
or as web data). In step 3390, pool control logic 70 determines if
the current time is the sunrise or sunset time. If a negative
determination is made, the process reverts to step 3388. If a
positive determination is made, the process proceeds to step 3392,
where pool control logic 70 transmits an instruction to the pool
device to deactivate/resume normal operation. The process then
reverts to step 3376. Optionally, in step 3394, pool control logic
70 could transmit an instruction to the user to enter a ZIP code
via a user interface device and in step 3396, pool control logic 70
could receive the ZIP code data from the user interface device and
then the process could proceed to step 3380. In step 3398, pool
control logic 70 could also/alternatively receive GPS data from a
smart device on the local network (e.g., smart phone connected to
home Wi-Fi) and then the process could proceed to step 3380.
[0291] FIG. 33P is a flowchart illustrating processing steps
carried out by the pool control logic 70 for operating pool devices
at different setpoints during the daytime and evening. For example,
pool control logic 70 could operate a sanitization system at a
first setpoint during the daytime and operate at a second setpoint
during the evening. In step 3400, pool control logic 70 receives
web data on sunrise/sunset times. The web data on sunrise/sunset
times can be obtained by way of the process described herein, in
connection with FIG. 33N. In step 3402, pool control logic 70
receives time and date data (e.g., via an internal clock or as web
data). In step 3404, pool control logic 70 determines if the
current time is the sunrise or sunset time. If a negative
determination is made, the process reverts to step 3402. If a
positive determination is made, the process proceeds to step 3406,
where pool control logic 70 retrieves setpoint data for a daylight
sanitization rate from the memory. In step 3408, pool control logic
70 transmits an instruction to a sanitization system to operate at
the daylight sanitization rate. In step 3410, pool control logic 70
receives time and date data (e.g., via an internal clock or as web
data). In step 3412, pool control logic 70 determines if the
current time is the sunrise or sunset time. If a negative
determination is made, the process reverts to step 3410. If a
positive determination is made, the process proceeds to step 3414,
where pool control logic 70 retrieves setpoint data on an evening
sanitization rate from the memory. In step 3416, pool control logic
70 transmits an instruction to the sanitization system to operate
at the evening sanitization rate. The process then reverts to step
3400.
[0292] FIG. 33Q is a flowchart illustrating processing steps
carried out by the pool control logic 70 for operating a
sanitization system based on the current weather conditions. In
step 3418, pool control logic 70 retrieves current weather
conditions data from the memory. Current weather conditions data
can be obtained by way of the process described herein, in
connection with FIG. 33F. Current weather conditions could include
air temperature, humidity, heat/cold index, wind-chill, etc.
Optionally, in step 3426, pool control logic 70 could receive water
temperature operational data from a sensor. In step 3420, pool
control logic 70 retrieves pool configuration parameters from the
memory. In step 3422, pool control logic 70 determines the
sanitization rate based on the current weather conditions. While
the sanitization rate could be determined based on the current
weather conditions, other chemical dispensing and/or production
rates could be determined as well. Optionally, in step 3428, pool
control logic 70 could determine the sanitization rate based on the
water temperature. In step 3424, pool control logic 70 transmits an
instruction to the sanitization system to operate at the determined
rate. The process then reverts to step 3418.
[0293] FIG. 33R is a flowchart illustrating processing steps
carried out by the pool control logic 70 for operating the system
10 based on maximum ambient noise. In step 3430, pool control logic
70 receives web data on the local noise ordinance (e.g., maximum
decibels at specified times allowed by code). The web data on the
local noise ordinance can be obtained by way of a similar process
as described herein, in connection with FIG. 33N (e.g., by
determining the location of the system 10 and then receiving web
data based on that location). In step 3432, pool control logic 70
receives time and date data (e.g., internal clock or web data). In
step 3434, pool control logic 70 receives operational data from an
ambient noise sensor. In step 3436 pool control logic 70 determines
if the current ambient noise is above the maximum ambient noise
(set by ordinance) at the current time. If a negative determination
is made, the process reverts to step 3432. If a positive
determination is made, the process proceeds to step 3438, where
pool control logic 70 transmits an instruction to a pool device
(e.g., water feature, pump, heater, blower, etc.) to reduce
operation by X %, wherein X is any suitable integer between one (1)
and one hundred (100) (e.g., 1, 2, 5, 10, etc.). The process then
reverts to step 3432. The above process can apply based on
geo-positioning data.
[0294] FIG. 33S is a flowchart illustrating processing steps
carried out by the pool control logic 70 for compensating for
ambient noise. In step 3440, pool control logic 70 receives web
data (e.g., Google maps) on local traffic conditions (e.g.,
number/density/speed of vehicles surrounding current location). The
web data on the local traffic conditions can be obtained by way of
a similar process as described herein, in connection with FIG. 33N
(e.g., by determining the location of the system 10 and then
receiving web data based on that location). In step 3442, pool
control logic 70 determines/estimates the noise intensity of the
local traffic. Optionally, in step 3452, pool control logic 70
could receive operational data from an ambient noise sensor that is
positioned to sense the noise produced by the local traffic. In
step 3444, pool control logic 70 determines the intensity of white
noise needed to compensate for the noise intensity of the local
traffic. In step 3446, pool control logic 70 transmits an
instruction to a pool device (e.g., water feature or other device
capable of producing white noise) to increase output by X %,
wherein X is any suitable integer (e.g., 5, 10, 50, etc.). In step
3448, pool control logic 70 receives operational data from an
ambient noise sensor (e.g., white noise sensor). In step 3450, pool
control logic 70 determines if the white noise being produced is
sufficient to compensate for the noise being produced by the local
traffic. If a negative determination is made, the process reverts
to step 3446. If a positive determination is made, the process
reverts to step 3440.
[0295] FIG. 33T is a flowchart illustrating processing steps
carried out by the pool control logic 70 for determining the local
cost of energy. In step 3454, pool control logic 70 receives an IP
address from a smart device on a local network. In step 3456, pool
control logic 70 receives location data based on the IP address
(e.g., web data/geolocation provider). In step 3458, pool control
logic 70 receives web data (e.g., a listing) of local energy
providers (based on ZIP code, location/address, or GPS coordinates,
discussed hereinbelow). In step 3460, pool control logic 70
transmits an instruction to the user to select their local energy
provider (e.g., from a list of local energy providers). The local
energy providers/vendors can also be determined by way of the user
entering, scanning, or selecting the vendor from a drop-down menu.
In step 3462, pool control logic 70 receives web data on local
energy cost (e.g., as provided by the selected energy vendor). The
local energy costs could include both current energy costs and/or
forecasted energy costs. Optionally, in step 3474, pool control
logic 70 could transmit a rebate/discount message to the user
(e.g., government and/or power company energy and/or energy-based
equipment rebates and discounts). In step 3464, pool control logic
70 saves the local energy cost data to the memory for later
retrieval. In step 3466, pool control logic 70 is delayed for X
seconds, wherein X is any suitable integer (e.g., 5, 10, 3600,
etc.) and the process then reverts to step 3454. Optionally, in
step 3468, pool control logic 70 could transmit an instruction to
the user to enter a ZIP code via a user interface device and in
step 3470, pool control logic 70 could receive the ZIP code data
from the user interface device and then the process could proceed
to step 3458. In step 3472, pool control logic 70 could
also/alternatively receive GPS data from a smart device on the
local network (e.g., smart phone connected to home Wi-Fi) and then
the process could proceed to step 3458.
[0296] FIG. 33U is a flowchart illustrating processing steps
carried out by the pool control logic 70 for informing the user of
the cost of a desired action. In step 3476, pool control logic 70
retrieves local energy cost data from the memory. The web data on
the local energy costs can be obtained by way of the process as
described herein, in connection with FIG. 33T (e.g., by determining
the location of the system 10 and then receiving web data based on
that location). In step 3478, pool control logic 70 receives user
input on a desired action (e.g., pump speed up, spa on, lights on,
etc.). The desired action could also include bringing a pool
feature to a desired state, over time (e.g., bringing the pool
water temperature to 80 degrees Fahrenheit by Friday at 5:00 pm and
maintaining the temperature for a specified duration of time). In
step 3480, pool control logic 70 determines the predicted cost of
the desired action. In step 3482, pool control logic 70 transmits a
message to the user (e.g., cost per minute, hour, day, etc.).
[0297] FIG. 33V is a flowchart illustrating processing steps
carried out by the pool control logic 70 for optimizing the
operation of pool devices based on energy cost (peak and off-peak
hours). In step 3484, pool control logic 70 retrieves local energy
cost data from the memory (e.g., peak/off-peak cost of
electricity). The web data on the local energy costs can be
obtained by way of the process as described herein, in connection
with FIG. 33T (e.g., by determining the location of the system 10
and then receiving web data based on that location). In step 3486,
pool control logic 70 receives user input on pool device operating
schedules (e.g., filtering, pool cleaning, etc.). In step 3488,
pool control logic 70 determines an optimized schedule for the
lowest energy cost. For example, normal filtering and pool cleaner
operation cycles could be adjusted based on the lowest cost of
energy during off-peak hours. In step 3490, pool control logic 70
transmits an instruction to the pool devices to operate according
to the optimized schedule. In addition, energy-based commands could
be capable of auto-overriding other system commands, and
vice-versa, based on weather/environmental demands (e.g., optimized
energy settings vs. weather vs. basic pool requirements--clean,
sanitized, etc.). The process then returns to step 3484.
[0298] FIG. 33W is a flowchart illustrating processing steps
carried out by the pool control logic 70 for warning the user of
pool device operation during peak energy cost hours. In step 3492,
pool control logic 70 retrieves local energy cost data from the
memory (e.g., peak/off-peak cost of electricity). The web data on
the local energy costs can be obtained by way of the process as
described herein, in connection with FIG. 33T (e.g., by determining
the location of the system 10 and then receiving web data based on
that location). In step 3494, pool control logic 70 retrieves user
input on a desired action (e.g., pump speed up, spa on, lights on,
etc.). In step 3496, pool control logic 70 receives time and date
data (e.g., internal clock, or as web data). In step 3498, pool
control logic 70 determines whether the current time corresponds to
peak hours for electricity costs. If a positive determination is
made, the process proceeds to step 3500, where pool control logic
70 transmits a message to the user (e.g., "Warning--Peak hours. Do
you wish to proceed?"). In step 3502, pool control logic 70
receives user input (e.g., yes/no). In step 3504, pool control
logic 70 determines if the user wishes to proceed with the desired
action. If a negative determination is made, the process ends. If a
positive determination is made, the process proceeds to step 3506,
where pool control logic 70 transmits an instruction to the pool
device to perform the desired action (e.g., pump speed up, spa on,
lights on, etc.) and the process ends. If a negative determination
is made at step 3498, the process proceeds to step 3506.
[0299] FIG. 33X is a flowchart illustrating processing steps
carried out by the pool control logic 70 for preventing use of the
system 10 during peak electrical cost hours. In step 3508, pool
control logic 70 retrieves local energy cost data from the memory
(e.g., peak/off-peak cost of electricity). The web data on the
local energy costs can be obtained by way of the process as
described herein, in connection with FIG. 33T (e.g., by determining
the location of the system 10 and then receiving web data based on
that location). In step 3510, pool control logic 70 retrieves user
input on a desired action (e.g., pump speed up, spa on, lights on,
etc.). In step 3512, pool control logic 70 receives time and date
data (e.g., internal clock, or as web data). In step 3514, pool
control logic 70 determines if it is currently peak hours for
electricity costs. If a positive determination is made, the process
proceeds to step 3516, where pool control logic 70 transmits a
message to the user (e.g., "Warning--Peak hours. Please enter
Priority User override code."). In step 3518, pool control logic 70
receives user input (e.g., Priority User override code). In step
3520, pool control logic 70 determines if the Priority User
override code is correct. If a positive determination is made, the
process proceeds to step 3522, where pool control logic 70
transmits an instruction to the pool device to perform the desired
action (e.g., pump speed up, spa on, lights on, etc.) and the
process ends. If a negative determination is made, the process
proceeds to step 3524, where pool control logic 70 determines if
there are retries remaining (e.g., remaining attempts to enter the
correct code). If a negative determination is made at step 3524,
the process ends. If a positive determination is made at step 3524,
the process reverts to step 3518. If a negative determination is
made at step 3514, the process proceeds to step 3522.
[0300] FIG. 33Y is a flowchart illustrating processing steps
carried out by the pool control logic 70 for deactivating
high-powered systems/devices/components to reduce electrical costs.
In step 3526, pool control logic 70 receives an instruction to
activate "Energy Save Mode." In step 3528, pool control logic 70
identifies high-powered lighting devices in the lighting system.
The high-powered lighting devices could be identified at the time
of installation (e.g., manually or scanned) or by pool control
logic 70 (e.g., macro or sensed). In step 3530, pool control logic
70 transmits an instruction to the high-powered lighting to
deactivate (e.g., deactivate non-LED lighting devices). While the
"Energy Save Mode" has been described herein in connection with
lighting devices, "Energy Save Mode" could also identify and
deactivate any device using an amount power that exceeds a
predefined setpoint. Additionally, pool control logic 70 could
transmit an instruction to a device to reduce operation until the
device is only consuming power at low, predefined setpoint. In
addition to the examples discussed hereinabove, in connection with
FIGS. 33T-33Y, web data (e.g., 3rd party Web advised conditions,
energy cost, weather, environmental, etc.) could be used to
prompt/trigger pool control logic 70 (e.g., pump control, valve
control, lighting control, cleaner control, etc.) to adjust speed,
flow, position, mode, performance, behavior, etc. of any piece of
pool equipment or feature, or any other device in communication
with the system 10, to reduce energy costs, or to return to a
previous state.
[0301] The system of the present disclosure also provides systems
for leveraging synergies between the pool control logic 70 and
other applications (e.g., connecting to and/or communicating with a
common application and sharing a user interface, advising the user
of various alerts/conditions, controlling pool functions and/or
devices, reaction or synchronization to/with external devices
connected through the cloud, etc.). For example, FIG. 33Z is a
flowchart illustrating processing steps carried out by the pool
control logic 70 for alerting the user to pool/spa area ingress and
egress. In step 3532, pool control logic 70 receives live or
historical video of the pool/yard (e.g., from 3.sup.rd party
application/source). In step 3534, pool control logic 70 analyzes
the video of the pool/yard for occupant ingress/egress. In step
3536, pool control logic 70 determines if there has been an
ingress/egress (e.g., unwanted intrusion, monitoring the
whereabouts of children, etc.) in connection with a body of water.
If a negative determination is made, the process reverts to step
3532. If a positive determination is made, the process proceeds to
step 3538, where pool control logic 70 transmits a message to the
user (e.g., "Alert--pool ingress/egress"). The process then reverts
to step 3532. Optionally, in step 3540, pool control logic 70 could
transmit instructions to an alarm system to activate (e.g.,
3.sup.rd party alarm system/security provider) and then revert to
step 3532. The pool control logic 70 could also communicate with
3rd party security systems (e.g., front-door systems with video,
audio, door unlock/lock, etc.) and in-home lighting systems and
receive data from 3rd party live satellite image/video feeds.
[0302] FIG. 33AA is a flowchart illustrating processing steps
carried out by the pool control logic 70 for leveraging video data
from a 3.sup.rd party to maintain the cleanliness of a pool/spa. In
step 3542, pool control logic 70 receives live or historical video
of the pool/yard (e.g., from 3.sup.rd party application/source). In
step 3544, pool control logic 70 analyzes the video of the
pool/yard for debris (e.g., presence of debris in pool, debris
movement in pool, debris concentration in pool, etc.). In step
3546, pool control logic 70 determines if there is debris in the
pool. If a negative determination is made, the process reverts to
step 3542. If a positive determination is made, the process
proceeds to step 3548, where pool control logic 70 transmits an
instruction to a pool device to activate (e.g., cleaner, skimmer,
filter, etc.). The process then reverts to step 3542. Optionally,
in step 3550, pool control logic 70 could transmit an instruction
to a pool cleaner to traverse the area of the pool having the
highest concentration of debris, and then revert to step 3542.
[0303] FIG. 33AB is a flowchart illustrating processing steps
carried out by the pool control logic 70 for operation of the
lighting system 14h based on operational data from an external
source. In step 3552, pool control logic 70 receives operational
data from an external source (e.g., a signal that the garage door
is opening). Optionally, in step 3562, pool control logic 70 could
receive operational data from another external device (e.g., a
signal that the indoor lighting devices are turned on). In step
3554, pool control logic 70 receives web data on sunrise/sunset
times (e.g., based on ZIP code, address, or GPS coordinates). The
web data on the sunrise/sunset times can be obtained by way of the
process as described herein, in connection with FIG. 33N (e.g., by
determining the location of the system 10 and then receiving web
data based on that location). In step 3556, pool control logic 70
receives current time and date data (e.g., from an internal clock,
or as web data). In step 3558, pool control logic 70 determines if
the current time is after sunset. If a negative determination is
made, the process reverts to step 3552. If a positive determination
is made, the process proceeds to step 3560, where pool control
logic 70 transmits an instruction to the lighting system to
activate (e.g., a selection, pool zone, yard zone, or all outdoor
lights). The process then reverts to step 3552. In addition to the
foregoing, pool control logic 70 could also synchronize/trigger the
outdoor/pool lighting system to an "all on" command for the indoor
lights. This is particularly useful for emergency lighting
scenarios. For example, the indoor lights could receive an "all on"
command in response to a triggered smoke detector and pool control
logic 70 could transmit an instruction to the lighting system 14h
to activate all lights at maximum intensity. Pool control logic 70
could determine that an "all on" command has been sent to the
indoor lights directly, by receiving the same command (e.g., direct
communication or network communication between the indoor lights
and/or smoke detector and pool control logic 70), or indirectly, by
monitoring the indoor lighting and/or smoke detector (e.g., light
sensors or video monitoring for the indoor lighting, noise sensor
for the smoke detector, etc.).
[0304] FIG. 33AC is a flowchart illustrating processing steps
carried out by the pool control logic 70 for matching or
synchronizing the operation of the lighting system 14h to interior
mood lighting in a home. In step 3564, pool control logic 70
receives operational data from an external device (e.g., mood/color
lighting selected in a home). Alternatively, pool control logic 70
could receive operational data from a sensor positioned for sensing
the lighting conditions (e.g., intensity or color) in the home, or
pool control logic 70 could receive operational data from a third
party application or video feed showing the lighting conditions in
the house. In step 3566, pool control logic 70 determines the RGB
color spectrum of the mood lighting. In step 3568, pool control
logic 70 transmits an instruction to the lighting system to operate
the lights at the determined RGB color spectrum (e.g., matching the
mood lighting to a selection, pool zone, yard zone, or all outdoor
lights).
[0305] FIG. 33AD is a flowchart illustrating processing steps
carried out by the pool control logic 70 for communicating with a
smart device in the possession of a servicer/installer. In step
3570 the smart device scans an equipment bar code (e.g., at time of
service, installation, etc.). Optionally, in step 3585, pool
control logic 70 could receive the equipment bar code data scanned
by the smart device. In step 3572, the smart device identifies the
location of the scanned equipment (e.g., via GPS, geo-positioning
application, etc.). In step 3574, the smart device transmits the
location of the equipment and the date of service/installation to
the cloud. For example, the location of the equipment and date of
service/installation could be used for warranty registration, as
well as other purposes, as described hereinbelow. The cloud could
be accessed by pool control logic 70, or a third party system
(e.g., smart device/maintenance system used by servicer/installer).
Optionally, in step 3582, pool control logic 70 could save the
location of the equipment and the date of service/installation to
the memory for later retrieval. In step 3576, pool control logic 70
receives information on existing equipment installed at the same
location/site (e.g., from the cloud or from the memory). In step
3578, pool control logic 70 determines if it is at or near time to
service/replace any of the existing installed equipment. If a
positive determination is made, the process proceeds to step 3580,
where pool control logic 70 transmits a notification to the
servicer/installer (e.g., "Device due for maintenance in X days")
and the process ends. Optionally, if a positive determination is
made in step 3578, the process could proceed to step 3584, where
pool control logic 70 transmits information to the
servicer/installer regarding past issues with the equipment at the
location/site and the process ends. If a negative determination is
made in step 3578, the process ends. This service information could
also be accessed through the cloud and viewed by the
servicer/installer, original equipment manufacturer, or authorized
service center. The service information could also be provided to
the servicer/installer before arrival at the site through a smart
device and/or application utilizing geo-fencing and global
positioning systems (e.g., a geo-fence is placed around the site
and the service information is provided to the servicer/installer
upon crossing the geo-fence threshold), discussed hereinbelow.
[0306] FIG. 33AE is a flowchart illustrating processing steps
carried out by the pool control logic 70 for communicating with an
application used by a servicer/installer. In step 3586, a smart
device scans an equipment bar code (e.g., at the time of service,
installation, etc.). Optionally, in step 3606, pool control logic
70 could receive the equipment bar code data scanned by the smart
device. In step 3588, an application on the smart device receives
equipment information (e.g., web data from the equipment
manufacturer). In step 3590, the application displays critical
equipment requirements (e.g., plumbing size, flow, clearance,
etc.). In step 3592, the application receives information on
existing equipment at the same location/site (e.g., from the cloud
or from memory). The application can receive information on
existing equipment by way of a similar process as to that described
herein, in connection with FIG. 33AD. Alternatively, in addition to
scanning the equipment being scanned/installed, any preexisting
equipment could be scanned, and data on the preexisting equipment
could be received from the cloud or from memory. In step 3594, the
application analyzes the information for any potential adverse
interactions with other equipment installed at the same
location/site. In step 3596, the application determines if there
are any potential adverse interactions. If a positive determination
is made, the process proceeds to step 3598, where the application
displays a notification to the servicer/installer (e.g.,
"Caution--incompatible equipment"). If a negative determination is
made, the process proceeds to step 3600, where the application
receives known pool parameters (e.g., location, regional
weather/environmental conditions, pool geometry, connected pool
devices, energy costs, user preferences, etc.). In step 3602, the
application determines optimal settings for the newly
serviced/installed equipment. The application can recommend
programming based on regional preferences, including seasonal
programming (summer, winter, etc.). Further, the application can
estimate energy costs based on location weather data and other
locational factors. The price estimation can take into account
local currency. In step 3604, the application displays the optimal
settings for the newly serviced/installed equipment. While the
process described hereinabove, in connection with FIG. 33AE, makes
reference to an application that could be used by a
servicer/installer, pool control logic 70 could also accomplish
these same steps.
[0307] It is noted that global positioning and geo-fencing systems
could be utilized with the systems of the present disclosure to
provide a servicer with service opportunities (e.g., time to
service/replace existing equipment). For example, a smart device
having a global positioning system could be used to alert the
servicer of service opportunities when an application on the smart
device recognizes that the current location of the smart device is
within a specified range of a geo-fenced area around a site having
equipment in need of servicing/replacement. In this regard, FIG.
33AF is a flowchart illustrating processing steps carried out by
notifying a servicer of servicing opportunities around his/her
current location. In step 3608, an application receives current
location data (e.g., GPS coordinates) from a smart device. The
application could run on the smart device, a laptop, a remote
server having a web-accessible user interface, or any other
suitable mobile device that can accompany the servicer/installer.
In step 3610, the application receives the location of equipment
and date of service/installation from the cloud within a specified
range (e.g., location and service/installation dates of equipment
within 50 miles. In step 3612, the application determines if any of
the equipment within the specified range needs
servicing/replacement. In step 3614, the application places a
geo-fence around sites with equipment needing
servicing/replacement. In step 3616, the application determines if
the current location of the smart device (e.g., mobile device
running application and carried by the servicer) is within a
geo-fenced area. If a negative determination is made, the process
reverts to step 3608. If a positive determination is made, the
process proceeds to step 3618, where the application transmits a
notification to the servicer/installer (e.g., location of site,
equipment needing service/replacement, past issues, etc.) and the
process reverts to step 3608. While the process described
hereinabove, in connection with FIG. 33AE, makes reference to an
application that could be used by a servicer/installer, pool
control logic 70 could also accomplish/be used in connection with
these same steps. For example, pool control logic 70 could transmit
the location and service date of the equipment to the cloud or same
the data to memory, where the data is later accessed by the
application, or pool control logic 70 could determine if any of the
equipment needs servicing/replacing and transmit a notification to
the application regarding same.
[0308] FIG. 33AG is a flowchart illustrating processing steps of a
maintenance/targeted marketing system in accordance with the system
of the present disclosure for notifying a pool/spa owner that
equipment is in need of service. In step 3620, the maintenance
system receives (e.g., from pool control logic, cloud, servicer,
etc.) data on the location of equipment and date of
service/installation. In step 3622, the maintenance system
determines if any equipment needs servicing/replacement. In step
3624, the maintenance system cross-references the location of the
equipment needing servicing/replacement with a customer information
database (e.g., house phone, cellular phone, home address, email
address, etc.). In step 3626, the maintenance system transmits a
notifications to owners/users with equipment needing
servicing/replacement (e.g., robo-calls, SMS messaging, letters,
emails, etc.).
[0309] FIG. 33AH is a flowchart illustrating processing steps
carried out by the pool control logic 70 for limiting the operation
of pool devices when the an adult is not present. In step 3628,
pool control logic 70 retrieves pool location, geometry, and
orientation data from memory. The pool location, geometry, and
orientation data can be obtained by way of the process described
herein, in connection with FIG. 33A. In step 3630, pool control
logic 70 places a geo-fence around the pool/spa area. In step 3632,
pool control logic 70 receives operational data from a smart device
of an adult/parent (e.g., GPS coordinates). In step 3634, pool
control logic 70 determines if the smart device is within the
geo-fenced area. If a positive determination is made, the process
proceeds to step 3636, where pool control logic 70 transmits an
instruction to the pool devices to operate in "Adult Mode" (e.g.,
parent, adult-only, features enabled) and the process reverts to
step 3632. If a negative determination is made, the process
proceeds to step 3638, where pool control logic 70 transmits an
instruction to the pool devices to operate in "Safe Mode" (e.g.,
parent, adult-only, features disabled) and the process reverts to
step 3632.
[0310] FIGS. 34A-34J are diagrams showing additional embodiments of
the pool and/or spa control system of the present disclosure,
indicated generally at 4610. More specifically, FIGS. 34A-34J
illustrate modular relays 4670, a wiring hub 4646, and a control
module 4661 provided in accordance with the present disclosure.
[0311] FIG. 34A is a diagram illustrating another embodiment of the
system of the present disclosure, indicated generally at 4610. In
this embodiment, network connectivity and remote monitoring/control
is provided by way of a wiring hub 4646 which can be easily mounted
to a variety of surfaces (discussed hereinbelow in connection with
FIGS. 34F-34I. The wiring hub 4646 provides connections for various
pool and spa equipment, such as a variable speed pump 4614a, a
single-speed pump 4613, and a legacy heater 4615, as well as other
equipment. For example, the hub 4646 could communicate with and
control a smart valve actuator 4614e, and/or lighting system 4614h.
Optional smart control relays 4670 could also be in communication
with the hub 4646, or could communicate with any other HUA (e.g., a
unique addressing system, digital, analog or mechanical switches or
dip switches) enabled pool/spa component capable of receiving or
assigning a network address.
[0312] As can be seen, the hub 4646 could be in communication
(e.g., using any of the wired or wireless connections and
associated communication protocols discussed hereinabove) with a
control module 4661 having a user interface 4660. The user
interface device 4660 could include physical keys, a digital
display, and/or a touchscreen 4662, as shown in FIG. 34A. Any other
suitable input technologies, or any combination thereof, could also
be utilized, thereby enabling a user to interact with the pool
and/or spa control system 10. Additionally, the control module 4661
could provide a WiFi hotspot for allowing a service provider's
cellular telephone, tablet computer, or other mobile computing
device 4644 to communicate with the system 10, and to control the
pool/spa equipment shown in FIG. 34A. Communication between the
service provider's cellular telephone, tablet computer, or other
mobile computing device 4644 and the system 10 could be established
using the user interface 4660 (e.g., using physical keys, a digital
display, and/or by touch) or by proximity to the control module
4661, described in greater detail hereinbelow. A breaker panel 4627
provides electrical power to the various devices shown in FIG. 34A.
Breaker panel 4627 could also be a smart circuit breaker (e.g., a
circuit breaker that can be controlled via wired or wireless
communication) used to provide and/or to interrupt power to the
devices disclosed herein. In some embodiments, photovoltaic (e.g.,
solar) cells and/or systems could provide electrical power to one
or more of the various devices shown in FIG. 34A. The hub 4646
could also communicate with the homeowner's WiFi router 4622 via
the control module 4661, thereby providing an Internet connection
to the pool/spa components in communication with the wiring hub
4646. A remote pool/spa server 4618 could communicate with the
router 4622 via the Internet, to provide remote monitoring and
control of the pool/spa equipment, if desired. Additionally, the
server 4618 could communicate with one or more remote computer
systems 4620 such as a smart phone, a tablet computer, a remote
computer system, home automation, etc., if desired. The pool/spa
control logic discussed herein could be installed in the server
4618, in one or more of the remote computers 4620, and/or in the
control module 4661, if desired.
[0313] As illustrated in FIG. 34A, the system could include a
control/UI/Wifi module 4661 which includes an external controlling
unit 4660 having a user interface ("UI") display 4662, a control
board with processor and memory (not shown), and which is able to
communicate with a home router 4622 by way of a wired or wireless
connection (e.g., integral Wifi/cellular/RF, wired Ethernet, and/or
an external wifi/cellular antenna). More specifically, the
Control/UI/Wifi module 4661 could include a printed circuit board
(not shown), a control module having a processor and memory, a
graphical user interface display 4662 (e.g., LCD, LED, buttons,
knobs, capacitive plastic, etc.), a wifi module, ethernet jack, USB
port, LEDs, a sealed enclosure, a mounting bracket (e.g., for
mounting the module 4661 to a wall, post, pole, plumbing, etc.),
and a means for communication with a wiring hub 4646. In other
embodiments, the control module 4661 could be mounted on or inside
another piece of equipment such as, for example, a pump, heater,
chlorinator, control, timeclock, etc.) The control module 4661
could communicate with the wiring hub 4646 by way of either wired
(e.g., RS485, ethernet, USB, serial, etc.) or wireless (e.g., Wifi,
Bluetooth, ZigBee, ZWave, cellular, thread, etc.) communication
protocols.
[0314] The wiring hub 4646 includes an enclosure, provisions for
wire routing (meeting or exceeding IPxx ingress protection
standards), a printed circuit board, and a power cord "whip"
(cable). The wiring hub could be provided with communication
interfaces for receiving and transmitting data to one or more
devices. For example, the wiring hub could communicate with,
temperature sensors, external sensor, flow sensors, pressure
sensors, chemical and physical property sensors, valve actuator
ports, RS485 bus connections (for smart devices, smart relay(s),
smart (firmware assisted) valves, smart sensors, and other smart
devices) chlorination connections, lighting connections, power
connectors, low voltage relays, etc. Additionally, the
communication interfaces could also be used to expand the
functionality of the wiring hub such as, for example, by being used
to interface with wireless communication chips (e.g., Wifi,
Bluetooth, Zigbee, ZWave, cellular, thread, etc.), and additional
communication modules.
[0315] The Control/UI/Wifi module 4661 is used to monitor,
activate, and operate installed pool equipment. The control module
4661 could operate the equipment as needed with people present or
absent, in the pool or around the backyard, which may be year-round
and/or all-day based on application (e.g. residential vs.
commercial) or location. The control module 4661 also monitors,
detects, informs, and initiates protective action through a
heuristic capability (using one or more algorithms) by accumulating
and analyzing raw sensor data and external data to automatically
develop `normal` and `abnormal` operating ranges, then taking
action or alerting operators when the algorithm detects that
operation is out of normal or safe operating range. The heuristic
algorithms can also learn from operator response to a condition,
and therefore account for factors not anticipated or sensed by the
equipment. Such algorithms could be implemented in any of the
embodiments discussed in the present disclosure, and need not be
limited to the control module 4661.
[0316] The control module 4661 provides for distributed (e.g., the
control module can be moved throughout the pool/spa environment
based on the particular needs of the pool/spa environment and
needs/wants of the pool/spa user) control of pool equipment and
conditions that can be moved according to the specific needs of a
particular pool/spa environment and/or user. For example, the
control module 4661 could be moved away from the power switching or
pool equipment to a remote location, closer to the wireless
network, or closer to the home, or closer to wherever the user is
(e.g., poolside). In addition, the control module 4661 could also
allow for full pool control capability to be moved, or transferred,
to a remote location from the pool pad, such as for example, to a
cloud server 4618 or to a remote office.
[0317] The connection to the wiring hub can be extended or
virtualized via communications protocol over other mediums. The
wiring hub 4646 could locally switch power or the wiring hub 4646
could command smart relays 4670 (discussed hereinbelow) to switch
power or control signals. The wiring hub 4646 could further be
provided with "limp mode" behaviors (discussed in greater detail
hereinbelow) if communication to the controller is severed or
impaired. These behaviors could include, but are not limited to,
maintaining interlocks between relays, schedules, or other special
behaviors that are intended to keep the pool system functional at a
reduced level until normal operation is restored. The wiring hub
4646 could also integrate safety control functions needed for
heating or other appliances, or the wiring hub 4646 could directly
communicate with such safety controls.
[0318] The control module 4661 and wiring hub 4646 could be mounted
on a wall, on a post, on a stake (e.g., rebar), on a piece of
plumbing, inside or on a piece of existing pool/spa equipment
(e.g., pump, heater, chlorinator, existing automation, etc.).
Further the control module 4661 and wiring hub 4646 may be mounted
together in a single location or mounted separately.
[0319] The wiring hub 4646 could provide power to the control
system by tapping existing power connections at the load end of the
conduit coming from a sub panel, timeclock, control, junction box
or other electrical connection to the powered equipment. After
turning off the power at breaker 4627, a pool installer or service
professional could remove the power whip from the existing
equipment, and then reconnect the power whip to the wiring hub,
thereby providing power to the wiring hub and control module 4661
without having to access the line voltage compartment of an
electrical panel. Further, a new whip could then be connected to
the wiring hub 4646 which could, in turn, deliver power from the
wiring hub 4646 to additional powered equipment (see FIGS. 34B and
34C). For example, an existing power conduit from a variable speed
pump 4614a or a single speed pump 4613 could be disconnected from
the variable speed pump 4614a and then plugged back into, or
otherwise connected to, the wiring hub 4646. A new power whip could
then be used to connect the wiring hub 4646 to the variable speed
pump 4614a. Further, a communication cable (e.g., RS485) could be
connected between the wiring hub 4646 and the variable speed pump
4614 to provide communication therebetween. In another example, the
installed power conduit from a heater 4615 could be disconnected
from the heater 4615 and then plugged into, or otherwise connected
to, the wiring hub 4646. A new power conduit could then be used to
connect the wiring hub 4646 to the heater 4615 and a communication
cable (e.g., RS485) could be connected between the wiring hub 4646
and the heater 4615 to provide communication therebetween. In a
further example, the installed power conduit from a powered device
(e.g., pump, heater, chlorinator, cleaner, transformer, etc.) is
disconnected from the powered device and then reconnected to an
input of the wiring hub 4646. A new power conduit cable is then
used to connect the wiring hub 4646 to a smart relay 4670 and an
additional power conduit cable is used to connect the smart relay
4670 to the powered device (e.g., pump, heater, chlorinator,
cleaner, transformer, etc.). As illustrated in FIG. 34F, the wiring
hub 4646 and/or control/UI/wifi module 4661 could also be powered
directly from a 120V/240V NEMA style plug, thereby qualifying as a
cord-connected appliance. Because safety codes allow for increased
flexibility in the location and mounting of cord-connected
appliances, the labor to install or retrofit the devices is
reduced, and the accessibility to the user, installer, or site
wiring technician is improved. The modular nature of the wiring hub
4646 and control module 4661 provides for configurations thereof
that are tailored for integration with the installed pool/spa
equipment (e.g., such as a pump, heater, chlorinator, etc.) or that
can remain in stand-alone configurations, thereby providing
flexible communication to the controlled devices (e.g., via a wired
or wireless connection). It is within the scope of the present
disclosure that any and all of the pool control logic described
herein could be located in and run from the wiring hub 4646 and/or
the control module 4661.
[0320] The modular relays of the present disclosure could be used
in connection with both residential and some commercial
applications. The modular relays provide control (e.g., activation
and deactivation) of a piece of pool equipment based on a control
signal received from a controller (e.g., control module 4661) or
local manual input (discussed hereinbelow). For example, the
modular relay 4670 could be used to control a pump, cleaner
booster, spa booster, heater, pool lights, spa lights, landscape
lights, post lights, accent lights, other types of lights, fans,
chlorinators, water feature pumps, pond pumps, and cleaners, as
well as additional pieces of electrically powered/controlled
pool/spa equipment and yard equipment/devices. The modular relay
4670 could include a printed circuit board, a processor, an HUA
(e.g., a unique addressing system, digital, analog or mechanical
switches or dip switches), activation and/or deactivation button,
status LEDs, a relay (s), an enclosure with multiple power entries,
a power cord whip, and wired (e.g., RS485, USB, ethernet, etc.)
and/or wireless communication (e.g., Wi-Fi, Bluetooth, Bluetooth
LE, zwave, ZigBee, cellular, thread, mesh, etc.) interfaces for
communicating with the controlling hardware.
[0321] The modular relay 4670 can be controlled by a variety of
controlling devices. For example, the relay 4670 could be
controlled on schedule (e.g., existing timeclocks 4672), using an
algorithm (e.g., controller/pool control logic 70), through user
input (e.g., a button on the modular relay), from a web enabled
device (e.g., through the cloud, the router or direct) or in
stand-alone manual mode. The controlling devices could include, but
are not limited to, a pump, a heater, a cleaner, a salt
chlorinator, a lighting controller, a chemical automation system, a
hub or an existing controller, a smart phone, tablet, computer, or
smartwatch, or a voice enabled device (e.g., Amazon Echo).
[0322] The modular relay of the present disclosure could be capable
of detecting when there is no communication from a controlling
system/device, if the modular relay has not yet been configured, or
if the modular relay has been improperly operated or installed, and
in response, placing itself in stand-alone manual or `limp`
modes.
[0323] In stand-alone mode (as well as service, manual, limp or
other modes which are independent from commands from a controller),
the relay can operate independently of the pool/spa control system.
For example, in the event that communication with the control
system could not be established, the modular relay could
automatically enter standalone mode. In standalone mode, the
modular relay could provide a visual indication (e.g., a flashing
or steadily illuminated multicolor LED status indicator) that
communication with the control system could not be established, or
that communication has been severed. The modular relay could then
implement a limp mode for the relay. In limp mode the modular relay
could still be activated in response to timed events/schedules. The
behaviors of the modular relay when in manual or limp modes could
be defined by firmware or set by user preference, thus providing
the ability to maintain a schedule, always turn off, always turn
on, switch to a special schedule, or other actions intended to
maintain the water body while the pool/spa control system is in a
state of reduced functionality.
[0324] The relay could also enter service mode in response to
motion or other proximity detection (e.g., when a service provider
is in close proximity to a piece of pool/spa equipment), geofencing
(e.g., when a service provider enters the vicinity of the pool/spa
area), voice command (e.g., in response to audible request to
"enter service mode") or a button press (e.g., a physical "service"
button located on the relay). Service mode could also allow a
technician to temporarily operate the relay and then pass control
back (e.g., manually or via a timer) to the controller. The modular
relay device could also allow local control (e.g., by touch or
voice) at the smart relay without disabling remote control.
[0325] In an exemplary embodiment the relay could enter service
mode in response to a service provider being in close proximity to
the relay. For example, an application running on the service
provider's mobile device could communicate with the relay using any
of the communication protocols heretofore described and grant the
service provider access to configuration parameters for the relay
and/or the pool control system 10. In further embodiments,
additional security measures could be implemented for preventing
unauthorized access to the configuration parameters. For example, a
password could be required for access to the configuration
parameters. The password could be stored within the application so
as to auto-populate and unlock the system parameters when the
service provider is in close proximity to the relay. Alternatively,
the service provider could be prompted for a password when in close
proximity to the relay. Multiple passwords could be set so as to
unlock various system parameters associated with individual
passwords. For example, a service provider password could be used
to unlock all of the system parameters, whereas a pool user
password could only unlock a subset of the system parameters.
[0326] The modular relay could indicate the status of the modular
relay through LEDs (e.g., integrated into the modular relay), text,
graphics, or sound (e.g., provided on a user interface device), or
directly to web, wifi, Bluetooth, Zigbee enabled devices (e.g.,
smartphones and other mobile devices). For example the status
indications could include, but are not limited to, power, Internet
connection, communicating with the system, no communication with
the system, wifi connected, no wifi, controlled mode, service mode,
enabled or disabled, current, voltage, runtime history, actuation
history, etc.
[0327] The smart relay can identify itself to a controller (e.g.,
by providing a physical or network address, or by asking for an
address to be provided by the controller automatically), thereby
allowing the modular relay to communicate with, and be controlled
by the controller. The modular relay could also be manually given a
particular network address. The controller could control one or a
plurality of relays independently, in a timed sequence, or
simultaneously.
[0328] As illustrated in FIG. 34A discussed in greater detail
hereinbelow, the modular relay device could be provided with its
own proprietary/dedicated electrical/junction box ("enclosure") for
one (e.g., relay 4670) or a plurality of relays (e.g., wiring hub
4646), but could also be installed in an existing single gang, dual
gang, timeclock, or non-traditional electrical/junction box. As
shown in FIGS. 34G-34I, the proprietary/dedicated enclosure of the
modular relay device could be provided with a multitude of means
for mounting the enclosure to the pool pad. For example, the means
for mounting the enclosure could include, but are not limited to,
hose clamps, screw holes, rebar mounts, zip-tie holes, etc. FIG.
34F illustrates the modular relay 4670 with integral means for
mounting to a plumbing pipe (e.g., rounded back). FIG. 34G
illustrates the modular relay 4670 with integral means for mounting
to a pole (e.g., rounded back). FIG. 34H illustrates the modular
relay 4670 with integral means for mounting to a post or wall
(e.g., screw bosses). FIG. 34I illustrates the modular relay 4670
with integral means for mounting to rebar inserts (e.g., rebar
holders). A secondary structure could also be provided and could
include one or more of the means for mounting the enclosure.
[0329] As illustrated in FIG. 34B, the modular relay device could
include an incoming (power) whip/connection (including conduit
connection hardware) for conducting power from the supply (e.g.,
breaker panel). The connection could be built in, attached,
supplied or purchased separately. According to the embodiment
illustrated in FIG. 34B, incoming whip(s) could connect to an
existing sub-panel, timeclock enclosure, or junction box with
conductors connecting to existing equipment's power connection and
the opposite end of the incoming whip(s) could connect to the relay
connection in the modular relay system inside the enclosure. It is
desirable to utilize the existing whip to connect the breaker panel
4627 to the wiring hub 4646 or another intermediary piece of
equipment (e.g., timeclock 4672) so as to avoid entering/accessing
the "hot" section of the breaker panel 4627 or subpanel.
[0330] Whips can enter and exit the enclosure from the same side
(e.g., both entering and exiting the bottom of the enclosure as
shown in FIG. 34B) or from opposite sides (e.g., from a side to the
top or bottom, from the top or bottom to the side, or from the top
to the bottom or bottom to the top, etc.). The whips could be
coupled to the enclosure using straight connections, using 45
degree or 90 degree conduit connectors, or low profile connectors.
Standard conduit connectors could be used or proprietary
connections could be added to improve simplicity of connections.
The threading of the conduit connectors could be male or female, or
alternatively, the conduit connectors and the enclosure need not
use threading at all. Additionally, there can be a conduit entry
and/or exit in the cover of the relay or relay enclosure. All of
the conduit entries/exits and conduit connectors discussed
hereinabove could also have integral liquid tight cord entries for
ease of installation. Accordingly, the modular relay device
enclosure is designed such that it readily accepts incoming whips
from existing equipment (e.g., sub-panel, timeclock or junction
box, etc) and exiting whips to the powered and controlled
device.
[0331] The enclosure of the modular relay device could have relays
that are detachable, that are integral, or that are integral and
fully potted. Further, the relays could be permanently installed,
mounted by way of screws, or could be mounted by way of a hinged
connection (inside or outside) with one or more screws.
[0332] The modular relay device could have a ground fault circuit
interrupter ("GFCI"), arc fault, or other protective circuit built
into the relay. The modular relay device could also measure load
power, supply voltage, contact closure, contact resistance, or
general contact health. In addition, the modular relay device could
measure circuit or ambient temperature, or sense water flow or
temperature via an attached sensor. The inclusion of GFCI or other
safety functions could satisfy wiring requirements without needing
an additional (and expensive) GFCI breaker.
[0333] The relay could be encased/over molded into a line cord,
thereby allowing a servicer/installer to remove the existing whip
from the power supply (e.g., breaker panel) to the piece of
equipment and replace it with a new line cord having an integral
relay. It is desirable to utilize the existing whip to connect the
breaker panel to the wiring hub so as to avoid entering/accessing
the "hot" section of the breaker panel or subpanel, and use the new
over molded line cord with integral relay to connect the wiring hub
and piece of pool/spa equipment. However, the new over molded line
cord with integral relay could be used to connect breaker panel and
the wiring hub, and the existing whip could be used to connect the
piece of pool/spa equipment and the wiring hub. The new line cord
could further include a means to communicate with the controller
(e.g., RS485, USB, Ethernet, Bluetooth, Wifi, Zigbee, Cellular,
Thread, LE Bluetooth, any mesh type network, etc.).
[0334] The relay could also include a number of additional smart
relay capabilities that could allow for the addition of other
circuitry, inputs, or external communication modules. For example,
the modular relay device could accept sensor inputs (e.g., temp,
light, wind, etc.) or external data (e.g., storm detection, web
servers, GPS inputs for geo fencing, etc.). It is within the scope
of the current disclosure that any and all of the pool control
logic described herein could be locate in and run from the relay
4670.
[0335] FIG. 35 is a diagram illustrating another embodiment of the
system of the present disclosure, wherein a wireless communication
device, indicated generally at 4800, provides communication between
pool/spa components or equipment, a home router, and the internet.
The wireless communication interface 4800 allows pool controlling
devices (e.g., pump, heater, chlorinator, cleaner, hub, automation,
etc.) to communicate with the home router and thereby communicate
with the Internet. The wireless communication device could be
located directly on the main (intelligence) printed circuit board
("PCB"), could be attached/plugged into the main PCB, could be
provided as a modular upgrade to the main PCB or PCB enclosure,
could be a modular upgrade to/external to the main PCB enclosure,
or could be located remotely to the main PCB enclosure. As shown in
FIG. 35, an antenna could be mounted with (internal antenna 4804)
or remote to (external antenna 4816) a wireless transceiver module
4802 in the embodiments described herein. The wireless
communication interface 4800 could also allow pool controlling
devices to directly communicate with web enabled devices (e.g.,
smartphones, tablets, thermostats, voice enabled devices, etc.)
without the need to go through a home router. Additionally, the
wireless communication interface 4800 could provide communication
between the pool/spa components or equipment and the web/cloud
server, thereby providing tools and indicators to assist a user in
solving connectivity problems with the controller through the
server/cloud and to the consumer and apps.
[0336] As shown in FIG. 35, the wireless communication interface
4800 includes a protocol processor 4808, a radio circuit 4810, and
an antenna 4804 and could be installed directly on the circuit
board of the controlling equipment. In another embodiment, the
wireless communication interface 4800 could have a secondary
external antenna 4816 that could be installed for better
connectivity (e.g., signal strength) or for placement at a location
closer to the home router.
[0337] The wireless communication interface 4800 could also include
a printed circuit board, a protocol processor 4808, an HUA module
4812 (e.g., for providing a unique hardware address), a radio
circuit 4810, an antenna 4804, status LEDs 4814, an
ethernet/USB/RS485/Bluetooth connection 4806, and an enclosure that
could be mounted using the enclosure itself or using a secondary
mount. For example, a secondary mount could be provided for
mounting the wireless communication interface 4800 without (or
with) the use of tools (e.g., by snapping the antenna to the mount
or other suitable methods). In addition to, or in place of, the
ethernet/USB/RS485/Bluetooth connection 4806, the wireless
communication interface 4800 could include any wired or wireless
communication protocol disclosed herein for communicating with the
controller hardware.
[0338] An antenna (internal antenna 4802 or external antenna 4816)
is used to communicate commands from remote web enabled devices
(e.g., wireless devices) to a controller unit, which activate
equipment as needed with people present or absent, in the pool or
around the backyard, which may be year-round and/or all-day based
on application (e.g. residential vs. commercial) or location.
Additionally, the wireless communication interface 4800 could
communicate with the controlling devices by way of RS485, USB,
Bluetooth, ethernet, cellular, Wi-Fi, ZigBee or other communication
protocols. For example, the antenna 4802 could facilitate
communication with the home router through Wi-Fi, Cellular,
Bluetooth, ethernet, or other communication protocols.
[0339] The wireless communication interface 4800 could also be
provided with a button to activate service/troubleshooting
indicators (e.g., LEDs 4814) to provide information relating to the
status/connectivity problems of the wireless communication
interface 4800. For example, the wireless communication interface
4800 could be provided with LED indicators 4814 which could be
illuminated in various colors (e.g., black, green, orange, red,
etc.) and activation patterns (e.g., solid, blinking, etc.) based
on the status of the wireless communication interface 4800. For
example, a green LED could indicate normal operation, a yellow LED
could indicate an issue that can be addressed by the user, and a
red LED could indicate an issue that needs to be addressed by a
service provider. The status LEDs could further include a power
icon LED (indicating bad cable, no power, power ok, WPS
activation), a router icon LED (indicating router not present,
incorrect password, no IP address assigned, router DHCP error,
incompatible router/black listed firmware or model), a web icon LED
(indicating web not present, no UDP connection allowed, no remote
server found, connected to web server), an Internet icon LED
(indicating no internet/no google, high error rate, connected to
the internet), a signal strength LED (indicating not configured,
out of range, weak signal, 75% or greater signal), a quality of
signal LED (indicating error rates via a bar graph, high error
rate, strong connection/low error rate), and a connection speed LED
(indicating reduced connection speed/sufficient connection speed).
Additionally, the LEDs could indicate the status of the connection
as illustrated in Table 1 below.
TABLE-US-00001 TABLE 1 LED State Connection Status Power: Off No
Power, USB/Wire Corruption Power: Off No SSID Password Router:
Blinking No IP Address Internet: Off No Internet Access (No Google)
Router: Blinking No DHCP Server Response (Static Only) Router
Config: Blinking No IP Path -> Remote Server (Internet is OK)
Router Config: Blinking No UDP to Remote Server (Firewall) Radio
Link: Blinking High Error Rate (Break Out) No Network Connection
Internet: Blinking Frequent Internet Response Delays Slow Flicker
on High Past Issue Not Currently Happening Trending Issue Power:
Slow Flicker Firmware Needs Update radio, host, optional, urgent
Power: Slow Flicker WPS for Unknown Password
[0340] The connection status could also be communicated through the
controller user interface (e.g., a status page) to help
installers/users identify communication problems with the cloud
and/or application using similar multicolor status indicators as
described above. For example, all faults could be provided in a
list with one color (e.g., green) or another color (e.g., red)
indicators to identify a connection problem area. The status page
could also provide a solution to a particular connection problem
associated with a color. Further, the system could prompt the user
to contact the manufacturer in the event that a problem is not
known or that the problem is known to not be resolvable through a
troubleshooting manual.
[0341] The status page could be activated through a service button
(e.g., provided on the control device, pool/spa equipment, or in an
application) to allow a web-enabled device to obtain the status of
the wireless communication interface via an application. For
example, the application status page could provide all of the
faults in a list with green or red indicators to easily identify
problem areas, a description of the solutions to particular
problems, a walk-through presentation on how to address/fix the
problem, and/or a video illustrating how to address/fix the
problem. The application could also provide a configuration
walk-through page to instruct a user on how to configure the
wireless communication interface. The configuration walk-through
page could be activated through a service button. The application
could also connect to a service to provide remote customer service
via a web-enabled controller which could allow the service provider
to remotely troubleshoot and fix the problem with minimum user
interaction.
[0342] The pool "hub" disclosed herein, as well as the various
embodiments disclosed herein, allows for wired and wireless
communication (e.g., wireless methods 802.11 protocols, Zigbee,
Zwave), with pool pad components. Communication could include
product status, product health, energy use (e.g., individual and/or
system), errors, preventative maintenance, etc. The hub could
incorporate all of the types of communication to the hub and from
the hub to the home router. The pool hub could be upgraded through
the web, push updates to connected equipment at the pad, etc. The
hub could be fully configured (e.g., through an app), which
includes schedules, names, temperatures, possible chemical dosage,
percentage output, etc. The hub could have web based cloud
connectivity to other cloud based devices or systems to allow for
enhanced communication and/or enhanced external inputs. The hub
could have a communication antenna for RF mesh (e.g., ZWave,
Zigbee, Thread, Weave), BlueTooth, etc to connect to pool and
non-pool equipment. The connectivity could be done at the pool pad,
the processing could be done on the cloud (e.g., with one app built
based on activated features). The hub could connect thermal imaging
to relay pool, pad, spa, and/or weather information to the hub. The
hub could enable virtual interlocks between devices based on
predetermined rules and relationships.
[0343] The system of the present disclosure is modular and can grow
with the addition and/or replacement of equipment. More
specifically, the system consolidates all products as they are
added (e.g., pump, heater, chemistry automation systems), and could
only show the ones currently installed. App updates (e.g., for
accessing the system from a local device) could come from new
compiled code and/or a profile held in the device and transferred
to the app. The system could store the operating profile and/or
environment of the devices captured by the hub or in the devices
and relayed to the hub (which could support the predictive failure
ability as well as supports warranty analysis claims). The system
could store standard profiles for heater/pump (e.g., Northeast
region by zipcode) and/or heater/pump/lights (e.g., Southwest
region by zipcode) for easy configuration (e.g., start with
standard configurations based on the geography).
[0344] The system could monitor a variety of types of plug in
and/or wireless sensors (e.g., air, pool, spa, solar, temperature,
etc.) for a variety of types of measurements (e.g., presence of
flow, measurement of flow, line pressure, water levels, UV levels,
wind speeds, light presence, etc.). Other types of sensors that
could be used include turbidity sensors, bacteria sensors,
alkalinity sensors, hardness sensors, RF sensors, sound wave
sensors, different light spectrum sensors, reflectors, magnetic
sensors, radar, infrared, humidity, evaporation, moisture, motion,
galvanic corrosion, chemical corrosion, electrolysis, electrical
storm sensors, etc. The sensors could analyze and/or process raw
data (e.g., locally sensed parameters, from a third party source,
etc.) with an integrated processor or communicate the raw data
(e.g., locally sensed parameters, from a third party source, etc.)
for processing in a co-located or remote processor. The sensor
analysis could incorporate trigger points, trend monitoring, manual
correlation analysis, automatic correlation analysis, etc. The
sensors could be individual or grouped (e.g., for more efficient
connection and/or pairing).
[0345] The hub could function as a router for data, relay for data,
or analyze the data. The hub could have one or many different
electrical and protocol data communication interfaces to support
connection to legacy and future protocols and devices. The hub
could have built in Ethernet (e.g., wired, wifi, cellular, and/or
other), as well as communication with home router and/or direct to
cloud (e.g., cellular). The hub could connect through wired (e.g.,
RS485) and/or wireless communication (e.g., wifi, blutooth, zwave,
zigbee, etc.) with a pump (e.g., for full variable speed pump
("VSP") capabilities), heater or heat pump (e.g., for heat
control), etc. (i.e., low voltage and/or high voltage
applications). The hub could have one or more modular relays or
relay banks (e.g., four relays or relay banks). The hub could
connect to the relay bank for relay control through wired (e.g.,
RS485) and/or wireless communication. The relays could be used to
control any electrical devices (e.g., high or low voltage), such as
pumps, lights, etc. The hub could control wired or wireless valves
with transformation at plug or 120V (e.g., to provide power to
valve based on hub architecture). The hub could connect to a light
controller through wired and/or wireless (e.g., Bluetooth and/or RF
mesh such as ZWave, Zigbee, Thread, Weave, etc.) communication,
such as to give relay control to a pool, spa, backyard lighting,
etc.
[0346] The system can perform a variety of types of analytics. For
example, the system could analyze electrical, gas, and/or propane
usage for one or more pool devices, sites, and/or geographies
(e.g., based on data from the hub or device). The system could
analyze consolidated site information to facilitate creation of
algorithms (e.g., to increase efficiency for all users). The system
could use historical data trends to predict future trends, future
costs, utility budgets, warnings, efficiency change, as well as to
offer preventative maintenance, predictive failure, and/or
potential downtime risks. The system could communicate with
utilities via a web-based API or some other suitable mechanism. The
system could use data trends and/or external data to minimize
energy usage and/or facilitate energy consumption decisions. The
system could analyze data to predict a budget for requested
outcomes to give consumers better visibility in their choices. The
system could use external web based data to automate decisions
based on learned or imputed data or trends. The system could use
historical and/or external data to predict outcomes heating or
filtering events to increase autonomy and reduce energy usage for
these outcomes. The system could use failures, predictive failures
or preventative maintenance alerts to automatically assign or
request service from a customer or partner. The system could use
external data from partners to increase the efficiency, potential
decisions, functionality of the hub in the IoT world. The system
could use data to adjust automated decisions based on sensors,
decision information, inputs from other devices, etc. The system
could use flow, pool temperature, air temperature, wind data, etc.
to automatically adjust the pool turnover and optimize (e.g.,
fastest, most efficient) the pool pump for amount of turnover,
speed, etc., and/or to automatically adjust the chemical dispensing
and/or production to maximize life of cells. The system could use
data communicated to the hub from a water leveling sensor to
predict leaks and/or water bills, and/or to automatically alert
leak repair company that customer has an issue with his or her
pool. The system could use web based data (e.g., time of year,
sunrise and sunset, time, etc.) to predict light availability and
automate changes in device schedules. The system could use
consolidated site information to help notify the user of a devices
operation through the actions of an alternate device. The system
could provide an installer with a step by step interface for
product installation when a product is selected.
[0347] While various forms of web data have been described above in
connection with FIGS. 1-33AH, web data can also include, but is not
limited to: environmental conditions such as ambient temperature,
humidity, wind speed and direction, rain, lightning, snow, cloud
coverage, forecasts (e.g., 5 day, 10 day, etc.), pollen,
visibility, fog, pollution, smog, road conditions, travel delays,
UV index, location, zip code, GPS coordinates, IP address, sunrise,
sunset, sun location, wind chill, public water costs, public water
availability, public water quality, drought or flood alerts,
average chemical costs (e.g., internet costs of chlorine, etc.),
tornado/hurricane alerts, etc.; local energy data such as
electricity costs, fuel costs, peak hours and cost fluctuation, sun
location, available energy rebates, etc.; personal data produced in
conjunction with web or web enabled device (e.g., nest, phone, hub,
etc.) such as location (e.g., home, away, on the way home, etc.),
data usage, amount of web enabled devices used or connected (e.g.,
five downloaded apps could represent a family of five), energy used
(e.g., fuel, electricity, etc.), data speed (e.g., upload/download
rate (mbps), ping), etc.; and product data (e.g., in conjunction
with registration) such as warranty, age, recalls, tech bulletins,
replacement parts, specs, tech support, tutorials (e.g.,
instructional videos), specials (e.g., coupons, promotions, etc.),
local support (e.g., authorized service center), firmware updates,
new product releases, pool industry news, safety alerts, safety
suggestions, etc.
[0348] It is contemplated that all of the systems disclosed herein
could interface with one or more dedicated/proprietary or 3.sup.rd
party voice interaction devices (e.g., Apple's Ski, Amazon Echo,
etc.). Pool control logic 70 could interface with the voice
interaction devices directly (e.g., Bluetooth), locally (e.g.,
through network router or mesh network), or via the cloud. The user
commands, inputs, actions, etc., described herein, could be
provided to pool control logic 70 via the voice interaction device
and notifications, messages, alerts, etc., described herein, could
be transmitted to the user via the voice interaction device (e.g.,
verbal notification, messages, alerts, etc.). For example, to
activate the lighting system 14h, a user could simply say, "Alexa,
turn on the pool lights."
[0349] It is contemplated that that the various devices in the
embodiments described herein could also communicate by way of power
line carrier (e.g., power-line digital subscriber line (PDSL),
mains communication, power-line telecommunications, or power-line
networking (PLN)) to allow the various interconnected components to
communicate with one another via electrical wiring.
[0350] It is also contemplated that site data could be replaced
with cloud data, or data at the site could be combined with data in
the cloud, and the system could intelligently combine disparate
data from different cloud servers.
[0351] Also contemplated is capturing specific equipment data
(e.g., bar codes) by a smartphone camera at the site at the time of
installation and connecting to an application. This can, at the
same time, capture GPS coordinates for the address and date of
installation for warranty registration, and automatically load the
location of the pool into the pool control logic with cloud support
for sunrise/sunset, real time and forecasted weather data.
Similarly, by standing by the pool and taking photo of the pool,
one can record North-South-East-West (e.g., phone compass) and load
similar data into the pool control logic with cloud support for
using wind direction as well. If photos are taken multiple times in
the day, compass and date information could be used to extrapolate
the pool's sun exposure for pool heating and other
calculations.
[0352] In addition to receiving operational data from locally
installed pool/spa equipment, remote data (e.g., an off-site or
cloud server) and web data, described hereinabove, it is also
contemplated that pool control logic 70 could receive operational
data from one or more pieces of pool equipment having enhanced
sensing capabilities. For example, the system 10 could include
lighting system 14h (see, e.g., FIG. 1) having a smart light 5014h.
More specifically, as shown in FIG. 36, smart light 5014h could
include temperature sensor 5000 (e.g., for temperature sensing of
air, water, etc.), microphone 5001, chemistry sensor 5002 (e.g.,
for sensing salinity, pH, ORP, TDS, chlorine, etc.), light output
sensor 5004 (e.g. for sensing lumen, lux, CCT, CIE, etc.),
occupancy sensor 5006 (e.g., IR, sound/audio detection, radar,
etc.), water clarity sensor 5008, water level sensor, 5010, water
pressure sensor 5012, flow sensor 5014, turbidity sensor 5016, user
input module 5018 (e.g., touch panel, physical buttons, etc.) and
network communication and local control subsystem 12h (see, e.g.,
FIGS. 1-2). The smart light 5014h could further include the ability
to measure for stray current. The user input module could include
touch-based inputs (e.g., capacitive, inductive, fear field RF,
etc.). The smart light 5014h could further include a display 5019
provided as a separate component or integrally provided with user
input module 5018. The smart light 5014h could accordingly be used
to display an error message for a fault condition or warning
message regarding pool chemistry, or could be used to display any
other kind of visual media. Although previously discussed, it is
noted that the network communication and local control subsystem
12h could communicate with pool control logic 70, located in one or
more of the pool/spa components discussed herein, using any of the
communication protocols discussed herein, including but not limited
to, power line carrier, ethernet, RF, Bluetooth, Wi-Fi, and ZigBee.
Smart light 5014h could also record hours of operation, light
output, voltage, and current as well as corresponding operating and
environmental conditions during use. It is further noted that
temperature sensor 5000, microphone 5001, chemistry sensor 5002,
light output sensor 5004, occupancy sensor 5006, water clarity
sensor 5008, water level sensor, 5010, water pressure sensor 5012,
flow sensor 5014, turbidity sensor 5016, user input module 5018,
and network communication and local control subsystem 12h could be
incorporated into the a lighting device, or could be provided as an
additional attachment to the lighting device body. Further, as
discussed above, pool control logic 70 could reside or be run
within the smart light 5014h, in another piece of pool/spa
equipment, remotely, or distributed amongst one or more of these
locations.
[0353] FIG. 37 is a flowchart illustrating processing steps of the
pool control logic 70 for controlling a heater based on operational
data received from the smart lights 5014h described above. More
specifically, multiple smart lights provided in and around the
pool/spa could act as a mesh array of temperature sensor inputs for
determining the average temperature of the pool/spa and controlling
the heater accordingly. In step 5020, the pool control logic 70
receives operational data, e.g., temperature, from a first smart
light. In step 5022, the pool control logic 70 receives operational
data, e.g., temperature, from a second smart light. In step 5024,
the pool control logic 70 receives operational data, e.g.,
temperature, from the nth smart light. That is, the pool control
logic 70 receives operational data for all smart lights in addition
to the first and second smart lights discussed in connection with
steps 5022 and 5024. In step 5026, the pool control logic 70
determines the average temperature off the pool/spa based on the
operational data received from the smart lights. In step 5028, the
pool control logic 70 retrieves temperature setpoint data from
memory. In step 5030, the pool control logic 70 determines if the
average temperature (determined in step 5026) is below the
temperature setpoint. If a positive determination is made, e.g.,
the average temperature is below the temperature setpoint, then the
process proceeds to step 5032, where the pool control logic 70
transmits an instruction to activate a heater and the process
reverts to step 5020. If a negative determination is made, e.g.,
the average temperature is greater than the temperature setpoint,
then the process proceeds to step 5034, where the pool control
logic 70 transmits an instruction to deactivate a heater and the
process reverts to step 5020. It is also contemplated that instead
of determining the average temperature of the pool/spa, pool
control logic 70 could determine the warmest or coolest area of the
pool/spa and control the heater accordingly (e.g., warming the
coolest area of the pool to a temperature setpoint, or cease
warming of the pool when the warmest area of the pool reaches a
temperature setpoint).
[0354] FIG. 38 is a flowchart illustrating processing steps of the
pool control logic 70 for controlling a heater by determining a
predicted temperature setpoint based on previous user specified
temperature setpoints. In step 5036, the pool control logic 70
receives an instruction to activate a heater. In step 5038, the
pool control logic 70 retrieves a first previous user temperature
setpoint from memory. In step 5040, the pool control logic 70
retrieves a second previous user temperature setpoint from memory.
In step 5042, the pool control logic 70 retrieves the nth previous
user temperature setpoint from memory. That is, in step 5042 the
pool control logic 70 retrieves all other previous user temperature
setpoints from memory that are desired. For example, the system can
be set-up so that the three (3), four (4), five (5), ten (10), or
twenty (20), etc., most recent previous user temperature setpoints
are utilized in this process. In step 5044, the pool control logic
70 determines a predicted user temperature setpoint based on the
previous user temperature setpoints retrieved from memory in steps
5038, 5040, and 5042. This determination can be based on, for
example, the mean, median, mode, etc., of the previous user
temperature setpoints retrieved from memory. In step 5046, the pool
control logic 70 transmits an instruction to a heater to operate,
e.g., until the predicted setpoint determined in step 5044 is
reached.
[0355] FIG. 39 is a flowchart illustrating processing steps of the
pool control logic 70 for controlling the pool/spa water chemistry
by operating sanitization equipment based on operational data
received from water chemistry sensors in one or more smart lights
5014h. In step 5048, the pool control logic 70 receives water
chemistry setpoints, e.g., relating to salinity, pH, ORP, TDS,
chlorine levels, etc., from memory. In step 5050, the pool control
logic 70 receives water chemistry operational data, e.g., salinity,
pH, ORP, TDS, chlorine levels, etc., from smart light sensors. In
step 5052, the pool control logic 70 determines if the water
chemistry operational data (determined in step 5050) is within
specific levels, e.g., which are based on the setpoints retrieved
in step 5048. If a positive determination is made, then the process
returns to step 5050, where the pool control logic 70 continues to
receive water chemistry operational data from the smart light
sensors. If a negative determination is made, then the process
proceeds to step 5054, where the pool control logic 70 determines
an action to correct the water chemistry, e.g., increase
chlorination rate by X %. In step 5056, the pool control logic
transmits an instruction to the chemistry automation system to take
corrective action in accordance with the action determined in step
5054, e.g., increase the chlorination rate by X %, and the process
reverts to step 5050.
[0356] In accordance with additional embodiments of the present
disclosure, using similar processing steps as described in
connection with FIG. 39, pool control logic 70 could also use
operational data received from the smart light 5014h sensors to
control a robotic cleaner based on operational data received from
water clarity sensor 5008 or occupancy sensor 5006, activate the
pump and/or filter based on operational data received from water
clarity sensor 5009, activate water features, actuate valves, or
activate the pump based on operational data received from flow
sensor 5014, trigger a house alarm (if armed) based on operational
data received from occupancy sensor 5006, activate the lighting
system based on operational data received from occupancy sensor
5006 (e.g., turn on the lights, increase the intensity of the
lights, switch light color based on an unplanned occupancy or turn
lights on based on time of day, automatically turn off after a
period of time if no occupant detected, "follow the swimmer" by
only activating the light when an occupant is detected proximate
thereto), adjust the water temperature based on operational data
received from occupancy sensor 5006, adjust light output based on
operational data received from ambient light sensor 5004, and
adjust CCT based on operational data received from ambient air
temperature sensor 5000.
[0357] FIG. 40 is a flowchart illustrating processing steps of the
pool control logic 70 for predictively displaying the most popular
light show based on previously selected light shows. In step 5058,
the pool control logic 70 receives an instruction to activate a
light show. In step 5060, the pool control logic 70 retrieves a
first previously selected light show from memory. In step 5062, the
pool control logic 70 retrieves a second previously selected light
show from memory. In step 5064, the pool control logic 70 retrieves
the nth previously selected light show from memory. That is, in
step 5064 the pool control logic 70 retrieves all other previously
selected light shows from memory. For example, the system can be
set-up so that the three (3), four (4), five (5), ten (10), or
twenty (20), etc., most recent previously selected light shows are
utilized in this process. In step 5066, the pool control logic 70
determines the most common light show based on the previously
selected light shows retrieved from memory in steps 5060, 5062, and
5064. In step 5068, the pool control logic 70 transmits an
instruction to a lighting system to display the most common light
show as determined in step 5066. It is further contemplated that
rather than receiving all of the previously selected light shows
from the memory, pool control logic 70 could instead retrieve a set
number of most recent light shows (e.g., most recent 10 light
shows), or pool control logic 70 could retrieve light shows that
were selected within a specified period of time (e.g., light shows
selected within the last year). In addition to displaying light
shows, it is also contemplated that the smart light 5014h could
communicate with music and speaker systems to provide a coordinated
music and lighting show (e.g., lights change color and intensity,
pulse, move, etc. based on a particular musical selection).
[0358] It is further contemplated smart light 5014h could provide
for user interaction with the pool/spa control system 10 and pool
control logic 70. As discussed above, the smart light could include
a user input module 5018 having touch-based inputs and a display
5019. For example, the user could use the touch-based controls to
adjust the water temperature at the smart light 5014h, or to modify
or change a light show or light color. Similarly, the touch-based
controls and display 5019 could be used to virtually configure
custom light shows. Additionally, the user could interact with the
pool/spa control system 10 using the microphone 5001 (e.g., using
voice commands either above or below water).
[0359] In accordance with embodiments of the disclosure, the pool
control logic 70 could receive operational data from a plurality of
smart lights 5014h disposed about a pool/spa. More specifically,
pool control logic 70 could receive operational data from occupancy
sensors 5006 in the plurality of smart lights 5014h. Using the
plurality of lights 5014h and sensors 5006 as nodes in a mesh
array, pool control logic 70 could determine the location of the
occupant in the pool/spa.
[0360] In accordance with embodiments of the present disclosure,
the smart light 5014h could further perform an optical comparison
with a camera to identify when the pool is dirty or contains debris
or other particulate.
[0361] In accordance with embodiments of the present disclosure, a
plurality of smart lights 5014h could be used as an array to
provide directional input for a robotic cleaner. For example, as
discussed above, pool control logic 70 could determine areas of the
pool having high concentrations of dirt or debris. Further, a
plurality of smart lights 5014h could be disposed about a pool/spa.
Pool control logic 70 could then determine the smart light 5014h in
closest proximity to the debris and send an instruction to activate
the smart light 5014h. The pool cleaner would then detect the light
from the smart light 5014, proceed towards the same, and
accordingly proceed towards the area having a high concentration of
debris. Alternatively, smart lights 5014h could independently
illuminate if they determine they are proximate to an area of high
debris. The pool cleaner could then proceed to each area of high
debris, in turn.
[0362] In accordance with embodiments of the present disclosure,
smart lights 5014h could be used to provide light catalyzed
chemistry for sanitization by adjusting their light output
wavelength. For example, pool control logic 70 could receive an
instruction to sanitize the pool/spa. Pool control logic 70 could
then retrieve light wavelength sanitization setpoint data from the
memory (e.g., sanitization wavelength is 254 nm). Pool control
logic 70 could then transmit an instruction to the lighting system
14h and/or smart light 5014h to operate at the sanitization
setpoint (e.g., 254 nm).
[0363] Having thus described the disclosure in detail, it is to be
understood that the foregoing description is not intended to limit
the spirit or scope thereof.
* * * * *