US20190086110A1

Movatterモバイル変換

Info

Publication number: US20190086110A1
Application number: US15/707,769
Authority: US
Inventors: Glen Kazumi Okita; Shayan Habib
Original assignee: Ecofactor Inc
Current assignee: Ecofactor Inc
Priority date: 2017-09-18
Filing date: 2017-09-18
Publication date: 2019-03-21

Abstract

Systems and methods are disclosed to incorporate manual changes to the setpoint for a thermostatic controller into the programming of the thermostatic controller to take into account the occupants acclimatization to humidity and temperature for comfort and energy efficiency.

Description

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

Any and all applications for which a foreign or domestic priority claim is identified in the Application Data Sheet as filed with the present application are hereby incorporated by reference under 37 CFR 1.57.

BACKGROUND OF THE INVENTIONField of the Invention

The invention relates to the use of thermostatic HVAC controls that are connected to a computer network. In particular, embodiments of the invention pertain to the use of communicating thermostats to optimize the energy efficiency and the comfort for the residents of a home based at least in part on acclimatization of the occupants. Optimization is performed by a machine learning system running as a cloud service to adjust a thermostat. Background

The optimum value for a thermostat parameter varies based on weather, season, time-of-day, and the thermodynamics of the structure. A thermal model can be used to optimize the parameter to deliver desired cooling or heating while minimizing energy use. The overall goal of that parameter shall be to reduce the energy consumption while improving the comfort for the residents of a home.

As an embedded device with limited processing capacity, a parameter may be used as a simple threshold to control system behavior. However it may not be possible or desirable for an embedded device to adjust each parameter in an optimized way.

SUMMARY OF THE INVENTION

A cloud service can characterize the overall performance of an HVAC system based on external and intrinsic conditions, and create a customized parameter setting for each structure. The external and intrinsic conditions that change slowly over time, such as seasonal variations, can be processed and accounted for with periodic updates to parameters. A simplified model can incorporate real-time conditions, such as indications of humidity from a humidity sensor. In an embodiment, a thermostat comprises the humidity sensor. In another embodiment, a humidifier comprises the humidity sensor.

When the device is offline, it can operate using a local snapshot of adjusted parameters. If the adjustments are highly seasonal and there is an extended disconnected period, the parameter adjustments can be slowly decreased over time until the device operates on default parameters. In other cases, such as optimizations based on type of structure, there is no need to reduce level of adjustment over time. The effective value of an adjusted parameter can incorporate both varying levels and fixed levels of adjustment.

Certain embodiments disclose a method to adjust variable thermostats to reduce energy usage and to maintain comfort levels for occupants of a house. The method comprises receiving, at one or more server computers comprising computer hardware, measurements of temperature inside of the house over time from a thermostat, the one or more servers communicating with the thermostat via a network, the thermostat configured to control at least one heating, ventilation, and air conditioning (HVAC) system that conditions the house; comparing, with the one or more server computers, the inside temperature measurements of the house with outside temperature measurements over time when the HVAC system is running to derive a time-weighted change in temperature (ΔT ); calculating, with the one or more server computers, an adjustment to a setpoint optimization adjustment based on the outside humidity measurements and the time-weighted ΔT ; and changing, with the one or more server computers, an operation of the HVAC system in response to the adjustment to the setpoint optimization adjustment.

In an embodiment, the method further comprises sending, with the one or more server computers, data to the thermostat to change the operation of the HVAC system. In an embodiment, the thermostat is configured to adjust one or more of a setpoint of the thermostat and a run time of the HVAC system in response to the data. In an embodiment, the method further comprises displaying the adjusted setpoint to a user. In an embodiment, the method further comprises displaying the setpoint without the adjustment to the setpoint optimization adjustment to a user.

In an embodiment, the method further comprises displaying the setpoint with some of the adjustment to the setpoint optimization adjustment to a user. In an embodiment, the method further comprises receiving measurements of humidity inside of the house over time. In an embodiment, the adjustment to the setpoint optimization adjustment is further based on the inside humidity measurements. In an embodiment, the HVAC system is programmable. In an embodiment, the method further comprises sending, with the one or more server computers, data to the programmable HVAC system to adjust a setpoint of the programmable HVAC system in response to the adjustment to the setpoint optimization adjustment and the time-weighted ΔT .

Certain embodiments disclose a system to adjust variable thermostats for reduced energy usage and to maintain comfort levels for occupants of a house. The system comprises a thermostat operatively connected to a heating, ventilation, and air conditioning (HVAC) system that conditions the house; an electronic storage medium comprising stored data of a plurality of inside temperature and humidity measurements taken within the house; and computer hardware configured to communicate with the electronic storage medium, the thermostat, and the humidity sensor, the computer hardware configured to compare the inside temperature measurements of the house with outside temperature measurements over time when the HVAC is running to derive a time-weighted change in temperature ΔT ; calculate an adjustment to a setpoint optimization adjustment based on the outside humidity measurements and the time-weighted ΔT ; and change an operation of the HVAC system in response to the adjustment to the setpoint optimization adjustment.

In an embodiment, the computer hardware is further configured to send data to the thermostat to change the operation of the HVAC system. In an embodiment, the thermostat is configured to adjust one or more of a setpoint of the thermostat and a run time of the HVAC system in response to the data.

In an embodiment, the computer hardware is further configured to display the adjusted setpoint to a user. In an embodiment, the computer hardware is further configured to display the setpoint without the adjustment to the setpoint optimization adjustment to a user. In an embodiment, the computer hardware is further configured display the setpoint with some of the adjustment to the setpoint optimization adjustment.

In an embodiment, the method further comprises a humidity sensor configured to measure humidity inside of the house over time. In an embodiment, the adjustment to the setpoint optimization adjustment is further based on the inside humidity measurements. In an embodiment, the HVAC system is programmable. In an embodiment, the computer hardware is further configured to send the data to the programmable HVAC system to adjust a setpoint of the programmable HVAC system in response to the adjustment to the setpoint optimization adjustment.

Certain embodiments disclose a method to adjust variable thermostats to reduce energy usage and to maintain comfort levels for occupants of a house. The method comprises receiving, at one or more server computers comprising computer hardware, measurements of temperature inside of the house over time from a thermostat, the one or more servers communicating with the thermostat via a network, the thermostat configured to control at least one heating, ventilation, and air conditioning (HVAC) system that conditions the house; recording, with the one or more server computers, manual inputs to the thermostat from the occupants of the house to determine acclimatization to temperature of the occupants; calculating, with the one or more server computers, a perceived setpoint adjustment based on the inside temperature measurements, outside humidity measurements, and the acclimatization of the occupants; and sending, with the one or more server computers, data to the thermostat to adjust one or more of a setpoint of the thermostat and a run time of the HVAC system in response to the perceived setpoint adjustment.

In an embodiment, the method further comprises receiving, at the one or more server computers, measurements of humidity inside of the house over time, wherein the perceived setpoint adjustment is further based on the inside humidity measurements.

In an embodiment, the method further comprises displaying the adjusted setpoint and the adjusted run time.

In an embodiment, the method further comprises displaying the setpoint without the perceived setpoint adjustment.

In an embodiment, the method further comprises displaying the setpoint with some the perceived setpoint adjustment.

In an embodiment, the perceived temperature is further based on an acclimatization of a peer group to which the occupants belong.

In an embodiment, the peer group is based on demographics of the occupants.

In an embodiment, the peer group is based on characteristics of the house.

In an embodiment, the perceived temperature is further based on a regional acclimatization.

In an embodiment, the method further comprises sending, with the one or more server computers, the data to a programmable HVAC system to adjust a setpoint of the programmable HVAC system in response to the perceived setpoint adjustment.

Certain embodiments disclose a system to adjust variable thermostats to reduce energy usage and to maintain comfort levels for occupants of a house. The system comprises a thermostat operatively connected to a heating, ventilation, and air conditioning (HVAC) system that conditions the house; an electronic storage medium comprising stored data of a plurality of inside temperature measurements taken within the house over time; and computer hardware configured to communicate with the electronic storage medium and the thermostat, the computer hardware further configured to: record manual inputs to the thermostat from the occupants of the house to determine acclimatization to temperature of the occupants; calculate a perceived setpoint adjustment based on the inside temperature measurements, outside humidity measurements, and the acclimatization of the occupants; and send data to the thermostat to adjust one or more of a setpoint of the thermostat and a run time of the HVAC system in response to the perceived setpoint adjustment.

In an embodiment, a humidity sensor is configured to measure humidity over time inside of the house, wherein the perceived setpoint adjustment is further based on the inside humidity measurements. In an embodiment, the computer hardware is further configured to display the adjusted setpoint and the adjusted run time. In an embodiment, the computer hardware is further configured to display the setpoint without the perceived setpoint adjustment. In an embodiment, the computer hardware is further configured to display the setpoint with some of the perceived setpoint adjustment. In an embodiment, the perceived temperature is further based on an acclimatization of a peer group to which the occupants belong.

In an embodiment, the peer group is based on demographics of the occupants. In an embodiment, the peer group is based on characteristics of the house. In an embodiment, the perceived temperature is further based on a regional acclimatization. In an embodiment, the HVAC system is programmable and wherein the computer hardware is further configured to send the data to the programmable HVAC system to adjust a setpoint of the programmable HVAC system in response to the perceived setpoint adjustment.

Certain embodiments disclose a method to adjust variable thermostats to reduce energy usage and to maintain comfort levels for occupants of a house. The method comprises receiving, at one or more server computers comprising computer hardware, measurements of inside temperature of the house over time from a thermostat, the one or more servers communicating with the thermostat via a network, the thermostat configured to control at least one heating, ventilation, and air conditioning (HVAC) system that conditions the house, the HVAC system having a run cycle that includes a heating or cooling run time and a fan delay; determining, with the one or more server computers, a duration of a previous run cycle of the HVAC system based on the measurements of the inside temperature and settings of the thermostat; determining, with the one or more server computers, a change in temperature inside of the house over the previous run cycle; and adjusting, with the one or more server computers, a duration of the fan delay of a next run cycle to reduce energy consumption, the adjustment based on one or more of the duration of the previous run cycle, the inside temperature, the outside temperature, the change in temperature, and a time of day.

In an embodiment, the method further comprises receiving measurements of inside humidity of the house over time from a humidity sensor. In an embodiment, the adjustment is further based on the inside humidity. In an embodiment, the method further comprises receiving measurements of outside temperature over time and outside humidity over time. In an embodiment, the adjustment is further based on one or more of the outside temperature and the outside humidity. In an embodiment, the HVAC system includes a source of heating or cooling and a ventilation fan, and the fan delay comprises a time between turning off the source of heating or cooling and turning off the ventilation fan.

Certain embodiments disclose a system to adjust variable thermostats to reduce energy usage and to maintain comfort levels for occupants of a house. The system comprises a heating, ventilation, and air conditioning (HVAC) system that conditions the house, the HVAC system having a run cycle that includes a heating or cooling run time and a fan delay; a thermostat operatively connected to the HVAC system; an electronic storage medium comprising stored data of a plurality of inside temperature measurements taken within the house; and computer hardware configured to communicate with the electronic storage medium and the thermostat, the computer hardware further configured to receive measurements of inside temperature of the house over time from a thermostat; determine a duration of a previous run cycle of the HVAC system based on the measurements of the inside temperature and settings of the thermostat; determine a change in temperature inside of the house over the previous run cycle; and adjust a duration of the fan delay of a next run cycle to reduce energy consumption, the adjustment based on one or more of the duration of the previous run cycle, the inside temperature, the outside temperature, the change in temperature, and a time of day.

In an embodiment, the computer hardware is further configured to receive measurements of inside humidity of the house over time from a humidity sensor. In an embodiment, the adjustment is further based on the inside humidity. In an embodiment, the computer hardware is further configured to receive measurements of outside temperature over time and outside humidity over time. In an embodiment, the adjustment is further based on one or more of the outside temperature and the outside humidity. In an embodiment, the HVAC system includes a source of heating or cooling and a ventilation fan, and the fan delay comprises a time between turning off the source of heating or cooling and turning off the ventilation fan.

For purposes of summarizing the disclosure, certain aspects, advantages and novel features of the inventions have been described herein. It is to be understood that not necessarily all such advantages may be achieved in accordance with any particular embodiment of the invention. Thus, embodiments of the invention may be carried out in a manner that achieves one advantage or group of advantages as taught herein without necessarily achieving other advantages as may be taught or suggested herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example of an overall environment in which an embodiment of the invention may be used.

FIG. 2 shows a high-level illustration of the architecture of a network showing the relationship between the major elements of one embodiment of the subject invention.

FIGS. 3a, 3band 3care simplified schematics of central chiller HVAC systems used in multi-unit buildings.

FIG. 4 shows a high-level schematic of the thermostat used as part of an embodiment of the subject invention.

FIG. 5 shows one embodiment of the database structure used as part of an embodiment of the subject invention.

FIGS. 6aand 6billustrate pages of a website that may be used with an embodiment of the subject invention.

FIGS. 7a, 7b, 7c, 7d, 7e, 7fand 7gare flowcharts showing the steps involved in the operation of different embodiments of the subject invention.

FIG. 8 is a flowchart that shows how the invention can be used to select different HVAC settings based upon its ability to identify the location of a potential occupant using a mobile device connected to the system.

FIG. 9 is a flowchart that shows how the invention can be used to select different HVAC settings based upon its ability to identify which of multiple potential occupants is using the mobile device connected to the system.

FIGS. 10aand 10bshow how comparing inside temperature and outside temperature and other variables for a given conditioned space permits calculation of dynamic signatures.

FIG. 11 is a flow chart for a high level version of the process of calculating the appropriate just-in-time turn-on time for the HVAC system in a given conditioned space.

FIG. 12 is a more detailed flowchart listing the steps in the process of calculating the appropriate turn-on time in a given conditioned space for a just-in-time event.

FIGS. 13a, 13b, 13cand 13dshow the steps shown in the flowchart inFIG. 12 in the form of a graph of temperature and time.

FIG. 14 shows a table of some of the data used by an embodiment of the subject invention to predict temperatures.

FIG. 15 shows an embodiment of the subject invention as applied in a specific conditioned space on a specific day.

FIG. 16 shows an embodiment of the subject invention as applied in a different specific conditioned space on a specific day.

FIGS. 17, 17-1 and 17-2 show a table of predicted rates of change in temperature inside a given conditioned space for a range of temperature differentials between inside and outside.

FIG. 18 shows how manual inputs can be recognized and recorded by an embodiment of the subject invention.

FIG. 19 shows how an embodiment of the subject invention uses manual inputs to interpret manual overrides and make short-term changes in response thereto.

FIG. 20 shows how an embodiment of the subject invention uses manual inputs to make long-term changes to interpretive rules and to setpoint scheduling.

FIG. 21 is a flow chart illustrating the steps involved in generating a demand reduction event for a given subscriber.

FIG. 22 is a flow chart illustrating the steps involved in confirming that a demand reduction event has taken place.

FIG. 23 is a representation of the movement of messages and information between the components of an embodiment of the subject invention.

FIGS. 24aand 24bshow graphical representations of inside and outside temperatures in two different conditioned spaces, one with high thermal mass and one with low thermal mass.

FIGS. 25aand 25bshow graphical representations of inside and outside temperatures in the same conditioned spaces as inFIGS. 24aand 24b, showing the cycling of the air conditioning systems in those conditioned spaces.

FIGS. 26aand 26bshow graphical representations of inside and outside temperatures in the same conditioned space as inFIGS. 24aand 25a, showing the cycling of the air conditioning on two different days in order to demonstrate the effect of a change in operating efficiency on the parameters measured by the thermostat.

FIGS. 27aand 27bshow the effects of employing a pre-cooling strategy in two different conditioned spaces.

FIGS. 28aand 28bshow graphical representations of inside and outside temperatures in two different conditioned spaces in order to demonstrate how the system can correct for erroneous readings in one conditioned space by referencing readings in another.

FIG. 29 is a flowchart illustrating the steps involved in calculating the effective thermal mass of a conditioned space using an embodiment of the subject invention.

FIG. 30 is a flowchart illustrating the steps involved in determining whether an HVAC system has developed a problem that impairs efficiency using an embodiment of the subject invention.

FIG. 31 is a flowchart illustrating the steps involved in correcting for erroneous readings in one conditioned space by referencing readings in another using an embodiment of the subject invention.

FIG. 32 shows the conventional programming of a programmable thermostat over a 24-hour period.

FIG. 33 shows the programming of a programmable thermostat over a 24-hour period using ramped setpoints.

FIG. 34 shows the steps required for the core function of the ramped setpoint algorithm.

FIG. 35 shows a flowchart listing steps in the process of deciding whether to implement the ramped setpoint algorithm using an embodiment of the subject invention.

FIG. 36 shows the browser as seen on the display of the computer used as part of an embodiment of the subject invention.

FIG. 37 is a flowchart showing the steps involved in the operation of one embodiment of the subject invention.

FIG. 38 is a flowchart that shows how an embodiment of the invention can be used to select different HVAC settings based upon its ability to identify which of multiple potential occupants is using the computer attached to the system.

FIG. 39 is a block diagram of network architecture for an acclimatization-based system to dynamically adjust variable thermostat settings, according to certain embodiments.

FIG. 40 illustrates an exemplary database structure for an acclimatization-based system to dynamically adjust variable thermostat settings, according to certain embodiments.

FIG. 41 is a flow chart illustrating a process to recognize and record manual inputs, according to certain embodiments.

FIG. 42 is a flow chart illustrating a process to use manual inputs to interpret manual overrides and make short-term changes in response thereto, according to certain embodiments.

FIG. 43 is a flow chart illustrating a process to use manual inputs to alter long-term changes to interpretative rules and setpoint scheduling, according the certain embodiments.

FIG. 44 is a flow chart illustrating a process to dynamically adjust thermostat settings and HVAC run time based on occupant's acclimatization, according to certain embodiments.

FIG. 45 is a flow chart illustrating a process using historical data that indicates acclimatization to temperature and humidity to dynamically adjust temperature based on current humidity, according to certain embodiments.

FIG. 46 is a flow chart illustrating a process to adjust a variable thermostat according to relative temperature to reduce energy usage and to maintain comfort levels, according to certain embodiments.

FIG. 47 is a flow chart illustrating a process to propose a setpoint optimization change to the setpoint of a thermostat, according to certain embodiments.

DETAILED DESCRIPTION

FIG. 1 shows an example of anoverall environment100 in which an embodiment of the invention may be used. Theenvironment100 includes aninteractive communication network102 withcomputers104 connected thereto. Also connected to network102 aremobile devices105, and one ormore server computers106, which store information and make the information available tocomputers104 andmobile devices105. Thenetwork102 allows communication between and among thecomputers104,mobile devices105 andservers106.

Presently preferrednetwork102 comprises a collection of interconnected public and/or private networks that are linked to together by a set of standard protocols to form a distributed network. Whilenetwork102 is intended to refer to what is now commonly referred to as the Internet, it is also intended to encompass variations which may be made in the future, including changes additions to existing standard protocols. It also includes various networks used to connect mobile and wireless devices, such as cellular networks.

When a user of an embodiment of the subject invention wishes to access information onnetwork102 usingcomputer104 ormobile device105, the user initiates connection from hiscomputer104 ormobile device105. For example, the user invokes a browser, which executes oncomputer104 ormobile device105. The browser, in turn, establishes a communication link withnetwork102. Once connected to network102, the user can direct the browser to access information onserver106.

Theservers106 that provide offerings on the World Wide Web are typically called websites. A website is often defined by an Internet address that has an associated electronic page. Generally, an electronic page is a document that organizes the presentation of text graphical images, audio and video.

