Patent Application
20190086109
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.
The invention relates to message-based demand response (MDR) messages that are exchanged between a utility company and its customers for its demand response program.
Demand Response (DR) is considered an effective way by utilities worldwide to address mismatches between demand and supply. Utilities may operate with constrained generation or limited supplies of energy. As a result, they must reduce their peak energy loads. Some demand response programs reduce the peak load by switching off high load sources. Other demand response programs reduce the peak load by trying to change the behavior of the user. The behavior changing communication between a utility company and its participating users is through DR messages.
Through DR messages, utilities can deliver peak energy reduction from their residential customers without placing any devices into the home. Utilizing meter and customer data, demand response programs connect with residents via multiple communication channels to motivate a reduction in peak demand and drive customer engagement during peak energy days. DR message channels can include e-mail (electronic mail), SMS (short message service), phone calls, and in-app messaging (message embedded into a mobile application).
DR messages can target on a large scale thousands to millions of customers over a short-period of a few hours. During the summer season when hot weather occurs, energy demand is very high because users are running their HVAC (heating, ventilating, and air conditioning) systems to cool their homes. If the hot weather lasts several days or several weeks, such as in the case of a severe and prolonged period of excessively hot weather or heat wave, many streams of DR messages may be generated by the utility.
User participation to reduce energy consumption is important to realizing the full potential offered by DR programs that generate streams of DR messages.
To effectively reach the user and drive user actions, the user should be motivated by the received message and understand the value and the benefits of her actions. Customer motivations not only vary from one individual to another, but also for the same individual over time. However, it is possible to learn effective communication methods for a particular customer and to adapt to that customer's changing preferences.
Research consistently demonstrates that demand response is most effective when users are subject to pricing forces, such as penalties for usage and/or rewards for conservation, at specific times of the events.
Due to the scale and repetitiveness of the DR messages, personalizing the DR message, incentivizing the user to maximize the effectiveness of the DR message, and finding the effective communication channel for the user over a short-period of time can be automated with advanced computer programs.
Machine learning is a subfield of computer science that provides a framework to construct algorithms that can learn from large existing data sets and make predictions on future data sets. Such algorithms operate by building a model from a given set of inputs in order to make data-driven predictions or decisions as outputs to other computer programs.
There is a need to create a new machine learning method that can be applied to generate the DR messages that will enable the utility to successfully engage its users into reducing their energy consumption during a peak load on the energy distribution network.
In an embodiment, DR messages are automatically generated by an MDR service using a machine learning system.
In an embodiment, a method to learn the timing of a DR message from a utility to its customers through a machine learning algorithm is disclosed. In an embodiment, the algorithm is a supervised machine learning algorithm. In another embodiment, the algorithm is a reinforcement machine learning algorithm. In an embodiment, the algorithm is a binary linear classification algorithm.
In an embodiment, a method to learn the timing of a DR message from a utility to its customers through a reinforcement machine learning algorithm is disclosed. In an embodiment, the algorithm uses a score function to rank the engagement of the user. In an embodiment, the algorithm uses a score function to quantify the impact of the shed on the utility distribution network.
In an embodiment, a method to learn the content of a DR message from a utility to its customers through a machine learning algorithm is disclosed. In an embodiment, the algorithm is a regression algorithm. In an embodiment, the algorithm is a supervised machine learning algorithm. In another embodiment, the algorithm is a reinforcement machine learning algorithm. In an embodiment, the algorithm is a multivariate regression algorithm.
In an embodiment, a method to learn the content of a DR message from a utility to its customers through a reinforcement machine learning algorithm is disclosed. In an embodiment, the algorithm uses a score function to rank the engagement of the user. In an embodiment, the algorithm uses a score function to quantify the impact of the shed on the utility distribution network.
In an embodiment, a method to learn the incentive category of a DR message from a utility to its customers through a machine learning algorithm is disclosed. In an embodiment, the algorithm is a supervised machine learning algorithm. In another embodiment, the algorithm is a reinforcement machine learning algorithm. In an embodiment, the algorithm uses a score function to rank the engagement of the user. In an embodiment, the algorithm uses a score function to quantify the impact of the shed on the utility distribution network. In an embodiment, the method further comprises learning the incentive level of the incentive category.
Examples of categories include community, economic, fun, and environment. In some embodiments, messages are characterized by content and optional incentive. In other embodiments, the messages are associated with a message profile that includes timing, content, and optional incentive.
A message profile may include a plurality of message characteristics, such as timing, frequency (number of pre-event messages, number of post-event messages), content (including topic/category, tone, behavioral feedback, visual or audio presentation), delivery method (email, SMS, phone, Facebook ads, etc.), incentive (bill credit, gift card, incentive level), and the like. In an embodiment, the message profile is determined independently for each user when there are multiple users within a household. DR message opt-in and opt-out may also be performed independently for each user.
A user may also belong to one or more peer groups, where groups are formed on the basis of similar values, age, income, home ownership, location, and other user segmentation parameters. This collection of peer groups can be considered a user profile.
A user may also be associated with a premise profile. In an embodiment, a premise profile includes one or more of the age of home, the age of HVAC, the presence or absence of large energy loads such as, for example, pool pumps or electric water heater, the presence or absence of solar panels or other alternative energy systems, the neighborhood, the number of occupants, and the like.
MDR is the method of determining and learning a message profile for a user based on behavior, performance, an associated user profile, and an associated premise profile
In an embodiment, an additional feature to the methods disclosed above is the HVAC home usage for learning the user home presence. In an embodiment, presence in the home can be provided by other systems, such as arming or disarming a security system, or can be inferred from other sensors, such as a motion sensor or camera. Presence information for a home can also be used to adjust DR message timing and content.
In an embodiment, an additional feature to the methods disclosed above is the prevalence of high load devices for the method to better target DR messages. In an embodiment, an additional feature to the methods disclosed above is high weather temperature that might push the user to not being able to participate to the DR event. In an embodiment, an additional feature to the methods disclosed above is the premise profile, defined by the age of the home, and square footage to develop a profile of the peer group (PG). In an embodiment, where an additional feature to the methods disclosed above is the user profile, defined by ages, ethnicity, and other types of demographics to develop a profile of the peer group (PG).
Certain embodiments disclose a method to send demand response messages to a user from a message-based demand response service. The demand response messages include a request to reduce energy consumption. The method comprises receiving, at one or more server computers comprising computer hardware, energy consumption measurements from an electrical meter associated with a household of the user, where the energy consumption measurements are indicative of energy usage over time for the household; calculating, with the one or more server computers, a predictive timing score based on the energy consumption measurements and indications of user responses to past demand response messages; and sending, with the one or more server computers, the demand response message in response to receiving an indication of an energy event, the demand response message sent to the user at the predicted time.
In an embodiment, the method further comprises determining a predicted time to send demand response messages to the user based on the predictive timing score. In an embodiment, the method further comprises determining whether the user performed an action that indicates engagement with the demand response message. In an embodiment, the action comprises one or more of opening a link associated with the demand response message and accessing an account associated with the user.
In an embodiment, the action comprises an action to reduce energy consumption as indicated by the energy consumption measurements from the electrical meter taken after the predicted time.
In an embodiment, the method further comprises updating the predictive timing score based on the determination. In an embodiment, the method further comprises receiving one or more of presence data from presence sensors, geo-fencing data from geo-fencing systems, HVAC runtimes from intelligent thermostats, and HVAC schedules from the intelligent thermostats, wherein the predictive timing score is further based any of the received presence data, geo-fencing data, HVAC runtimes, and HVAC schedules.
In an embodiment, the predictive timing score comprises a load shed score, an engagement score, and an unsubscription penalty. In an embodiment, the method further comprises calculating the load shed score and the engagement score from actions of the user and actions of homeowners who belong to the same peer group as the user. In an embodiment, the unsubscription penalty is based at least in part on a number homeowners that belong to the same peer group as the user that are unsubscribing from the message-based demand response service.
Certain embodiments disclose a demand response message system to send demand response messages to users from a message-based demand response service. The system comprises one or more server computers comprising computer hardware configured to receive energy consumption measurements from an electrical meter associated with a household of the user, where the energy consumption measurements are indicative of energy usage over time for the household; one or more server computers configured to calculate a predictive timing score based on the energy consumption measurements and indications of user responses to past demand response messages; and one or more server computers configured to send the demand response message in response to receiving an indication of an energy event, the demand response message sent to the user at the predicted time.
In an embodiment, the one or more server computers are further configured to determine a predicted time to send demand response messages to the user based on the predictive timing score. In an embodiment, the one or more server computers are further configured to determine whether the user performed an action that indicates engagement with the demand response message. In an embodiment, the action comprises one or more of opening a link associated with the demand response message and accessing an account associated with the user. In an embodiment, the action comprises an action to reduce energy consumption as indicated by the energy consumption measurements from the electrical meter taken after the predicted time. In an embodiment, the one or more server computers are further configured to update the predictive timing score based on the determination.
In an embodiment, the one or more servers are further configured to receive one or more of presence data from presence sensors, geo-fencing data from geo-fencing systems, HVAC runtimes from intelligent thermostats, and HVAC schedules from the intelligent thermostats, and wherein the predictive timing score is further based any of the received presence data, geo-fencing data, HVAC runtimes, and HVAC schedules. In an embodiment, the predictive timing score comprises a load shed score, an engagement score, and an unsubscription penalty. In an embodiment, the one or more computer servers are further configured to calculate the load shed score and the engagement score from actions of the user and actions of homeowners who belong to the same peer group as the user. In an embodiment, the unsubscription penalty is based on a number homeowners that belong to the same peer group as the user that are unsubscribing from the message-based demand response service.
Certain embodiments are directed to a method to send demand response messages to a user. The demand response messages including a request to reduce energy consumption. The method comprises receiving, at one or more server computers comprising computer hardware, energy consumption measurements from an electrical meter associated with a household of the user, the energy consumption measurements indicative of energy usage over time for the household; analyzing, with the one or more server computers, variations in the energy consumption measurements to determine levels of confidence over time that the household is occupied; receiving, at the one or more server computers, an indication of an energy reduction event; and in response to receiving the energy event, when the confidence level that the household is occupied at a first time is less than a threshold, determining a second time to send a demand response message to the user based at least in part on the levels of confidence over time that the household is occupied.
In an embodiment, the method further comprises not sending the demand response message to the user when the confidence level that the household is occupied at the first time is less than the threshold. In an embodiment, the method further comprises sending the demand response message to the user when the confidence level that the household is occupied at the first time is greater than the threshold.
In an embodiment, the method further comprises determining a preferred communication medium and sending the demand response message to the user using the preferred communication medium, where the determination of the preferred communication medium is based at least in part on indications of user responses to past demand response messages. In an embodiment, the demand response message comprises one or more of an email, a telephone call, a test message, and a short message service message. In an embodiment, the method further comprises determining occupancy of the household of the user based at least in part on computer activity of a computer associated with a location of the house.
In an embodiment, the method further comprises determining occupancy of the household of the user based at least in part on geopositioning information send from a mobile device associated with the user. In an embodiment, the method further comprises determining a message category of the demand response message to send to the user, the determination of the message category based at least in part on indications of user responses to past demand response messages.
In an embodiment, the message category comprises one of environmental, economics, community, and fun. In an embodiment, the method further comprises determining an incentive, to include in the demand response message sent to the user, the determination of the incentive based at least in part on indications of user responses to past demand response messages.
Certain embodiments disclose a demand response message system to send demand response messages to a user. The demand response messages including a request to reduce energy consumption. The system comprises one or more server computers comprising computer hardware, configured to receive energy consumption measurements from an electrical meter associated with a household of the user, the energy consumption measurements indicative of energy usage over time for the household; one or more server computers configured to analyze variations in the energy consumption measurements to determine levels of confidence over time that the household is occupied; one or more server computers configured to receive an indication of an energy reduction event; and in response to receiving the energy event, when the confidence level that the household is occupied at a first time is less than a threshold, determining a second time to send a demand response message to the user based at least in part on the levels of confidence over time that the household is occupied.
In an embodiment, the one or more server computers are further configured to not send the demand response message to the user when the confidence level that the household is occupied at the first time is less than the threshold. In an embodiment, the one or more server computers are further configured to send the demand response message to the user when the confidence level that the household is occupied at the first time is greater than the threshold.
In an embodiment, the one or more server computers are further configured to determine a preferred communication medium and to send the demand response message to the user using the preferred communication medium, the determination of the preferred communication medium based at least in part on indications of user responses to past demand response messages. In an embodiment, the demand response message comprises one or more of an email, a telephone call, a test message, and a short message service message.
In an embodiment, the one or more server computers are further configured to determine occupancy of the household of the user based at least in part on computer activity of a computer associated with a location of the house. In an embodiment, the one or more server computers are further configured to determine occupancy of the household of the user based at least in part on geopositioning information send from a mobile device associated with the user.
In an embodiment, the one or more server computers are further configured to determine a message category of the demand response message to send to the user, the determination of the message category based at least in part on indications of user responses to past demand response messages. In an embodiment, the message category comprises one of environmental, economics, community, and fun. In an embodiment, the one or more server computers are further configured to determine an incentive, to include in the demand response message sent to the user, the determination of the incentive based at least in part on indications of user responses to past demand response messages.
Certain embodiments disclose a method to determine user occupancy of a household. The method comprises receiving, at one or more server computers comprising computer hardware, energy consumption measurements from an electrical meter associated with the household of the user, where the energy consumption measurements are indicative of energy usage over time for the household; determining, with the one or more server computers, intra-day usage patterns from the energy consumption measurements; determining, with the one or more server computers, at least one occupancy time that a user is occupying the household based on the intra-day usage patterns; assigning, with the one or more server computers, a level of confidence to the at least one occupancy time based at least in part on a consistency of the intra-day usage patterns; receiving, at the one or more server computers, additional occupancy information; adjusting the level of confidence based on the additional occupancy information; and determining, with the one or more server computers, that the household is occupied when the level of confidence is greater than a threshold.
In an embodiment, said receiving the additional occupancy information comprises receiving occupancy data from an occupancy determination system that includes a mobile device of the user.
In an embodiment, said receiving the additional occupancy information comprises receiving HVAC runtimes from an intelligent thermostat.
In an embodiment, said receiving the additional occupancy information comprises receiving HVAC schedules from an intelligent thermostat.
In an embodiment, said receiving the additional occupancy information comprises receiving presence data from presence sensors.
In an embodiment, said receiving the additional occupancy information comprises receiving geo-fencing data.
Certain embodiments disclose a system to determine user occupancy of a household. The system comprises one or more server computers comprising computer hardware configured to receive energy consumption measurements from an electrical meter associated with the household of the user, where the energy consumption measurements are indicative of energy usage over time for the household; one or more server computers configured to determine intra-day usage patterns from the energy consumption measurements; one or more server computers configured to determine at least one occupancy time that a user is occupying the household based on the intra-day usage patterns; one or more server computers configured to assign a level of confidence to the at least one occupancy time based at least in part on a consistency of the intra-day usage patterns; one or more server computers configured to receive additional occupancy information; adjusting the level of confidence based on the additional occupancy information; and one or more server computers configured to determine that the household is occupied when the level of confidence is greater than a threshold.
In an embodiment, the additional occupancy information comprises occupancy data from an occupancy determination system that includes a mobile device of the user. In an embodiment, the additional occupancy information comprises HVAC runtimes from an intelligent thermostat. In an embodiment, the additional occupancy information comprises HVAC schedules from an intelligent thermostat. In an embodiment, the additional occupancy information comprises presence data from presence sensors. In an embodiment, the additional occupancy information comprises geo-fencing data. In an embodiment, the energy consumption measurements are further indicative of the energy usage for a same period of day across two or more consecutive days. In an embodiment, the energy consumption measurements are further indicative of a day level occupancy based on low level energy usage for two or more consecutive days.
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.
The terms user, occupant, homeowner, owner, renter, and the like, are used interchangeably herein to identify the occupant of a residence.
Presently preferred network 102 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. While network 102 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 on network 102 using computer 104 or mobile device 105, the user initiates connection from his computer 104 or mobile device 105. For example, the user invokes a browser, which executes on computer 104 or mobile device 105. The browser, in turn, establishes a communication link with network 102. Once connected to network 102, the user can direct the browser to access information on server 106.
One popular part of the Internet is the World Wide Web. The World Wide Web contains a large number of computers 104 and servers 106, which store HyperText Markup Language (HTML) and other documents capable of displaying graphical and textual information. HTML is a standard coding convention and set of codes for attaching presentation and linking attributes to informational content within documents.
The servers 106 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, network 102 may also be used to deliver computer applications that have traditionally been executed locally on computers 104. 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, the network 102 can comprise a wide variety of interactive communication media. For example, network 102 can include local area networks, interactive television networks, telephone networks, wireless data systems, two-way cable systems, and the like.
In one embodiment, computers 104 and servers 106 are equipped with communications hardware such as modem, a network interface card or wireless networking such as 802.11 or cellular radio-based systems. The computers include processors.
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 and mobile devices 105 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 and 106 and mobile devices 105 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 devices 105 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
Also attached to the Network may be cellular radio towers 120, or other means to transmit and receive wireless signals in communication with mobile devices 105. Such communication may use GPRS, GSM, CDMA, EvDO, EDGE or other protocols and technologies for connecting mobile devices to a network.
Water in the secondary loop emerges from the chiller and is sent to through pipes to individual air handlers 110. In some implementations, the chilled water always flows through the same path regardless of the settings of thermostats 108. If thermostat 108 is in cooling mode, then fan 214 blows air from inside the conditioned unit across the air handler, transferring heat from the air to the water being transported through the air handler 110. If thermostat 108 is in off mode, then fan 214 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.
With the systems shown in
To allow the thermostat to communicate bi-directionally with the computer network, the thermostat also includes means 264 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 means 264 may include one or more antennae 266. Thermostat 108 may also include controls 268 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. Thermostat 108 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. Thermostat 108 should be capable of communicating such parameters to servers 106, and of allowing remote control of such parameters as well.
The data used to manage the subject invention is stored on one or more servers 106 within one or more databases. As shown in
Users of connected thermostats 108 may create personal accounts. Each user's account will store information in database 900, 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, 11th floor); 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 in database 1200.
In one embodiment, a background application installed on mobile device 105 shares geopositioning data for the mobile device with the application running on server 106 that logs such data. Based upon this data, server 106 runs software that interprets said data (as described in more detail below). Server 106 may then, depending on context, (a) transmit a signal to thermostat 108 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 to mobile device 105 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.
As shown in
As shown in
In step 402 the server retrieves from database 300 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”. In step 404 the server retrieves from database 300 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. In step 406 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. In step 408 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 step 402. If not, in step 410 the server calculates the allocated HVAC cost for all of the individual time intervals.
In step 502 the server retrieves from database 300 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”. In step 504 the server retrieves from database 300 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. In step 506 the server retrieves from database 300 the cost per minute of run time for the air handler given the actual fan speed as retrieved in step 504. 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. In step 508 the server computes the cost to operate the individual air handler for the specified time interval. In step 510 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 step 502. If not, in step 512 the server calculates the allocated HVAC cost for all of the individual time intervals.
In step 602 the server retrieves from database 300 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”. In step 604 the server retrieves from database 300 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 in step 606 the server retrieves from database 300 the cycling data for the last air handler to be evaluated.
In step 608 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. In step 610 the server retrieves from database 300 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.
In step 612 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 in step 610, as well as the other parameters retrieved in steps 602-608. Specifically, the method described in
In step 614 the server repeats the process followed in step 612 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 in step 616 the server calculates operating costs for the last air handler to be evaluated for that time increment.
In step 618 the server determines whether additional time segments will require evaluation. If more time segments do require calculation, the server returns to step 602. If not, the server proceeds to step 620, in which it calculates the total allocated operating cost allocated to the first air handler for the relevant intervals.
The process disclosed in
In step 702 the server retrieves from database 300 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”. In step 704 the server retrieves from database 300 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.
In step 706 the server retrieves from database 300 the cycling data for the next air handler to be evaluated for the specified time interval, and in step 708 the server retrieves from database 300 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 and 712 the server retrieves from database 300 the cycling and fan speed data for the last air handler to be evaluated.
In step 714 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.
In step 716 the server retrieves from database 300 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.
In step 718 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 in step 716, as well as the other parameters retrieved in steps 702-714. Specifically, the method described in
In step 720 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 in step 722 the server calculates operating costs for the last air handler to be evaluated for that time increment.
In step 724 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 step 702. If not, in step 726 the server calculates the allocated HVAC cost for all of the individual time intervals.
In step 802 the server retrieves from database 300 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”. In step 804 the server retrieves from database 300 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. In step 806 the server retrieves from database 300 the cost per minute of run time for the air handler given both the valve status and actual fan speed as retrieved in step 804. 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. In step 808 the server computes the cost to operate the individual air handler for the specified time interval. In step 810 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 step 802. If not, in step 812 the server calculates the allocated HVAC cost for all of the individual time intervals.
This information may come from sensors 220a and 220b. 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 step 902 the server retrieves information about absolute and/or relative coolant temperatures as it enters and leaves the air handlers being evaluated.
In step 904 the server retrieves from database 300 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”. In step 906 the server retrieves from database 300 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.
In step 908 the server retrieves from database 300 the cycling data for the next air handler to be evaluated for the specified time interval, and in step 910 the server retrieves from database 300 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 and 914 the server retrieves from database 300 the cycling and fan speed data for the last air handler to be evaluated.
In step 916 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.
In step 918 the server retrieves from database 300 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.
In step 920 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 in step 922, as well as the other parameters retrieved in steps 902-916. Specifically, the method described in
In step 922 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 in step 924 the server calculates operating costs for the last air handler to be evaluated for that time increment.
In step 926 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 step 902. If not, in step 928 the server calculates the allocated HVAC cost for all of the individual time intervals.
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.
In step 1002 the server retrieves information about the energy consumption associated with operation of the main chiller fans 212. 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.
In step 1004 the server retrieves from database 300 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”. In step 1006 the server retrieves from database 300 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.
In step 1008 the server retrieves from database 300 the cycling data for the next air handler to be evaluated for the specified time interval, and in step 1010 the server retrieves from database 300 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 and 1014 the server retrieves from database 300 the cycling and fan speed data for the last air handler to be evaluated.
In step 1016 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.
In step 1018 the server retrieves from database 300 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.
In step 1020 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 in step 1022, as well as the other parameters retrieved in steps 1002-1016. Specifically, the method described in
In step 1022 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 in step 1024 the server calculates operating costs for the last air handler to be evaluated for that time increment.
In step 1026 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 step 1002. If not, in step 1028 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 user 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 users are likely to yield sub-optimal energy management outcomes, because users 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.
If the server 106 determines in step 1306 that the home should be in unoccupied or away mode, then in step 1350 the server queries database 300 to determine whether thermostat 108 is set for set for home or away mode. If thermostat 108 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 in step 1352 the application will retrieve from database 300 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 step 1358, 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 in step 1354 the application transmits a command to the location specified by the user (generally mobile device 105) 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 in step 1318 the application will write to database 300 the fact that the user has so elected and terminate. If the user elects to change the setting, then in step 1316 the application transmits the revised setpoint to the thermostat. In step 1318 the application writes the updated setting information to database 300. If thermostat 108 is already in away mode, the program ends. If it was in home mode, then in step 1314 server 108 initiates a state change to put thermostat 108 in away mode. In either case, the server then in step 1316 writes the state change to database 300. 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.
In step 1402 server 106 retrieves the most recent geospatial coordinates from the mobile device 105 associated with mobile user #1. In step 1404 server 106 uses current and recent coordinates to determine whether mobile user #1's “home” (or “occupied”) settings should be applied. If server 106 determines that User #1's home settings should be applied, then in step 1406 server 106 applies the correct setting and transmits it to the thermostat(s). In step 1408, server 106 writes to database 300 the geospatial information used to adjust the programming. If after performing step 1404, the server concludes that mobile user #1's “home” settings should not be applied, then in step 1412 server 106 retrieves the most recent geospatial coordinates from the mobile device 105 associated with mobile user #2. In step 1414 server 106 uses current and recent coordinates to determine whether mobile user #2's “home” settings should be applied. If server 106 determines that User #2's home settings should be applied, then in step 1416 server 106 applies the correct setting and transmits it to the thermostat(s). In step 1408, server 106 writes to database 300 the geospatial and other relevant information used to adjust the programming. If after performing step 1414, the server concludes that mobile user #2's “home” settings should not be applied, then in step 1422 server 106 retrieves the most recent geospatial coordinates from the mobile device 105 associated with mobile user #N. In step 1424 server 106 uses current and recent coordinates to determine whether mobile user #N's “home” settings should be applied. If server 106 determines that User #N's home settings should be applied, then in step 1426 server 106 applies the correct setting and transmits it to the thermostat(s). In step 1408, server 106 writes to database 300 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 in step 1430 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 to mobile device 105 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 of mobile device 105 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 that User #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 allow thermostat 108 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 10th floor maintain very high winter setpoints, thereby reducing the need to run the heating for the unit directly above it on the 11th floor (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 10th floor unit of these facts, or otherwise use the data to reinforce more energy-efficient choices.
For example,
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.
In step 1534, 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.
In step 1536, 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 (AT) for the relevant range of possible pre-existing inside temperatures and outside climatic conditions. An example of a simple prediction table is illustrated in
In step 1538, the server uses the prediction tables created in step 1106, combined with input parameters TT and Temp(TT) to determine the time at which slope AT intersects with predicted initial temperature PT. The time between PT and TT is the key calculated parameter: the preconditioning time interval, or PTI.
In step 1540, 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 AT.
Thus if MTI is greater than PTI, then in step 1542 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., AT 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 to 61).
In step 1544, the server schedules setpoint changes calculated in step 1112 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 in
Each of these data points should be captured at frequent intervals. In the currently preferred embodiment, as shown in
After calculating the appropriate slope ΔT 1560 by which to ramp inside temperature in order to reach the target as explained above, the server transmits a series of setpoints 1566 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 in
Because the inside temperature 1599 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.
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.
In step 1712, 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 step 1714 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 step 1716 the server logs the occurrence and magnitude of the override to one or more databases in overall database structure 300.
The process of interpreting a manual override is shown in
In step 1808 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 in
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.
In step 1908 the server interprets the overrides in light of the existing programming schedule, rules for overrides, contextual data, etc. In step 1910 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 step 1914. If the rules are to be revised, then in step 1912 the server revises the rules and the new rules are stored in one or more databases in overall database structure 300. In step 1914 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 in step 1916 the server retrieves from database 900 the permissions the server has to make autonomous changes to settings. If the server has been given permission to make the proposed changes, then in step 1918 the server revises the thermostat's programming and writes the changes to one or more databases in overall database structure 300. If the server has not been authorized to make such changes autonomously, then in step 1920 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 on website 200, 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 by remote server 106 may also be done by thermostat 108 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 as gateway 112.
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. Because server 106 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, database 300 will contain a history of the thermal performance of each conditioned space. That performance data will allow the server 106 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.
For example, assume that on at 3 PM on date Y utility X wishes to trigger a demand reduction event. A server at utility X transmits a message to the server at demand reduction service provider Z requesting W megawatts of demand reduction. The demand reduction service provider server determines that it will turn off the air conditioner for conditioned space A in order to contribute to the required demand reduction. At the time the event is triggered, the inside temperature as reported by the thermostat in conditioned space A is 72 degrees F. The outside temperature near conditioned space A is 96 degrees Fahrenheit. The inside temperature at conditioned space B, which is not part of the demand reduction program, but is both connected to the demand reduction service server and located geographically proximate to conditioned space A, is 74 F. Because the air conditioner in conditioned space A has been turned off, the temperature inside conditioned space A begins to rise, so that at 4 PM it has increased to 79 F. Because the server is aware of the outside temperature, which remains at 96 F, and of the rate of temperature rise inside conditioned space A on previous days on which temperatures have been at or near 96 F, and the temperature in conditioned space B, which has risen only to 75 F because the air conditioning in conditioned space B continues to operate normally, the server is able to confirm with a high degree of certainty that the air conditioner in conditioned space A has indeed been shut off.
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.
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 of server 106 can be combined with the functions of server 2400.
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 in
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 between server 106 and thermostat 108 will also allow thermostat 108 to regularly measure and send to server 106 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,
The differences in thermal mass will affect the cycling behavior of the HVAC systems in the two conditioned spaces as well.
Because server 106 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, database 300 will contain a history of the thermal performance of each system and each conditioned space. That performance data will allow the server 106 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 the server 106 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,
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.
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.
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.
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.
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, in step 3114 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 concludes 3116 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, in step 3118, 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 a message 3120 alerting the party to the possible problem. If the problem does not match the clogged filter paradigm, the system compares 3122 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 a message 3124 alerting the party to the possible problem. If the problem does not match the refrigerant leak paradigm, the system compares 3126 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 a message 3128 alerting the party to the possible problem. If the problem does not match the open door/window paradigm, the system continues to step through remaining know patterns N 3130 until either a pattern is matched 3132 or the list has been exhausted without a match 3134.
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.
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 and 3410 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 the server 106 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 that time 3412.
In order to implement such ramped setpoints automatically, algorithms may be created. These algorithms may be generated and/or executed as instructions on remote server 106 and the resulting setpoint changes can be transmitted to a given thermostat on a just-in-time basis or, if the thermostat 108 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 user 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.
Returning to the branch after step 3508, if the current phase at that point is not phase “0”, then in step 3520, 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 in step 3522, 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 in step 3520 is equal to the setpoint in the previous phase, then in step 3524 new setpoint is made to equal current setpoint plus the differential associated with each phase change. In step 3526 the “previous-phase setpoint” variable is reset to equal the new setpoint in anticipation of its use during a subsequent iteration.
In step 3622, the system records the changes to the thermostat settings to database 300. In step 3624, the system records the changes to the phase status of the algorithm to database 300. In step 3626, 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 in step 3628, the application transmits revised settings to the thermostat. In step 3630, the application then hibernates for the specified duration until it is invoked again by beginning at step 3602 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 or other device 104.
In an alternative embodiment, the application running on computer 104 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 the computer 104 is a web-enabled television or web-enabled set-top device connected to a television as a display, software running on computer 104 detects user activity, and transmits a message indicating such activity to server 106. 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 by server 106 of this trigger, server 106 transmits instructions to computer 104 causing it to display a dialog box asking the user whether the user wishes to change HVAC settings.
Alternatively, server 106 may use biometric data provided by computer 104, 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.
Presently preferred network 102 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. While network 102 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.
When a user of the subject invention wishes to access information on network 102, the user initiates connection from his computer 104. For example, the user invokes a browser, which executes on computer 104. The browser, in turn, establishes a communication link with network 102. Once connected to network 102, the user can direct the browser to access information on server 106.
One popular part of the Internet is the World Wide Web. The World Wide Web contains a large number of computers 104 and servers 106, which store HyperText Markup Language (HTML) documents capable of displaying graphical and textual information. HTML is a standard coding convention and set of codes for attaching presentation and linking attributes to informational content within documents.
The servers 106 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 the Internet, the network 102 can comprise a wide variety of interactive communication media. For example, network 102 can include local area networks, interactive television networks, telephone networks, wireless data systems, two-way cable systems, and the like.
In one embodiment, computers 104 and servers 106 are equipped with communications hardware such as modem or a network interface card. The computers include processors.
Computers 104 can also be handheld and wireless devices 105 such as personal digital assistants (PDAs), cellular telephones and other devices capable of accessing the network.
Computers 104 utilize a browser configured to interact with the World Wide Web. Such browsers may include Microsoft Explorer, Mozilla, Firefox, Opera or Safari. They may also include browsers used on handheld 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 and 106 may use an operating system such as Microsoft Windows, Apple Mac OS, Linux, Unix or the like.
Servers 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. In an embodiment, server 106a comprises a utility server and server 106b comprises a demand reduction service server.
Also attached to the network 102 are electricity or electrical meters 3908 associated with electrical energy consuming buildings, such as houses 3909 of the various users. The electricity meters 3908 measure the electrical energy consumption or electrical power consumption of their associated houses 3909. In an embodiment, the electric meters 3908 comprise smart meters that measure and record the consumption of electric energy in intervals and that communicate the consumption information to the severs 106a, 106b for monitoring, billing, and demand reduction services. In an embodiment, the smart meters enable two-way communication between the meter and the servers 106a, 106b.
In an embodiment, each user is connected to the servers 106a 106b via wired or wireless connection such as Ethernet or a wireless protocol such as IEEE 802.11, the gateway 110 that connects the computer 104 and the electricity meter 3908 to the Internet via a broadband connection such as a digital subscriber line (DSL) or other form of broadband connection to the World Wide Web. In one embodiment, electric utility server 106a and demand reduction service server 106b are in communication with the network 102. Servers 106a and 106b contain the content to be served as web pages and viewed by computers 104, as well as databases containing information used by the servers. Also connected to the servers 106a, 106b via the Internet are computers located at one or more electrical utilities.
In an embodiment, the data used to generate the content delivered in the form of the website is stored on one or more servers 106 within one or more databases. In another embodiment, the data to determine whether to send a demand response message, the content of the demand response message, and the timing of the transmission of the demand response message is stored on one or more servers 106 within one or more databases. As shown in
The website will allow electrical energy users to create personal accounts. In an embodiment, each user's account stores information, which tracks various attributes relative to users of the site. Such attributes may include the make and model of the specific HVAC equipment in the user's home; the age and square footage of the home, the solar orientation of the home, the location of the thermostat in the home, the user's preferred temperature settings, whether the user is a participant in a demand reduction program, etc.
In another embodiment, each user's account stores demand reduction alerts, demand reduction messages, responses to demand reduction messages, and the like to allow the user to view demand reduction requests, and to permit the demand reduction service to learn the content and timing of demand reduction messages for improved user response.
Embodiments of an MDR service that generates effective DR messages are disclosed. In one embodiment, a machine learning method automates the generation of DR messages for utilities.
Each DR message is associated with a profile that comprises attributes, such as but not limited to the timing of the message (or time of day), the message content (or category), an optional incentive, and an optional incentive level.
For an initial deployment of a DR program, a variety of message profiles are tested amongst the population of the user group of the program to study the effectiveness of the communication. After each DR event, the profile of each message sent to each user is evaluated to learn new and effective approaches for future DR messages. Over time, that additional learning of the effectiveness of the message profile provides a more precise and complete behavioral model of the user to assess how to motivate the user to save energy. When a satisfactory behavioral model of the user responses to DR messages has been built and is being maintained for each user, the likelihood for the utility to succeed in engaging users to participate in future DR events increases over time.
At step 4104, the process 4100 determines when to send the DR message for greater user compliance to the DR message. For example, the user may not respond to a DR message sent in the morning when the household is preparing for work and school. In an embodiment, the timing determination is learned by DR message service based on historical DR message timing and responses to the DR messages that are stored in the servers 106a, 106b in the user message profiles database 4006. In an embodiment, timing may depend on historical response to prior messages and on the individual user occupancy determination. For example, if the user is more likely to be at home, then DR message timing can be adjusted to prefer a time close to the desired DR event. In an embodiment, historical DR message responses can be combined with occupancy determination. For example, even though the user may be at home, they may respond more strongly to a message sent the evening before a DR event.
At step 4106, the process 4100 determines the DR message content for greater user compliance to the DR message. For example, reducing energy consumption saves the user money and also has a positive environmental impact. The user may not respond to a DR message appealing a reduction of the user's energy costs, but may respond to DR messages appealing the user's concern for the environment. In another example, a DR message with distinct visuals or copy can have a stronger response than other DR messages even though the category or theme of both DR messages may be in the same. In a further example, a DR message with a greater level of urgency can have a stronger response than a similar DR message with a lesser level of urgency.
In an embodiment, the content determination is learned by the DR message service based on historical DR message content and responses to the DR messages that are stored in the servers 106a, 106b in the user message profiles database 4006.
At step 4108, the process 4100 determines the communication medium to use to send the DR message to the user for greater user compliance to the DR message. Examples of communication include, but are not limited to, email, short message service (SMS), phone call, messenger, a letter, and the like. For example, a user may not check email, but reads a text message as soon as it arrives.
In an embodiment, the user specifies a preference, such as choosing to receive DR messages via SMS, or not wanting phone calls. The process 4100 applies the user's preferences when making a determination of the medium or the media to use to send the DR message.
In an embodiment, the communication medium determination is learned by the DR message service based on the communication medium used for historical DR messages and responses to the DR messages that are stored in the servers 106a, 106b in the user message profiles database 4006. Machine learning, supervised machine learning, or reinforcement machine learning can be used to determine the communication medium.
At step 4110, the process 4100 determines an optional incentive to include with the DR message for greater user compliance to the DR message. Examples of incentives include, but are not limited to time-of-use pricing, critical-peak pricing, games, contests, and lotteries. In an embodiment, optional incentives are stored in the DR incentives and rewards database 4010. For example, a user may be incentivized to participate in a DR request when also participating in a contest to win a prize. In an embodiment, the incentive determination is learned by the DR message service based on the incentives used with historical DR messages and responses to the DR messages stored in the servers 106a, 106b in the user message profiles database 4006. For example, the DR message service can determine effective incentives based on message response and DR performance for historical messages with different incentives, different incentive levels, or lack of incentives
At step 4112, the process 4100 sends the DR message to the user at the determined timing with the determined content and optional determined incentive via the determined medium. In an embodiment, the timing, content, incentive, and communication medium are stored in the user message profile database 4006.
At step 4114, the process 4100 determines the effectiveness of the DR message to the user. In an embodiment, process 4100 reviews the stored smart meter data showing the electrical energy consumption associated with user's house 3909 and determines whether the energy consumption indicates that the user complied with the DR message. In an embodiment, the process 4100 determines the effectiveness of the DR message to the user based on the smart meter data and the weather data. In an embodiment, the smart meter data is stored in the smart meter data base 4005 and the weather data is stored in the weather database 4008. In another embodiment, the process 4100 determines the effectiveness of the DR message to the user based on whether the DR message was opened. In a further embodiment, the process 4100 determines the effectiveness of the DR message to the user based on whether the user took an action on the content within the message, such as clicking on a link with the message, for example.
At step 4116, the process 4100 updates one or more of the user profile associated with the user, the premise profile associated with the characteristics of the user's house 3909, and the user profile associated with demographics of the user based on the effectiveness of the DR message. In an embodiment, the message profile is stored in the user message profile database 4006; the user profile is stored in the user profile database 4011; and the premise profile is stored in the premise profile database 4010.
The initial timing to send the DR message is ideally selected when the user is likely to be at home and amenable to receive a message. For example, the user may be at home in the morning before leaving for the office; however it is unlikely that someone would be receptive to a DR message at that time. During a workday, most users are expected to return home from work in the evening between 16:00 and 20:00. During the weekend, most users might exhibit different schedule patterns that can be less predictable than during a weekday.
In order to establish the timing, in one embodiment, the MDR service analyzes the data collected from the smart meter located at the user home.
In an embodiment, a DR message sent to a user when the user is not occupying the house 3903 is less likely to elicit a response than a DR message sent when the user is likely occupying the house 3909. In order to increase DR compliance, DR messages are sent to the user when the user is likely to be occupying the house around the time of the DR event. In a further embodiment, DR messages are sent to the user when the user is likely to be occupying the house and the user is amenable to receiving the message. Different occupants of the same house can receive messages at different times in order to increase DR compliance.
In another embodiment, determining home occupancy for a plurality of occupants allows sending messages so that they can be acted upon easily when someone is at home. If a subset of the occupants is present in a home, then tailored messages can be sent to those expected to be at home.
At step 4804 the process 4800 analyzes meter data from an electricity meter that measures the electrical energy consumed by the house 3909 of the user to determine whether the house 3909 is occupied. In an embodiment, the electricity meter is a smart meter and the meter data is smart meter data.
Referring to
If the house is occupied, then the process 4800 moves to step 4808, where the DR message is sent to the user. The demand response messages can be sent using one or more of an email, a telephone call, a text message, and a short message service message. In an embodiment, demand response messages can be sent via social media such as Facebook®, for example, or Google® search, for example, utilizing personalized ad targeting.
If the house is unoccupied, based at least in part on the analysis of the smart meter data, the process 4800 moves to step 4810, where the DR message is not sent.
Variations in the energy consumption throughout the 24 hour period are illustrated. Energy consumption 4404 represents baseline energy consumption for the house 3909; energy consumption 4406 represents additional energy consumption beyond the baseline of variable power loads, excluding energy consumption due to operation of an HVAC system; and energy consumption 4408 represents the energy consumed by the HVAC system. Curve 4410 illustrates the mean energy consumption for the corresponding hour on the x-axis. It is the mean of the individual data points 4402.
By projecting the variation of the energy that has been consumed, the MDR service assesses with a high level of confidence when the people living in the same home are at home or not. For example, the occupancy determination is due to historical pattern of energy usage. Looking across multiple days, it is possible to determine the consistency of intra-day usage patterns. If this pattern is very consistent, there can be higher confidence that occupancy can be predicted correctly.
Occupancy can be detected based on whether the household is occupied for a period of a given day (time-based analysis by hour of day across several days), or based on whether the household is occupied based on low activity for consecutive/adjacent days (a day level occupancy).
The determination of consecutive/adjacent may skip days of mild weather. For example, if Mon/Thurs/Fri are hot and Tues/Wed are mild, then inactivity on Tues/Wed does not contribute to interpreting an extended absence. However, if there is inactivity on Mon/Thurs/Fri then the overall level of inactivity can be used to infer an extended absence.
The correlation with outside weather is also important when inferring time-of-day occupancy since mild weather days can be skipped or given a lower weighing when determining whether a lack of inactivity represents a lack of occupancy.
In an embodiment, a predicted timing score is based on predicted occupancy. Occupancy may be determined according to time-of-day or by extended absence. Occupancy may be determined according to time-of-day or by extended absence for a user. If the user is not present in the house, a different member of the household may occupy the house and receive different message or message timing. If an extended absence is inferred, then no message need be sent.
At step 4906, the process 4900 analyzes the variations in the meter data. At step 4908, the process 4900 determines the levels of confidence that the house 3909 is occupied at times of the day.
For example, referring to
In another example, the process 4900 determines that the level of confidence that the house 3909 is occupied at 10:00 is 0.35 and the level of confidence that the house 3909 is occupied at 19:00 is 0.95.
At step 4910, the MDR service receives an indication of an energy event. In an embodiment, the MDR service receives the indication of the energy event from the utility. In an embodiment, the indication of the energy event is an indication that energy consumption needs to be reduced.
At step 4912, the process 4912 determines whether the level of confidence at a time T is greater than a threshold.
In an embodiment, the threshold is a predetermined threshold. In an embodiment, the threshold is a number greater than 0.50 or a percentage greater than 50%, indicating that there is a greater probability that the house 3909 is occupied at time T than not occupied. A greater probability that the house is occupied increases the chances of user compliance to a DR request.
In an embodiment, time T is approximately the time of the energy event. In another embodiment, time T is approximately the time the MDR service receives the indication of the energy event. In a further embodiment, the time T is a time preceding the time of the energy event that the MDR service determines is the best time to send a DR message for greater user compliance.
If the process 4900 determines that the house 3909 is occupied at time T, then the process moves to step 4914, where the DR message is sent at time T.
If the process 4900 determines that the house 3909 is unoccupied at time T, then the process moves to step 4916, where the DR message is not sent.
In an embodiment, the MDR service determines another time to send the DR message to the user.
In addition to smart meter data and surveys, the MDR service may augment the analysis of the message timing using other market data. In other embodiments, the MDR service analyzes data collected from mobile-devices connected to an occupancy determination system, or answers from users to marketing survey questions, or any other user generated profile data to establish the timing of the DR message. For example, there exist studies for direct email marketing on when it is most effective to send a message, or when it is most likely for a recipient to open a direct marketing message.
In an embodiment, a background application installed on computer 104 detects activity by a user of the computer, such as cursor movement, keystrokes or otherwise, and signals an application running on server 106a or server 106b that activity has been detected. Server 106a, 106b determines, based on the activity by the user of the computer, that the house 3909 is occupied.
In another embodiment, the geographic location of networked user electronics devices serves as indications of occupancy of the house 3909. In an embodiment, at least one mobile electronic device is used to indicate the state of occupancy of the house 3909.
In an embodiment, the MDR service determines the geographic location of a mobile electronic device that is connected to the network 102 and associates the mobile electronic device to a structure, such as house 3909, having a known geographic location. In addition, the MDR service determines whether the location of the mobile electronic device indicates occupancy of the house 3909 by a person associated with the mobile electronic device and sends the DR message when the house 3909 is deemed to be occupied.
Mobile devices can also be handheld and wireless devices such as personal digital assistants (PDAs), cellular telephones and other devices capable of accessing the network. Mobile devices 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.
For example, the establish occupancy using geo-fencing or location, the mobile device transmits geopositioning information to server 106 via network 102, such as the Internet. The server 106 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. The server evaluates the geopositioning data in order to determine whether the structure associated with the mobile device is unoccupied in light of the movement (or lack thereof) in the geopositioning data.
The data used to manage location is stored on one or more servers 106 within one or more databases. The overall database structure 4000 may include a user location database and such other databases as may be needed to support these and additional features.
Assuming a time when the user is at home has been determined, the next step is to decide when to send the message. For some users that are very responsive to read frequently new messages, the message could be sent minutes before the DR event. For some users that are not so responsive to read new messages, the message could be sent many hours before the DR event.
In one embodiment, no analysis need be done to determine timing of the initial message. A random or weighted random timing can be applied and the MDR service can learn from the results of the initial and subsequent messages.
After a DR message has been sent, the method learns if the timing was effective or not. In some embodiments, it is possible to instrument the message so that the user's actions to read the message (e.g. click through) can be used to determine effectiveness.
In other embodiments, the DR performance from smart meter data can be used to infer whether an action was taken in response to the message.
For each following DR message, the timing can be changed within various time variations to find the most effective timing based on the measures above.
Selecting the timing that is expected to be the most effective will not provide any opportunity for the method to compare timing effectiveness for each DR event. In order to maintain opportunity for the method to learn how the effectiveness of the timing might change over time, in an embodiment, the message timing can also be randomly selected for certain users.
In some embodiments, the message content may be categorized into “themes”. It is not expected that sending the same message each time will be effective in modifying user behavior. Instead, message details may be varied to retain interest, but themes can be used to group the motivating message to a user.
In an embodiment, the initial content of a DR message is written around a given theme. The utility would need to write only one type of message per theme. Each user that might receive the same message theme will be classified into the same category. In an embodiment, each user is assigned into one of the following category examples that determine the content of the received DR message:
For example, if the four message categories, “environmental”, “economics”, “community”, and “fun”, are selected for a DR event, and a user receives over a DR season two messages of the category “economics”, followed by one message of the category “fun”, then the method learns for that given user of the combination {“economics”, “economics”, “fun”}.
The number and topic of the categories to be learned are not limited to the examples listed above. Different programs, utilities, and partners benefit from choosing categories matched to their customer base and program objectives.
As an alternative, or in addition, to a themed message, smart meter data, occupancy patterns, or other user profile information collected from the home and its occupants can be used to provide specific recommendations. For example, specific equipment such as pool pumps or clothes dryers can be identified by smart meter disaggregation. A specific call to action can increase the likelihood of behavior modification by recommending actions and offering projected benefits from those actions. HVAC energy consumption can be a large contributor to peak energy usage. Excessive HVAC energy consumption can be identified relative to neighborhood, occupancy, dwelling size, etc. For example, if it can be determined that the home is not occupied but HVAC consumption is high, a recommendation to set back during peak hours can be made without significant impact to comfort.
In other embodiments, there may be an option to take direct control of a change to save energy. If a user has pre-approved an action to save energy, as in a demand-response program, messaging is not required and an automated action can be taken. In addition, there may be opportunities to save energy determined by smart meter data, occupancy, or other profile information that could be applied where a user has not given assent. In this case, a messaging system can be used to ask for permission to apply a specific change to save energy for a specific occurrence, or for all future occurrences.
Finally, a messaging system can be used to increase engagement and satisfaction by acknowledging participation in automated programs, or to affirm an agreement to an automated change.
In order to send the first DR message, some initial probabilities are assigned by the method for classifying each user into a message category. By having learned over multiple DR messages, the method decides to maintain the user in a specific category that has proved its effectiveness or to change the category of the user that may be more effective.
After a DR message has been sent, the method learns if the message content was effective or not. In some embodiments, it is possible to instrument the message so that the user's actions to read the message (e.g. click through) can be used to determine effectiveness.
In other embodiments, the DR performance from smart meter data can be used to infer whether an action was taken in response to the message.
In further embodiments, a user can greatly reduce load after a DR message, but the user behavior may be unrelated to the message, such as taking a vacation day, for example. A multi-day analysis of a user for event days, and a multiple event day analysis can be used to determine consistent responsiveness to DR messages.
For each following DR message, the message content can be changed within various time variations to find the most effective timing based on the measures above.
As it has been described for the timing of the message, always displaying the message that is expected to be the most effective will not provide any opportunity for the method to compare content effectiveness for each DR event. In order to maintain the opportunity for the method to learn how the effectiveness of a category might change over time, the message category can be randomly selected for some messages.
User behavior changes over time. One key dimension of that behavior is message fatigue that can cause the user to respond less positively to a given message profile than she did during a previous event.
Learning of fatigue behavior is based on correlating actions taken in response to a message with the prior history of messages. The correlation of prior history can be based on recency, frequency, and cumulative measures of prior message delivery. The recency, frequency, and cumulative measures may be further characterized by category, as some categories may elicit more fatigue than others.
In some embodiments, different types of incentives are offered to users. Some utilities do have Critical Peak Pricing (CPP) or Time-of-Use (ToU) programs while others do not. Those programs might affect the types of incentives proposed.
Different types of incentive categories are possible, such as, but not limited to, games, contest, lottery, and the like. For each of the incentive categories, different types of rewards are possible such as, but not limited to, cash, gift cards, rewards programs, and the like.
Ideally, for any incentive category, only a certain group of winners are selected in order to stimulate the benefits of increased participation and excitement while keeping incentive costs from becoming prohibitively high.
In an embodiment, control groups are offered scenarios with different incentives and rewards in order for the method to learn the effectiveness of the incentives and rewards for each incentive category, which is likely to be limited by the budget of the utility for that program.
After a DR message has been sent, the method learns if the message profile was effective or not. In some embodiments, it is possible to instrument the message so that the user's actions to read the message (e.g. click through) can be used to determine effectiveness.
In other embodiments, the DR performance from smart meter data can be used to infer whether an energy reduction action was taken in response to the message.
Learning from the DR Message
For each following DR message, the message profile (timing, content, and optional incentive) can be changed within various profile variations to find the most effective profile based on the measures above.
The profile of each message for each user is effective if the user reduces energy consumption during the DR event. The method predicts the best choice for the message timing and the message content. An effective prediction increases the engagement results of the whole user population, and, as a result of being effective, reduces the shed on the utility distribution network. For each subsequent DR message, the method continuously improves its learning.
Additionally, in an embodiment, the prediction model of the method classifies users by their locations as identified by their zip code or any other neighborhood categorization, and their recent average household energy usage. Both user locations and user energy consumptions are two important factors that can have an impact on the shed reduction. Certain locations of users can be more sensitive to participate into DR events. And, users that consume a lot of energy might be the best target segment for the utility to reduce the load on their distribution network.
In addition to an energy saving outcome, a messaging program measures engagement outcomes, such as open or click-through rates. Participants in a messaging program can also be compared to control users to determine the improvement in engagement and satisfaction from personalized and actionable energy messaging.
In an embodiment, the goal of the machine learning method is to increase the engagement of the user and drive user participation into the DR programs in order to reduce the shed on the utility network.
Different users have different schedules depending if it is a weekday or a weekend day. Different users will respond differently to different types of message categories. The continuous learning nature of the method allows both to record and to adapt to how user behaviors change over time. For example, a vacationing user can have both weekday and weekend schedules change significantly from one week to another one. Another user might respond positively to a message encouraging her to help the environment for two events, but stop responding after that. As a result, the method adapts to those changes, and finds another timing or message category is effective for that user.
To improve the accuracy of the learning, in an embodiment, the method can assign each user to a peer group (PG). A peer group, as the name suggests, is a set of users that are determined to display similar behaviors.
For each user, the method maintains the best guess of the timing and the category of the messages that are most effective. The method uses that information before an event to pick the best message profile for that user. Based on the user actions during the DR event, that best guess in the method is updated. When a user shows engagement with the utility, for instance, by opening any links into the message or logging into her account, the timing of the message provided by the method is correct. When, after opening the link in the message, the user takes action to reduce energy consumption, the category of the message selected by the method is successful.
A first embodiment of a learning approach for the method is supervised learning. In supervised learning, the method learns from a data set how to make predictions by establishing the relationships that exist between input data and output data.
Typically, as shown on
At step 4504, the process 4500 determines a time T when the user is likely at home. Referring to
After the initial time T, the process 4500 determines the time T when the user is likely at home by learning. In an embodiment, the learning is a binary linear classification algorithm where the process 4500 learns from multiple variations to T, T+ΔT, where AT can range from a few minutes to a few hours.
At step 4506, the process 4500 sends the DR message to the user at time T+AT.
At step 4508, the process 4500 determines whether the user interacted with the DR message.
From each input x=T+ΔT, the process 4500 learns if the timing of the DR message leads to the user to click on the links of the DR message or to log in into her account. If the user clicks on the links, the output of the learning algorithm is y=1, if not the output of the learning algorithm is y=0.
At step 4510, the process 4500 stores the output of the learning algorithm associated with the time T+ΔT and updates the time T to send the DR message based on the learning algorithm. The binary linear classification of the process 4500 establishes the output y € {0,1} for x=T+ΔT.
In an embodiment, the first or initial category of the DR message for each user is randomly selected to classify each user into a message category. For example, assuming the utility selects the four message categories as illustrated in
After the initial DR message comprising the initial category, the process 4600 determines the DR message category by learning. In an embodiment, the learning is a binary linear classification where the process 4600 learns from multiple permutations of the category.
At step 4604, the process 4600 sends the DR message and at step 4606, the process 4600 determines whether the user reduced energy consumption. In an embodiment, the process 4600 learns if the category content of the DR message leads to the user to click on the links of the DR message or to log in into her account.
After the initial category selection, the process 4600 learns which message permutation xij (where i is the message number and j the permutation number for that message number) engages the user to participate in the second DR message:
x11={A,A}
x12={A,B}
x13={A,C}
x14={A,D}
After the second DR message, the process 4600 learns which new message permutation results in engaging the user:
x21={{A,A,A}, {A,A,B}, {A,A,C}, {A,A,C}}
x22={{A,B,A}, {A,B,B}, {A,B,C}, {A,B,D}}
x23={{A,C,A}, {A,C,B}, {A,C,C}, {A,C,D}}
x24={{A,D,A}, {A,D,B}, {A,D,C}, {A,D,D}}
Learning continues until the last DR message is sent.
If there are many events, the permutations of sequences of categories can become very large. To support practical calculations, the number of permutations can be limited to a subset of previous events. In an embodiment, one approach is to track permutations of the last N events, such as N=3. In other embodiments, N can be greater than 3 or N can be less than 3.
In an embodiment, there are four possible user actions:
As a result of the user actions, the process 4600 learns from each of the possible user actions.
By implementing a binary linear classification, the process 4600 learns the message permutations, for any given permutation, xij, that lead to the user to click on the link of the message.
If the user clicks on the link, the output of the method is y=1, if not the output of the method is y=0.
At step 4608, the process 4600 stores the output of the learning and updates the effective message category associated with the user. The binary linear classification of the process 4600 establishes the output y∈{0,1} for each given permutation xij.
In another embodiment, the process 4600 further comprises implementing a regression of the permutations to further refine the message category that leads the user to reduce energy consumption. For example, regression determines how likely a given message is going to perform for a user or a peer group of users and is used to “learn” which message results in better DR performance.
For any given permutation, xij, the process 4600 learns the permutation of the messages that lead to the user to reduce energy consumption or to shed energy. The shed y of a home is a variable expressed in kilowatts, and generally is less than 3 kW in the United-States for a single family home.
The regression establishes the output y=(xij) for each given permutation xij where f(xij)=ax
The supervised learning process 4600 may also consider additional parameters to increase the effectiveness of the DR message. Additional parameters to consider include:
Both user locations and user energy consumptions are two important factors that can have an impact on the shed reduction.
With the additional features, the regression comprises multivariate regression and establishes the output y=f(xij) for each given permutation xij where f(xij)=ax
With that additional capability, the process 4600 can predict more accurately the shed for the utility by classifying each user in a peer group (PG) defined by y, the zip code, and z, the recent household energy usage.
As the number of DR messages grow, a more sophisticated approach to the learning can be done by introducing a score function. In that case, the learning differs from supervised learning to become reinforcement learning.
In an embodiment, the same reinforcement learning method can be applied to both the timing and the category of the DR message. The score increases when the user engages by clicking on the links of the DR message and the user takes actions to reduce her shed on the utility network.
For example, the proposed initial probability for each category for each user DR message is:
At step 4720, the process 4700 calculates scores S earned for each user-message profile combination (timing, category, user) from the latest event. The profile of the message can be either the timing or the category of the message. At step 4721 the process 4700 calculates the score earned for each category and at step 4721 the process 4700 calculates the score earned for each time.
In an embodiment, the total score can be written as:
S
profile,event=Load Shed Scoreprofile,event+Engagement Scoreprofilement−Unsubscription Penaltyprofile,event
where:
The profile of the message can be either the timing or the category of the message. The load shed score and engagement score terms are calculated from the shed and actions of the individual homeowner and other homeowners who belong to the same peer group. The unsubscription penalty term is determined from looking at how many similar homeowners are unsubscribing from the service in response to messages of the given category due to message fatigue.
At step 4730, the process 4700 updates the DR message category and timing scores S for each user-profile combination. At step 4731, the process 4700 updates the message category scores for each message category and a step 4732, the process 4700 updates the score for each time T.
The profile of the message can be either the timing or the category of the message. This allows the total score for the user's profile to weigh results from the last event against learnings from previous events. In an embodiment,
S
profile
=m*S
profile+(1−m)*Sprofile,event
where:
m is the memory factor that retains learning from past events;
m is set to a number between 0 and 1;
m=0 means use only learning from newest events;
m=1 means do not learn.
At step 4740, the process 4700 determines the next DR message category and timing for the user based on the reinforcement learning. At step 4741 the process 4700 determines whether to increase the learning. If, at step 4741, the process 4700 determines that additional learning is not desired, then the process 4700 moves to steps 4742 and 4743 where the updated message category and timing as determined by the updated score calculation, Scategory and Stiming, is used for the next DR message category and timing, respectively.
If, at step 4741, the process 4700 determines that additional learning is not desired, then the process 4700 moves to step 4744.
To improve the learning of the method, it is useful to occasionally try a different message with a random probability. This assists the reinforcement learning to learn if other categories would perform better for users. In another embodiment, different DR message categories with random probabilities and different timing can be used for the next DR message category and timing.
At step 4744, the process 4700 proposes a new probability for each category for each user DR message and at step 4745, the process 4700 proposes a new timing T for the DR message based at least in part in the smart data.
For example, the proposed new probability for each category for each user DR message is:
The process 4700 repeats steps 4720, 4730, and 4740 to calculate and update scores with the additional learning.
The reinforcement learning process 4700 may also consider additional parameters to increase the effectiveness of the DR message. Additional parameters to consider include:
The number of learning opportunities for a single customer over a single season is limited. Both user locations and user energy consumptions are two important factors that can have an impact on the shed reduction. Location and energy consumption can be used to group users into peer groups based on zip, neighborhood, community associations, energy usage, or patterns of energy usage, for example. In an embodiment, clusters of customers are considered based on a profile, where profile may be based on location (such as ZIP), consumption patterns (high usage, EV owner, etc.), content engagement (green enthusiasts), or any combination of properties known or derived about a customer. More than one method of clustering can be used to different learning objectives. For example, clustering by location may have less value when determining when to send a message.
As described previously to the shed and engagement feature of the learning, the category of the incentive could be an additional feature to the method. In an embodiment, for each category of the incentive, the method learns the level of incentive that maximizes the engagement and the shed while keeping the sum of all the incentives provided under budget. For example, incentive possibilities can be treated as weighted choices, similar to message categories, where the probability of all categories sums to 1. If 1 is treated as a scaled budget, then all incentive choices and/or incentive levels can be given a weight and the incentive can be allocated per weighting to produce the best result for a given level of funding.
Other learning features can be integrated into the methods.
In an embodiment, the method learns the HVAC home usage. The HVAC home usage feature could be used by the method to learn the user home presence.
In an embodiment, the method learns the prevalence of high load devices, such as pool pump, in a home. Homes with high load devices are a good segment to target DR messages.
In an embodiment, the method learns high weather temperatures that push the user to still run the HVAC system during a DR event and not being able to participate to the DR event.
In an embodiment, the method learns from the premise profile, defined by the age of the home, and square footage. The premise profile could be used to develop a profile of the peer group.
In an embodiment, the method learns from the user profile, defined by ages, ethnicity, and other types of demographics. The user profile could be used to develop a profile of the peer group.
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.
