Patent Application
20180087795
This invention relates to the use of thermostatic HVAC and other energy management and home automation controls that are connected to a computer network. More specifically, the present invention pertains to the combination of a thermostatic controller with additional sensors, transducers, radios, rich user interfaces and other components in order to provide a centralized tool for accomplishing a wide range of tasks related to home comfort, convenience and security.
More specifically, it relates to the use of a multi-function device that includes traditional thermostat functions in addition to functions that allow it to perform as a key component of home automation, security and other systems.
Heating and cooling systems for buildings (heating, ventilation and cooling, or HVAC systems) have been controlled for decades by thermostats. At the most basic level, a thermostat includes a means to allow a user to set a desired temperature, a means to sense actual temperature, and a means to signal the heating and/or cooling devices to turn on or off in order to try to change the actual temperature to equal the desired temperature. The most basic versions of thermostats use components such as a coiled bi-metallic spring to measure actual temperature and a mercury switch that opens or completes a circuit when the spring coils or uncoils with temperature changes. More recently, electronic digital thermostats have become prevalent. These thermostats use solid-state devices such as thermistors or thermal diodes to measure temperature, and microprocessor-based circuitry to control the switch and to store and operate based upon user-determined protocols for temperature vs. time.
These programmable thermostats generally offer a very restrictive user interface, limited by the cost of the devices, the limited real estate of the small wall-mounted boxes, and the inability to take into account more than two variables: the desired temperature set by the user, and the ambient temperature sensed by the thermostat. Users can generally only set one series of commands per day, and in order to change one parameter (e.g., to change the late-night temperature) the user often has to cycle through several other parameters by repeatedly pressing a few buttons.
Because the interface of programmable thermostats is so poor, the significant theoretical savings that are possible with them (sometimes cited as 25% of heating and cooling costs) are rarely realized. In practice, studies have found that more than 50% of users never program their thermostats at all. Significant percentages of the thermostats that are programmed are programmed sub-optimally, in part because, once programmed, people tend to not to re-invest the time needed to change the settings very often.
A second problem with standard programmable thermostats is that they represent only a small evolutionary step beyond the first, purely mechanical thermostats. Like the first thermostats, they only have two inputs—ambient temperature and the preset desired temperature. The entire advance with programmable thermostats is that they can shift between multiple present temperatures at different times without real-time involvement of a human being.
Because most thermostats control HVAC systems that do not offer infinitely variable output, traditional thermostats are designed to permit the temperature as seen by the thermostat to vary above and below the setpoint to prevent the HVAC system from constantly and rapidly cycling on and off, which is inefficient and harmful to the HVAC system. The temperature range in which the thermostat allows the controlled environment to drift is known as both the dead zone and, more formally, the hysteresis zone. The hysteresis zone is frequently set at +/−1 degree Fahrenheit. Thus if the setpoint is 68 degrees, in the heating context the thermostat will allow the inside temperature to fall to 67 degrees before turning the heating system on, and will allow it to rise to 69 degrees before turning it off again.
As energy prices rise, more attention is being paid to ways of reducing energy consumption. Because energy consumption is directly proportional to setpoint—that is, the further a given setpoint diverges from the balance point (the inside temperature assuming no HVAC activity) in a given house under given conditions, the higher energy consumption will be to maintain temperature at that setpoint), energy will be saved by virtually any strategy that over a given time frame lowers the average heating setpoint or raises the average cooling setpoint. Conventional programmable thermostats allow homeowners to save money and energy by pre-programming setpoint changes based upon comfort or schedule. For example, in the summer, allowing the setpoint to rise by several degrees (or even shutting off the air conditioner) when the home is unoccupied will generally save significantly on energy. But such thermostats have proven to be only minimally effective in practice.
Because they have such primitive user interfaces, they are difficult to program, and so many users never bother at all, or set them up once and do not alter the programming even if their schedules change.
Another limitation of conventional thermostats may arise when a home contains more than one HVAC system, which generally means that it has more than one thermostat. It has generally not been possible to control both systems from a single location. Thus, for example, if a given home has one system for upstairs and one for downstairs, it has not been feasible to turn off both systems from the thermostat nearest the door when leaving the house, for example.
Some homes provide multiple zones of control, each of which may have a separate thermostatic controller, but may connect those zones to a common HVAC system by means of dampers, separate fans, and so on.
In the hotel industry, the heating and cooling decisions made in hundred or even thousands of individual rooms with independently controlled HVAC systems are aggregated into a single energy bill, so hotel owners and managers are sensitive to energy consumption by those systems. Hotel guests often turn the air conditioner to a low temperature setting and then leave the room for hours at a time, thereby wasting considerable energy. An approach commonly used outside of the United States to combat this problem is to use a keycard to control the HVAC system, such that guests place the keycard into a slot mounted on the wall near the door of the room which then triggers the lights and HVAC system to power up, and turn them off when the guest removes the card upon leaving the room. However, because most hotels give each guest two cards, it is easy to simply leave the extra card in the slot, thus defeating the purpose of the system. Recently, systems have been introduced in which a motion sensor is connected to the control circuitry for the HVAC system. If no motion is detected in the room for some predetermined interval, the system concludes that the room is unoccupied, and turns off the HVAC system or alters the setpoint to a more economical level. When the motion sensor detects motion (which is assumed to coincide with the return of the guest), the HVAC system resets to the guest's chosen setting.
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 until very recently, tremendous technological change has come to the tools used for personal communication. When programmable thermostats were first offered, telephones were virtually all tethered by wires to a wall jack. But now a large percentage of the population carries at least one mobile device capable of sending and receiving voice or data or even video (or a combination thereof) from almost anywhere by means of a wireless network. These devices create the possibility that a consumer can, with an appropriate mobile device and a network-enabled HVAC system, control his or her HVAC system even when away from home. But systems that rely on active management decisions by consumers are likely to yield sub-optimal energy management outcomes, because consumers are unlikely to devote the attention and effort required to fully optimize energy use on a daily basis.
Many new mobile devices now incorporate another significant new technology—the ability to geolocate the device (and thus, presumably, the user of the device). One method of locating such devices uses the Global Positioning System (GPS). The GPS system uses a constellation of orbiting satellites with very precise clocks to triangulate the position of a device anywhere on earth based upon arrival times of signals received from those satellites by the device. Another approach to geolocation triangulates using signals from multiple cell phone towers. Such systems can enable a variety of so-called “location-based services” to users of enabled devices. These services are generally thought of as aids to commerce like pointing users to restaurants or gas stations, and so on.
Rapid change has also come to the tools used for connecting once-mundane devices to each other, and to smart phones and other Internet-enabled devices. For decades, home security systems were hard-wired systems connected to a central office via phone lines, or local-only (i.e., each home system was an island, separate from any other system). Home automation—systems that control of lights, media devices, and the like—consisted of highly customized and proprietary systems assembled and maintained by outside vendors at considerable expense, or complex DIY projects that were beyond the abilities of many consumers, and were generally islands as well. Today consumers can choose from Internet-connected security cameras, lightbulbs and lighting controllers, motorized window treatments, door locks, and many other devices. When a consumer owns more than one or two of such devices, managing them can become complex and frustrating. Separate “siloed” systems also fail to deliver synergies that could come from combining those systems so that helpful information that may exist in one such system might benefit the others. Finally, many of these systems require components other than the primary device in order to operate and connect to the larger network. Many such systems require dedicated hubs that connect to the edge device (e.g., a camera) using one protocol (e.g., ZigBee), while connecting to the user through another (e.g., 802.11).
The traditional thermostat does have some advantages for use in a modern networked system: it is typically a wall-mounted device in a convenient location; 24-volt power is generally available within the wall and connected to thermostat, enabling modern electronics to perform a much broader range of functions in a convenient location without the need to relocate existing HVAC wiring or install new wiring; and a wall-mounted device in a convenient location can be shared by all occupants of a home, including children or elderly members without regular access to a smartphone.
It would be desirable to provide an integrated device that can function as a communicating thermostat as well as a hub for a broad range of additional connected products. It would also be desirable for that integrated multi-function device to provide an array of sensors and transducers to enable a wider range of means by which the occupants of a space can interact with the device. It would also be desirable if the device included a plurality of networking technologies to enable it to be used to connect with and manage a wide range of devices.
In an embodiment, the invention comprises a thermostat attached to an HVAC system, where said thermostat is augmented by one or more of the following: an occupancy sensor, a camera, a microphone, and a speaker. The occupancy sensor may be a passive infrared sensor, but other forms of occupancy detection using a camera for motion detection, a microphone for audio level, a light sensor for brightness level, a physical motion sensor (such as a gyroscope or accelerometer), an active light sensor (such as beam interruption), radar, sonar, gas sensor (such as CO2), other methods of detecting presence, or any combination of these may be used.
In an embodiment, the thermostat functions as a home hub, which may connect to a network with a plurality of additional devices that can include: one or more remote temperature sensors, one or more remote humidity sensors, one or more thermostats for additional HVAC units, one or more occupancy sensors, one or more cameras, microphones, speakers, water leak sensors, door/window sensors, tilt sensors, light sensors, physical motion sensors, light fixtures and/or light bulbs, handheld remote controls (such as key fobs), alarm alerts (such as a siren or silent phone call), and alarm/security panels (for status and arming). In this embodiment, the home hub thermostat can act as a control panel for a complete security system with an appropriate set of devices.
In an embodiment, a thermostat/hub includes a monitoring camera, which may be high-definition or ultra-high definition, to monitor the physical space around the thermostat. The home hub thermostat may also include at least a microphone and speaker system to support interactive voice control with speech recognition. For higher quality and speech recognition accuracy, a microphone array with beam-forming can be provided.
In an embodiment, the thermostat/hub includes a display that supports user interaction and presentation of information useful to occupants of the structure, including information about multiple devices connected to the thermostat hub. The display on the thermostat/hub can be used to show video of other cameras connected to the system. Combined with a microphone and speaker comprising the thermostat/hub, these aspects can, for example, connect with a front door camera/speaker/microphone for interactive screening of visitors. This can be done safely from within the house without opening an entry door.
In an embodiment, the display on the thermostat/hub may support rich user interaction through means such as a touch screen.
In an embodiment, the rich user interface may comprise a module that can be removably attached to a more permanently attached wall-mounted module. The removable module may be a dedicated, application-specific device, or it may be a general-purpose device such as a smart phone or tablet computer.
In an embodiment, the invention comprises a thermostat attached to an HVAC system, a local network connecting the thermostat to a larger network such as the Internet, and one or more geolocation-enabled mobile devices attached to the network, and a server in bi-directional communication with a plurality of such thermostats and devices. The server pairs each thermostat with one or more geolocation-enabled mobile devices which are determined to be associated with the occupants of home in which the thermostat is located.
The server logs the ambient temperature sensed by each thermostat vs. time and the signals sent by the thermostats to their HVAC systems. The server also monitors and logs the geolocation data related to the geolocation-enabled mobile devices associated with each thermostat. Based on the locations and movement evidenced by geolocation data, the server instructs the thermostat to change temperature settings between those optimized for occupied and unoccupied states at the appropriate times based on the evolving geolocation data.
One embodiment of the invention is directed to a method for varying temperature setpoints for an HVAC system. The method comprises determining the geographic location of a mobile electronic device that is connected to a network and associating said mobile electronic device to a structure having a known geographic location that contains one or more networked climate control devices. In addition, the method comprises determining whether the location of said mobile electronic device indicates occupancy of said structure by a person associated with said mobile electronic device and adjusting the temperature setpoint on said controller for an HVAC system for said structure based upon whether or not said structure is deemed to be occupied.
In another embodiment, the mobile electronic device is a telephone. In an additional embodiment, the networked mobile electronic device is a tablet or similar device. In a further embodiment, the mobile electronic device is connected to the Internet.
In an embodiment the method for determining the geographic location of a mobile electronic device uses the global positioning system. In another embodiment, the method for determining the geographic location of a mobile electronic device is based upon estimation of the distance between the mobile electronic device and one or more antennas used to receive radio signals from said mobile electronic device. In a further embodiment, the mobile electronic device communicates with a remote server.
In yet another embodiment, the variation of temperature setpoints is logged to a database. In a further embodiment, the variation of temperature setpoints is initiated by a remote computer. In a different embodiment, the temperature setpoints are varied automatically. In a further embodiment, an occupant is prompted to confirm occupancy prior to adjustment of said temperature setpoint.
In one embodiment, a system for altering the setpoint on a thermostat for space conditioning of a structure comprises at least one said thermostat having at least one temperature setting associated with the presence of one or more occupants in said structure, and at least one temperature setting associated with the absence of occupants in said structure. The system also comprises one or more mobile electronic devices having at least a user interface, where the mobile electronic devices and said thermostat are connected to a network and where the setpoint on said thermostat is adjusted between said temperature setting associated with the presence of one or more occupants in said structure and said temperature setting associated with the absence of occupants in said structure based upon the geographic location of said electronic device.
In a further embodiment, the mobile electronic device is a telephone. In yet another embodiment, the networked mobile electronic device is a tablet or similar device. In still a further embodiment, the mobile electronic device is connected to the Internet.
In an embodiment, the method for determining the geographic location of a mobile electronic device is the global positioning system. In another embodiment, the method for determining the geographic location of a mobile electronic device is based upon estimation of the distance between the mobile electronic device and one or more antennas used to receive radio signals from said mobile electronic device. In a further embodiment, the mobile electronic device communicates with a remote server.
In a different embodiment, the variation of temperature setpoints is logged to a database. In another embodiment, the variation of temperature setpoints is initiated by a remote computer. In a further embodiment, the temperature setpoints are varied automatically. In still another embodiment, an occupant is prompted to confirm occupancy prior to adjustment of said temperature setpoint.
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 servers 106 are physically remote from users of computers 104 and mobile devices 105, but are accessible to those users via network 102, those servers 106 are sometimes referred to herein as being “in the cloud.”
When a user of an embodiment of the subject invention wishes to access information on network 102 using computer 104, 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 104and 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 conventional computers that are equipped with communications hardware such as modem or a network interface card. The computers include processors such as those sold by Intel and AMD. Other processors may also be used, including general-purpose processors, multi-chip processors, embedded processors and the like.
Computers 104 can also be microprocessor-controlled home entertainment equipment including advanced televisions, televisions paired with home entertainment/media centers, and wireless remote controls.
Computers 104 may 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 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 may use an operating system such as Microsoft Windows, Apple Mac OS, Linux, Unix or the like.
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.
Also attached to the network may be additional devices such as digital cameras 130, motion sensors 140, lightbulbs and lighting controllers 150. A wide variety of additional devices may be connected to the network, such as motorized window treatments door locks and moisture sensors intended to detect leaks, smoke and carbon monoxide detectors, remote temperature sensors, and so on. The preceding examples are intended to provide examples and are not intended to limit the range of devices that may be connected to the network. In some networking environments, such as ZigBee, repeaters may also be used to improve and/or extend coverage, or the devices may be connected using a wired network such as Ethernet.
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 (including Bluetooth Low Energy), cellular systems such as CDMA, GSM and GPRS, or other wireless protocols. The thermostat 250 may also include controls 266 allowing users to change settings directly at the thermostat.
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 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 response program, and so on.
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 (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, and so on. Such signaling activity may be conducted via email, text message, pop-up alerts, voice messaging, or other means.
As shown in
As shown in
Row 372 shows a 24-hour period. Programming row 374 displays various programming periods and when they are scheduled, such as setting 376, which includes a setpoint of 59 degrees and begins at 9 AM and runs until 9 PM. Row 374 shows the schedule used for one set of conditions, such as (in this case) Monday through Friday; row 378 shows the schedule for Saturday and Sunday.
If the server 106 determines that the home should be in occupied or “home” mode, then in step 1308 the server queries database 300 to determine whether thermostat 108 is
already 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 unoccupied, then in step 1310 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 1316, in which it changes the programmed setpoint for the thermostat to the setting intended for the house when occupied. If the user has previously specified that the application should not make such changes without further user input, then in step 1312 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 house 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 elects 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 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 away 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 house 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 house 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” 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.
At least an embodiment of the invention is capable of delivering additional benefits for homeowners in terms of increased 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 the thermostat 108 to regularly measure and send to the server information about the temperature in the building. 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 performance data will allow the server 106 to calculate an effective thermal mass for each such structure—that is, the rate at which the temperature inside a given building will change in response to changes in outside temperature. Because the server will also log these inputs against other inputs including time of day, humidity, and so on 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 ability to predict the rate of change in inside temperature in a given house 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.
Using TT as an input, in step 1516 the server then determines the time at which the computational steps required to program the preconditioning event will be performed (ST). In step 1518, performed at start time ST, the server begins the process of actually calculating the required parameters, as discussed in greater detail below. Then in 1520 specific setpoint changes are transmitted to the thermostat so that the temperature inside the home may be appropriately changed as intended.
In step 1534, the server retrieves data used to calculate the appropriate start time with the given input parameters. This data includes 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, and so on; 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, to more detailed tables including humidity, solar radiation, wind, and so on. 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 (ΔT) 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 1536, combined with input parameters TT and Temp (TT) to determine the time at which slope ΔT intersects with predicted initial temperature PT. The time between PT and TT is the key calculated parameter: the preconditioning time interval, or PTI.
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 ΔT.
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., ΔT is quantized into discrete interval data of at least 1 degree F. each. For example, if Temp (PT) is 65 degrees F., Temp (TT) is 72 degrees F., and PT is 90 minutes, the thermostat might be programmed to be set at 66 for 10 minutes, 67 for 12 minutes, 68 for 15 minutes, and so on.
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 house further from its natural setpoint given outside weather conditions, and so on. (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 1542 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 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 home 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.
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 inside temperature based upon outside temperatures, and so on.
An additional capability offered by an embodiment of the instant invention is the ability to adapt the programming of the HVAC control system based upon the natural behavior of occupants. Because an embodiment of 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 two-way communicating devices discussed herein, do not record such inputs locally, and neither recognize nor transmit the fact that a manual override has occurred. Furthermore, in a system as described herein, 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 an embodiment of the subject invention does have access to.
In step 1704, the server retrieves any additional automated setpoint changes C that have been scheduled for the thermostat by server 106 at time0. Such changes may include algorithmic changes intended to reduce energy consumption, and so on.
In step 1706 the server calculates the difference (dA) between A0 and A-1; for example, if the actual setpoint is 67 degrees at T-1 and 69 at T0, dA is +2; if the setpoint at T-1 is 70 and the setpoint at T0 is 66, dA is −4.
In step 1708, the server performs similar steps in order to calculate dS, the difference between S0 and S-1. This is necessary because, for example, the setpoint may have been changed because the server itself had just executed a change, such as a scheduled change from “away” to “home” mode. In step 1710 the server evaluates and sums all active algorithms and other server-initiated strategies to determine their net effect on setpoint at time0. For example, if one algorithm has increased setpoint at time0 by 2 degrees as a short-term energy savings measure, but another algorithm has decreased the setpoint by one degree to compensate for expected subjective reactions to weather conditions, the net algorithmic effect sC is +1 degree.
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 1806 the server retrieves contextual data required to interpret the manual override. Such data may include current and recent weather conditions, current and recent inside temperatures, and so on. This data is helpful because it is likely that manual overrides are at least in part deterministic: that is, that they may often be explained by such contextual data, and that such understanding can permit anticipation of the desire on the part of the occupants to override and to adjust programming accordingly, so as to anticipate and obviate the need for such changes. The amount of data may be for a period of a few hours to as long as several days or more. Recent data may be more heavily weighted than older data in order to assure rapid adaptation to situations in which manual overrides represent stable changes such as changes in work schedules, and so on.
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 step 1812 the server determines whether to alter the current setpoint as a result of applying the rules in step 1810. If no setpoint change is indicated, then the routine ends. If a setpoint change is indicated, then in step 1814 the server transmits the setpoint change to the thermostat for execution in the home, and in step 1816 it records that change to one or more databases in overall database structure 300.
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 1904 the server retrieves the recent override data as recorded in
In step 1908 the server interprets the overrides in light of the existing programming schedule, rules for overrides, contextual data, and so on. 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, text message, personalized website, and so on.
Additional means of implementing an embodiment of 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, and so on. 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.
An additional way in which an embodiment of the instant invention can reduce energy consumption with minimal impact on comfort is to vary the turn-on delay enforced by the thermostat after the compressor is turned off Compressor delay is usually used to protect compressors from rapid cycling, which can physically damage them.
The ability to predict the rate of change in inside temperature in a given house under varying conditions may also be applied to permit calculation of the effect of different compressor delay settings on inside temperatures, HVAC cycling and energy consumption.
In step 2006, server 106 determines whether a specific home is subscribed to participate in compressor delay events. If a given home is eligible, then in step 2008 the server retrieves the parameters needed to specify the compressor delay routine for that home. These may include user preferences, such as the weather, time of day and other conditions under which the homeowner has elected to permit hysteresis band changes, the maximum length of compressor delay authorized, and so on.
In step 2010 the appropriate compressor delay settings are determined, and in step 2012 the chosen settings are communicated to the thermostat. In step 2014 the server determines if additional thermostats in the given group must still be evaluated. If so, the server returns to step 2006 and repeats the subsequent steps with the next thermostat. If not, the routine ends.
Because the hysteresis band operates to so as to maintain the temperature within a range of plus or minus one degree of the setpoint, in the case of air conditioning the air conditioner will switch on when the inside temperature reaches 71 degrees, continue operating until it reaches 69 degrees, then shut off. The system will then remain off until it reaches 71 degrees again, at which time it will again switch on. The percentage of time during which inside temperature is above or below the setpoint will depend on conditions and the dynamic signature of the individual, home. Under the conditions illustrated, the average inside temperature AT12112 is roughly equal to the setpoint of 70 degrees.
It should be noted that the shape of the actual waveform will most likely not be sinusoidal, but for ease of illustration it is sometimes be presented as such in the figures.
Residential air conditioning is a major component of peak load. The traditional approach to dealing with high demand on hot days is to increase supply—build new power plants, or buy additional capacity on the spot market. But because reducing loads has come to be considered by many 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. An embodiment of the instant invention provides a means to verify demand response without additional hardware such as a data logger.
Because server 106 logs the temperature readings from inside each house (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 house. 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 building will change in response to changes in outside temperature. Because the server will also log these inputs against other inputs including time of day, humidity, and so on 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.
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 at house A in order to achieve the required demand reduction. At the time the event is triggered, the inside temperature as reported by the thermostat in house A is 72 degrees F. The outside temperature near house A is 96 degrees Fahrenheit. The inside temperature at House 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 House A, is 74 F. Because the air conditioner in house A has been turned off, the temperature inside House 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 house A on previous days on which temperatures have been at or near 96 F, and the temperature in house B, which has risen only to 75 F because the air conditioning in house B continues to operate normally, the server is able to confirm with a high degree of certainty that the air conditioner in house A has indeed been shut off.
In contrast, if the HVAC system at house A has been tampered with, so that a demand reduction signal from the server does not actually result in shutting off the air conditioner in house A, when the server compares the rate of temperature change at house 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 house A as expected, and may not credit house 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 house A's participation in the demand reduction program.
The server then receives 2406 temperature signals from the subscriber's thermostat. At the conclusion of the demand reduction event, the server transmits a signal 2408 to the thermostat permitting the thermostat to signal its attached HVAC system to resume cooling, if the system has been shut off, or to reduce the target temperature to its pre-demand reduction setting, if the target temperature was merely increased. If thermostat 108 is capable of storing scheduling information, these instructions may be transmitted prior to the time they are to be executed and stored locally. After determining the total number of subscribers actually participating in the DR event, the server then calculates the total demand reduction achieved and sends a message 2410 to the electric utility confirming such reduction.
Additional steps may be included in the process. For example, if the subscriber has previously requested that notice be provided when a peak demand reduction event occurs, the server will 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 home 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.
The system installed in a subscriber's home may optionally include additional temperature sensors at different locations within the building. These additional sensors may we 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 building. 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 houses as well.
Because of the lower thermal mass of House B, the air conditioning system in House B has to run longer in order to maintain the same target temperature range, as shown by shaded areas 2614.
Because server 106 logs the temperature readings from inside each house (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 house. 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 building 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, and so on 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 house 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 server 106 is aware of the cycle times in nearby houses, it can determine that, for example, on date X+1 the efficiency of House A is only in the 23rd percentile. The server will be programmed with a series of heuristics, gathered from predictive models and past experience, correlating the drop in efficiency and the time interval over which it has occurred with different possible causes. For example, a 50% drop in efficiency in one day may be correlated with a refrigerant leak, especially if followed by a further drop in efficiency on the following day. A reduction of 10% over three months may be correlated with a clogged filter. Based upon the historical data recorded by the server, the server 106 will be able to alert the homeowner that there is a problem and suggest a possible cause.
Because the system will be able to calculate effective thermal mass, it will be able to determine the cost effectiveness of strategies such as pre-cooling for specific houses under different conditions.
Although the pre-cooling cycle time in a given home may be relatively long, the homeowner may still benefit if the price per kilowatt during the morning pre-cooling phase is lower than the price during the peak load period.
The system 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 structure, 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.
Until the point at which the sun hits the thermostat, the average inside temperature and temperature as read by the thermostat track very closely. But when the direct sunlight hits the thermostat, the thermostat and the surrounding area can heat up, causing the internal temperature as read by the thermostat to diverge significantly from the average temperature for the rest of the house. A conventional thermostat has no way of distinguishing this circumstance from a genuinely hot day, and will both over-cool the rest of the house and waste considerable energy when it cycles the air conditioner in order to reduce the temperature as sensed by the thermostat.
If the air conditioning is turned off, this phenomenon will manifest as a spike in temperature as measured by the thermostat. If the air conditioning is turned on (and has sufficient capacity to respond to the distorted temperature signal caused by the sunlight), this phenomenon will likely manifest as relatively small changes in the temperature as sensed by the thermostat, but significantly increased HVAC usage (as well as excessively lowered temperatures in the rest of the house, but this result may not be directly measured in a single sensor environment).
An embodiment of the system, in contrast, has multiple mechanisms that will allow it to correct for such distortions. First, because an embodiment of the subject system compares the internal readings from House C with the external temperature, it will be obvious that the rise in temperature at 4:00 PM is not correlated with a corresponding change in outside temperature. Second, because the system is also monitoring the readings from the thermostat in nearby House D, which (as shown in
In step 3006, the server retrieves data regarding recent temperature readings as recorded by the thermostat in home X. In step 3008, the server retrieves profile data for home X. Such data may include square footage and number of floors, when the house was built and/or renovated, the extent to which it is insulated, its address, make, model and age of its furnace and air conditioning hardware, and other data.
In step 3010, the server retrieves the current inside temperature reading as transmitted by the thermostat. In step 3012, the server calculates the thermal mass index for the home under those conditions; that is, for example, it calculates the likely rate of change for internal temperature in home X from a starting point of 70 degrees when the outside temperature is 85 degrees at 3:00 PM on August 10th when the wind is blowing at 5 mph from the north and the sky is cloudy. The server accomplishes this by applying a basic algorithm that weighs each of these external variables as well as variables for various characteristics of the home itself (such as size, level of insulation, method of construction, and so on.) and data from other houses and environments.
In step 3106, the server retrieves data regarding current and recent temperature readings as recorded by the thermostat in home X. In step 3108, the server retrieves profile data for home X. Such data may include square footage and number of floors, when the house was built and/or renovated, the extent to which it is insulated, its address, make, model and age of its furnace and air conditioning hardware, and other data. In step 3110, the server retrieves comparative data from other houses that have thermostats that also report to the server.
Such data may include interior temperature readings, outside temperature for those specific locations, duty cycle data for the HVAC systems at those locations, profile data for the structures and HVAC systems in those houses and the calculated thermal mass index for those other houses. In step 3112, the server calculates the current relative efficiency of home X as compared to other homes. Those comparisons will take into account differences in size, location, age, and so on in making those comparisons.
The server will also take into account that comparative efficiency is not absolute, but will vary depending on conditions. For example, a house 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 house 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 will calculate efficiency under varying conditions.
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 homeowner a message 3120 alerting the homeowner 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 a 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 homeowner a message 3124 alerting the homeowner 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 homeowner a message 3128 alerting the homeowner to the possible problem. If the problem does not match the refrigerant leak 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.
In step 3206, the server retrieves data regarding current and recent temperature readings as recorded by the thermostat in home X. In step 3208, the server retrieves profile data for home X. Such data may include square footage and number of floors, when the house was built and/or renovated, the extent to which it is insulated, its address, make, model and age of its furnace and air conditioning hardware, and other data.
In step 3210, the server retrieves comparative data from other houses that have thermostats that also report to the server. Such data may include interior temperature readings, outside temperature for those specific locations, duty cycle data for the HVAC systems at those locations, profile data for the structures and HVAC systems in those houses and the calculated thermal mass index for those other houses.
In step 3212, the server calculates the expected thermostat temperature reading based upon the input data. In step 3214, the server compares the predicted and actual values. If the calculated and actual values are at least roughly equivalent, the server concludes 3216 that there is no thermostat-related anomaly. If the calculated and actual values are not roughly equivalent, the server retrieves additional historical information about past thermostat readings in step 3218.
In step 3220, the server retrieves solar progression data, i.e., information regarding the times at which the sun rises and sets on the days being evaluated at the location of the house being evaluated, and the angle of the sun at that latitude, and so on. In step 3222, the server compares the characteristics of the anomalies over time, to see if, for example, abnormally high readings began at 3:06 on June 5th, 3:09 on June 6th, 3:12 on June 7th, and the solar progression data suggests that at the house being analyzed, that sun would be likely to reach a given place in that house three minutes later on each of those days.
If the thermostat readings do not correlate with the solar progression data, the server concludes 3224 that the sun is not causing the distortion by directly hitting the thermostat.
If the thermostat readings do correlate with solar progression, the server then calculates 3226 the predicted duration of the distortion caused by the sun.
In step 3228, the server calculates the appropriate setpoint information to be used by the thermostat to maintain the desired temperature and correct for the distortion for the expected length of the event. For example, if the uncorrected setpoint during the predicted event is 72 degrees, and the sun is expected to elevate the temperature reading by eight degrees, the server will instruct the thermostat to maintain a setpoint of 80 degrees. In step 3230, the server sends the homeowner a message describing the problem.
One or more embodiments of the invention may be used to implement additional energy savings by implementing small, repeated changes in setpoint. Because energy consumption is directly proportional to setpoint—that is, the further a given setpoint diverges from the balance point (the natural inside temperature assuming no HVAC activity) in a given house 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 at least roughly 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%.
Embodiments of the invention can automatically generate optimized ramped setpoints 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 consumer acceptance, additional parameters may be considered, including: time of day outside weather conditions recent history of manual inputs 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.
In step 3506 the algorithm advances to the next phase from the most recent phase; i.e., if the algorithm is just starting, the phase changes from “0” to “1”; if it has just completed the third phase of a three-phase ramp, the phase will change from “2” to “0”. In step 3508 the application determines if the current phase is “0”. If it is, then in step 3510 the algorithm determines whether current setpoint equals the setpoint in the previous phase. If so, which implies no manual overrides or other setpoint adjustments have occurred during the most recent phase, then in step 3512 the algorithm sets the new setpoint back to the previous phase “0” setpoint. If not, then in step 3514, the algorithm keeps the current temperature setting as setpoint for this new phase. In step 3516, the algorithm logs the resulting new setpoint as the new phase “0” setpoint for use in subsequent phases.
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 house 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 3614, the algorithm determines whether one or more conditions that preclude application of the algorithm, such as extreme outside weather conditions, whether the home is likely to be occupied, and so on. If any of the exclusionary conditions apply, the application skips execution of the ramped setpoint algorithm for the current iteration. If not, the application proceeds to step 3616 in which the application determines whether the setpoint has been altered by manual overrides, thermostat setback schedule changes, or other algorithms as compared to the previous value as stored in database 300. If setpoint has been altered, the application proceeds to step 3620 discussed below.
In step 3618, the program described in
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.
An embodiment of the subject invention may also be used to detect occupancy 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.
The screen shows that a browser 3700 is displayed on computer 104. In one 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 the application running on server 106 that activity has been detected. 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; (b) signal the background application running on computer 104 to trigger a software routine that instantiates a pop-up window 3702 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, and so on. The user can respond by clicking the cursor on “yes” button 3704 or “No” button 3706. Equivalent means of signaling activity may be employed with interactive television programming, gaming systems, and so on.
If the HVAC settings then in effect are intended to apply for an occupied home, then the application terminates for a specified interval. If the HVAC settings then in effect are intended to apply when the home is unoccupied, then in step 3808 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 3816, in which it changes the programmed setpoint for the thermostat to the setting intended for the house when occupied. If the user has previously specified that the application should not make such changes without further user input, then in step 3810 the application transmits a command to computer 104 directing the browser to display a message informing the user that the current setting assumes an unoccupied house and asking the user in step 3812 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 3814 the application will write to database 300 the fact that the users has so elected and terminate. If the user elects to change the setting, then in step 3816 the application transmits the revised setpoint to the thermostat. In step 3814 the application writes the updated setting information to database 300.
For example, upon initiating the service, one or more users may have filled out online questionnaires sharing their age, gender, schedules, viewing preferences, and so on. In step 3908, server 106 compares the received information about user activity to previously stored information retrieved from database 300 about the occupants and their viewing preferences. For example, if computer 104 indicates to server 106 that the computer is being used to watch golf, the server may conclude that an adult male is watching; if computer 104 indicates that it is being used to watch children's programming, server 106 may conclude that a child is watching.
In step 3910 the server transmits a query to the user in order to verify the match, asking, in effect, “Is that you Bob?” In step 3912, based upon the user's response, the application determines whether the correct user has been identified. If the answer is no, then the application proceeds to step 3916. If the answer is yes, then in step 3914 the application retrieves the temperature settings for the identified occupant. In step 3916 the application writes to database 300 the programming information and information regarding matching of users to that programming.
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 106transmits instructions to computer 104 causing it to display a dialog box asking the user whether the user wishes to change HVAC settings.
Additional functionality is also envisioned as part of different embodiments of the invention. For example, information from historic data may be used to predict how long it will take a user to reach home from the current coordinates, and the estimated arrival time may be used to calculate optimal cycling strategies for the HVAC system. 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 come home 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 home, 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 home or other 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.
In an embodiment of the invention, Thermostat/hub 108 may be of modular construction. For example, it may be comprised of two separate components, a first module and a second module. As shown in
A second module 4006 may include a more sophisticated user interface, such as a touch screen. In a preferred embodiment, the user interface of the second module is not hardwired to specific uses, but can be configured through software to a broad range of uses, so that the second module may be used to interact with a broad range of applications other than that of controlling an HVAC system. Thus if a security camera is connected to the system, the second module can display still images and/or video captured by the camera, and may provide software-configured controls that would allow a user to select from multiple cameras, select specific images, configure settings, and so on. If wirelessly controllable lighting is connected to the system, the second module can be used to adjust aspects of lighting such as timing, brightness and, with some light sources, color temperature. If a home security system is connected to the system, the second module can be used to arm and disarm the system, communicate with a central office, check the status of various sensors, and so on. In a preferred embodiment these and many other devices and systems can be connected to and controlled with the second module. Because in properly wired modern homes, 24-volt AC power is available from the normal thermostat wiring, it will be possible to supply sufficient power in many homes from the wall wiring through module 4002 to module 4006 to charge and provide ongoing power to devices like tablets and smart phones. Charging and power may be provided via a conventional physical connector, such as USB or Apple's Lightning connector, or it could be provided via non-contact methods such as inductive charging.
As shown in
Second module 4006 could also include additional sensors such as smoke detectors, carbon monoxide sensors, or sensors intended to detect other chemicals. Any of the elements disclosed as being included in the second module 4006 may also be included in the first module 4002.
In an embodiment, the first module can be configured so that user devices such as tablets and smart phones can be attached to the wall-mounted first module. For example, the user devices may be securely attached physically and electrically to the wall-mounted first module.
In an embodiment, the second module is a specific device designed to work with the first module. In another embodiment, the second module is a general purpose device. Such devices may include tablet computers or smart phones such as the iPad and iPhone from Apple, Amazon Kindle, Android devices, and so on. The first module may be configured so that it includes both a means to physically mount one of these devices to the first module (and thus to the wall), as well as one or more appropriate electrical connectors permitting the second module to receive power and access the circuits within the first module.
With respect to the second module 4006 being a general purpose device, the means for connecting second module 4006 to first module 4002 may include a dedicated bracket dimensioned to securely attach a specific device, such as an Apple iPod Mini, to the first module. Different brackets can be provided for different tablets.
In the absence of a modular construction, a first module may contain all functions of the second module described above. The first module or second module may have zero or more built-in sensors or smart devices, and may optionally be augmented by zero or more modular smart devices that are designed to be attached by an end user (e.g., Moto Mods for smartphones).
Thermostat/hub 108 may be connected to one or more cameras 4206. Such cameras can be motion activated, or can continuously capture and transmit images (e.g., over one or more networks, such as the internet, a local area network, and so on). Images captured by camera 4206 may be viewed on the thermostat/hub 108, and/or may be transmitted to other devices, stored locally or uploaded to a cloud-based server. Thermostat/hub 108 may be connected to one or more smoke detectors, carbon monoxide detectors, heat sensors or similar emergency-related sensors 4208. Connectivity to thermostat/hub 108 may permit advanced functions such as silencing false alarms, viewing information about the specific sensor triggering the alarm from the user interface of the thermostat/hub, viewing maintenance information such as battery levels, and so on. Similar functionality is added by connecting with additional sensors such as water sensor 4210 and gas sensor 4212. These sensors can, for example, enable detection of a flooded basement, or a natural gas leak, and enable a user to view information about those events either from the thermostat/hub, or from a remote location.
Thermostat/hub 108 may be connected to one or more security-related devices, which can include a siren or other audible device 4214 used to signal a problem; door/window sensors 4216, which can signal the system of an open door or an open or broken window; and electronic door lock 4218, which may be used to enable remote locking and unlocking of a door as well as reporting of the status of that door.
It should be noted that where wireless connections are used to connect the thermostat/hub to these devices, it may not always be possible or required to directly connect the thermostat/hub to those devices. It is also possible to use one or more devices as a repeater or network extender. In this topology, thermostat/hub 108 connects directly to one or more repeater/extenders 4228. Any or all of the nodes discussed herein may be connected to the thermostat/hub 108 through such repeater/extenders instead.
In addition to connecting to multiple devices within a given home or other structure, thermostat/hub 108 can be connected to devices and servers via the Internet. This may be accomplished by connecting thermostat/hub 108 (via a wireless connection such as 802.11, or a wired connection such as Ethernet) to router 4230, which connects in turn to a wide area network such as the Internet 102. A wide variety of other devices can then connect to thermostat/hub 108 via the Internet, including computer 104 and mobile device 105.
It should also be noted that functions described as being provided by separate modules can be provided by modules that combine several functions.
Because the location of the thermostat in many homes is in a central hallway or other place that may be frequently passed by multiple family members, the subject invention enables useful applications not generally applicable to either traditional thermostats or tablet computers. For example, the rich user interface of the second module may be used to display family schedules, to-do lists, shopping lists, and other information that family members wish to share. By making these lists and documents live and editable from multiple devices, the shopping list as shown on the thermostat/hub can be easily viewed by a family member on the way out the door. If that family member buys one or more of the items on the list, he or she can “cross them off the list” on his or her mobile device, and the list shown on the thermostat/hub can update to reflect the activity.
These and other applications for the system may be enabled by an open software architecture that permits applications from 3rd parties to run on the system. An open software architecture can include the option to extend functionality with applications provided by an App Store. An App Store allows an individual to browse and install applications to the thermostat/hub device. Applications in an App Store can be supplied by any number of 3rd parties. The thermostat/hub may take advantage of established App Stores such as Google Play or iTunes, or as an alternative a curated App Store specific to the thermostat/hub device may be used. Applications from different suppliers in the store can be installed on the same thermostat/hub, and the customer may choose which applications they wish to run. For example, Android devices typically offer an Applications drawer to launch any installed applications. Other mechanisms to improve convenience to operate devices managed by the thermostat/hub, such as configurable shortcuts on a Home screen, may also be provided.
In another embodiment, many or all of the elements normally found in a traditional thermostat may be relocated to a module located generally proximate to the air handler for the HVAC system, which is frequently placed outside the primary conditioned space, such as in a garage, attic or basement. These elements, such as relays and basic HVAC system operating logic, can be located in a first module and can connect with wiring to the HVAC system. If the first module is located outside the primary conditioned space, it will require only a very basic user interface, such as a small number of LEDs to indicate power status, networking status, and so on. Locating the first module outside the conditioned space means that at least one temperature sensor must be present in a separate module that is located in an appropriate place within the conditioned space.
In some of these embodiments, a second module may consist of a dedicated device that can be located in the space normally allocated to a thermostat within the conditioned space, or it may located in a different spot, or it may be a battery-powered device that does not require attachment to the wall and is not permanently located in a specific location. (However, many of the diagnostic functions discussed elsewhere in this document will be less effective if the measurement location is variable and/or indeterminate.)
In one such embodiment, the second module is attached to a wall, and offers a minimal user interface. In this embodiment, the primary functions of the second module are (i) to mount environmental sensors (such as temperature sensors, humidity sensors), and possibly other sensors like occupancy sensors; and (ii) communications systems. The communications systems will permit the second module to communicate with the first module.
This embodiment may also include a third module, which may be a dedicated user interface, or may be a general purpose device such as a smart phone or a tablet computer. In both cases, the third module can communicate with the second module with one or more of a variety of wireless protocols, including but not limited to WiFi (802.11), ZigBee or Z-Wave (802.14), Bluetooth, and Bluetooth low energy.
An example of this embodiment is illustrated in
Another example of a similar embodiment is illustrated in
Inclusion of one or more loudspeakers and one or more microphones in one or more of the modules will permit the thermostat/hub to be used to interact in numerous ways with the larger ecosystem of devices connect to the hub. For example, if the thermostat/hub is connected to a device intended to permit home occupants to see and hear visitors who ring the doorbell, the thermostat/hub can function as a node of an intercom, with the device comprising one or more of a microphone, loudspeaker and/or a camera, mounted in or near the door as another node. If the system is equipped with a camera at the door node, the feed from the camera can be viewed on the screen of the thermostat module if it is equipped with an appropriate display screen. If the door node also includes a loudspeaker, the occupant can also speak into the microphone(s) located in the thermostat/hub module and be heard by the visitor.
Because the thermostat/hub can also be connected to the Internet, the thermostat/hub can also be used to permit people within a structure to interact with other people using a smart phone or other device regardless of their location. This capability may be of limited value to consumers who are comfortable with the use of smart phones. However, some people have not embraced this technology, such as some elderly people. A thermostat/hub equipped with a camera, a microphone and a speaker could, for example, be used to permit a remote caregiver to “call” an elderly person. If the elderly person is doing well, he or she can stand in front of the thermostat/hub and have a video chat with a family member or caregiver. If the person being checked on is having a problem that prevents him or her from coming to the thermostat/hub, the caregiver or relative can initiate other responses, such as sending paramedics, coming to the home themselves, and so on.
The thermostat/hub can also be connected to a variety of devices intended for personal health-related monitoring. Thus the thermostat/hub can be used as part of systems used to monitor data from devices such as heart rate monitors, motion sensors and other devices used to suggest or indicate that a person may have suffered an adverse health event. Other sensors that can be connected to a thermostat/hub may include pressure sensors used to detect the presence and/or motion of a person on a bed, couch or other surface; thermal sensors used to detect presence or abnormal health conditions; personal emergency response systems, so that a person who has fallen or otherwise been injured or ill can summon help by pressing a button on a worn device.
In addition to or instead of a built-in loudspeaker, the thermostat/hub can be connected via Bluetooth or another wireless protocol to one or more devices with additional or higher-quality audio amplifiers and speakers. For example, the thermostat/hub may be connected to a television or home theater system. Where such auxiliary audio and/or video systems are connected, the system may be set to enable interaction through multiple devices or only a specified device.
Because there is a virtually infinite range of potential configurations for the thermostat/hub depending on factors including what peripheral devices and systems it is connected with, the preferences of users, and so on., effectively managing the settings used to operate the thermostat/hub will be imperative. And because the software used to operate those many devices is likely to evolve over time, potentially requiring frequent updates to configurations and settings on the thermostat/hub, the thermostat/hub may communicate with a cloud-based server 106, for example communicate at greater than a threshold frequency. These communications will enable a variety of tasks. Those tasks may include: updating firmware and settings on the thermostat/hub; providing a back-up copy of information normally stored on the thermostat/hub, including usage patterns, sensor data, configuration data, and so on.; storage of recordings made by cameras, microphones, and so on; enabling of processor-intensive functions such as speech recognition and image processing; and other functions.
Connection to the cloud can also enable the thermostat/hub to connect to other cloud-based services, including but not limited to music services such as Spotify, Pandora, and so on, and including voice-enabled commerce-based services, such as those provided by Amazon.
Connection to multiple devices (locally and/or via the Internet) permits the thermostat/hub to provide numerous additional functions. The thermostat/hub may provide an application that collects one or more shopping lists aggregated from multiple individual shopping lists created by different people. Thus for example, one member of a household may notice that the family is out of milk and toothpaste and add those items to her own shopping list on her smart phone; another family member may add laundry detergent and paper towels to his own list on his desktop computer. An integrated shopping list application running in the cloud can be used to combine those individual shopping list into a single integrated list.
That list can be displayed on the thermostat/hub or other device. The application can enable on-line ordering of those items, or it can transmit the integrated shopping list to one or more individual client devices so that a user can consult the full list while shopping in a physical store.
Similar functionality may be used to share family bulletin boards and other dynamic information that benefits from coordination between multiple users with multiple inputs.
In an embodiment, all functions that can be displayed (and heard) at the thermostat/hub can be accessed from other devices, including smart phones, tablets, computers, and so on. An application running on those devices can be used to enable those devices to function as user interfaces for all functions enabled at the thermostat/hub, provided that those devices have been given appropriate permission to connect, and are connected to the thermostat/hub via a network.
If a user owns or rents multiple homes, an embodiment will permit a single user of a computer or mobile device to access multiple premise-specific systems from a single account on the user's computer or mobile device. A similar approach may be used in the case of a landlord or property manager, so that a large number of premises can be managed from a single interface. Similarly, if a user owns or rents multiple homes, the user interface accessible in one home may be used to access and change settings and communicate with systems located in the other home.
As described above, thermostat 4702 can control smart devices 4704 or cause control of smart devices 4704. With respect to controlling smart devices 4704, thermostat 4702 can control the smart devices 4704 via a local wired or wireless connection. For example, thermostat 4702 can provide information to the smart devices 4704 over a local area network and/or wide area network, such as via one or more routers positioned in the structure. As another example, thermostat 4702 can provide information directly to smart devices 4704 via a Bluetooth or Wi-Fi network created by the thermostat 4702. Optionally, with respect to the direct communications, each smart device may route information from the thermostat 4702 to an intended smart device. In this way, if an intended smart device is too far from the thermostat 4702 to receive communications (e.g., the smart device is out of range), one or more intermediary smart devices may route communications to the intended smart device. The thermostat 4702 and smart devices 4704 may utilize one or more protocols to communicate, such that the thermostat 4702 can provide instructions to a smart device and the smart device can respond. Optionally, the thermostat 4704 can utilize different protocols for different smart devices 4704. For example, each smart device may be designed to function over a particular protocol, such as a particular set of application programing interface (API) calls and/or particular frequency ranges for wireless communications. When each smart device is included in the structure, the thermostat 4702 can optionally attempt to communicate via different protocols to the smart device until the smart device responds successfully. In this way, the thermostat 4702 can control smart devices 4702 and act as a hub within the structure.
Additionally, one or more smart devices 4704 can be incorporated into the thermostat 4702. For example, thermostat 4702 can incorporate a camera that is used for surveillance. Such a camera could be built into a monolithic thermostat, or could be a modular option that is attached to the thermostat (e.g., Moto Mod for smartphones). A thermostat may have a combination of built-in and modular smart devices. For example, a user may select particular modular smart devices, and attach and/or mount these modular smart devices to the thermostat. Optionally a modular smart device may be in wireless communication with the thermostat. An example thermostat 4702 is illustrated in
The thermostat 5100, 4702, may utilize a C-wire (e.g., a common wire that carries 24V AC power) to power accessories incorporated in the thermostat (e.g., camera 5108, speaker, microphone, and so on), or modularly connected to the thermostat (e.g., as described in
Optionally, one or more smart devices 4704 may include thermostats, such as an additional thermostat 4702. For example, thermostat 4702 can display information received from an additional smart thermostat, be controlled by the additional smart thermostat, and so on. As an example, a first thermostat may receive temperature control instructions second thermostat (e.g., the second thermostat can be placed elsewhere). Additionally, a first thermostat may receive routed video calls from a second thermostat. For example, a user can utilize the second thermostat to place a video call, which can be received on the first thermostat. As another example, a user can initiate a video call with an outside user via the first thermostat, and transfer the video call for presentation on the second thermostat or include a user in front of the second thermostat in the video call. \
With respect to the thermostat 4702 causing control of smart devices 4704, the thermostat 4702 can provide information, such as instructions, to smart devices 4704 (e.g., cloud-enabled smart devices) the structure via an outside system. For example to control an example smart device (e.g., a smart camera), the thermostat 4702 can provide information to a smart device cloud system 4708 associated with the smart device (e.g., over the internet). The smart device cloud system 4708, for example a system of one or more computers, can then provide instructions to the example smart device within the structure (e.g., over the internet). Optionally, thermostat 4702 can initially provide information to an associated cloud system, which can then provide information to the smart device cloud system. For example, the thermostat 4702 may be associated with an intelligent personal assistant, such as ALEXA. In this example, a user can interact with the intelligent personal assistant (e.g., provide verbal instructions) to control a particular smart device. For example, the user can provide verbal commands or speech to the thermostat (e.g., via a microphone). The thermostat can relay the interactions (e.g., verbal instructions) to the associated cloud system for processing, which can parse the verbal instructions, for example utilizing natural language processing, to determine that the user is to control the particular smart device. The associated cloud system can provide instructions to the smart device cloud system 4708, which can then provide control instructions to the particular smart device within the structure. In this way, the thermostat 4702 may control cloud-enabled smart devices.
As illustrated in
As described above, with respect to at least
The applications can further utilize information obtained from sensors 4706 monitoring physical characteristics associated with the structure, occurrences of events, and so on, to perform functionality. For example, one or more sensors may monitor temperature within the structure, and based on information indicating a thermal model for the structure, the thermostat 4702 can determine whether a door or window is open. That is, the thermostat can determine that the structure is losing, or gaining, heat at a rate inconsistent with the thermal model of the structure if the windows or doors were closed. An application executing on the thermostat can then provide a notification to the user regarding the opening. For example, the thermostat 4702 can notify the user according to a location associated with the user, such as whether the user in the structure. Location can he determined according to a calendar of the user (e.g., whether the user has an appointment), a location of the user device 4710 (e.g., the thermostat 4702 can request location from the user device 4710, or indicate to an application on the user device 4710 of the open door/window and the user device application can determine whether to notify the user based on the device's 4710 location), and so on. Additionally, based on a door or window being open, the thermostat 4710 can activate on security related smart devices. For example, if the user is not within the structure and did not activate an alarm, camera system, movement detection devices, and so on, the thermostat 4702 can activate one or more of these to determine whether the structure has been improperly accessed. Examples of determining thermal models are described in more detail in U.S. Patent Pub. 2013/0338837, which is hereby incorporated by references in its entirety for all purposes.
As another example of utilizing sensors 4706, an example sensor may detect presence of persons within the structure. For instance, the example sensor may obtain video, or images, and determine whether a person is discernible. Similarly, the example sensor may utilize distance sensors, sensors that detect movement, and so on, to determine presence of a person. Optionally, an application executing on the thermostat 4702 can determine whether a door or window is open, as described above, and then monitor for presence of persons within the structure. Based on the user being located away from the structure, the application can notify the user, activate an alarm, provide information to a security related device to perform actions, and so on.
With respect to the example of
The thermostat 4702 includes an application engine 4806, which can execute applications obtained from an electronic application store. As described above the thermostat 4702 may access application stores associated with mobile devices, for example the Google Play store or iTunes/iPhone App store. Additionally, the thermostat 4702 can connect to an application store associated with the thermostat 4702, and applications specific to the thermostat 4702 can be obtained. A user can utilize a user device to connect to a particular application store, select one or more applications and cause the downloading of the applications to the thermostat 4702. For example, the applications can be ‘pushed’ to the thermostat 4702, or the thermostat 4702 can obtain identifications of the applications (e.g., the thermostat 4702 can receive a manifest file) and obtain the applications. In this way, a user of the thermostat 4702 can customize functionality to be performed by the thermostat 4702. Furthermore, the thermostat 4702 may include a set of applications, or general software associated with particular functionality, without accessing an application store, such that the thermostat 4702 can perform some, or all, of the functionality described herein.
The thermostat 4702 further includes a presentation engine 4708, which can present information on a display of the thermostat (e.g., display 4110 described above) or cause presentation of information on other devices (e.g., user device 4710, smart devices, and so on). The presentation engine 4708 can further customize presented user interfaces according to received information from smart devices 4802A-H and/or sensors 4804. For example, the thermostat 4702 can normally present controls associated with adjusting temperature. If the thermostat 4702 obtains information indicating the occurrence of an upcoming calendar appointment of a user, the thermostat 4702 can update a display to present information indicating the appointment. The thermostat 4702 can further update the display upon determining presence of a user, or the user associated with the calendar appointment (e.g., based on detection of a user device of the user, or based on facial recognition as performed by a smart device, sensors, or thermostat using a camera), is near the thermostat 4702.
Example use cases of the smart devices 4802A-H follow, however it should be understood these examples are merely illustrative, and the thermostat 4702 can perform additional functionality, communicate with additional smart devices/sensors, and so on. The camera smart device 4802A can provide video or images for presentation on the thermostat 4702. For example, since the thermostat 4702 can generally be positioned in a hallway of a structure, or near a front door, the camera 4802A can be positioned to provide a view of the outside of the front door, such that a user can monitor the view in the hallway. The camera can detect 4802A presence of a person outside the front door, or optionally a security related device 4802F or doorbell 4802D can detect the person. The thermostat 4702 can then present video of the front door, and optionally enable a two-way communication with the person at the front door. The thermostat 4702 can further determine whether a user within the structure is proximate to the thermostat 4702, for example based on distance measuring sensors, and can present video upon a positive determination. Upon a negative determination, the thermostat 4702 can route video obtained from the camera 4802A to a user device of the user.
Furthermore, the thermostat 4702 can control lights 4802C within a structure. As an example, the thermostat 4702 can present user interfaces associated with lighting control, and a user of the thermostat 4702 can adjust the lights 4802C while proximate to the thermostat 4702. Since, as described above, the thermostat 4702 can function as a smart home hub, the thermostat 4702 can further route instructions from a user device of the user to the lights 4802C. For instance, the user device can execute an application associated with the lights 4802C, and utilizing application programming interface (API) calls associated with the thermostat 4702 and/or lights 4802C, the thermostat 4802C can provide control instructions to the lights 4802C. Optionally, the thermostat 4702 can adjust color temperature of the lights as a day progresses into night (e.g., the lights can become progressively redder), for example to increase comfort and/or convenience for the user. Similarly, the thermostat 4702 can adjust intensity of light based on the user being present. Optionally, the thermostat 4702 can adjust lights automatically based on information indicating that the user is not within the structure, for example to conserve energy. As an example, the thermostat 4702 can adjust intensities of lights (e.g., adjust an intensity from a light being high to dim or off, and variations within). As another example, the thermostat 4702 can cause different lights to turn on/off according to a periodic or random schedule. In this way, the thermostat 4702 can also make the structure appear to be occupied, and thus reduce a risk of the structure being improperly accessed.
Optionally, the thermostat 4702 can adjust the lights based on information indicating that a person is at a front door and/or based on information obtained from security devices 4802F. For example, the thermostat 4702 can light a hallway leading to the front door, or if the thermostat 4702 has information indicating a location of a user within the structure, light a path from the user's location to the front door. Similarly, the thermostat 4702 can adjust a light outside of the structure to indicate that the user will be answering the front door. For example, the color can be a calming blue, or blue color modulated in time, if the user is going to answer the front door (e.g., based on the user's movements, or based on the user indicating he/she will answer on the thermostat 4702 or an app on a user device). Alternatively, the color may be a red or orange if the user is not going to answer. Furthermore, if the security devices 4802F detects an improper entry into the structure, the thermostat 4802F can cause the lights 4802C to strobe or turn a particular color to alert neighbors. Similarly, the security device 4802F can raise an alarm, alert the user (e.g., generate a notification to be provided to a user device of the user), alert the authorities, and so on.
A cleaning robot 4802E may be activated by the thermostat 4702 upon determining that a user has left the structure. For example, a user device of the user can automatically provide information to the thermostat 4702 that the user is greater than a threshold distance away from the structure. The thermostat 4702 can then instruct the cleaning robot 4802E to being cleaning. Additionally, the thermostat 4702 can instruct a coffee device 4802G to begin making coffee. For example, at a particular time each morning the thermostat 4702 can instruct the coffee device 4802G to initiate, or the thermostat 4702 can route instructions received from a user device of the user. A smart plug 480211 may be similarly activated by the thermostat 4702 according to conditions identified by the user or by an application executing on the thermostat 4702.
As described above, the thermostat 4702 can utilize information obtained from sensors 4804 in combination with the smart devices 4802A-H. For example, and with respect to the smart plug 4802H, the thermostat 4702 can monitor temperature information of the structure. After a certain time, such as a time when a user if sleeping in a room, the thermostat 4702 can determine that the temperature of the structure can be reduced to converse energy. The thermostat 4702, for example an application executing on the thermostat 4702, may determine that more energy can be conserved if central heating is allowed to reduce even further, but a space heater in the user's room is allowed to turn on. The smart plug 4802H can then be automatically activated to heat the user's room, while the remainder of the structure is allowed to cool further. The thermostat 4702 can then adjust the temperature upwards as the time gets closer to a time at which the user generally wakes up.
The above examples are non-exhaustive, and the functionality afforded by the thermostat 4702 can be modified according to the addition or subtraction of smart devices, sensors, applications, and so on.
An example use case of performing actions based on presence of a person at a front door follows. As illustrated, a person 4904 is approaching the front door of the structure 4902. Optionally, more than one person may approach the front door of the structure 4902. A smart device (e.g., security related smart device, doorbell, and so on) can then trigger information to the user's user device or the thermostat 4702, which can then route the triggered information to the user's user device. Similarly, a sensor may detect presence of the person 4904, and the thermostat 4702 can obtain information from the sensor, and can then optionally route the information to the user's user device.
Based on the presence of the person 4904, the thermostat 4702 can update presentation of a display and/or control smart devices in response. For example, the thermostat 4702 can present information on the display of the thermostat 4702 regarding the presence of the person (e.g., ‘Person at Door’). As described above, the thermostat 4702 can vary the presentation according to presence of the user. If the user is at home, the thermostat 4702 can present information indicating that the person 4904 is at the door, and if not, the thermostat 4702 can optionally provide a notification to the user. If the front door area of the structure 4902 includes a display, or a speaker, the thermostat 4702 can optionally route video or audio of the user to the display or speaker. For example, if the display or speaker are only accessible via local direct connections, as described above in
The thermostat controls temperature of a structure according to temperature information (block 5002). As described above, the thermostat can obtain information indicating temperature within the structure, for example from temperature sensors, and can adjust the temperature accordingly.
The thermostat determines presence of one or more users inside the structure based on obtained sensor information (block 5004). As described above, the thermostat can be in communication with smart devices and/or sensors. An example smart device may include a camera, and the camera can provide information o the thermostat indicating presence of a user. Similarly, an example smart device may include a microphone, and the smart device can provide information indicating presence. The thermostat can further utilize information obtained from sensors, such as distance sensors, movement sensors, microphones, location sensors (e.g., global navigation satellite system sensors (GNSS) in a user device of a user, from which location information can be obtained and provided by the user device). Internet activity may further indicate presence, such as whether utilized bandwidth has increased. Electrical activity can further indicate presence, such as a sudden increase or usage in electricity associated with the user. Optionally, the thermostat can obtain information indicating the electrical activity from a home energy monitor.
The thermostat dynamically controls smart devices based on presence of the user (block 5006). As described above, with respect to
Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code modules executed by one or more computer systems or computer processors comprising computer hardware. The code modules (or “engines”) may be stored on any type of non-transitory computer-readable medium or computer storage device, such as hard drives, solid state memory, optical disc, and/or the like. The systems and modules may also be transmitted as generated data signals (for example, as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums, and may take a variety of forms (for example, as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). The processes and algorithms may be implemented partially or wholly in application-specific circuitry. The results of the disclosed processes and process steps may be stored, persistently or otherwise, in any type of non-transitory computer storage such as, for example, volatile or non-volatile storage.
In general, the terms “engine” and “module”, as used herein, refer to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, Lua, C or C++. A software module may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves, and/or may be invoked in response to detected events or interrupts. Software modules configured for execution on computing devices may be provided on one or more computer readable media, such as a compact discs, digital video discs, flash drives, or any other tangible media. Such software code may be stored, partially or fully, on a memory device of the executing computing device. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware modules may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. The modules described herein are preferably implemented as software modules, but may be represented in hardware or firmware. Generally, the modules described herein refer to logical modules that may be combined with other modules or divided into sub-modules despite their physical organization or storage. Electronic Data Sources can include databases, volatile/non-volatile memory, and any memory system or subsystem that maintains information.
The various features and processes described above may be used independently of one another, or may be combined in various ways. All possible combinations and subcombinations are intended to fall within the scope of this disclosure. In addition, certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate. For example, described blocks or states may be performed in an order other than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. The example blocks or states may be performed in serial, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the disclosed example embodiments.
Conditional language used herein, such as, among others, “can,” “could,” “might,” “may,” “for example,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list. Conjunctive language such as the phrase “at least one of X, Y and Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to convey that an item, term, etc. may be either X, Y or Z. Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y and at least one of Z to each be present.
The term “a” as used herein should be given an inclusive rather than exclusive interpretation. For example, unless specifically noted, the term “a” should not be understood to mean “exactly one” or “one and only one”; instead, the term “a” means “one or more” or “at least one,” whether used in the claims or elsewhere in the specification and regardless of uses of quantifiers such as “at least one,” “one or more,” or “a plurality” elsewhere in the claims or specification.
The term “comprising” as used herein should be given an inclusive rather than exclusive interpretation. For example, a general purpose computer comprising one or more processors should not be interpreted as excluding other computer components, and may possibly include such components as memory, input/output devices, and/or network interfaces, among others.
While certain example embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the disclosure. Thus, nothing in the foregoing description is intended to imply that any particular element, feature, characteristic, step, module, or block is necessary or indispensable. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions disclosed herein. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of certain of the inventions disclosed herein.
Any process descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those skilled in the art.
It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure. The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the invention can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the invention with which that terminology is associated.
| Number | Date | Country | |
|---|---|---|---|
| 62399281 | Sep 2016 | US |