In addition to delivering content in the form of web pages,network102 may also be used to deliver computer applications that have traditionally been executed locally oncomputers104. This approach is sometimes known as delivering hosted applications, or SaaS (Software as a Service). Where a network connection is generally present, SaaS offers a number of advantages over the traditional software model: only a single instance of the application has to be maintained, patched and updated; users may be able to access the application from a variety of locations, etc. Hosted applications may offer users most or all of the functionality of a local application without having to install the program, simply by logging into the application through a browser.

In addition to the Internet, thenetwork102 can comprise a wide variety of interactive communication media. For example,network102 can include local area networks, interactive television networks, telephone networks, wireless data systems, two-way cable systems, and the like.

Computers

104 can also be microprocessor-controlled home entertainment equipment including advanced televisions, televisions paired with home entertainment/media centers, and wireless remote controls.

Computers

104 andmobile devices105 may utilize a browser or other application configured to interact with the World Wide Web or other remotely served applications. Such browsers may include Microsoft Explorer, Mozilla, Firefox, Opera, Chrome or Safari. They may also include browsers or similar software used on handheld, home entertainment and wireless devices.

The storage medium may comprise any method of storing information. It may comprise random access memory (RAM), electronically erasable programmable read only memory (EEPROM), read only memory (ROM), hard disk, floppy disk, CD-ROM, optical memory, or other method of storing data.

Computers

104 and106 andmobile devices105 may use an operating system such as Microsoft Windows, Apple Mac OS, Linux, Unix or the like, or may use simpler embedded operating systems with limited ability to run applications.

Computers

106 may include a range of devices that provide information, sound, graphics and text, and may use a variety of operating systems and software optimized for distribution of content via networks.

Mobile devices

105 can also be handheld and wireless devices such as personal digital assistants (PDAs), cellular telephones and other devices capable of accessing the network.Mobile devices105 can use a variety of means for establishing the location of each device at a given time. Such methods may include the Global Positioning System (GPS), location relative to cellular towers, connection to specific wireless access points, or other means

FIG. 2 illustrates in further detail the architecture of the specific components connected to network102 showing the relationship between the major elements of one embodiment of the subject invention. Attached to the network arethermostats108 andcomputers104 of various users. Connected tothermostats108 areindividual air handlers110. Each air handler may supply conditioned air to an entire apartment or unit, or multiple air handlers may be used in a given space. Each user may be connected to theserver106 via wired or wireless connection such as Ethernet or a wireless protocol such as IEEE 802.11, via a modem orgateway112 that connects the computer and thermostat to the Internet via a broadband connection such as a digital subscriber line (DSL), cellular radio or other method of connection to the World Wide Web. Thethermostats108 may be connected locally via a wired connection such as Ethernet or Homeplug or other wired network, or wirelessly via IEEE802.11, 802.15.4, or other wireless network, which may include agateway112.Server106 contains content to be served as web pages and viewed bycomputers104, software to managethermostats108, software to manage the operation ofthermostats108, as well as databases containing information used by the servers.

Also attached to the Network may becellular radio towers120, or other means to transmit and receive wireless signals in communication withmobile devices105. Such communication may use GPRS, GSM, CDMA, EvDO, EDGE or other protocols and technologies for connecting mobile devices to a network.

FIG. 3ashows a simplified high-level schematic of a representative sample of one kind of chiller-based air conditioning system with which the subject invention may be used. The system includes two water loops.Secondary loop202 absorbs heat from inside the conditioned space;primary loop204 transfers that heat to the outside air.Chiller206 is where the heat is exchanged between the two loops.

Pumps

208aand208bforce water to move through the primary and secondary loops. Heat is transferred to the outside air incooling tower210, wherefan212 blows air past the water that has absorbed heat in the chiller. (Some system architectures use heat exchangers inside the cooling tower; others directly expose the water to the air.)

Water in the secondary loop emerges from the chiller and is sent to through pipes toindividual air handlers110. In some implementations, the chilled water always flows through the same path regardless of the settings ofthermostats108. Ifthermostat108 is in cooling mode, then fan214 blows air from inside the conditioned unit across the air handler, transferring heat from the air to the water being transported through theair handler110. Ifthermostat108 is in off mode, then fan214 does not move air across the air handler, and negligible heat transfer takes place. In the simplest case, the thermostat is binary: the fan is off or it is on. Alternatively, the fan may have two or more discrete speeds, or may even be controlled by a potentiometer that permits infinite adjustment of speed within the fan's range.

FIG. 3bshows a schematic of an alternative chiller-based HVAC system with which the subject invention may be used. The system architecture is roughly similar to the system shown inFIG. 3a, but in this embodiment, there arevalves216 that may be used to divert chilled water away fromair handlers110. These valves may be controlled bythermostats108. This approach may be used in order to, for example, allow users to run the fan without “running the air conditioner”, which may increase comfort at lower cost due the well-known value of moving air in order to increase comfort in warm conditions.

With the systems shown inFIGS. 3aand 3b, it is possible to allocate at least a portion the energy use associated with an individual air handler with data generated by or otherwise available at each individual thermostat.

FIG. 3cshows a schematic of an alternative chiller-based HVAC system with which the subject invention may be used. The system architecture is roughly similar to that shown inFIGS. 3aand 3b, but in this embodiment, there are also means for measuring the temperature of the water in the secondary loop at at least two places:temperature sensor220a measures the temperature of the water in the secondary loop prior to circulation through heat exchangers110 (WT1);temperature sensor220b measures the temperature of the water in the secondary loop after circulation through heat exchangers110 (WT2). The difference between these two (ΔWT) gives a measure of the amount of cooling accomplished by the loop overall. When the air handlers in each unit in the loop are all off and/or when the valves determining whether to route the loop through the air handlers are all set to bypass, AWT will be relatively small, and this baseline value may be thought of as system overhead or deadweight loss. When the air handlers in each unit in the loop are all on and/or when the valves determining whether to route the loop through the air handlers are all set to send the water through each air handler, AWT will be relatively large. The difference between the two cases represents a measure of the work done by the HVAC system, and can be used to calculate the energy use attributable to the units in a given loop.

FIG. 3calso includes ameans222 for varying the speed of the fan incooling tower210. Some chiller-based systems increase efficiency under dynamic load conditions by varying the speed of the motor driving the fan (and/or by increasing or decreasing the speed with which water is pumped through the primary and/or secondary loops). A variation on the system shown inFIG. 3cwould be a system in which the flow rate of the water circulating between the central chiller and the individual occupancy units may be varied by increasing or decreasing the work done by the pumps that circulate the water.

FIG. 4 shows a high-level block diagram ofthermostat108 used as part of an embodiment of the subject invention.Thermostat108 includes temperature sensing means252, which may be a thermistor, thermal diode or other means commonly used in the design of electronic thermostats. It includes amicroprocessor254,memory256, adisplay258, apower source260, arelay262, which turns the blower motor in the air handler on and off in response to a signal from the microprocessor, and contacts by which the relay is connected to the wires that lead to the blower motor. In systems in which the thermostat controls a valve that determines the flow of water through the air handler, a relay, potentiometer or other device will control the valve.

To allow the thermostat to communicate bi-directionally with the computer network, the thermostat also includesmeans264 to connect the thermostat to a local computer or to a wireless network. Such means could be in the form of Ethernet, wireless protocols such as IEEE 802.11, IEEE 802.15.4, Bluetooth, cellular systems such as CDMA, GSM and GPRS, or other wireless protocols. Communication means264 may include one ormore antennae266.Thermostat108 may also includecontrols268 allowing users to change settings directly at the thermostat, but such controls are not necessary to allow the thermostat to function for all parts of part of the subject invention. Such controls may consist of buttons, switches, dials, etc.Thermostat108 may also include means to vary additional system parameters, such as variable fan speed, opening and closing valves that regulate the flow of the heat transfer medium, etc.Thermostat108 should be capable of communicating such parameters toservers106, and of allowing remote control of such parameters as well.

The data used to manage the subject invention is stored on one ormore servers106 within one or more databases. As shown inFIG. 5, theoverall database structure300 may includetemperature database400,thermostat settings database500,energy bill database600, chiller systemvariable database700,weather database800,user database900,transaction database1000, product andservice database1100,user location database1200 and such other databases as may be needed to support these and additional features. Alternatively, data may be managed using a distributed file system such as Apache Hadoop.

Users ofconnected thermostats108 may create personal accounts. Each user's account will store information indatabase900, which tracks various attributes relative to users of the system. Such attributes may include the location and size of the user's unit within a building (e.g., the southwest corner, 11^thfloor); the specific configuration of the air handler and other unit-specific equipment in the user's unit; the user's preferred temperature settings, whether the user is a participant in a demand response program, etc.

User personal accounts may also associate one or more mobile devices with such personal accounts. For mobile devices with the capability for geopositioning awareness, these personal accounts will have the ability log such positioning data over time indatabase1200.

In one embodiment, a background application installed onmobile device105 shares geopositioning data for the mobile device with the application running onserver106 that logs such data. Based upon this data,server106 runs software that interprets said data (as described in more detail below).Server106 may then, depending on context, (a) transmit a signal tothermostat108 changing setpoint because occupancy has been detected at a time when the system did not expect occupancy (or vice versa); or (b) transmit a message tomobile device105 that asks the user if the server should change the current setpoint, alter the overall programming of the system based upon a new occupancy pattern, etc. Such signaling activity may be conducted via email, text message, pop-up alerts, voice messaging, or other means.

FIGS. 6aand 6billustrate a website that may be provided to assist users and others to interact with an embodiment of the subject invention. The website will permit thermostat users to perform through the web browser substantially all of the programming functions traditionally performed directly at the physical thermostat, such as choosing temperature set points, the time at which the thermostat should be at each set point, etc. Preferably the website will also allow users to accomplish more advanced tasks such as allow users to program in vacation settings for times when the HVAC system may be turned off or run at more economical settings, and to set macros that will allow changing the settings of the temperature for all periods with a single gesture such as a mouse click.

As shown inFIG. 6a,screen351 of website350 displayscurrent temperature352 as sensed bythermostat108. Clicking on “up”arrow354 raises thesetpoint358; clicking thedown arrow356 lowerssetpoint358.Screen351 may also convey information about the outside weather conditions, such as agraphic representation360 of the sun, clouds, etc. In conditioned spaces with multiple thermostats,screen351 may allow users to select from multiple devices to adjust or monitor. Users will be able to usescreen351 by selecting, for example,master bedroom thermostat362, livingroom thermostat364,game room thermostat366, orbasement thermostat368.

As shown inFIG. 6b,screen370 allows users to establish programming schedules. Row372 shows a 24-hour period.Programming row374 displays various programming periods and when they are scheduled, such as away setting376, which begins at approximately8AM and runs until approximately 5:30 PM. When the away setting376 is highlighted, the user can adjust the starting time and ending time for the setting by dragging thebeginning time378 to the left to choose an earlier start time, and dragging it to the right to make it later. Similarly, the user can dragending time380 to the left to make it earlier, and to the right to make it later. While away setting376 is highlighted, the user can also changeheating setpoint382 by clicking on uparrow384 or downarrow386, and coolingsetpoint388 by clicking on uparrow390 or downarrow392. The user can save the program by clicking on savebutton394.

FIG. 7aillustrates how an embodiment of the subject invention can be used to calculate the cost of operation of the chiller and other common portions of the HVAC system to be allocated to a given conditioned space using the cycle time of the blower for the air handler in that conditioned space.

Instep402 the server retrieves fromdatabase300 the cycling data for a given air handler for a specified time interval (such as for one minute). Such data could indicate that for the interval in question the fan in the air handler was “on,” or that it was “off”. Instep404 the server retrieves fromdatabase300 the cost per minute of run time for the air handler. This number is likely to be a function of several variables, which may include the cost per kilowatt hour of electricity (or the cost of other energy sources), the operating cost per time interval for the chiller unit associated with the air handler, and the number (and perhaps size) of other air handlers also associated with the same chiller. For example, a given chiller may be connected to 75 air handlers, and cost $50 per hour to operate when electricity costs $0.09/kWh. Instep406 the server computes the cost to operate the individual air handler for the specified time interval. For example, if during a given minute the cost to operate a given chiller is $1.50, and during that minute 20 air handlers are operating, then the chiller cost for each air handler would be $0.075 for that minute. Instep408 the server determines whether there are additional time intervals for which operating cost is to be calculated. If there are additional intervals, the server returns to step402. If not, instep410 the server calculates the allocated HVAC cost for all of the individual time intervals.

FIG. 7billustrates how an embodiment of the subject invention can be used to calculate the cost of operation of the HVAC system to be allocated to a given conditioned space using the cycle time of the blower for the air handler in that conditioned space plus variable speed data for that blower.

Instep502 the server retrieves fromdatabase300 the cycling data for a given air handler for a specified time interval (such as for one minute). Such data could indicate that for the interval in question the fan in the air handler was “on,” or that it was “off”. Instep504 the server retrieves fromdatabase300 values for the speed of the fan in the air handler for the specified time interval. Such data may be expressed as a percentage of maximum speed, as a direct measurement of revolutions per minute, as a measurement of the current drawn by the electric motor powering the fan, or some other measurement. Instep506 the server retrieves fromdatabase300 the cost per minute of run time for the air handler given the actual fan speed as retrieved instep504. This number is also likely to be a function of variables including the cost per kilowatt/hour of electricity, the overall operating cost per time interval for the chiller unit associated with the air handler, and the number (and perhaps size) of other air handlers also associated with the same chiller. Instep508 the server computes the cost to operate the individual air handler for the specified time interval. Instep510 the server determines whether there are additional time intervals for which operating cost is to be calculated. If there are additional intervals, the server returns to step502. If not, instep512 the server calculates the allocated HVAC cost for all of the individual time intervals.

FIG. 7cillustrates how an embodiment of the subject invention can be used to calculate the cost of operation of the HVAC system to be allocated to a given conditioned space using the cycle time of the blower for the air handler in that conditioned space plus data from other blowers in other units. This approach permits calculation of variable operating costs—that is, it permits the amount allocated to a given unit to vary as actual operating cost change with the demands placed on the system by other units.

Instep602 the server retrieves fromdatabase300 the cycling data for the first air handler to be evaluated for a specified time interval (such as for one minute). Such data could indicate that for the interval in question the fan in the air handler was “on,” or that it was “off”. Instep604 the server retrieves fromdatabase300 the cycling data for the next air handler to be evaluated for the specified time interval. The server continues to retrieve cycling data for additional air handlers until instep606 the server retrieves fromdatabase300 the cycling data for the last air handler to be evaluated.

Instep608 the server retrieves additional data to be used to allocate overall operating costs during the specified interval. Such data may include static data such as the square footage of each separate unit in the building, the relative location of each unit (because units with more south and west-facing windows are likely to have higher cooling loads, etc.), the size of each air handler and/or its included blower motor, or dynamic data such as the actual and/or predicted temperature rise (in the case of cooling) or drop (in the case of heating) for each air handler. Instep610 the server retrieves fromdatabase300 the cost per minute of run time for the complete chiller system for the time increment being evaluated. This number may be calculated or actually measured, and will likely be a function of the cost of a kilowatt-hour of electricity, the overall operating cost per time interval for the chiller unit associated with the air handler, and the number (and perhaps size) of other air handlers also associated with the same chiller.

Instep612 the server calculates the cost of operating the first air handler for the time increment being evaluated. This cost will likely be a function of the overall cost per minute calculated instep610, as well as the other parameters retrieved in steps602-608. Specifically, the method described inFIG. 7cis intended to vary the allocated cost for a given unit during a given interval based upon the load placed upon the chiller not just by that unit, but by other units as well. This approach would allow equitable full allocation of chiller operating costs regardless of the number of units operating at a given time. Alternatively, the sources for the data used for this calculation may be sensor data sourced from the controlled system rather than stored values retrieved from a database.

Instep614 the server repeats the process followed instep612 for the same time increment for the next air handler to be evaluated.

The server continues to calculate operating costs for additional time increments until instep616 the server calculates operating costs for the last air handler to be evaluated for that time increment.

Instep618 the server determines whether additional time segments will require evaluation. If more time segments do require calculation, the server returns to step602. If not, the server proceeds to step620, in which it calculates the total allocated operating cost allocated to the first air handler for the relevant intervals.

The process disclosed inFIG. 7cmay be repeated for each of the air handlers connected to a given chiller.

FIG. 7dillustrates how an embodiment of the subject invention can be used to calculate the cost of operation of the HVAC system to be allocated to a given conditioned space using the cycle time and fan speed of the blower for the air handler in that conditioned space plus data from other blowers in other units.

Instep702 the server retrieves fromdatabase300 the cycling data for the first air handler to be evaluated for a specified time interval (such as for one minute). Such data could indicate that for the interval in question the fan in the air handler was “on,” or that it was “off”. Instep704 the server retrieves fromdatabase300 values for the speed of the fan in the air handler for the specified time interval. Such data may be expressed as a percentage of maximum speed, as a direct measurement of revolutions per minute, as a measurement of the current drawn by the electric motor powering the fan, or some other measurement.

Instep706 the server retrieves fromdatabase300 the cycling data for the next air handler to be evaluated for the specified time interval, and instep708 the server retrieves fromdatabase300 values for the speed of the fan in the next air handler for the specified time interval. The server continues to retrieve cycling data and fan speed values for additional air handlers until in

steps

710 and712 the server retrieves fromdatabase300 the cycling and fan speed data for the last air handler to be evaluated.

Instep714 the server retrieves additional data that may be used to allocate overall operating costs during the specified interval. Such data may include static data such as the square footage of each separate unit in the building, the relative location of each unit (because units with more south and west-facing windows are likely to have higher loads, etc.), the size of each air handler and/or its included blower motor, or dynamic data such as the actual or predicted temperature rise (in the case of cooling) or drop (in the case of heating) for each air handler.

Instep716 the server retrieves fromdatabase300 the cost per minute of run time for the complete chiller system for the time increment being evaluated. This number may be calculated or actually measured, and will likely be a function of the cost of a kilowatt-hour of electricity, the overall operating cost per time interval for the chiller unit associated with the air handler, and the number (and perhaps size) of other air handlers also associated with the same chiller. Alternatively, the sources for the data used for this calculation may be sensor data sourced from the controlled system rather than stored values retrieved from a database.

Instep718 the server calculates the cost of operating the first air handler for the time increment being evaluated. This cost will likely be a function of the overall cost per minute calculated instep716, as well as the other parameters retrieved in steps702-714. Specifically, the method described inFIG. 7dis intended to vary the allocated cost for a given unit during a given interval based upon the load placed upon the chiller not just by that unit, but by other units as well. This approach would allow equitable full allocation of chiller operating costs regardless of the number of units operating at a given time, even where the individual units employ variable-speed fans.

Instep720 the server calculates the cost of operating the next air handler for the time increment being evaluated. The server continues to calculate operating costs for additional air handlers until instep722 the server calculates operating costs for the last air handler to be evaluated for that time increment.

Instep724 the server determines whether there are additional time intervals for which operating costs are to be calculated. If there are additional intervals, the server returns to step702. If not, instep726 the server calculates the allocated HVAC cost for all of the individual time intervals.

FIG. 7eillustrates how an embodiment of the subject invention can be used to calculate the cost of operation of the HVAC system to be allocated to a given conditioned space where the thermostat for a given unit operates by opening and closing a valve that determines whether the coolant insecondary loop202 circulates through air handler in that conditionedspace110 plus data from other valves connected to the air handlers in other units.

Instep802 the server retrieves fromdatabase300 the cycling data for a given air handler for a specified time interval (such as for one minute). Such data could indicate that for the interval in question the valve that determines whether secondary coolant is circulated through the air handler was “on,” or “off”. Instep804 the server retrieves fromdatabase300 values for the speed of the fan in the air handler for the specified time interval. Such data may be expressed as a percentage of maximum speed, as a direct measurement of revolutions per minute, as a measurement of the current drawn by the electric motor powering the fan, or some other measurement. Instep806 the server retrieves fromdatabase300 the cost per minute of run time for the air handler given both the valve status and actual fan speed as retrieved instep804. This number is also likely to be a function of the cost per kilowatt/hour of electricity, the overall operating cost per time interval for the chiller unit associated with the air handler, and the number (and perhaps size) of other air handlers also associated with the same chiller. Instep808 the server computes the cost to operate the individual air handler for the specified time interval. Instep810 the server determines whether there are additional time intervals for which operating cost is to be calculated. If there are additional intervals, the server returns to step802. If not, instep812 the server calculates the allocated HVAC cost for all of the individual time intervals.

FIG. 7fillustrates how an embodiment of the subject invention can be used to calculate the cost of operation of the HVAC system to be allocated to a given conditioned space whereserver106 has access to information regarding the overall change in temperature for the coolant insecondary loop202.

This information may come from

sensors

220a and220b. This information can be useful because the energy required to operate the chiller may be expected to vary based upon the load placed on it by all of the connected air handlers. A large temperature rise from inlet to outlet may be expected to require the chiller to use more energy in order to reject the heat the air handlers add to the coolant; a minor temperature rise in coolant temperature will require less energy to dissipate. If may therefore be advantageous to allow the overall operating costs being allocated to individual air handlers to vary based upon overall operating costs as approximated by the temperature rise in the secondary coolant.

In step902 the server retrieves information about absolute and/or relative coolant temperatures as it enters and leaves the air handlers being evaluated.

Instep904 the server retrieves fromdatabase300 the cycling data for the first air handler to be evaluated for a specified time interval (such as for one minute). Such data could indicate that for the interval in question the fan in the air handler was “on,” or that it was “off”. Instep906 the server retrieves fromdatabase300 values for the speed of the fan in the air handler for the specified time interval. Such data may be expressed as a percentage of maximum speed, as a direct measurement of revolutions per minute, as a measurement of the current drawn by the electric motor powering the fan, or some other measurement.

Instep908 the server retrieves fromdatabase300 the cycling data for the next air handler to be evaluated for the specified time interval, and instep910 the server retrieves fromdatabase300 values for the speed of the fan in the next air handler for the specified time interval. The server continues to retrieve cycling data and fan speed values for additional air handlers until in

steps

912 and914 the server retrieves fromdatabase300 the cycling and fan speed data for the last air handler to be evaluated.

Instep916 the server retrieves additional data that may be used to allocate overall operating costs during the specified interval. Such data may include static data such as the square footage of each separate unit in the building, the relative location of each unit (because units with more south and west-facing windows are likely to have higher loads, etc.), the size of each air handler and/or its included blower motor, or dynamic data such as the actual and/or predicted temperature rise (in the case of cooling) or drop (in the case of heating) for each air handler.

Instep918 the server retrieves fromdatabase300 the cost per minute of run time for the complete chiller system for the time increment being evaluated. This number may be calculated or actually measured, and will likely be a function of the cost of a kilowatt-hour of electricity, the overall operating cost per time interval for the chiller unit associated with the air handler, and the number (and perhaps size) of other air handlers also associated with the same chiller.

Instep920 the server calculates the cost of operating the first air handler for the time increment being evaluated. This cost will likely be a function of the overall cost per minute calculated instep922, as well as the other parameters retrieved in steps902-916. Specifically, the method described inFIG. 7fis intended to vary the allocated cost for a given unit during a given interval based upon the load placed upon the chiller not just by that unit, but by other units as well. This approach would allow equitable full allocation of chiller operating costs regardless of the number of units operating at a given time, even where the individual units employ variable-speed fans.

Instep922 the server calculates the cost of operating the next air handler for the time increment being evaluated. The server continues to calculate operating costs for additional air handlers until instep924 the server calculates operating costs for the last air handler to be evaluated for that time increment.

Instep926 the server determines whether there are additional time intervals for which operating costs are to be calculated. If there are additional intervals, the server returns to step902. If not, instep928 the server calculates the allocated HVAC cost for all of the individual time intervals.

FIG. 7gillustrates how an embodiment of the subject invention can be used to calculate the cost of operation of the HVAC system to be allocated to a given conditioned space whereserver106 has access to information regarding the speed of the fan or fans used to chill theprimary loop204 ofchiller206.

This information may come from sensors attached to the motor or motors, or from control circuitry that determines the voltage and/or current supplied to the motor, or even from external power sources sued to drive especially large systems. This information can be useful because the energy required to operate the chiller may be expected to vary based upon the load placed on it by all of the connected air handlers. When loads are greater, the fan(s) will have to work harder in order to reject the heat the air handlers add to the secondary loop, which are in turn transferred to the primary loop; a minor temperature rise in secondary loop coolant temperature will require less energy to dissipate, thus permitting the fan(s) to run more slowly. If may therefore be advantageous to allow the overall operating costs being allocated to individual air handlers to vary based upon overall operating costs as approximated by the speed of the fans used to chill the primary loop coolant.

Instep1002 the server retrieves information about the energy consumption associated with operation of themain chiller fans212. Such information may include rotational speed, current draw, diesel fuel flow rate (in the case of diesel-fueled engines turning the fans), or other means of measuring or estimating energy use.

Instep1004 the server retrieves fromdatabase300 the cycling data for the first air handler to be evaluated for a specified time interval (such as for one minute). Such data could indicate that for the interval in question the fan in the air handler was “on,” or that it was “off”. Instep1006 the server retrieves fromdatabase300 values for the speed of the fan in the air handler for the specified time interval. Such data may be expressed as a percentage of maximum speed, as a direct measurement of revolutions per minute, as a measurement of the current drawn by the electric motor powering the fan, or some other measurement.

Instep1008 the server retrieves fromdatabase300 the cycling data for the next air handler to be evaluated for the specified time interval, and instep1010 the server retrieves fromdatabase300 values for the speed of the fan in the next air handler for the specified time interval. The server continues to retrieve cycling data and fan speed values for additional air handlers until in

steps

1012 and1014 the server retrieves fromdatabase300 the cycling and fan speed data for the last air handler to be evaluated.

In step1016 the server retrieves additional data that may be used to allocate overall operating costs during the specified interval. Such data may include static data such as the square footage of each separate unit in the building, the relative location of each unit (because units with more south and west-facing windows are likely to have higher loads, etc.), the size of each air handler and/or its included blower motor, or dynamic data such as the actual or predicted temperature rise (in the case of cooling) or drop (in the case of heating) for each air handler.

Instep1018 the server retrieves fromdatabase300 the cost per minute of run time for the complete chiller system for the time increment being evaluated. This number may be calculated or actually measured, and will likely be a function of the cost of a kilowatt-hour of electricity, the overall operating cost per time interval for the chiller unit associated with the air handler, and the number (and perhaps size) of other air handlers also associated with the same chiller.

Instep1020 the server calculates the cost of operating the first air handler for the time increment being evaluated. This cost will likely be a function of the overall cost per minute calculated instep1022, as well as the other parameters retrieved in steps1002-1016. Specifically, the method described inFIG. 7gis intended to vary the allocated cost for a given unit during a given interval based upon the load placed upon the chiller not just by that unit, but by other units as well. This approach would allow equitable full allocation of chiller operating costs regardless of the number of units operating at a given time, even where the individual units employ variable-speed fans.

Instep1022 the server calculates the cost of operating the next air handler for the time increment being evaluated. The server continues to calculate operating costs for additional air handlers until instep1024 the server calculates operating costs for the last air handler to be evaluated for that time increment.

Instep1026 the server determines whether there are additional time intervals for which operating costs are to be calculated. If there are additional intervals, the server returns to step1002. If not, instep1028 the server calculates the allocated HVAC cost for all of the individual time intervals.

It should be noted that the processes described above in the context of air conditioning and the circulation of a coolant can be applied in other contexts as well, such as a hydronic system in which a heated fluid is circulated, steam-based systems, etc.

Other central-plant HVAC system topologies are also possible. So long as it is possible to measure at least one dynamic aspect of the cost of operating the common aspects of the system, and at least one dynamic aspect of the system that is controlled separately for individual occupancy units, it will be possible to allocate operating costs to some degree based upon such measurements.

In addition to being used to help properly allocate the cost of operating a centralized chiller-based HVAC system, the subject invention may also be used to help enable and encourage owners, tenants and other occupants of units conditioned by such systems to be more energy efficient.

One of the most significant ways to cut HVAC energy use without adversely affecting comfort is to avoid heating and cooling spaces when they are unoccupied. Directly sensing occupancy with motion sensors is common in the hospitality industry, but is more problematic in multi-room contexts. It also requires expensive retrofitting in existing structures.

Adding occupancy detection capability to residential HVAC systems could also add considerable value in the form of energy savings without significant tradeoff in terms of comfort. But the systems used in hotels do not easily transfer to the single-family residential context. Hotel rooms tend to be small enough that a single motion sensor is sufficient to determine with a high degree of accuracy whether or not the room is occupied. A single motion sensor in the average home today would have limited value because there are likely to be many places one or more people could be home and active yet invisible to the motion sensor. The most economical way to include a motion sensor in a traditional programmable thermostat would be to build it into the thermostat itself. But thermostats are generally located in hallways, and thus are unlikely to be exposed to the areas where people tend to spend their time. Wiring a home with multiple motion sensors in order to maximize the chances of detecting occupants would involve considerable expense, both for the sensors themselves and for the considerable cost of installation, especially in the retrofit market. Yet if control is ceded to a single-sensor system that cannot reliably detect presence, the resulting errors would likely lead the homeowner to reject the system.

Although progress in residential HVAC control has been slow, tremendous technological change has come to the tools used for personal communication. When programmable thermostats were first offered, telephones were virtually all tethered by wires to a wall jack. But now a large percentage of the population carries at least one mobile device capable of sending and receiving voice or data or even video (or a combination thereof) from almost anywhere by means of a wireless network. These devices create the possibility that a consumer can, with an appropriate mobile device and a network-enabled HVAC system, control his or her HVAC system even when away from home. But systems that relay on active management decisions by consumers are likely to yield sub-optimal energy management outcomes, because consumers are unlikely to devote the attention and effort required to fully optimize energy use on a daily basis.

Many new mobile devices now incorporate another significant new technology—the ability to geolocate the device (and thus, presumably, the user of the device). One method of locating such devices uses the Global Positioning System (GPS). The GPS system uses a constellation of orbiting satellites with very precise clocks to triangulate the position of a device anywhere on earth based upon arrival times of signals received from those satellites by the device. Another approach to geolocation triangulates using signals from multiple cell phone towers. Such systems can enable a variety of so-called “location based services” to users of enabled devices. These services are generally thought of as aids to commerce like pointing users to restaurants or gas stations, etc.

The subject invention can actually indirectly detect and even anticipate some occupancy changes without a direct occupancy sensor by using information about the behavior and location of users of that space as gathered from other electronic devices used by those actual or potential occupants.

FIG. 8 is a high-level flowchart showing the steps involved in the operation of one embodiment of the subject invention in order to use a mobile device to assist in the process of determining whether to condition a given space for occupancy. Instep1302,mobile device105 transmits geopositioning information toserver106 via the Internet. Instep1304 the server compares the latest geopositioning data point to previous data points in order to determine whether a change in location or vector of movement has occurred. Instep1306 the server evaluates the geopositioning data in order to determine whether the temperature settings for the HVAC system for the structure associated with themobile device105 should be optimized for an unoccupied structure, or for an occupied structure in light of the movement (or lack thereof) in the geopositioning data. If theserver106 determines that the home should be in occupied or “home” mode, then instep1308 the server queriesdatabase300 to determine whetherthermostat108 is already set for home or away mode. Ifthermostat108 is already in home mode, then the application terminates for a specified interval. If the HVAC settings then in effect are intended to apply when the home is unoccupied, then instep1310 the application will retrieve fromdatabase300 the user's specific preferences for how to handle this situation. If the user has previously specified (at the time that the program was initially set up or subsequently modified) that the user prefers that the system automatically change settings under such circumstances, the application then proceeds to step1316, in which it changes the programmed setpoint for the thermostat to the setting intended for the space when occupied. If the user has previously specified that the application should not make such changes without further user input, then instep1312 the application transmits a command to the location specified by the user (generally mobile device105) directing the device display a message informing the user that the current setting assumes an unoccupied space and asking the user to choose whether to either keep the current settings or revert to the pre-selected setting for an occupied home. If the user selects to retain the current setting, then instep1318 the application will write todatabase300 the fact that the user has so elected and terminate. If the user elects to change the setting, then instep1316 the application transmits the revised setpoint to the thermostat. Instep1318 the application writes the updated setting information todatabase300.

If theserver106 determines instep1306 that the home should be in unoccupied or away mode, then instep1350 the server queriesdatabase300 to determine whetherthermostat108 is set for set for home or away mode. Ifthermostat108 is already in home mode, then the application terminates for a specified interval. If the HVAC settings then in effect are intended to apply when the home is occupied, then instep1352 the application will retrieve fromdatabase300 the user's specific preferences for how to handle this situation. If the user has previously specified (at the time that the program was initially set up or subsequently modified) that the user prefers that the system automatically change settings under such circumstances, the application then proceeds to step1358, in which it changes the programmed setpoint for the thermostat to the setting intended for the space when unoccupied. If the user has previously specified that the application should not make such changes without further user input, then instep1354 the application transmits a command to the location specified by the user (generally mobile device105) directing the device display a message informing the user that the current setting assumes an unoccupied space and asking the user to choose whether to either keep the current settings or revert to the pre-selected setting for an occupied home. If the user selects to retain the current setting, then instep1318 the application will write todatabase300 the fact that the user has so elected and terminate. If the user elects to change the setting, then instep1316 the application transmits the revised setpoint to the thermostat. Instep1318 the application writes the updated setting information todatabase300. Ifthermostat108 is already in away mode, the program ends. If it was in home mode, then instep1314

server

108 initiates a state change to putthermostat108 in away mode. In either case, the server then instep1316 writes the state change todatabase300. In each case the server can also send a message to the person who owns the mobile device requesting, confirming or announcing the state change.

FIG. 9 is a flowchart that shows one process by which the subject invention can be used to select different HVAC settings based upon its ability to identify which of multiple potential occupants is using the mobile device attached to the system. The process shown assumes (a) a static hierarchy of temperature preferences as between multiple occupants (that is, that for a given conditioned space,mobile user #1's preferences will always control the outcome ifmobile user #1 is present, thatmobile user #2's preferences yield to #1's, but always prevail overuser #3, etc.); and (b) that there are no occupants to consider who are not associated with a geopositioning-enabled mobile device. Other heuristics may be applied in order to account for more dynamic interactions of preferences, for situations in which some occupants do not have enabled mobile devices, etc.

Instep1402

server

106 retrieves the most recent geospatial coordinates from themobile device105 associated withmobile user #1. Instep1404

server

106 uses current and recent coordinates to determine whethermobile user #1's “home” (or “occupied”) settings should be applied. Ifserver106 determines thatUser #1's home settings should be applied, then instep1406

server

106 applies the correct setting and transmits it to the thermostat(s). Instep1408,server106 writes todatabase300 the geospatial information used to adjust the programming. If after performingstep1404, the server concludes thatmobile user #1's “home” settings should not be applied, then instep1412

server

106 retrieves the most recent geospatial coordinates from themobile device105 associated withmobile user #2. Instep1414

server

106 uses current and recent coordinates to determine whethermobile user #2's “home” settings should be applied. Ifserver106 determines thatUser #2's home settings should be applied, then instep1416

server

106 applies the correct setting and transmits it to the thermostat(s). Instep1408,server106 writes todatabase300 the geospatial and other relevant information used to adjust the programming. If after performingstep1414, the server concludes thatmobile user #2's “home” settings should not be applied, then instep1422

server

106 retrieves the most recent geospatial coordinates from themobile device105 associated with mobile user #N. Instep1424

server

106 uses current and recent coordinates to determine whether mobile user #N's “home” settings should be applied. Ifserver106 determines that User #N's home settings should be applied, then instep1426

server

106 applies the correct setting and transmits it to the thermostat(s). Instep1408,server106 writes todatabase300 the geospatial information used to adjust the programming.

If none of the mobile devices associated with a given home or other structure report geospatial coordinates consistent with occupancy, then instep1430 the server instructs the thermostat(s) to switch to or maintain the “away” setting.

Additional energy-saving and comfort-enhancing functionality is also envisioned as part of the subject invention. For example, information from historic data may be used to predict how long it will take a regular user to reach a conditioned space from the current coordinates, and the estimated arrival time may be used to calculate optimal cycling strategies for the HVAC system. Thus the longer it is predicted to take the mobile device user to arrive at home, the later the subject invention will switch to an occupied setting. In addition, information about traffic conditions may be integrated into these calculations, so that the geospatial data relative tomobile device105 may indicate that a user is taking his or her normal route, but because of a traffic jam, is likely to arrive later than would otherwise be expected. The characteristics of a given location may be used to infer arrival times as well. For example, if the geospatial data indicates that the user ofmobile device105 has arrived at the supermarket on his way to the conditioned space, a delay of 20 minutes is likely, whereas if the user has parked at a restaurant, the delay is likely to be one hour.

It is also possible to incorporate more sophisticated heuristics in incorporating the varying preferences of multiple occupants of a given structure. For example, rules can be structured so thatUser #1's preferences control during the heating season, but not during the cooling season;User #2's preferences might control during certain times of the day but not others;User #3's preferences may take precedence whenever they result in a more energy efficient strategy, but not when they result in increased energy use, and so on.

The subject invention is capable of delivering additional techniques that increase comfort and efficiency. In addition to using the system to allow better signaling and control of the HVAC system, which relies primarily on communication running from the server to the thermostat, the bi-directional communication will also allowthermostat108 to regularly measure and send to the server information about the temperature in the conditioned space. By comparing outside temperature, inside temperature, thermostat settings, cycling behavior of the HVAC system, and other variables, the system will be capable of numerous diagnostic and controlling functions beyond those of a standard thermostat. It will also be capable of using the known physical relationship between different conditioned spaces (that is, the fact that, for example, one apartment might be directly above another) to understand and optimize the use of energy in those spaces. Thus if the occupants of an apartment on the 10^thfloor maintain very high winter setpoints, thereby reducing the need to run the heating for the unit directly above it on the 11^thfloor (because heat rises), the cost allocation system could, if desired, share some of the cost of that heating between units, or could advise the occupant of the 10^thfloor unit of these facts, or otherwise use the data to reinforce more energy-efficient choices.

For example,FIG. 10ashows a graph of inside temperature, outside temperature and HVAC activity for a 24-hour period in a specific hypothetical conditioned space. Whenoutside temperature1502 increases, insidetemperature1504 follows, but with some delay because of the thermal mass of the building, unless theair conditioning1506 operates to counteract this effect. When the air conditioning turns on, the inside temperature stays constant (or rises at a much lower rate or even falls) despite the rising outside temperature. In this example, frequent and heavy use of the air conditioning results in only a very slight temperature increase inside the space of 4 degrees, from 72 to 76 degrees, despite the increase in outside temperature from 80 to 100 degrees.

FIG. 10bshows a graph of the same conditioned space on the same day, but assumes that the air conditioning is turned off from noon to 7 PM. As expected, theinside temperature1504arises with increasingoutside temperatures1502 for most of that period, reaching 88 degrees at 7 PM. Becauseserver106 logs the temperature readings from inside each conditioned space (whether once per minute or over some other interval), as well as the timing and duration of air conditioning cycles,database300 will contain a history of the thermal performance of each such space. That performance data will allow theserver106 to calculate an effective thermal mass for each such space—that is, the speed with which the temperature inside a given conditioned space will change in response to changes in outside temperature. Because the server will also log these inputs against other inputs including time of day, humidity, etc. the server will be able to predict, at any given time on any given day, the rate at which inside temperature should change for given inside and outside temperatures. Because the server also logs similar data from other thermostats in other units in the same building, it is also possible to predict how temperatures and setpoints in one unit will affect temperatures and system run times on adjacent units.

The ability to predict the rate of change in inside temperature in a given space under varying conditions may be applied by in effect holding the desired future inside temperature as a constraint and using the ability to predict the rate of change to determine when the HVAC system must be turned on in order to reach the desired temperature at the desired time. The ability of an HVAC system to vary turn-on time in order to achieve a setpoint with minimum energy use may be thought of as Just In Time (JIT) optimization.

FIG. 11 shows a flowchart illustrating the high-level process for controlling a just-in-time (JIT) event for a specific occupied space. Instep1512, the server determines whether aspecific thermostat108 is scheduled to run the preconditioning program. If, not, the program terminates. If it so scheduled, then instep1514 the server retrieves the predetermined target time when the preconditioning is intended to have been completed (TT). Using TT as an input, instep1516 the server then determines the time at which the computational steps required to program the preconditioning event will be performed (ST). Instep1518, performed at start time ST, the server begins the process of actually calculating the required parameters, as discussed in greater detail below. Then in1520 specific setpoint changes are transmitted to the thermostat so that the temperature inside the home may be appropriately changed as intended.

FIG. 12 shows a more detailed flowchart of the process. Instep1532, the server retrieves input parameters used to create a JIT event for a specific occupied space. These parameters include the maximum time allowed for a JIT event for thermostat108 (MTI); the target time the system is intended to hit the desired temperature (TT); and the desired inside temperature at TT (TempTT). It is useful to set a value for MTI because, for example, it will be reasonable to prevent the HVAC system from running a preconditioning event if it would be expected to take8 hours, which might be prohibitively expensive.

Instep1534, the server retrieves data used to calculate the appropriate start time with the given input parameters. This data may include a set of algorithmic learning data (ALD), composed of historic readings from the thermostat, together with associated weather data, such as outside temperature, solar radiation, humidity, wind speed and direction, etc.; together with weather forecast data for the subject location for the period when the algorithm is scheduled to run (the weather forecast data, or WFD). The forecasting data can be as simple as a listing of expected temperatures for a period of hours subsequent to the time at which the calculations are performed, or may include more detailed tables including humidity, solar radiation, wind, etc. Alternatively, it can include additional information such as some or all of the kinds of data collected in the ALD.

Instep1536, the server uses the ALD and the WFD to create prediction tables that determine the expected rate of change or slope of inside temperature for each minute of HVAC cycle time (ΔT ) for the relevant range of possible pre-existing inside temperatures and outside climatic conditions. An example of a simple prediction table is illustrated inFIGS. 17-1 and 17.2.

Instep1538, the server uses the prediction tables created in step1106, combined with input parameters TT and Temp(TT) to determine the time at which slope ΔT intersects with predicted initial temperature PT. The time between PT and TT is the key calculated parameter: the preconditioning time interval, or PTI.

Instep1540, the server checks to confirm that the time required to execute the pre-conditioning event PTI does not exceed the maximum parameter MTI. If PTI exceeds MTI, the scheduling routine concludes and no ramping setpoints are transmitted to the thermostat.

If the system is perfect in its predictive abilities and its assumptions about the temperature inside the home are completely accurate, then in theory the thermostat can simply be reprogrammed once—at time PT, the thermostat can simply be reprogrammed to Temp(TT). However, there are drawbacks to this approach. First, if the server has been overly conservative in its predictions as to the possible rate of change in temperature caused by the HVAC system, the inside temperature will reach TT too soon, thus wasting energy and at least partially defeating the purpose of running the preconditioning routine in the first place. If the server is too optimistic in its projections, there will be no way to catch up, and the home will not reach Temp(TT) until after TT. Thus it would be desirable to build into the system a means for self-correcting for slightly conservative start times without excessive energy use. Second, the use of setpoints as a proxy for actual inside temperatures in the calculations is efficient, but can be inaccurate under certain circumstances. In the winter (heating) context, for example, if the actual inside temperature is a few degrees above the setpoint (which can happen when outside temperatures are warm enough that the home's natural “set point” is above the thermostat setting), then setting the thermostat to Temp(TT) at time PT will almost certainly lead to reaching TT too soon as well.

The currently preferred solution to both of these possible inaccuracies is to calculate and program a series of intermediate settings between Temp(PT) and Temp(TT) that are roughly related to ΔT.

Thus if MTI is greater than PTI, then instep1542 the server calculates the schedule of intermediate setpoints and time intervals to be transmitted to the thermostat. Because thermostats cannot generally be programmed with steps of less than 1 degree F., ΔT is quantized into discrete interval data of at least 1 degree F. each. For example, if Temp(PT) is 65 degrees F., Temp(TT) is 72 degrees F., and PT is 90 minutes, the thermostat might be programmed to be set at 66 for 10 minutes, 67 for 12 minutes, 68 for 15 minutes, etc. The server may optionally limit the process by assigning a minimum programming interval (e.g., at least ten minutes between setpoint changes) to avoid frequent switching of the HVAC system, which can reduce accuracy because of the thermostat's compressor delay circuit, which may prevent quick corrections. The duration of each individual step may be a simple arithmetic function of the time PTI divided by the number of whole degree steps to be taken; alternatively, the duration of each step may take into account second order thermodynamic effects relating to the increasing difficulty of “pushing” the temperature inside a conditioned space further from its natural setpoint given outside weather conditions, etc. (that is, the fact that on a cold winter day it may take more energy to move the temperature inside the home from 70 degrees F. to 71 than it does to move it from 60 degrees to61).

Instep1544, the server schedules setpoint changes calculated in step1112 for execution by the thermostat.

With this system, if actual inside temperature at PT is significantly higher than Temp(PT), then the first changes to setpoints will have no effect (that is, the HVAC system will remain off), and the HVAC system will not begin using energy, until the appropriate time, as shown inFIG. 12. Similarly, if the server has used conservative predictions to generate ΔT, and the HVAC system runs ahead of the predicted rate of change, the incremental changes in setpoint will delay further increases until the appropriate time in order to again minimize unnecessary energy use.

FIGS. 13(a) through 13(d) shows the steps in the preconditioning process as a graph of temperature and time.FIG. 13(a) showsstep1532, in which inputs targettime TT1552, target temperature Temp(TT)1554, maximumconditioning interval MTI1556 and the predicted inside temperature during the period of time the preconditioning event is likely to begin Temp(PT)1558 are retrieved.

FIG. 13(b) shows the initial calculations performed instep1538, in which expected rate of change intemperature ΔT1560 inside the home is generated from the ALD and WFD using Temp(TT)1554 attime TT1552 as the endpoint.

FIG. 13(c) shows how instep1538

ΔT

1560 is used to determinestart time PT1562 and preconditioningtime interval PTI1564. It also shows how instep1540 the server can compare PTI with MTI to determine whether or not to instantiate the pre-conditioning program for the thermostat.

FIG. 13(d) showsstep1542, in which specific rampedsetpoints1566 are generated. Because of the assumed thermal mass of the system, actual inside temperature at any given time will not correspond to setpoints until some interval after each setpoint change. Thus initial ramped setpoint1216 may be higher than Temp(PT)1558, for example.

FIG. 14 shows an example of the types of data that may be used by the server in order to calculateΔT1560. Such data may include insidetemperature1572, outsidetemperature1574,cloud cover1576,humidity1578,barometric pressure1580,wind speed1582, andwind direction1584.

Each of these data points should be captured at frequent intervals. In the currently preferred embodiment, as shown inFIG. 14, the interval is once every 60 seconds.

FIG. 15 shows application of the subject invention in a conditioned space. Temperature and setpoints are plotted for the 4-hour period from4AM to8AM with temperature on the vertical axis and time on the horizontal axis. Thewinter nighttime setpoint1592 is 60 degrees F.; themorning setpoint temperature1594 is 69 degrees F. Theoutside temperature1596 is approximately 45 degrees F. Thetarget time TT1598 for the setpoint change to morning setting is 6:45 AM. In the absence of the subject invention, the occupant could program the thermostat to change to the new setpoint at 6:45, but there is an inherent delay between a setpoint change and the response of the temperature inside the home. (In this space on this day, the delay is approximately fifty minutes.) Thus if the occupant truly desired to achieve the target temperature at the target time, some anticipation would be necessary. The amount of anticipation required depends upon numerous variables, including the capacity and state of tune of the HVAC system, the thermal properties of the building envelope, current and recent weather conditions, etc.

After calculating theappropriate slope ΔT1560 by which to ramp inside temperature in order to reach the target as explained above, the server transmits a series ofsetpoints1566 to the thermostat because the thermostat is presumed to only accept discrete integers as program settings. (If a thermostat is capable of accepting finer settings, as in the case of some thermostats designed to operate in regions in which temperature is generally denoted in Centigrade rather than Fahrenheit, which accept settings in half-degree increments, tighter control may be possible.) In any event, in the currently preferred embodiment of the subject invention, programming changes are quantized such that the frequency of setpoint changes is balanced between the goal of minimizing network traffic and the frequency of changes made on the one hand and the desire for accuracy on the other. Balancing these considerations may result in some cases in either more frequent changes or in larger steps between settings. As shown inFIG. 15, the setpoint “stairsteps” from 60 degrees F. to 69 degrees F. In nine separate setpoint changes over a period of 90 minutes.

Because theinside temperature1599 when the setpoint management routine was instantiated at 5:04 AM was above the “slope” and thus above the setpoint, the HVAC system was not triggered and no energy was used unnecessarily heating the space before such energy use was required. Actual energy usage does not begin until 5:49 AM.

FIG. 16 shows application of the subject invention in a different conditioned space during a similar four-hour interval. InFIG. 16, the predictedslope ΔT1560 is less conservative relative to the actual performance of the home and HVAC system, so there is no off cycling during the preconditioning event—the HVAC system turns on at approximately 4:35 AM and stays on continuously during the event. The conditioned space reaches the target temperature Temp(TT) roughly two minutes prior to target time TT.

FIGS. 17-1 and 17-2 shows a simple prediction table. Thefirst column1602 lists a series of differentials between outside and inside temperatures. Thus when the outside temperature is 14 degrees and the inside temperature is 68 degrees, the differential is -54 degrees; when the outside temperature is 94 degrees and the inside temperature is 71 degrees, the differential is 13 degrees. Thesecond column1604 lists the predicted rate of change in inside temperature ΔT1210 assuming that the furnace is running in terms of degrees Fahrenheit of change per hour. A similar prediction table will be generated for predicted rates of change when the air conditioner is on; additional tables may be generated that predict how temperatures will change when the HVAC system is off.

Alternatively, the programming of the just-in-time setpoints may be based not on a single rate of change for the entire event, but on a more complex multivariate equation that takes into account the possibility that the rate of change may be different for events of different durations, as well as other variables such as wind speed, humidity, solar conditions (cloudy vs. clear), etc.

The method for calculating start times may also optionally take into account not only the predicted temperature at the calculated start time, but may incorporate measured inside temperature data from immediately prior to the scheduled start time in order to update calculations, or may employ more predictive means to extrapolate what the inside temperature is likely to be based upon outside temperatures, etc.

Significant energy savings are possible if HVAC control systems can reliably detect when a space is unoccupied. Explicit occupancy sensors are widely available, and can generally accomplish this, though this task is much easier in single-room spaces like hotel rooms than it is in multi-room spaces like larger homes. But the subject invention can accomplish some of the benefits of explicit occupancy detection by recognizing manual interaction with the physical thermostat—the buttons on the thermostat itself can only be pressed if someone is there to press them.

Some thermostats are capable of explicitly reporting manual overrides, but others are not. Where, as with the subject invention, an energy management service may make frequent changes to thermostat setpoints, disambiguating human interactions is of great importance.

Because the instant invention is capable of recording the setpoint actually used at a connected thermostat over time, it is also capable of inferring manual setpoint changes (as, for example, entered by pushing the “up” or “down” arrow on the control panel of the device) even when such overrides of the pre-set program are not specifically recorded as such by the thermostat.

In order to adapt programming to take into account the manual overrides entered into the thermostat, it is first necessary to determine when a manual override has in fact occurred. Most thermostats, including many two-way communicating devices, do not record such inputs locally, and neither recognize nor transmit the fact that a manual override has occurred. Furthermore, in a system as described herein, frequent changes in setpoints may be initiated by algorithms running on the server, thereby making it impossible to infer a manual override from the mere fact that the setpoint has changed. It is therefore necessary to deduce the occurrence of such events from the data that the subject invention does have access to.

FIG. 18 illustrates the currently preferred method for detecting the occurrence of a manual override event. Instep1702, the server retrieves the primary data points used to infer the occurrence of a manual override from one or more databases inoverall database structure300. The data should include each of the following: for the most recent point at which it can obtain such data (time0) the actual setpoint as recorded at the thermostat at (A0); for the point immediately prior to time0 (time-1), the actual setpoint recorded for the thermostat (A-1); for time0 the setpoint as scheduled byserver106 according to the basic setpoint programming (S0), and for time-1 the setpoint as scheduled byserver106 according to the standard setpoint programming (S-1). Instep1704, the server retrieves any additional automated setpoint changes C that have been scheduled for the thermostat byserver106 at time0. Such changes may include algorithmic changes intended to reduce energy consumption, etc. Instep1706 the server calculates the difference (dA) between A0 and A-1; for example, if the actual setpoint is 67 degrees at time-1 and 69 at time0, dA is +2; if the setpoint at time-1 is 70 and the setpoint at time0 is 66, dA is −4. Instep1708, the server performs similar steps in order to calculate dS, the difference between S0 and S-1. This is necessary because, for example, the setpoint may have been changed because the server itself had just executed a change, such as a scheduled change from “away” (or unoccupied) to “home” (or occupied) mode. Instep1710 the server evaluates and sums all active algorithms and other server-initiated strategies to determine their net effect on setpoint at time0. For example, if one algorithm has increased setpoint at time0 by 2 degrees as a short-term energy savings measure, but another algorithm has decreased the setpoint by one degree to compensate for expected subjective reactions to weather conditions, the net algorithmic effect sC is +1 degree.

Instep1712, the server calculates the value for M, where M is equal to the difference between actual setpoints dA, less the difference between scheduled setpoints dS, less the aggregate of algorithmic change sC. Instep1714 the server evaluates this difference. If the difference equals zero, the server concludes that no manual override has occurred, and the routine terminates. But if the difference is any value other than zero, then the server concludes that a manual override has occurred. Thus instep1716 the server logs the occurrence and magnitude of the override to one or more databases inoverall database structure300.

The process of interpreting a manual override is shown inFIG. 19.Step1802 is the detection of an override, as described in detail inFIG. 18. Instep1804 the server retrieves the stored rules for thesubject thermostat108. Such rules may include weather and time-related inferences such as “if outside temperature is greater than 85 degrees and inside temperature is more than 2 degrees above setpoint and manual override lowers setpoint by 3 or more degrees, then revert to original setpoint in 2 hours,” or “if heating setpoint change is scheduled from ‘away’ to ‘home’ within 2 hours after detected override, and override increases setpoint by at least 2 degrees, then change to ‘home’ setting,” or the like. Instep1806 the server retrieves contextual data required to interpret the manual override. Such data may include current and recent weather conditions, current and recent inside temperatures, etc. This data is helpful because it is likely that manual overrides are at least in part deterministic: that is, that they may often be explained by such contextual data, and such understanding can permit anticipation of the desire on the part of the occupants to override and to adjust programming accordingly, so as to obviate the need for such changes. The amount of data may be for a period of a few hours to as long as several days or more. Recent data may be more heavily weighted than older data in order to assure rapid adaptation to situations in which manual overrides represent stable changes such as changes in work schedules, etc.

Instep1808 the server retrieves any relevant override data from the period preceding the specific override being evaluated that has not yet been evaluated by and incorporated into the long-term programming and rules engines as described below inFIG. 19. Instep1810 the server evaluates the override and determines which rule, if any, should be applied as a result of the override. Instep1812 the server determines whether to alter the current setpoint as a result of applying the rules instep1810. If no setpoint change is indicated, then the routine ends. If a setpoint change is indicated, then instep1814 the server transmits the setpoint change to the thermostat for execution, and instep1816 it records that change to one or more databases inoverall database structure300.

In order to ensure that both the stored rules for interpreting manual overrides and the programming itself continue to most accurately reflect the intentions of the occupants, the server will periodically review both the rules used to interpret overrides and the setpoint scheduling employed.FIG. 20 shows the steps used to incorporate manual overrides into the long-term rules and setpoint schedule. Instep1902 the server retrieves the stored programming for a given thermostat as well as the rules for interpreting overrides for that thermostat. Instep1904 the server retrieves the recent override data as determined using the process described inFIGS. 18 and 19 to be evaluated for possible revisions to the rules and the programming. Instep1906 the server retrieves the contextual data regarding overrides retrieved in step1904 (Because the process illustrated inFIG. 20 is not presently expected to be executed as a real-time process, and is expected to be run anywhere from once per day to once per month, the range and volume of contextual data to be evaluated is likely to be greater than in the process illustrated inFIG. 19).

Instep1908 the server interprets the overrides in light of the existing programming schedule, rules for overrides, contextual data, etc. Instep1910 the server determines whether, as a result of those overrides as interpreted, the rules for interpreting manual overrides should be revised. If the rules are not to be revised, the server moves to step1914. If the rules are to be revised, then instep1912 the server revises the rules and the new rules are stored in one or more databases inoverall database structure300. Instep1914 the server determines whether any changes to the baseline programming for the thermostat should be revised. If not, the routine terminates. If revisions are warranted, then instep1916 the server retrieves fromdatabase900 the permissions the server has to make autonomous changes to settings. If the server has been given permission to make the proposed changes, then instep1918 the server revises the thermostat's programming and writes the changes to one or more databases inoverall database structure300. If the server has not been authorized to make such changes autonomously, then instep1920 the server transmits the recommendation to change settings to the customer in the manner previously specified by the customer, such as email, changes to the customer's home page as displayed onwebsite200, etc.

Additional means of implementing the instant invention may be achieved using variations in system architecture. For example, much or even all of the work being accomplished byremote server106 may also be done bythermostat108 if that device has sufficient processing capabilities, memory, etc. Alternatively, these steps may be undertaken by a local processor such as a local personal computer, or by a dedicated appliance having the requisite capabilities, such asgateway112.

Demand for electricity varies widely from winter to summer, and from early morning to late afternoon. Air conditioning is a major component of peak load. The traditional approach to dealing with high demand on hot days is to build increase supply—build new power plants, or buy additional capacity on the spot market. But because many people now consider reducing loads to be a superior strategy for matching electricity supply to demand when the grid is stressed, the ability to shed load by turning off air conditioners during peak events has become a useful tool for managing loads. A key component of any such system is the ability to document and verify that a given air conditioner has actually turned off. Data logging hardware can accomplish this, but due to the cost is usually only deployed for statistical sampling. The instant invention provides a means to verify demand response without additional hardware such as a data logger.

Thermostats

108 record temperature readings at frequent intervals, such as once per minute. Becauseserver106 logs the temperature readings from inside each conditioned space (whether once per minute or over some other interval), as well as the timing and duration of air conditioning cycles,database300 will contain a history of the thermal performance of each conditioned space. That performance data will allow theserver106 to calculate an effective thermal mass for each such space—that is, the speed with the temperature inside a given space is expected to change in response to changes in outside temperature. Because the server will also log these inputs against other inputs including time of day, humidity, etc. the server will be able to predict, at any given time on any given day, the rate at which inside temperature should change for given inside and outside temperatures. This will permit remote verification of load shedding by the air conditioner without directly measuring or recording the electrical load drawn by the air conditioner, and without requiring reliance on bare HVAC cycling data, which is susceptible to manipulation.

FIG. 21 shows the steps followed in order to initiate air conditioner shutoff. When a summer peak demand situation occurs, the utility will transmit an email orother signal2202 toserver106 requesting a reduction in load.Server106 will determine2204 if a given conditioned space is served by the utility seeking reduction; determine2206 if a given user has agreed to reduce peak demand; and determine2208 if a reduction of consumption by the user is required or desirable in order to achieve the reduction in demand requested by the utility or demand response aggregator. The server will transmit2210 a signal to the user'sthermostat108 signaling the thermostat to shut off theair conditioner110.

FIG. 22 shows the steps followed in order to verify that a specific air conditioner has in fact been shut off.Server106 will receive and monitor2302 the temperature readings sent by the user'sthermostat108. The server then calculates2304 the temperature reading to be expected for that thermostat given inputs such as current and recent outside temperature, recent inside temperature readings, the calculated thermal mass of the structure, temperature readings in other conditioned spaces such as other units within the same building, etc. The server will compare2306 the predicted reading with the actual reading. If the server determines that the temperature inside the conditioned space is rising at roughly the rate predicted if the air conditioning is shut off, then the server confirms2308 that the air conditioning has been shut off. If the temperature reading from the thermostat shows no increase, or significantly less increase than predicted by the model, then the server concludes2310 that the air conditioning was not switched off, and that no contribution to the demand response request was made.

In contrast, if the HVAC system for conditioned space A has been tampered with, so that a demand reduction signal from the server does not actually result in shutting off the air conditioner for conditioned space A, when the server compares the rate of temperature change in conditioned space A against the other data points, the server will receive data inconsistent with the rate of increase predicted. As a result, it will conclude that the air conditioner has not been shut off in conditioned space A as expected, and may not credit conditioned space A with the financial credit that would be associated with demand reduction compliance, or may trigger a business process that could result in termination of conditioned space A's participation in the demand reduction program.

FIG. 23 illustrates the movement of signals and information between the components of one embodiment of the subject invention to trigger and verify a demand reduction response. Where demand response events are undertaken on behalf of a utility by a third party, participants in the communications may includeelectric utility server2400, demandreduction service server106, andthermostat108. Instep2402 theelectric utility server2400 transmits a message to demandreduction service server106 requesting a demand reduction of a specified duration and size. Demandreduction service server106 usesdatabase300 to determine which subscribers should be included in the demand reduction event. For each included subscriber, the server then sends asignal2404 to the subscriber'sthermostat108 instructing it (a) to shut down at the appropriate time or (b) to allow the temperature as measured by the thermostat to increase to a certain temperature at the specified time, depending upon the agreement between the owner (or tenant, or facilities manager as the case may be) and the demand reduction service provider. The server then receives2406 temperature measurements from the subscriber's thermostat. At the conclusion of the demand reduction event, the server transmits asignal2408 to the thermostat permitting the thermostat to signal its attached HVAC system to resume cooling, if the system has been shut off, or to reduce the target temperature to its non-demand reduction setting, if the target temperature was merely increased. Ifthermostat108 is capable of storing scheduling information, these instructions may be transmitted prior to the time they are to be executed and stored locally. After determining the total number of subscribers actually participating in the DR event, the server then calculates the total demand reduction achieved and sends amessage2410 to the electric utility confirming such reduction.

Additional steps may be included in the process. For example, if the subscriber has previously requested that notice be provided when a peak demand reduction event occurs, the server may also send an alert, which may be in the form of an email or text message or an update to the personalized web page for that user, or both. If the server determines that a given conditioned space has (or has not) complied with the terms of its demand reduction agreement, the server may send a message to the subscriber confirming that fact.

It should also be noted that in some climate zones, peak demand events occur during extreme cold weather rather than (or in addition to) during hot weather. The same process as discussed above could be employed to reduce demand by shutting off electric heaters and monitoring the rate at which temperatures fall.

It should also be noted that the peak demand reduction service can be performed directly by an electric utility, so that the functions ofserver106 can be combined with the functions ofserver2400.

It should also be noted that additional variations are possible in a situation in which a building has multiple separately occupancy units owned or managed by a single entity. Additional variations are possible where a central chiller is combined with multiple air handlers in individual occupancy units, such as apartments or separate retail or office spaces. For example, a landlord may enter into an overall demand response contract that calls for delivery of several megawatts or more of load shedding, and achieve that goal by managing the thermostats in individual units. The landlord may incentivize tenants to agree to participate by sharing some of the benefit of the demand response payments with tenants that cooperate, and allocating payment (or credit against payments owed by the tenant to the landlord) based on the degree to which the load was actually reduced in that unit. The processes described inFIGS. 7athrough 7gmay easily be adapted to accomplish this.

The system installed in a subscriber's home may optionally include additional temperature sensors at different locations within the building. These additional sensors may be connected to the rest of the system via a wireless system such as 802.11 or 802.15.4, or may be connected via wires. Additional temperature and/or humidity sensors may allow increased accuracy of the system, which can in turn increase user comfort, energy savings or both.

The bi-directional communication betweenserver106 andthermostat108 will also allowthermostat108 to regularly measure and send toserver106 information about the temperature in the conditioned space. By comparing outside temperature, inside temperature, thermostat settings, cycling behavior of the HVAC system, and other variables, the system will be capable of numerous diagnostic and controlling functions beyond those of a standard thermostat.

For example,FIG. 24ashows a graph of inside temperature and outside temperature for a 24-hour period in conditioned space A, assuming no HVAC activity. Conditioned space A has double-glazed windows and is well insulated. Whenoutside temperature2502 increases, insidetemperature2504 follows, but with significant delay because of the thermal mass of the building.

FIG. 24bshows a graph of inside temperature and outside temperature for the same 24-hour period in conditioned space B. Conditioned space B is identical to conditioned space A except that it (i) is located a block away and (ii) has single-glazed windows and is poorly insulated. Because the two spaces are so close to each other, outsidetemperature2502 is the same inFIG. 24aandFIG. 24b. But the lower thermal mass of conditioned space B means that the rate at which theinside temperature2506 changes in response to the changes in outside temperature is much greater.

The differences in thermal mass will affect the cycling behavior of the HVAC systems in the two conditioned spaces as well.FIG. 25ashows a graph of inside temperature and outside temperature in conditioned space A for the same 24-hour period as shown inFIG. 24a, but assuming that the air conditioning is being used to try to maintain an internal temperature of 70 degrees. Outsidetemperatures2502 are the same as inFIGS. 24aand 24b. Insidetemperature2608 is maintained within the range determined bythermostat108 by the cycling of the air conditioner. Because of the high thermal mass of the conditioned space, the air conditioning does not need to run for very long to maintain the target temperature, as shown byshaded areas2610.

FIG. 25bshows a graph ofinside temperature2612 and outsidetemperature2502 for the same 24-hour period in conditioned space B, assuming use of the air conditioning as inFIG. 25a. Because of the lower thermal mass of conditioned space B, the air conditioning system in conditioned space B has to run longer in order to maintain the same target temperature range, as shown byshaded areas2614.

Becauseserver106 logs the temperature readings from inside each conditioned space (whether once per minute or over some other interval), as well as the timing and duration of air conditioning cycles,database300 will contain a history of the thermal performance of each system and each conditioned space. That performance data will allow theserver106 to calculate an effective thermal mass for each such structure—that is, the speed with the temperature inside a given conditioned space will change in response to changes in outside temperature and differences between inside and outside temperatures. Because theserver106 will also log these inputs against other inputs including time of day, humidity, etc. the server will be able to predict, at any given time on any given day, the rate at which inside temperature should change for given inside and outside temperatures.

The server will also record the responses of each occupancy unit to changes in outside conditions and cycling behavior over time. That will allow the server to diagnose problems as and when they develop. For example,FIG. 26ashows a graph ofoutside temperature2702, insidetemperature2704 andHVAC cycle times2706 in conditioned space A for a specific 24-hour period on date X. Assume that, based upon comparison of the performance of conditioned space A on date X relative to conditioned space A's historical performance, and in comparison to the performance of conditioned space A relative to other nearby conditioned spaces on date X, the HVAC system in conditioned space A is presumed to be operating at normal efficiency, and that conditioned space A is in the 86^thpercentile as compared to those other conditioned spaces.FIG. 26bshows a graph ofoutside temperature2708, insidetemperature2710 andHVAC cycle times2712 in conditioned space A for the 24-hour period ondate X+1. Conditioned space A's HVAC system now requires significantly longer cycle times in order to try to maintain the same internal temperature. If those longer cycle times were due to higher outside temperatures, those cycle times probably would not indicate the existence of any problems. But becauseserver106 is aware of the outside temperature, the system can eliminate that possibility as an explanation for the higher cycle times. Becauseserver106 is aware of the cycle times in nearby conditioned spaces, it can determine that, for example, on date X+1 the efficiency of conditioned space A is only in the 23^rdpercentile. The server may be programmed with a series of heuristics, gathered from predictive models and past experience, correlating the drop in efficiency and the time interval over which it has occurred with different possible causes. For example, a 50% drop in efficiency in one day may be correlated with a refrigerant leak, especially if followed by a further drop in efficiency on the following day. A reduction of 10% over three months may be correlated with a clogged filter. Based upon the historical data recorded by the server, theserver106 will be able to alert the appropriate responsible person that there is a problem and suggest a possible cause.

Because the system will be able to calculate effective thermal mass relative to each HVAC system or air handler, it will be able to determine the cost effectiveness of strategies such as pre-cooling for specific conditioned spaces under different conditions.FIG. 27ashows a graph ofoutside temperature2802, insidetemperature2804 andHVAC cycling times2806 in conditioned space A for a specific 24-hour period on date Y assuming that the system has used a pre-cooling strategy to avoid running the air conditioning during the afternoon, when rates are highest. Because conditioned space A has high thermal mass, the space is capable of “banking” cooling, and energy consumed during off-peak hours is in effect stored, allowing the conditioned space to remain cool even when the system is turned off. Temperatures keep rising during the period the air conditioning is off, but because thermal mass is high, the rate of increase is low, and the conditioned space is still comfortable several hours later. Although the pre-cooling cycle time is relatively long, the effective ratepayer may still benefit if electricity prices vary at different times of the day, and if the price per kilowatt during the morning pre-cooling phase is lower than the price during the peak load period, or if other incentives are provided.FIG. 27bshows a graph of the sameoutside temperature2802 in conditioned space B as in conditioned space A inFIG. 27afor the same 24-hour period and using the same pre-cooling strategy as shown bycycling times2806. But because conditioned space B has significantly less thermal mass, using additional energy in order to pre-cool the space does not have the desired effect; insidetemperature2808 warms up so fast that the cooling that had been banked is quickly lost. Thus the system will recommend that conditioned space A pre-cool in order to save money, but not recommend pre-cooling for conditioned space B.

The subject invention can also help compensate for anomalies such as measurement inaccuracies due to factors such as poor thermostat location. It is well known that thermostats should be placed in a location that will be likely to experience “average” temperatures for the overall conditioned space, and should be isolated from windows and other influences that could bias the temperatures they “see.” But for various reasons, not all thermostat installations fit that ideal.FIG. 28ashows a graph ofoutside temperature2902, the actual average inside temperature for the entire conditionedspace2904, and inside temperature as read by thethermostat2906 in conditioned space C for a specific 24-hour period on September 15^th, assuming that the thermostat is located so that for part of the afternoon on that day the thermostat is in direct sunlight. Until the point at which the sun hits the thermostat, the average inside temperature and temperature as read by the thermostat track very closely. But when the direct sunlight hits the thermostat, the thermostat and the surrounding area can heat up, causing the internal temperature as read by the thermostat to diverge significantly from the average temperature for the rest of the conditioned space. A conventional thermostat has no way of distinguishing this circumstance from a genuinely hot day, and will both over-cool the rest of the conditioned space and waste considerable energy when it cycles the air conditioner in order to reduce the temperature as sensed by the thermostat. If the air conditioning remains off, this phenomenon will manifest as a spike in temperature as measured by the thermostat. If the air conditioning turns on (and has sufficient capacity to respond to the distorted temperature signal caused by the sunlight), this phenomenon will likely manifest as relatively small changes in the temperature as sensed by the thermostat, but significantly increased HVAC usage (as well as excessively lowered temperatures in the rest of the conditioned space, but this result may not be directly measured in a single-sensor environment). The subject system, in contrast, has multiple mechanisms that will allow it to correct for such distortions. First, because the subject system compares the internal readings from conditioned space C with the external temperature, it will be obvious that the rise in sensed temperature at 4:00 PM is not correlated with a corresponding change in outside temperature. Second, because the system is also monitoring the readings from the thermostat in nearby conditioned space D, which (as shown inFIG. 28b) is exposed to the sameoutside temperature602, but has no sudden rise in measuredinternal afternoon temperature2908, the system has further validation that the temperature increase is not caused by climatic conditions. And finally, because the system has monitored and recorded the temperature readings from the thermostat in conditioned space C for each previous day, and has compared the changing times of the aberration with the progression of the sun, the system can distinguish the patterns likely to indicate solar overheating from other potential causes.

Another application for the subject invention is to determine the thermal characteristics of individual units within a larger building, and use that information to detect and recognize defects, and faults in the HVAC systems and building envelopes.

FIG. 29 illustrates the steps involved in calculating comparative thermal mass, or the thermal mass index for a specific conditioned space within a larger structure. Instep3002, the server retrieves climate data related to conditioned space X. Such data may include current outside temperature, outside temperature during the preceding hours, outside humidity, wind direction and speed, whether the sun is obscured by clouds, and other factors. Instep3004, the server retrieves HVAC duty cycle data for conditioned space X. Such data may include target settings for the thermostat in current and previous periods, the timing of switch-on and switch-off events and other data. Instep3006, the server retrieves data regarding recent temperature readings as recorded by the thermostat in conditioned space X. Instep3008, the server retrieves profile data for conditioned space X. Such data may include square footage, when the conditioned space was built and/or renovated, the extent to which it is insulated, its location within the larger structure, the make, model and age of the associated HVAC hardware specific that unit, and other data. Instep3010, the server retrieves the current inside temperature reading as transmitted by the thermostat. Instep3012, the server calculates the thermal mass index for the conditioned space under the relevant conditions; that is, for example, it may calculate the likely rate of change for internal temperature in conditioned space X from a starting point of 70 degrees when the outside temperature is 85 degrees at 3:00 PM on August 10^thwhen the wind is blowing at 5 mph from the north and the sky is cloudy. The server may accomplish this by applying a basic algorithm that weighs each of these external variables as well as variables for various characteristics of the conditioned space itself (such as size, level of insulation, method of construction, etc.) and data from other conditioned spaces and environments.

This approach may be used to recognize and diagnose changes in operating parameters of the HVAC system over time, both generally and in individual units.FIG. 30 illustrates the steps involved in one method for diagnosing defects in the HVAC system for specific conditioned space X. Instep3102, the server retrieves climate data related to conditioned space X. Such data may include current outside temperature, outside temperature during the preceding hours, outside humidity, wind direction and speed, whether the sun is obscured by clouds, and other factors. Instep3104, the server retrieves HVAC duty cycle data for conditioned space X. Such data may include target settings for the thermostat in current and previous periods, the timing of switch-on and switch-off events and other data. Instep3106, the server retrieves data regarding current and recent temperature readings as recorded by the thermostat in conditioned space X. Instep3108, the server retrieves profile data for conditioned space X. Such data may include square footage, when the conditioned space was built and/or renovated, the extent to which it is insulated, its location within the larger structure, make, model and age of HVAC equipment associated with that specific unit, if any, and other data. Instep3110, the server retrieves comparative data from other conditioned spaces that have thermostats that also report to the server. Such data may include interior temperature readings, outside temperature for those specific locations, duty cycle data for the HVAC systems at those locations, profile data for the structures and HVAC systems associated with those conditioned spaces and the calculated thermal mass index for those other conditioned spaces. In step3112, the server calculates the current relative efficiency of conditioned space X as compared to other conditioned spaces. Those comparisons will take into account differences in size, location, age, etc. In making those comparisons.

The server will also take into account that comparative efficiency is not absolute, but will vary depending on conditions. For example, a conditioned space that has extensive south-facing windows is likely to experience significant solar gain. On sunny winter days, that home will appear more efficient than on cloudy winter days. That same conditioned space will appear more efficient at times of day and year when trees or overhangs shade those windows than it will when summer sun reaches those windows. Thus the server may calculate efficiency under varying conditions.

For example, instep3114 the server compares the HVAC system's efficiency, corrected for the relevant conditions, to its efficiency in the past. If the current efficiency is substantially the same as the historical efficiency, the server concludes3116 that there is no defect and the diagnostic routine ends. If the efficiency has changed, the server proceeds to compare the historical and current data against patterns of changes known to indicate specific problems. For example, instep3118, the server compares that pattern of efficiency changes against the known pattern for a clogged air filter, which is likely to show a slow, gradual degradation over a period of weeks or even months. If the pattern of degradation matches the clogged filter paradigm, the server creates and transmits to the appropriate party amessage3120 alerting the party to the possible problem. If the problem does not match the clogged filter paradigm, the system compares3122 the pattern to the known pattern for a refrigerant leak, which is likely to show degradation over a period of a few hours to a few days. If the pattern of degradation matches the refrigerant leak paradigm, the server creates and transmits to the appropriate party amessage3124 alerting the party to the possible problem. If the problem does not match the refrigerant leak paradigm, the system compares3126 the pattern to the known pattern for an open window or door, which is likely to show significant changes for relatively short periods at intervals uncorrelated with climatic patterns. If the pattern of degradation matches the open door/window paradigm, the server creates and transmits to the appropriate party amessage3128 alerting the party to the possible problem. If the problem does not match the open door/window paradigm, the system continues to step through remainingknow patterns N3130 until either a pattern is matched3132 or the list has been exhausted without amatch3134.

FIG. 31 illustrates the steps involved in one method for diagnosing inaccurate thermostat readings due to improper location. Instep3202, the server retrieves climate data related to conditioned space X. Such data may include current outside temperature, outside temperature during the preceding hours, outside humidity, wind direction and speed, whether the sun is obscured by clouds, and other factors. Instep3204, the server retrieves HVAC duty cycle data for conditioned space X. Such data may include target settings for the thermostat in current and previous periods, the timing of switch-on and switch-off events and other data. Instep3206, the server retrieves data regarding current and recent temperature readings as recorded by the thermostat in conditioned space X. Instep3208, the server retrieves profile data for conditioned space X. Such data may include square footage, when the space was built and/or renovated, the extent to which it is insulated, its location within the larger structure, make, model and age of HVAC hardware specific to that space, if any, and other data. Instep3210, the server retrieves comparative data from other conditioned spaces that have thermostats that also report to the server. Such data may include interior temperature readings, outside temperature for those specific locations, duty cycle data for the HVAC systems at those locations, profile data for the structures and HVAC systems in those conditioned spaces and the calculated thermal mass index for those other conditioned spaces. Instep3212, the server calculates the expected thermostat temperature reading based upon the input data. Instep3214, the server compares the predicted and actual values. If the calculated and actual values are at least roughly equivalent, the server concludes3216 that there is no thermostat-related anomaly. If the calculated and actual values are not roughly equivalent, the server retrieves additional historical information about past thermostat readings instep3218. Instep3220, the server retrieves solar progression data, i.e., information regarding the times at which the sun rises and sets on the days being evaluated at the location of the conditioned space being evaluated, and the angle of the sun at that latitude, etc. Instep3222, the server compares the characteristics of the anomalies over time, to see if, for example, abnormally high readings began at 3:12 on June 5^th, 3:09 on June 6^th, 3:06 on June 7^thand the solar progression data suggests that at the conditioned space being analyzed, that sun would be likely to reach a given place in that unit three minutes earlier on each of those days. If the thermostat readings do not correlate with the solar progression data, the server may conclude3224 that the sun is not causing the distortion by directly hitting the thermostat. If the thermostat readings do correlate with solar progression, the server then calculates3226 the predicted duration of the distortion caused by the sun. Instep3228, the server calculates the appropriate setpoint information to be used by the thermostat to maintain the desired temperature and correct for the distortion for the expected length of the event. For example, if the uncorrected setpoint during the predicted event is 72 degrees, and the sun is expected to elevate the temperature reading by eight degrees, the server will instruct the thermostat to maintain a setpoint of 80 degrees. Instep3230, the server sends the appropriate party a message describing the problem.

The instant invention may also be used to implement additional energy savings by implementing small, repeated changes in setpoint for individual conditioned spaces. Because energy consumption is strongly correlated with setpoint—that is, the further a given setpoint diverges from the balance point (the natural inside temperature assuming no HVAC activity) in a given conditioned space under given conditions, the higher energy consumption will be to maintain temperature at that setpoint), energy will be saved by any strategy that over a given time frame lowers the average heating setpoint or raises the cooling setpoint. It is therefore possible to save energy by adopting a strategy that takes advantage of human insensitivity to slow temperature ramping by incorporating a user's desired setpoint within the range of the ramp, but setting the average target temperature below the desired setpoint in the case of heating, and above it in the case of cooling. For example, a ramped summer setpoint that consisted of a repeated pattern of three phases of equal length set at 72° F., 73° F., and 74° F. would create an effective average setpoint of 73° F., but would generally be experienced by occupants as yielding equivalent comfort as in a room set at a constant 72° F. Energy savings resulting from this approach have been shown to be in the range of 4-6%.

The subject invention can automatically generate optimized ramped setpoints for individual conditioned spaces in a larger building that could save energy without compromising the comfort of the occupants. It would also be advantageous to create a temperature control system that could incorporate adaptive algorithms that could automatically determine when the ramped setpoints should not be applied due to a variety of exogenous conditions that make application of such ramped setpoints undesirable.

FIG. 32 represents the conventional programming of a thermostat and the resulting behavior of a conditioned space's HVAC system in the air conditioning context. Themorning setpoint3302 of 74 degrees remains constant from midnight until 9:00 AM, and theinside temperature3304 varies more or less within the limits of the hysteresis band (which is generally set by the thermostat) during that entire period. When the setpoint changes to 80degrees3306, theinside temperature3308 rises until it reaches and then varies within the hysteresis band around the new setpoint, and so on. Whether the average temperature is equal to, greater or less than the nominal setpoint will depend on weather conditions, the dynamic signature of the structure, and the efficiency and size of the HVAC system. But in most cases the average temperature will be at least roughly equivalent to the nominal setpoint.

FIG. 33 represents implementation of a three-phase ramped setpoint derived from the same user preferences as manifested by the settings shown inFIG. 32. Thus the user-selected setpoint for the morning is still74 degrees, and is reflected in thesetpoint3404 at the start of each three-step cycle, but because (in the air conditioning context) the setpoint requested by the user is the lowest of the three discrete steps, rather than the middle step, the average setpoint will be one degree higher3402 (in the case of 1 degree steps between setpoints), and the resulting average inside temperature will be roughly one degree warmer than the average temperature without use of the ramped setpoints, thereby saving energy.

In the currently preferred embodiment, the implementation of the ramped setpoints may be dynamic based upon both conditions inside the structure and other planned setpoint changes. Thus, for example, the ramped

setpoints

3406,3408 and3410 may be timed so that the 9 AM change in user-determined setpoint from 74 degrees to 80 degrees is in effect anticipated, and the period in which the air conditioner is not used can be extended prior to the scheduled start time for the less energy-intensive setpoint. Similarly, because theserver106 is aware that a lower setpoint will begin at 5 PM, the timing can be adjusted to avoid excessively warm temperatures immediately prior to the scheduled setpoint change, which could cause noticeable discomfort relative to the new setpoint if the air conditioner is incapable of quickly reducing inside temperature on a given day based upon the expected slope of inside temperatures at thattime3412.

In order to implement such ramped setpoints automatically, algorithms may be created. These algorithms may be generated and/or executed as instructions onremote server106 and the resulting setpoint changes can be transmitted to a given thermostat on a just-in-time basis or, if thethermostat108 is capable of storing future settings, they may be transferred in batch mode to such thermostats. Basic parameters used to generate such algorithms include:

- the number of discrete phases to be used;
- the temperature differential associated with each phase; and
- the duration of each phase.

In order to increase user comfort and thus maximize consumer acceptance, additional parameters may be considered, including:

- time of day
- outside weather conditions
- recent history of manual inputs; and
- recent pre-programmed setpoint changes.

Time of day may be relevant because, for example, if the home is typically unoccupied at a given time, there is no need for perceptual programming. Outside weather is relevant because comfort is dependent not just on temperature as sensed by a thermostat, but also includes radiant differentials. On extremely cold days, even if the inside dry-bulb temperature is within normal comfort range, radiant losses due to cold surfaces such as single-glazed windows can cause subjective discomfort; thus on such days occupants may be more sensitive to ramping. Recent manual inputs (e.g., programming overrides) may create situations in which exceptions should be taken; depending on the context, recent manual inputs may either suspend the ramping of setpoints or simply alter the baseline temperature from which the ramping takes place.

FIG. 34 shows the steps used in an embodiment of the core ramped setpoint algorithm in the context of a remotely managed thermostat system. Instep3502 the application determines whether to instantiate the algorithm based upon external scheduling criteria. Such information may include previously learned occupancy patterns, previously learned temperature preferences, responses to previous implementations of energy-savings strategies, etc. Instep3504 the application running on a remote server retrieves from the thermostat the data generated by or entered into the thermostat, including current temperature settings, HVAC status and inside temperature. The algorithm performs preliminary logical tests at that point to determine whether further processing is required. For example, in the heating context, if the inside temperature as reported by thethermostat108 is more than 1 degree higher than the current setpoint, the algorithm may determine that running the ramped setpoint program will have no effect and therefore terminate. Instep3506 the algorithm advances to the next phase from the most recent phase; i.e., if the algorithm is just starting, the phase changes from “0” to “1”; if it has just completed the third phase of a three-phase ramp, the phase will change from “2” to “0”. Instep3508 the application determines if the current phase is “0”. If it is, then instep3510 the algorithm determines whether current setpoint equals the setpoint in the previous phase. If so, which implies no manual overrides or other setpoint adjustments have occurred during the most recent phase, then instep3512 the algorithm sets the new setpoint back to the previous phase “0” setpoint. If not, then instep3514, the algorithm keeps the current temperature setting as setpoint for this new phase. Instep3516, the algorithm logs the resulting new setpoint as the new phase “0” setpoint for use in subsequent phases.

Returning to the branch afterstep3508, if the current phase at that point is not phase “0”, then instep3520, the algorithm determines whether the current setpoint is equal to the setpoint temperature in the previous phase. If not, which implies setpoints have been adjusted by the occupants, thermostat schedules, or other events, then instep3522, the application resets the phase to “0”, resets the new setpoint associated with phase “0” to equal the current temperature setting, and sets the current setting to that temperature. Alternatively, if the current temperature setting as determined instep3520 is equal to the setpoint in the previous phase, then instep3524 new setpoint is made to equal current setpoint plus the differential associated with each phase change. Instep3526 the “previous-phase setpoint” variable is reset to equal the new setpoint in anticipation of its use during a subsequent iteration.

FIG. 35 shows one embodiment of the overall control application implementing the algorithm described inFIG. 35. Instep3602, the control application retrieves the current setting from the thermostat. Instep3604, the setting is logged indatabase300. Instep3606, the control program determines whether other algorithms that have higher precedence than the ramped setpoint algorithm are to be run. If another algorithm is to be run prior to the ramped setpoint algorithm, then the other program is executed instep3608. If there are no alternate algorithms that should precede the ramped setpoint application then instep3610, the control program determines whether the thermostat has been assigned to execute the ramped setpoint program. If not, the control program skips the remaining actions in the current iteration. If the program is set to run, then instep3612 the algorithm retrieves fromdatabase300 the rules and parameters governing the implementation of the algorithm for the current application of the program. Instep3614, the algorithm determines whether one or more conditions that preclude application of the algorithm, such as extreme outside weather conditions, whether the home is likely to be occupied, execution of a conflicting algorithm, etc. If any of the exclusionary conditions apply, the application skips execution of the ramped setpoint algorithm for the current iteration. If not, the application proceeds to step3616 in which the application determines whether the setpoint has been altered by manual overrides, thermostat setback schedule changes, or other algorithms as compared to the previous value as stored indatabase300. If the setpoint has been altered, the application proceeds to step3620 discussed below. Instep3618, the program described inFIG. 34 is executed. Instep3620, the application resets the phase to “0”. Certain temperature setting variables are reset in anticipation of their use in subsequent phases. These variables include thenew phase0 temperature setting, which is anchored to the current actual temperature setting, and the new previous-phase setpoint, which will be used for identifying setpoint, overrides in the subsequent phase.

Instep3622, the system records the changes to the thermostat settings todatabase300. Instep3624, the system records the changes to the phase status of the algorithm todatabase300. Instep3626, the application determines whether the new temperature setting differs from the current setting. If they are the same, the application skips applying changes to the thermostat. If they are different, then instep3628, the application transmits revised settings to the thermostat. Instep3630, the application then hibernates for the specified duration until it is invoked again by beginning atstep3602 again.

The subject invention may also be used to detect occupancy of a specific conditioned space through the use of software related to electronic devices located inside the conditioned structure, such as the browser running on computer orother device104.FIG. 36 represents the screen of a computer, television orother device104 using a graphical user interface connected to the Internet. The screen shows that abrowser3700 is displayed oncomputer104. In one embodiment, a background application installed oncomputer104 detects activity by a user of the computer, such as cursor movement, keystrokes or otherwise, and signals the application running onserver106 that activity has been detected. Conversely, a lack of activity on devices normally associated with an individual occupancy unit may suggest, but cannot conclusively show, that the unit is occupied.Server106 may then, depending on context, (a) transmit a signal tothermostat108 changing setpoint because occupancy has been detected at a time when the system did not expect occupancy (or that non-occupancy has been inferred when occupancy is assumed to be the norm); (b) signal the background application running oncomputer104 to trigger a software routine that instantiates a pop-upwindow3702 that asks the user if the server should change the current setpoint, alter the overall programming of the system based upon a new occupancy pattern, etc. The user can respond by clicking the cursor on “yes”button3704 or “No”button3706. Equilvalent means of signalling activity may be employed with interactive television programming, gaming systems, etc.

FIG. 37 is a flowchart showing the steps involved in the operation of one embodiment of the subject invention. Instep3802,computer104 transmits a message toserver106 via the Internet indicating that there is user activity oncomputer104. This activity can be in the form of keystrokes, cursor movement, input via a television remote control, etc. Instep3804 the application queriesdatabase300 to retrieve setting information for the associated HVAC system. Instep3806 the application determines whether the current HVAC program is intended to apply when the conditioned space is occupied or unoccupied. If the HVAC settings then in effect are intended to apply to an occupied unit, then the application terminates for a specified interval. If the HVAC settings then in effect are intended to apply when the home is unoccupied, then instep3808 the application will retrieve fromdatabase300 the user's specific preferences for how to handle this situation. If the user has previously specified (at the time that the program was initially set up or subsequently modified) that the user prefers that the system automatically change settings under such circumstances, the application then proceeds to step3816, in which it changes the programmed setpoint for the thermostat to the setting intended for the conditioned space when occupied. If the user has previously specified that the application should not make such changes without further user input, then in step3810 the application transmits a command tocomputer104 directing the browser to display a message informing the user that the current setting assumes an unoccupied conditioned space and asking the user instep3812 to choose whether to either keep the current settings or revert to the pre-selected setting for an occupied conditioned space. If the user elects to retain the current setting, then instep3814 the application will write todatabase300 the fact that the users has so elected and terminate. If the user elects to change the setting, then instep3816 the application transmits the revised setpoint to the thermostat. Instep3814 the application writes the updated setting information todatabase300. Similar logic may be used to proceed from a lack of activity oncomputer104 to a conclusion that the HVAC settings should be optimized for an unoccupied state.

FIG. 38 is a flowchart that shows how the subject invention can be used to select different HVAC settings based upon its ability to identify which of multiple potential occupants is using the computer or other device connected to the system. Instep3902

computer

104 transmits toserver106 information regarding the type of activity detected oncomputer104. Such information could include the specific program or channel being watched if, for example,computer104 is used to watch television. The information matching, for example,TV channel 7 at 4:00 PM on a given date to specific content may be made by referring to Internet-based or other widely available scheduling sources for such content. Instep3904

server

106 retrieves fromdatabase300 previously logged data regarding viewed programs. Instep3906

server

106 retrieves previously stored data regarding the occupants of the conditioned space. For example, upon initiating the service, one or more users may have filled out online questionnaires sharing their age, gender, schedules, viewing preferences, etc. Instep3908,server106 compares the received information about user activity to previously stored information retrieved fromdatabase300 about the occupants and their viewing preferences. For example, ifcomputer104 indicates toserver106 that the computer is being used to watch golf, the server may conclude that an adult male is watching; ifcomputer104 indicates that it is being used to watch children's programming,server106 may conclude that a child is watching. Instep3910 the server transmits a query to the user in order to verify the match, asking, in effect, “Is that you, Bob?” Instep3912, based upon the user's response, the application determines whether the correct user has been identified. If the answer is no, then the application proceeds to step3916. If the answer is yes, then instep3914 the application retrieves the temperature preferences for the identified occupant. Instep3916 the application writes todatabase300 the programming information and information regarding matching of users to that programming.

In an alternative embodiment, the application running oncomputer104 may respond to general user inputs (that is, inputs not specifically intended to instantiate communication with the remote server) by querying the user whether a given action should be taken. For example, in a system in which thecomputer104 is a web-enabled television or web-enabled set-top device connected to a television as a display, software running oncomputer104 detects user activity, and transmits a message indicating such activity toserver106. The trigger for this signal may be general, such as changing channels or adjusting volume with the remote control or a power-on event. Upon receipt byserver106 of this trigger,server106 transmits instructions tocomputer104 causing it to display a dialog box asking the user whether the user wishes to change HVAC settings.

Alternatively,server106 may use biometric data provided bycomputer104, such as fingerprints (which some computers and other devices now require for log-in), retinal scans, or other methods for identifying the user of an electronic device.

Those skilled in the relevant arts will likely recognize ways to apply the subject invention in additional contexts. In addition to use with chiller-based HVAC systems as described herein, the subject invention is also capable of use with other centralized systems including steam boilers, hydronic centralized heating, etc. The subject invention will be of value whenever a central plant is used to deliver space conditioning to separately owned or rented spaces, regardless of the means of generating and moving the conditioning (heating or cooling) medium.

Fan Delay

One such thermostat parameter for energy saving and comfort is the delay between actively running a compressor for cooling and turning off the compressor and turning off the ventilation fan. During the delay period, only the ventilation fan runs. This delay is called fan delay.

Fan delay can be employed when a compressor is used for heating, such as a heat pump, and can also be employed for other forms of heating such as forced air furnace and radiant. In each case, energy saving and comfort can be optimized by varying the delay between turning off the source of heating or cooling and turning off the ventilation fan.

A machine learning approach to learning fan delay would be one which monitors how long it takes for the next run cycle to start (and/or how much lower the temperature drops after the compressor stops running and the inside humidity behavior if available) depending on (a) the duration of the fan delay, (b) the duration of the previous run cycle, (c) the outside temperature, and (d) time of day. Leaky houses will see a low or negative benefit from long fan delay cycles, while well insulated houses should see a positive benefit. Similarly, poor HVAC duct insulation can reduce or eliminate the benefit of fan delay. The fan delay algorithm should be able to learn and adapt accordingly to differences in house thermal characteristics, differences in HVAC characteristics, and differences in outdoor weather.

Acclimatization-Based Dynamically Variable Thermostat Settings

Humans are sensitive to humid air because the human body uses evaporative cooling as the primary mechanism to regulate temperature. Under humid conditions, the rate at which perspiration evaporates on the skin is lower than it would be under arid conditions. Because humans perceive the rate of heat transfer from the body rather than temperature itself, we feel warmer when the relative humidity is high than when it is low.

Another example of an adjusted parameter is maintaining comfort based on perceived temperature based on humidity and outside temperature. When a person is exposed to consistent levels of temperature and humidity, there tends to be acclimatization. Occupants of cold climates may wear shorts when it is 60 degrees F., while those accustomed to warm climates may want to wear coats at that same temperature. The ill and elderly may also require different levels. So the level of acclimatization varies for each individual, and varies for cooling versus heating.

Because acclimatization varies, a machine learning approach can be used to learn the level of adjustment to maintain comfort, or the degree of energy savings that can be achieved.

An energy efficiency optimized approach to maintaining comfort can use customized calculations of perceived or relative temperature based on humidity and outside temperature. Based on outside temperature and humidity, indoor temperature and humidity, and temperature gradient when the HVAC running, the thermostat can minimize compressor run time while meeting perceived comfort levels. For example, on a very hot day that is not too humid, the HVAC can be turned off before it reaches the nominal setpoint. On a very humid day, the HVAC could cool below the nominal setpoint.

Machine learning adjustments generally require looking at a large number of historical data points for a given structure, and may include historical data points for comparable structures. This is generally impractical to run locally on an embedded device such as a thermostat. Optimization is performed by a machine learning system running as a cloud service to adjust a thermostat. However, the learned level of adjustment can be updated periodically on the thermostat for local processing.

FIG. 39 shows an example of anoverall environment3900 in which an embodiment of the invention that learns occupant acclimatization to temperature and humidity may be used. Theenvironment3900 includes theinteractive communication network102 with thecomputers104 connected thereto. Also connected to network102 aremobile devices105, and one ormore server computers106, which store information and make the information available tocomputers104 andmobile devices105. Thenetwork102 allows communication between and among thecomputers104,mobile devices105 andservers106.

When a user of an embodiment of the invention wishes to access information onnetwork102 usingcomputer104 ormobile device105, the user initiates connection from hiscomputer104 ormobile device105. For example, the user invokes a browser, which executes oncomputer104 ormobile device105. The browser, in turn, establishes a communication link withnetwork102. Once connected to network102, the user can direct the browser to access information onserver106.

Computers

104 can be microprocessor-controlled home entertainment equipment including advanced televisions, televisions paired with home entertainment/media centers, and wireless remote controls.

Computers

Mobile devices

105 can also be handheld and wireless devices such as personal digital assistants (PDAs), cellular telephones and other devices capable of accessing the network.Mobile devices105 can use a variety of means for establishing the location of each device at a given time. Such methods may include the Global Positioning System (GPS), location relative to cellular towers, connection to specific wireless access points, or other means.

In an embodiment, attached to thenetwork102 arecellular radio towers120, or other means to transmit and receive wireless signals in communication withmobile devices105. Such communication may use GPRS, GSM, CDMA, EvDO, EDGE or other protocols and technologies for connecting mobile devices to a network.

Also attached to the network arehumidity sensors3908,thermostats108, andcomputers104 of various users. In an embodiment, thehumidity sensors3908 are associated withthermostats108 within the houses of the various users. Humidity sensors, also known as hygrometers, measure the amount of water vapor in the air, otherwise known as humidity. A temperature humidity sensor, including both a thermometer and a hygrometer, measures the air temperature as well as humidity. In an embodiment, thehumidity sensors3908 measure and record the humidity instantaneously or in intervals and communicate the humidity information to theservers106. In another embodiment, a humidifier comprises thehumidity sensor3908.

Connected tothermostats108 are individual air handlers or HVAC (heating, ventilation and air conditioning)systems110. Eachair handler110 may supply conditioned air to an entire apartment or unit, or multiple air handlers may be used in a given space. In an embodiment, the HVAC systems are programmable. In an embodiment, the HVAC systems comprise thehumidity sensor3908. In an embodiment, the programmable HVAC systems are configured to adjust a setpoint of the programmable HVAC systems.

Each user may be connected to theserver106 via wired or wireless connection such as Ethernet or a wireless protocol such as IEEE 802.11, via a modem orgateway112 that connects thecomputer104 andthermostat108 to the Internet via a broadband connection such as a digital subscriber line (DSL), cellular radio or other method of connection to the World Wide Web.

Thehumidity sensors3908 and/orthermostats108 may be connected locally via a wired connection such as Ethernet or Homeplug or other wired network, or wirelessly via IEEE802.11, 802.15.4, or other wireless network, which may include agateway112.Server106 contains content to be served as web pages and viewed bycomputers104, software to managethermostats108, software to manage the operation ofthermostats108, as well as databases containing information used by theservers106.

As shown inFIG. 40, theoverall database structure4000 may includeoutside temperature database4004, outsidehumidity database4005, insidetemperature database4006, inside humidity database4007, delta-temperature (ΔT )database4008, perceived outsidetemperature database4009, perceive insidetemperature database4010,thermostat settings database4011,user database4012, and such other databases as may be needed to support these and additional features. In an embodiment, the perceived temperatures take into account the humidity and indicate a “real feel” temperature.

Thermostat

108, in an embodiment, is a communicatingthermostat108.Thermostat108 includes temperature sensing functionality, which may be a thermistor, thermal diode or other device used in the design of electronic thermostats.Thermostat108 further includes a microprocessor, memory, a display, a power source, a relay, which turns theHVAC system110 on and off in response to a signal from the microprocessor, and contacts by which the relay is connected to the wires that lead to theHVAC system110. To allow thethermostat108 to communicate bi-directionally with thecomputer network102, thethermostat108 also communicates with a local computer or to a wireless network, such as Ethernet, wireless protocols such as IEEE 802.11, IEEE 802.15.4, Bluetooth, cellular systems such as CDMA, GSM and GPRS, or other wireless protocols. Thethermostat108 also includes controls allowing users to change settings directly at thethermostat108.

An attribute of residential thermostats is that they give occupants the ability to change the current temperature setting. Even the most complex programmable thermostats allow users to do so with a simple gesture. With most programmable thermostats, this involves pushing an up arrow to raise the setpoint and a down arrow to lower the setpoint. Because programming thermostats is seen is prohibitively difficult by many people, this tends to be the most prevalent means of interacting with these systems.

Consumers generally understand this mode of interaction with thermostats. Such inputs can be reliably interpreted to express two things: first, a manual temperature adjustment entered at the thermostat is an unambiguous signal indicating that the structure containing the thermostat is occupied. And second, changes in setpoint entered at the thermostat indicate that at least one occupant desires an inside temperature that is different from the current actual temperature in the structure. In other words, if the buttons/arrows on the thermostat are used to select a setpoint of 68 degrees F. when the temperature inside the structure is 75 degrees F., it is safe to assume that someone inside the structure is too warm; if the buttons/arrows on the thermostat are used to select a setpoint of 75 degrees F. when the temperature inside the structure is 68 degrees F., it is safe to assume that someone inside the structure is too cold.

While certain aspects of interpretation of such explicit interactions with a thermostat are relatively straightforward in the immediate short-term, using those interactions (and their absence) to make decisions about setpoints in the longer term represent a classic problem of decision-making under uncertainty. If a thermostat that has gone six months without ever being touched between the hours of 9 AM and 5 PM on a weekday is manually overridden at 10:33 AM on the first Wednesday in March, what does that imply about the proper setpoint the next day? The day after? The following Wednesday? What does it imply about the proper setpoint on the same afternoon? In a system in which the bottom-line questions (is the conditioned space currently occupied, and by whom? The current temperature preference of the current occupant(s)?) is rarely given explicit answers. The minimal information that is available can be leveraged in creative ways in order to deliver reasonable approximations of the best strategy.

The techniques of reinforcement learning are applied to this problem.

Reinforcement Learning

Reinforcement learning (RL) is a algorithmic approach in which an ‘agent’ or set of algorithms that receives inputs in the form of data about the environment, makes decisions based on those inputs, and then turns those decisions into actions, learns by iteratively interacting with its surrounding environment (which from the perspective of the agent consists of a data set) in pursuit of some goal, which is generally in the form of a reward, and/or avoidance of an adverse result, which is generally in the form of a negative reward or punishment. The agent is directed by the feedback it receives (that is, that actions that lead to rewards are more likely to be repeated than actions that do not), but what makes RL a technique that is useful in many circumstances is that the correct action in a given circumstance is not known to the agent in advance. The process is similar to how much learning occurs in nature: a baby learns to crawl when it wants to move toward an interesting object by trying out relatively random movements, and over time focuses on those movements that result in the reward of achieving the desired result—reaching the desired object. It avoids those actions that are ineffective or that result in negative reward (e.g., getting hurt).

At a high level, a RL algorithm iteratively:

- 1. monitors the state of the surrounding environment;
- 2. decides which action would be the most valuable to take next; and
- 3. takes that action on the environment.

For example, a RL algorithm that learns to perfect a recipe for meringues will iteratively:

- 1. appraise the quality of the last meringue (results of objective tests, response of human taste tester, etc.);
- 2. decide which ingredients and/or preparation steps to adjust; and
- 3. update the meringue recipe.

During step (1) of this algorithm, the RL agent achieves an immediate reward or penalty—in this example based on the quality of the meringue just produced. The agent uses this reward to update the ‘value’ of the action it previously took.

Two key aspects of this approach are (i) that when a RL algorithm is first applied to a problem, the solution set consists of not a single answer but of many answers, and (ii) most or all of those answers are not known a priori. Thus this form of RL is applicable to a range of complex problems in which even a knowledgeable human “agent” would have to “learn as she goes.”

Another key aspect of this type of RL is that the agent's decision-making must weigh two different goals, which are often referred to as exploitation and exploration. Exploitation is how the agent uses what it already knows: if action A produces a reward, repeat action A. Exploration is how the agent increases its store of knowledge: “what happens if I try action B?” It is generally necessary to incent the agent to do some level of exploration in order to make the function of the agent useful. Otherwise, an agent operating in an environment with a large number of possible actions that hit upon action A the first time it is run would simply repeat Action A (a local optimum) ad infinitum without ever learning the results in other regions of the decision environment, and perhaps missing higher rewards that might come from other actions. Conversely, incenting an agent to do only exploration in an environment with a very large range of possible actions would likely result in achieving poor results until after an impractically large number of iterations.

A common method for balancing these two goals is to make each decision probabilistic, and to weight exploration with a high probability in the early stages but lower the weighting assigned to exploration with time as the decision space becomes better understood. Again, this appears to match how much learning occurs in the real world: a baby may initially try to move around while on its back or its side, but once crawling on all fours begins to show results, it favors that technique, and exploration is applied to the next problem—efficient coordination of the movement of its arms and legs.

However, there are a number of drawbacks to the prevalent approaches to RL. One such difficulty is in essence the flipside of a core benefit: the fact that it will work in situations in which the “right” answers are not known a priori. As the agent sets off on the path to optimization, it may end up in places that are unanticipated and undesirable results. What is needed is a way to tune the weighing of probabilities given to exploration and exploitation while the agent is running.

Thermostatic control of HVAC systems has been practiced in various forms for at least a century. It is important to find ways to use thermostats effectively because roughly half of the energy consumed by a typical American home goes to the cost of space heating and cooling, and thus is managed by a thermostat.

For example, a home that has only a furnace (no air conditioning), there are two possible states for the HVAC system (off and on/heating), and there are three possible states for the experience of comfort by occupants (cold, comfortable, and hot.) The thermostat is informed of the current comfort state by adjustments to the setpoint. If, for example, a manual adjustment informs the thermostat that the current comfort state is “cold” and the current state of the HVAC system is “off,” the agent takes the action of changing the state of the HVAC system to “on.” Such a thermostat is incapable of learning.

If energy costs and the effects of energy use on the environment are not considered, thermostatic control in a home are such that the occupant choses a preferred temperature and the thermostat maintains it. But in most cases this is extremely wasteful, in large part because most homes are not occupied24 hours per day, seven days per week. Heating and cooling unoccupied space is a major form of waste, and is the primary problem programmable thermostats were intended to solve.

If the occupants of a given home have perfectly consistent schedules, conventional programmable thermostats may, if perfectly programmed, do a passable job of maintaining while minimizing waste, though such primitive devices fail to take advantage of many opportunities to save energy. However, most homes are occupied by people who have complex, constantly evolving schedules. If, for example, a homeowner has programmed her thermostat to reduce the heating setpoint by 8 degrees while away during the day, and return to the comfort setting of 72 degrees at 7 PM, she is likely to be satisfied on a day when she returns at 7 PM. She will likely still be satisfied on a day when she comes home at9PM, though she will have wasted two hours of conditioning.

It would be beneficial if reinforcement learning could be applied to thermostatic controllers in a way that would enable continuous learning and optimization rather than simply creating a static schedule.

Setpoint Optimization

Setpoint optimization (SPO) is a RL problem in the sense that:

- learning is directed by rewards and penalties (e.g. energy savings and manual overrides respectively), but
- It is difficult to know in advance what the correct setpoint is for a given user at a given time of day.

In addition to the usual RL demands it is advantageous to make an SPO algorithm easily configurable, such that it's rate of exploration can be easily controlled by a human operator.

At a high level, the SPO algorithm iteratively:

- 1. gathers feedback from the environment such as successful energy-efficiency adjustments and user feedback;
- 2. decides what energy-efficiency strategy to apply for the next period of time (e.g. 24 hours); and
- 3. applies this strategy, possibly with adjustments based on real-time feedback.

In one form, the SPO problem is considered to consist of a space spanned by time and energy-efficiency (EE), where the latter can be regarded as the distance from the users' default scheduled setpoint. In practice both dimensions are discretized (30 minutes and 1 degree Fahrenheit for example). For the purposes of illustration, in the following we simplify matters by presuming that the EE at a particular time of the day is independent from the EE applied at any other time of the day.

In another embodiment, instead of a distance from a scheduled setpoint, the distance could be measured against a “comfort temperature”. The comfort temperature can be determined from historical data from an individual home. For example, the 75^thpercentile setpoint when an HVAC is running can be inferred to be the consensus comfort temperature of all occupants of a house. In other cases, the comfort temperature can be determined by the typical settings used by a collection of homes. The collection of homes can be grouped by region, home type, age, etc. to determine preferences based on type of home or demographics of the occupants. While, in one embodiment, the description describes increasing EE to save energy, the same approach, in other embodiments, can be used to learn “negative” EE and increase comfort.

The logic of the SPO algorithm can be separated into two distinct phases:

- 1. Action
  - what immediate changes should be made in EE?
- 2. Learning
  - how should EE evolve in the future?

Action

The action taken by the agent depends on whether there has been any feedback from the user.

For example, in the absence of input from the user, the agent gradually attempts to improve EE. The rate of this improvement is controlled by acceptance of prior EE changes. In other words, the algorithm cannot escalate to three degrees Fahrenheit before it has successfully proven two degrees has been acceptable.

When there is feedback from the user, the agent's action must be different. For example, if there has been an inefficient manual override the action can be to decrease subsequent EE and increase the number of days needed to make further adjustments.

Adjustment actions could depend on whether the manual override was approving or disapproving. Furthermore, they could well depend on variables such as time of day, day of week, outside weather, and previous user feedback.

Learning

A conventional thermostat may be thought of as having primitive decision making, but without any learning.

Long-term learning is achieved through building a table of adjustments to apply at different times of day, or days of week.

FIG. 47 illustrates aniterative process4900 to propose a setpoint optimization change to the setpoint of thethermostat108. Atstep4902, theprocess4900 or the one ormore servers106 determines an initial setpoint for energy efficiency (EE) optimization. In an embodiment, the initial setpoint is based on temperature and occupancy of the residence. In one embodiment, the temperature is the internal temperature of the residence as indicated by thethermostat108.

At step4904, theprocess4900 applies the EE optimized setpoint to thethermostat108. In an embodiment, when the EE optimized setpoint is applied, the amount of EE can be adjusted based on humidity and/or acclimatization. In another embodiment, the amount of EE can be adjusted based on any factors that affect the perceived amount of change. Further, the EE adjustment can result in a normalized change such that the perceived change remains the same to the user.

When the intended amount of EE does not change, the actual amount of EE applied can be adjusted periodically or continuously based upon humidity and/or acclimatization.

Atstep4906, theprocess4900 determines whether feedback has been received in response to the applied setpoint. In an embodiment, the feedback comprises a manual override (MO) of the applied setpoint.

If no feedback is received, the EE setpoint is successful and theprocess4900 moves to step4908. Atstep4908, theprocess4900 determines if it is acceptable to improve EE. If the criteria to improve EE has not been met, theprocess4900 returns to step4904.

In an embodiment, atstep4910, the EE setpoint is revised based at least in part on the feedback, humidity and/or acclimatization.

If atstep4906, feedback has been received, theprocess4900 moves to step4914. Atstep4914, theprocess4900 gathers the feedback, typically a MO by the user.

Theprocess4900 revises the EE setpoint based at least in part on the feedback atstep4916 and returns to step4904 to apply the revised EE setpoint. In an embodiment, atstep4916, the EE setpoint is revised based at least in part on the feedback, humidity and/or acclimatization.

In general, HVAC systems use energy in order to increase the difference between inside temperatures and outside temperatures. That is, in the winter context, when the outside temperature may be 40 degrees F. or lower, an unconditioned home is likely to eventual reach a temperature that (but for factors like solar gain and the presence of other heat sources such as appliances and people) is close to the outside temperature. In the summer context, outside temperatures may reach 100 degrees F. or more, and an unconditioned home, given the factors previously mentioned, can easily exceed the outside temperature. Humans tend to be quite uncomfortable at such temperatures, and therefore use HVAC systems to maintain inside temperatures within a relatively narrow range, usually ranging from the high 60s or low 70s in the winter, and somewhat higher in summer. For a given home and HVAC system, the higher the winter setpoint is maintained, and the lower the summer setpoint, the more energy is consumed. Thus one way of thinking about the problem of saving energy is to find ways to reduce the difference between inside and outside temperatures.

In general, people tend to be relatively intolerant of large deviations from the preferred comfort range when their homes are occupied. Thus while savings are certainly possible for many users at such times, there are often greater opportunities to save energy during periods when the structure is unoccupied.

If a system is capable of determining that a home is unoccupied with sufficient accuracy, several aspects of the task of saving energy are vastly simplified. For example, if a thermostat is connected as part of a home security system, there will likely be unambiguous signals that the home is unoccupied if, for example, the system has a specific state that indicates “armed—away.” Knowing only that the system is armed is insufficient, as some users will arm their systems when they go to sleep.

But such a system will still not be capable of maximizing savings against comfort. First, many people who have alarm systems do not always arm them, which will mean that there may be significant savings opportunities that are not explicitly signaled by the system. Second, relying on explicit arm-disarm signaling provides no ability to anticipate or predict. To minimize the chances of coming home to an uncomfortable home, users are likely to select relatively small setbacks for away periods. If the system could reliably anticipate when the home is likely to be re-occupied, more aggressive away setbacks could be employed.

The learning algorithms attempt to save energy by attempting to identify periods when the home is unoccupied in the absence of explicit signaling. These algorithms start from the following assumptions:

- 1) Manual overrides always indicate presence of occupants within the structure.
- 2) Manual overrides usually indicate some measure of dissatisfaction with the temperature inside the structure.
- 3) The absence of manual overrides may or may not indicate that the structure is unoccupied.
- 4) The dissatisfaction associated with a manual override varies over time.
- 5) The dissatisfaction associated with a manual override varies with the magnitude of the override—that is, a change of 8 degrees indicates greater dissatisfaction than a change of one degree.

It should be noted that, with networked HVAC control systems, it is possible that setpoint changes can come from sources other than direct manual overrides entered at the thermostat. Users may be able to change setpoints from a different device inside the home, or from a computer or mobile device that could be virtually anywhere in the world. Thus the logic employed must effectively differentiate between these alternate sources.

One of the challenges inherent in this process is differentiation between isolated events and emerging patterns. For example, the system may have learned that a home is probably unoccupied between 9 AM and 5 PM each Monday through Friday, and have acted on that knowledge by adopting a relatively aggressive away setpoint for most of that time each weekday. If, on a certain Wednesday, a manual override is recorded at 2 PM, how should the system react between 2 PM and 5 PM on that day? How should it react the following day? How should it react on the following Wednesday? If the system is highly sensitive to individual manual overrides, and the occupant's patterns of interaction are sufficiently uncorrelated, the system will make too many changes and likely deliver minimal savings. At the other extreme, if the system is tuned to be relatively insensitive to each manual override, the odds of generating savings increase, but so do the odds of making occupants uncomfortable.

One approach to this problem includes assigning multiple attributes to each manual override, and to make those attributes dynamic. The half-life concept gives a degree of persistence to the effect of a given manual override on subsequent days, but allows that effect to diminish with time. Thus a manual override will have full weight on the day it happens, but will be reduced over time until eventual the system no longer takes that particular event into account. The rate of decay will affect the extent to which the algorithm favors comfort vs. savings.

The system also makes assumptions regarding how manual interactions on one day may be related to interactions on other days. For example, a significant majority of the population works Monday through Friday, but not on Saturday or Sunday.

It should also be noted that vexation can be inferred from other forms of feedback instead of or in addition to manual overrides. Such alternate sources can include customer support calls or other means by which customers interact with the product or the provider of the service.

In operation, as the occupant(s) of a given building interact with the system, the algorithm builds a map of vexation for those occupants. For example, onday 1, the user manually overrides the system at 7:12 AM and 11:40 AM, but not again until 10:04 PM. Onday 2, the user overrides at 10:20 AM. Onday 3, the user overrides at 9:55 AM and 11:44 PM.

These three inputs permit the algorithm to construct a map of vexation for that system. It shows that there is a high likelihood of occupancy and sensitivity of the occupant to temperature changes beyond that user's preferred settings during morning hours and evening hours, but that during the afternoon, either the structure is likely to be unoccupied or even if it is occupied, the occupants have not shown the same sensitivity to temperature variation.

Thus, the algorithm will begin to attempt to save energy by reducing ΔT during periods of low vexation.

In order to adapt programming to take into account the manual overrides entered into the thermostat, it is first necessary to determine when a manual override has in fact occurred. Most thermostats, including two-way communicating devices discussed herein, do not record such inputs locally, and neither recognize nor transmit the fact that a manual override has occurred. Furthermore, in a system as described herein, changes in setpoints may be initiated by algorithms running on the server, thereby making it impossible to infer a manual override from the mere fact that the setpoint has changed. It is therefore necessary to deduce the occurrence of such events from the data that an embodiment of the invention does have access.

FIG. 41 illustrates a process4100 to detect the occurrence of a manual override event. Instep4102, the server retrieves the primary data points used to infer the occurrence of a manual override from one or more databases inoverall database structure4000. The data should include each of the following: for the most recent point for which it can obtain such data (time0) the actual setpoint as recorded at the thermostat (A0); for the point immediately prior to time0, (time-1), the actual setpoint recorded for the thermostat (A-1); for time0 the setpoint as scheduled byserver106 according to the standard setpoint programming (S0), and for (time-1) the setpoint as scheduled byserver106 according to the standard setpoint programming (S-1).

In embodiments where thethermostat108 is scheduled for manual operation and no schedule is available, then S0 is the last setpoint manually selected by the user. Since, in this case, there is no change to the setpoint applied by a schedule, dS=0.

In step4104, the server retrieves any additional automated setpoint changes C that have been scheduled for the thermostat byserver106 at time0. Such changes may include algorithmic changes intended to reduce energy consumption, etc.

In step4106 the server calculates the difference (dA) between A0 and A-1; for example, if the setpoint at time0 is 67 degrees at time-1 and 69 at time0, dA is +2; if the setpoint at time-1 is 70 and the setpoint at time0 is 66, dA is −4.

In step4108, the server performs similar steps in order to calculate dS, the difference between S0 and S-1. This is necessary because, for example, the setpoint may have been changed because the server itself had just executed a change, such as a scheduled change from “away” to “home” mode.

In step4110 the server evaluates and sums all active algorithms and other server-initiated strategies to determine their net effect on setpoint at time0. For example, if one algorithm has increased setpoint at time0 by 2 degrees as a short-term energy savings measure, but another algorithm has decreased the setpoint by one degree to compensate for expected subjective reactions to weather conditions, such as temperature and humidity, for example, the net algorithmic effect sC is +1 degree.

In step4112, the server calculates the value for M, where M is equal to the difference between actual setpoints dA, less the difference between scheduled setpoints dS, less the aggregate of algorithmic change sC.

In step4114 the server evaluates this difference. If the difference equals zero, the server concludes that no manual override has occurred, and the routine terminates. But if the difference is any value other than zero, then the server concludes that a manual override has occurred. Thus in step4116 the server logs the occurrence of an override to one or more databases inoverall database structure4000.

Anexemplary process4200 of interpreting a manual override is shown inFIG. 42.Step4202 is the detection of an override, as described in detail inFIG. 41.

In step4204, theserver106 retrieves the stored rules for thesubject thermostat108. Such rules may include weather and time-related inferences such as “if outside temperature is greater than 85 degrees and inside temperature is more than 2 degrees above setpoint and manual override lowers setpoint by 3 or more degrees, then revert to original setpoint in 2 hours,” or “if heating setpoint change is scheduled from “away” to “home” within following 2 hours after detected override, and override increases setpoint by at least 2 degrees, then change to “home” setting,” or the like.

Instep4206, theserver106 retrieves contextual data required to interpret the manual override. Such data may include current and recent weather conditions, including temperature and humidity, current and recent inside temperatures, current and recent inside humidity, and the like. This data is helpful because it is likely that manual overrides are at least in part deterministic: that is, that they may often be explained by such contextual data, and that such understanding can permit anticipation of the desire on the part of the occupants to override and to adjust programming accordingly, so as to anticipate and obviate the need for such changes.

In an embodiment, the manual override can be interpreted by adjusting the effective value of M based on humidity, learned tolerance to humidity, and acclimatization at step4116 of process4100, when M=0.

For example, higher humidity makes temperature variations less comfortable. Heat feels hotter and cold feels cooler. Setpoint temperatures should be moderated during high humidity—or conversely, efficiency can be more aggressive during low humidity without affecting comfort. In addition, the ability to learn an individual's (or household's) tolerance for humidity and discomfort can allow customized humidity-based adjustments. In an embodiment, setpoint optimization (SPO) adjusts setpoints based on historical acceptance or push back (via manual adjustments) to “proposed” setpoint changes. Scaling SPO adjustments based on humidity and individual tolerance of humidity can support both increased EE savings and increased comfort. One example of scaling adjustment is to determine humidity when a setpoint adjustment is made. If the change is accepted, the change is recorded in a humidity-dependent method. For example, if a change of 2 degrees is accepted at 30% humidity, this can be considered the equivalent of a 2.5 degrees change at <10% humidity or a 1.0 degree change at >60% humidity, and a 0.5 degree change at >80% humidity.

In step4208, theserver106 retrieves any override data from the period preceding the specific override being evaluated that has not yet been evaluated by and incorporated into the long-term programming and rules engines. The amount of data may be for a period of a few hours to as long as several days or more. Recent data will be more heavily weighted than older data in order to assure rapid adaptation to situations in which manual overrides represent stable changes such as changes in work schedules, etc.

Instep4210, theserver106 applies the rules to the override and determines which rule, if any, should be applied as a result of the override.

Instep4212, theserver106 determines whether to alter the current setpoint as a result of applying the rules instep4210. If no setpoint change is indicated, then theserver106 proceeds to step4218. If a setpoint change is indicated, then in step4214, theserver106 transmits the setpoint change to thethermostat108, and in step4216 it records that change to one or more databases inoverall database structure4000.

In order to ensure that both the stored rules for interpreting manual overrides and the programming itself continue to most accurately reflect the intentions of the occupants, the server will periodically review both the rules used to interpret overrides and the setpoint scheduling employed.FIG. 43 shows the steps used to incorporate manual overrides into the long-term rules and setpoint schedule. Instep4302, theserver106 retrieves the stored programming for a given thermostat as well as the rules for interpreting overrides for that thermostat.

In step4304, theserver106 retrieves the recent override data as recorded inFIGS. 41 and 42 to be evaluated for possible revisions to the rules and the programming.

In step4306, theserver106 retrieves the contextual data regarding overrides retrieved in step4304. Because the process illustrated inFIG. 43 may not be executed as a real-time process, and may be run anywhere from once per day to once per month, the range and volume of contextual data to be evaluated is may be greater than in the process illustrated inFIG. 42.

In step4308, theserver106 interprets the overrides in light of the existing programming schedule, rules for overrides, contextual data, etc. In step4310, theserver106 determines whether, as a result of those overrides as interpreted, the rules for interpreting manual overrides should be revised. If the rules are not to be revised, the process4300 moves to step4314.

If the rules are to be revised, then in step4312, theserver106 revises the rules and the new rules are stored in one or more databases inoverall database structure4000. In step4314, theserver106 determines whether any changes to the baseline programming for the thermostat should be revised. If not the routine terminates.

If revisions are warranted, then instep4316, theserver106 retrieves fromdatabase4012 the permissions theserver106 has to make autonomous changes to settings. If theserver106 has been given permission to make the proposed changes, then in step4318 the server revises the thermostat's programming and writes the changes to one or more databases inoverall database structure4000. If theserver106 has not been authorized to make such changes autonomously, then in step4320 theserver106 transmits the recommendation to change settings to the customer in the manner previously specified by the customer, such as email, changes to the customer's home page as displayed on the website, etc.

In an embodiment, theserver106 downloads the rules to thethermostat108, where thethermostat108 executes the rules and changes the setpoint.

For example, in many regions, humidity tends to rise through the afternoon and decline in the evening. A baseline humidity adjustment profile can be provided to eachthermostat108 at the beginning of each day, or beginning of each season. If there is a deviation from the expected pre-defined rules, such as a sudden thundershower, theserver106 may download to thethermostat108 different rules to reflect updated conditions. A threshold may be applied so that theserver106 updates rules for thosethermostats108 with significant deviations from baseline rule conditions.

In another embodiment, theserver106 sends a command to thethermostat108, where the command instructs thethermostat108 to change the setpoint to the newly determined setpoint, based on the changed rules. In a further embodiment, theserver106 downloads the data to thethermostat108 for the new thermostat setpoint.

Acclimatization depends upon perception and behavior adjustments depending at least on the season and temperature. For example, when used to wearing light clothing (e.g. shorts) during the summer, 68 degrees might feel cool. However, when exposed to freezing temperatures and bundled in winter coats, the same 68 degrees may feel quite warm. The level of acclimatization will depend on extended exposure to a temperature. When entering the conditioned space, a large ΔT between previous temperature (e.g. outside) and the conditioned space results in a positive perception. That is, when it is 100 degrees outside, entering a space that is 78 may feel approximately as good as when it is 76. With a larger ΔT, the setpoint optimization can be more efficient.

FIG. 44 illustrates anexemplary process4400 to dynamically adjust thermostat settings and HVAC run time based on occupant's acclimatization. At step4402, theserver106 determines whether theHVAC system110 is heating or cooling. In an embodiment, ΔT is the outside temperature minus the inside temperature. If ΔT is positive, then theHVAC system110 is cooling. If ΔT is negative, then theHVAC system110 is heating.

If cooling, theprocess4400 moves to step4404, where theserver106 calculates the cooling acclimatization based at least in part on historical outside temperature, humidity, and manually entered thermostat setpoints.

If heating, theprocess4400 moves to step4406, where theserver106 calculates the heating acclimatization based at least in part on historical outside temperature, humidity, and manually entered thermostat setpoints.

From

steps

4404 and4406, theprocess4400 moves to step4408, where theserver106 calculates a perceived setpoint adjustment based at least in part on the acclimatization, the HVAC temperature gradient, and the inside temperature and humidity.

Atstep4410, theserver106 adjusts the thermostat setpoint based on the perceived setpoint adjustment and at step4412 theserver106 adjusts the HVAC run time based on the perceived setpoint adjustment. Theprocess4400 returns to step4402 to continually adjust the setpoint adjustment and the HVAC run time.

FIG. 45 illustrates a process4500 using historical data that indicates acclimatization to temperature and humidity to dynamically adjust temperature based on current humidity.

Atstep4502, theserver106 receives the inside temperature measurements from thethermostat108 over time; at step4504, theserver106 receives the inside humidity measurements from thehumidity sensor3908 over time; and atstep4506, theserver106 receives the outside temperature measurements over time.

At step4508, theserver106 records the manual inputs to thethermostat108 from the occupants. At step4510, theserver106 determines the occupant's acclimatization.

In one embodiment, there are three forms of acclimatization that can be considered. One is seasonal, where someone gradually becomes accustomed to being hotter or colder during Summer and Winter. Another is current day, where an exceptionally hot or cold day can adjust individual perceptions. And another is time outside the home, taking advantage of occupancy information. When someone is out for an extended time, more acclimatization to outside temperature can be assumed. This may be imperfect, such as spending a long time in an air-conditioned car. In an embodiment, the acclimatization adjustments are expected to be limited to 1 or 2 degrees to reduce discomfort if acclimatization assumptions are not met.

At step4512, theserver106 compares the inside temperature measurements with the outside temperature measurements when theHVAC system110 is running, and at step4514, theserver106 determines the ΔT when theHVAC system110 is running, based on the comparison.

At step4516, theserver106 determines whether theHVAC system110 is heating or cooling. In an embodiment, the server uses the thermostat settings, which are reported to theserver106 to determine whether theHVAC system110 is heating or cooling. Thethermostat108 also may have an auto setting that switches between Heat and Cool automatically based on indoor temperature. The auto changes are also communicated to theserver106.

In an embodiment, ΔT is the outside temperature minus the inside temperature. If ΔT is positive, then theHVAC system110 is cooling. If ΔT is negative, then theHVAC system110 is heating.

If cooling, the process4500 moves to step4518, where theserver106 calculates the perceived setpoint adjustment based at least in part on inside temperature and humidity, outside temperature and humidity, and acclimatization.

If heating, the process4500 moves to step4520, where theserver106 calculates the perceived setpoint adjustment based at least in part on inside temperature and humidity, outside temperature and humidity, and acclimatization.

The perceived setpoint adjustment is an adjustment of the learned setpoint adjustment, where the learned setpoint adjustment is based upon the user behavior (push back to proposed thermostat settings). These learned setpoint adjustments can be further adjusted based upon how they would be perceived—more aggressive when conditions are favorable (e.g. low humidity, high ΔT) and vice-versa.

From both steps4518 and4520, the process4500 moves to step4522, where theserver106 adjusts the thermostat setpoint based on the perceived setpoint adjustment and the ΔT, and at step4524, theserver106 adjusts the HVAC run time based on the perceived setpoint adjustment and ΔT.

The process4500 returns to step4502 to continually adjust the setpoint adjustment and the HVAC run time, based at least in part on one or more of humidity and acclimatization.

FIG. 46 illustrates a process4600 to adjust a variable thermostat according to relative temperature to reduce energy usage and to maintain comfort levels of the occupants.

At step4602, theserver106 receives the temperature measurements of the inside temperature of the house from thethermostat108. At step4604, theserver106 receives the humidity measurements of the inside humidity from thehumidity sensor3908. At step4606, theservier106 receives weather information, such as the outside temperature, outside humidity, and the like.

At step4608, theserver106 compares the inside temperature measurements with the outside temperature measurements over time. Based at least in part on the comparison, theserver106 derives a ΔT.

In an embodiment, the ΔT over time is used to determine level of seasonal or day acclimatization. For example, at the beginning of winter there is less acclimatization to the cold. This could be measured as a time-weighted average AT over the last 4 weeks. On a hot summer day, the time-weighted ΔT will higher late afternoon vs. noon even though the magnitude of ΔT at a given moment is the same. The time-weighting need not be linear, and can give more weight to recent temperatures.

At step4612, theserver106 calculates time-weighted ΔT based at least in part on the outside temperature and humidity measurements. In an embodiment, theserver106 calculates the time-weighted ΔT based at least in part on inside temperature and humidity measurements and outside temperature and humidity measurements.

Atstep4614, in one embodiment, theserver106 determines whether to make a change to the setpoint adjustment based at least in part on humidity.

Atstep4616, in another embodiment, theserver106 determines whether to make a change to the setpoint adjustment based at least in part on acclimatization to humidity and temperature.

If a setpoint change is to be made, then the process4600 moves to step4618. Otherwise, the process4600 moves to step4602.

At step4618, theserver106 adjusts the setpoint of thethermostat108 according to the change in the setpoint adjustment. In an embodiment, theserver106 adjusts the setpoint of thethermostat106 and the run time of theHVAC system110.

From step4618, the process4600 returns to step4602 to continually adjust the thermostat setpoint and the HVAC run time.

In an embodiment, the SPO adjustment can be applied to thethermostat108 such that the display on thethermostat108 does not fully reflect the adjustment. For example, because humidity is low, the agent determines to increase the actual setpoint by 1 degree, but the display continues to show the original setting. In an embodiment, this change is called a change in thermostat “calibration”. The SPO adjustment can be split between setpoint display and calibration so that all, none, or a portion of the SPO adjustment is shown on the setpoint display of thethermostat108.

In an embodiment, one ormore servers106 perform the calculation to adjust the SPO. In another embodiment, the one or moresmart thermostats106 perform the calculations to adjust the SPO.

In other embodiments, the calculation for making adjustments to SPO can be split between one ormore server computers106 and local computation on asmart thermostat108. For example, the time-weighted ΔT for a season is not likely to be done using thermostat computation. However the intra-day time-weighted ΔT could be computed on thethermostat108, and thethermostat108 can combine different elements of seasonal, daily, humidity as inputs to compute SPO amounts. Also, the rules, such as weighting of seasonal vs. daily, can be defined by server computation, but computed and applied using thermostat computation.

To improve the accuracy of the learning, in an embodiment, any of the processes described herein can assign each consumer to a peer group (PG). A peer group, as the name suggests, is a set of consumers that are determined to display similar behaviors. In an embodiment, a peer group can be defined by zip code and recent household energy usage.

In an embodiment, any of the processes described herein learns from the premise profile, which can be defined by the age of the home, the square footage, and other types of home characteristics. The premise profile could be used to develop a profile of the peer group.

In an embodiment, any of the processes described herein learns from the resident profile, which can be defined by ages, ethnicity, and other types of demographics. The resident profile could be used to develop a profile of the peer group.

In an embodiment, any of the processes described herein use a regional sensitivity or region bias to increase the machine learning for humidity and temperature acclimatization. For example, the population of a southern region of the United States, where temperatures are generally warmer, may be more sensitive (less comfortable) when the humidity is high and the temperature drops than a northern region of the United States, where the weather is generally cooler. In an embodiment, the regional sensitivity is used to determine acclimatization when individual data, such as manual overrides to thermostat setpoints is lacking. In another embodiment, regional sensitivity is used to supplement the individual data in acclimatization calculations.

In an embodiment, any of the processes described herein use a horizontal analysis of the population to increase the machine learning for humidity and temperature acclimatization. By looking at a combination of actual setpoint and indoor temperatures compared against outdoor temperature, humidity, and ΔT across the entire population (e.g. horizontal), it is possible to determine setpoints that are considered “acceptable” or “comfortable” for the population as a whole. The range of setpoints used by the population under different conditions can be used to provide guidance for SPO adjustments. A bias towards comfort vs. efficiency can be done based on the population statistics. For example, at 90 degrees and 70% humidity we may find that the median preference is for a setpoint of 75 degrees, with a 75th percentile comfort setpoint of 72 degrees. A conservative comfort-oriented SPO may make a 1 degree adjustment to 73 and then stop. A SPO for a more aggressive EE may make a 2 degree change and keep making more changes until 77 degrees is reached. In an embodiment, the horizontal analysis is used to determine acclimatization when individual data, such as manual overrides to thermostat setpoints is lacking. In another embodiment, the horizontal analysis is used to supplement the individual data in acclimatization calculations.

In an embodiment, thethermostat108 and/or the website displaying the thermostat temperature displays the relative or perceived temperature instead of the actual or true temperature. In an embodiment, the processes described herein may make adjustments based on acclimatization to temperature and humidity to the thermostat setpoint visible to the occupant. In another embodiment, the processes described herein do not make the adjustments based on acclimatization to temperature and humidity to the thermostat setpoint visible to the occupant.

In an embodiment, the processes described herein may make rules changes based on acclimatization to temperature and humidity to the thermostat setpoint visible to the occupant. In another embodiment, the processes described herein do not make the rule changes based on acclimatization to temperature and humidity to the thermostat setpoint visible to the occupant. In an embodiment, some of the setpoint changes and some of the calibration or rule changes to the thermostat setpoint may be visible to the occupant.

Embodiments of the invention are also described above with reference to flow chart illustrations and/or block diagrams of methods, components, apparatus, systems, and the like. It will be understood that each block of the flow chart illustrations and/or block diagrams as well as each component, apparatus and system can be individually implemented or in any combination.

While particular embodiments of the present invention have been shown and described, it is apparent that changes and modifications may be made without departing from the invention in its broader aspects, and, therefore, that the invention may be carried out in other ways without departing from the true spirit and scope.