Patent Description:
The use of wireless communication between devices is common today and is growing at a rapid pace. For example, many building control systems, as well as other system, use wireless communication to pass information and/or commands between devices of the system. For example, in building control systems, such as Heating, Ventilation and/or Air Conditioning (HVAC) systems, security systems, fire systems, lighting systems, and the like, building control devices (e.g. sensors, valves, actuators, etc.) often include wireless communication modules that support wireless communication with a central building controller or the like. This may eliminate the need to run wires between each of the devices and the central controller. With the advent of the Internet of Things (IoT), many standard appliances, as well as other devices, now incorporate wireless communication modules that support communication over a network.

In some cases, some of these wireless devices are battery powered. To achieve acceptable battery life, such battery powered devices often spend a majority of their life time in a low power state. At strictly controlled times (e.g. every <NUM> minutes), the battery powered devices may wake up to wirelessly receive messages from another device and/or wirelessly send messages to other devices in a tightly synchronized manner. After processing the received messages, the battery powered devices typically return to the low power state in order to conserve battery power.

<CIT>, titled "Injecting active periods into scheduled inactive periods", <CIT>, titled "Facilitating Radio Frequency Communications Among Environmental Control System Components", and <CIT>, titled "Flexible Functionality Partitioning Within Intelligent-Thermostat-Controlled HVAC Systems", may be useful in understanding the invention.

The amount of time that the battery powered devices remains awake, as well as the frequency of the wake periods, directly affects the battery life of the battery powered devices. Thus, to increase the battery life of the battery powered devices, it is desirable to reduce the amount of time that the battery powered devices remains awake during each wake period, and to increase the time the battery powered devices remain in the low power state between the synchronized wake periods. However, increasing the time that the battery powered devices remain in the low power state between the wake periods increases typically decreases the responsiveness of the system, which can be undesirable particularly when a user is interacting with the system. What would be desirable is a system that maintains or even extends the battery life of such battery powered wireless devices while increasing the apparent responsiveness of the system.

The present disclosure generally relates to battery powered wireless devices, and more specifically to systems and methods for maintaining or even extends the battery life of such battery powered wireless devices while increasing the apparent responsiveness of the system. Generally, the battery powered wireless devices may wake up to listen for wireless messages more frequently during those periods in a day when a user is more likely to interact with the system, and may wake up to listen for wireless messages less frequently during those periods in a day when a user not likely to interact with the system. In some cases, the periods when a user is most likely to interact with the system and/or not likely to interact with the system may be learned based on prior user interactions.

According to the present invention there is provided a method for communication between a first device and second device of a building control system, a battery powered wireless device and a building control of a building control system as defined in the accompanying claims.

In one example, a method for communicating between a first device and a second device of a building control system includes wirelessly communicating between the first device and the second device during scheduled communication times, wherein the second device is placed in a listening state during the scheduled communication times, wherein the scheduled communication times are based at least in part on a pattern of user interactions times and wherein the frequency of the communication times are based at least in part on the pattern of user interaction times. Placing the second device in a listening state during the scheduled communication times. Placing the second device in a non-listening state between at least some of the scheduled communication times. The method further includes receiving a plurality of user inputs each at a user interaction time, wherein each of the plurality of user inputs cause a corresponding communication between the first device and the second device. The method further includes identifying one or more active user input periods of a day and one or more inactive user input periods of the day to determine the pattern of user interaction times. The identifying of the one or more active user input periods and the one or more inactive user input period to determine the pattern of user interaction times comprises clustering the user interaction times into a plurality of clusters, wherein each cluster corresponds to a corresponding cluster period; identifying each of the plurality of cluster periods as an active user input period; and identifying each of the times between the plurality of cluster periods as an inactive user input period. The second device may be maintained in the listening state more during active periods than during inactive periods. While using a building control system as an example, it is contemplated that such a method may be applied to any suitable system.

Alternatively, or in addition, the second device may be battery powered and the first device may be line powered.

Alternatively, or in addition, the second device may be part of a radiator valve and the first device may comprise a thermostat.

Alternatively, or in addition, the first device may be a master device and the second device may be a slave device.

Alternatively, or in addition, the first device may send, during a scheduled communication time, a message that notifies the second device of a next scheduled communication time, wherein the next scheduled communication time is scheduled to be sooner during active periods than during inactive periods.

Alternatively, or in addition, the one or more active periods and the one or more inactive periods may be identified over time by learning one or more patterns in the user interaction times.

In some cases, the method may further include maintaining a counter and a set point for each of a plurality of time periods for each of a plurality of days of a week, and initializing each of the counters to an initialization value. During the course of the week as time sequentially passes each of the plurality of time periods, the corresponding counter may decrement. The method may further include receiving a user input that specifies a set point at a user interaction time, identifying the time period that corresponds to the user interaction time, determine if the specified set point is different from the set point of the corresponding time period, and if so, setting the counter that corresponds to the corresponding time period to the initialization value, and identifying those time periods of the plurality of time periods that have higher counter values as active time periods and identifying those time periods that have lower counter values as inactive time periods.

The method further includes clustering the user interaction times into a plurality of clusters, wherein each cluster may correspond to a corresponding cluster period, identifying each of the plurality of cluster periods as an active period, and identifying each of the times between the pluralities of cluster periods as an inactive period.

In another aspect, a battery powered wireless device of a building control system includes: a battery, an antenna for receiving wireless communications, and a controller powered by the battery and operatively coupled to the antenna. The battery powered wireless device may further include a sensor operatively coupled to the controller. The controller is configured to wirelessly receive messages during scheduled communication times, wherein the controller enters a listening state during the scheduled communication times and enters a non-listening state between at least some of the scheduled communication times. The controller may further be configured to wirelessly communicate a value sensed by the sensor to the building control system during one or more of the scheduled communication times. The scheduled communication times are based at least in part on a pattern of user interactions with the building control system. The frequency of the scheduled communication times is based at least in part on the pattern of user interactions with the building control system. Each user interaction of the pattern of user interactions is associated with a respective user interaction time. To determine the pattern of user interactions by identifying one or more active user input periods of a day and one or more inactive user input periods of the day, the battery powered wireless device is configured to: cluster the user interaction times into a plurality of clusters, wherein each cluster corresponds to a corresponding cluster period; identify each of the plurality of cluster periods as an active user input period; and identify each of the times between the plurality of cluster periods as an inactive user input period.

Alternatively, or in addition, the scheduled communication times may be based at least in part on an occupancy schedule programmed into the building control system.

Alternatively, or in addition, the scheduled communication times may be based at least in part of a geo-fence crossing event detected by the building control system.

Alternatively, or in addition, the controller may be configured to store a set point and may use that set point to control a radiator.

Alternatively, or in addition, the scheduled communication times may be communicated to the controller via the antenna.

In another aspect, a building controller of a building control system includes: an antenna, and a controller operatively coupled to the antenna,. The controller is configured to wirelessly send messages to a remote building control device during future scheduled communication times, and the future scheduled communication times are based at least in part on a pattern of previous user interactions with the building control system, wherein the frequency of the future scheduled communication times is based at least in part on the pattern of previous user interactions with the building control system. Each previous user interaction of the pattern of previous user interactions is associated with a respective user interaction time. At least some of the previous user interactions may be received via the user interface. To determine the pattern of previous user interactions by identifying one or more active user input periods of a day and one or more inactive user input periods of the day, the building controller is configured to cluster the user interaction times into a plurality of clusters, wherein each cluster may correspond to a corresponding cluster period, identify each of the plurality of cluster periods as an active user input period, and identify each of the times between the pluralities of cluster periods as an inactive user input period.

Alternatively, or in addition, at least some of the previous user interactions may be communicated to the controller from a remote location.

The preceding summary is provided to facilitate an understanding of some of the innovative features unique to the present disclosure and is not intended to be a full description. A full appreciation of the disclosure can be gained by taking the entire specification, claims, figures, and abstract as a whole.

The disclosure may be more completely understood in consideration of the following description of various embodiments in connection with the accompanying figures, in which:.

While the disclosure is amenable various modifications and alternative forms, specifics thereof have been shown by way of example in the drawing and will be described in detail. It should be understood, however, that the intention is not to limit aspects of the disclosure to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure.

The following description should be read with reference to the figures. The description and figures are meant to be illustrative in nature. While a building control system is used as an example, it is contemplated that the present disclosure may be applied to any suitable system. In some cases, the disclosure may be applied to wireless building controllers such as wireless thermostats, wireless zone controllers, wireless equipment interface modules, wireless sensors such as wireless temperature, humidity and other sensors, wireless security system controllers, wireless building control actuators such as wireless damper and valve actuators, and/or any other suitable wireless building control device, as desired. These are just examples.

<FIG> is a schematic view of an illustrative building control system <NUM> having a central controller <NUM> in wireless communication with one or more building components servicing a building. The building control system <NUM>, as described herein according to the various illustrative embodiments, may be used to control environmental conditions in buildings such as, single family dwellings, multi-tenant buildings, retail stores, commercial offices, hospitals, restaurants, and/or any other suitable building or other structure. It will be generally understood that the building control system <NUM> of <FIG> may be expanded and adapted to control and manage other systems and building components, and may be deployed on a larger scale as the need arises. In addition, the building control system <NUM> may be configured to coordinate operational control of multiple building components service the building that otherwise operate independently of one another, such as HVAC, security and lighting. This may increase operational efficiency, reduce operational costs and maximize energy efficiency of the building in which the building control system <NUM> is deployed.

The illustrative building control system <NUM> shown in <FIG> includes one or more wireless devices <NUM>, <NUM>, a central controller <NUM>, a boiler/boiler interface <NUM>, and other accessories <NUM> (i.e., one or more discrete air conditioner units, one or more dampers, one or more lighting controllers, or any other suitable building components that may be used to service the building). It should be recognized that the boiler/boiler interface <NUM> may be any form of heating or cooling plant/plant interface. In a simplified embodiment, the building control system <NUM> may be used to communicate with a single wireless device <NUM> or <NUM>. In other embodiments, the building control system <NUM> may be used to communicate with and control multiple wireless devices <NUM>, <NUM> and/or multiple other accessories <NUM>. The wireless devices <NUM>, <NUM> may be located in different zones or rooms of the building and may be mounted, for example, on a wall, ceiling, or on a component it is designed to control and/or monitor. In the example shown, the wireless devices <NUM>, <NUM> may be electronic thermostatic radiator valve (eTRV) controllers, configured to be mounted on a radiator valve and/or configured to be part of the radiator valve. The central controller <NUM> may send one or more commands to the electronic thermostatic radiator valve (eTRV) controllers to set the corresponding radiator valves to desired valve position. An actuator in each of the electronic thermostatic radiator valve (eTRV) controllers may then turn the corresponding radiator valve to the commanded position. While eTRV controllers are used as an example, it should be recognized that the wireless devices <NUM>, <NUM> may include a damper actuator controlling an air damper in an air duct, a discrete air conditioner control unit, a user interface for accepting set points and/or other settings, and/or any other suitable wireless device as desired.

The central controller <NUM> may be configured to control the comfort level in one or more rooms and/or zones of the building by activating and/or deactivating the boiler/boiler interface <NUM> (e.g., any form of heating or cooling plant/plant interface), and/or the wireless devices <NUM>, <NUM>, and/or the other accessories <NUM> in a controlled manner. In some cases, the central controller <NUM> may be configured to transmit a command over a wired (as indicated by solid lines in <FIG>) or wireless (as indicated by dashed lines in <FIG>) network to the wireless devices <NUM>, <NUM> and/or the other accessories <NUM>. In some cases, a user may interact with a user interface on an internet device <NUM> (i.e., a phone, a tablet, a laptop, or any other suitable device), which may transmit a command, via a cloud <NUM>, to the central controller <NUM>. The central controller <NUM> may then transmit a command to the wireless devices <NUM>, <NUM> and/or the other accessories <NUM>. In this manner, the central controller <NUM> may assuming a master device role and communicate to a slave device (i.e., the wireless devices <NUM>, <NUM>). While shown in this example as a central controller <NUM>, it is contemplated that the central controller <NUM> may be or may include a hub device, such as a router, or any other suitable device.

The central controller <NUM> may be configured to wirelessly communicate over a wireless network using one or more wireless communication protocols such as cellular communication, ZigBee, REDLINK™, Bluetooth, Wi-Fi, IrDA, infra-red, radio frequency (RF), dedicated short range communication (DSRC), EnOcean, and/or any other suitable common or proprietary wireless protocol, as desired. In some cases, the wireless network may be an ad-hoc wireless network. In other cases, the wireless network may be a wireless mesh network such as a ZigBee wireless mesh network. In addition, the wireless network may include one or more routers (not shown in <FIG>) to extend and expand communication at the network level, but this is not required.

In some instances, a user interface may be provided as part of the central controller <NUM>, part of one or more of the wireless devices <NUM>, <NUM>, and/or provided as part of a separate device such as one or more of the internet devices <NUM>. The user interface may be used to facilitate a user's interactions with the building control system <NUM>, such as to set a mode of the building control system <NUM> (e.g. heat, cool, off) and/or to set one or more parameters of the building control system (e.g. set point, schedule, etc.).

<FIG> is a schematic block diagram of an illustrative remotely located wireless device <NUM> of the building control system shown in <FIG>. In the example shown, the wireless device <NUM> may operate on battery power and, as such may implement various algorithms to help conserve battery power when possible. As discussed above, the wireless device <NUM> may be an eTRV controller, but this is not required. In the example shown, the wireless device <NUM> may include a battery <NUM>, which may be rechargeable or replaceable. In general, it is desirable to lengthen the time between recharging and/or replacing the battery <NUM> of the wireless device <NUM>. The wireless device <NUM> may also include an optional sensor 36a that senses one or more conditions in or around the wireless device <NUM>, an optional actuator <NUM>, a wireless antenna <NUM> for wirelessly sending and/or receiving messages to and/or from a remotely located device (i.e., the central controller <NUM> or another wireless device <NUM>), and a memory <NUM> for storing one or more parameter values. In some cases, the wireless device <NUM> may also include a user interface <NUM> for interacting with a user.

When provided, the sensor 36a may be a temperature sensor, a humidity sensor, a pressure sensor, a flow sensor, a motion sensor, an occupancy sensor, a contact sensor, a light sensor, and/or any other suitable sensor. In some cases, the optional sensor 36a may be integrated with and form part of the wireless device <NUM>. In other cases, the sensor may be provided as a separate component, as indicated by sensor 36b and wirelessly coupled to the wireless device <NUM>. In still other instances, some sensors 36b may be separate components while other sensors 36a may be integrated with the wireless device <NUM>. These are just some example configurations.

In some cases, the wireless device <NUM> may use the sensors 36a and/or 36b to sense an ambient condition (e.g., temperature, humidity, etc.) in or around the wireless device <NUM>. The central controller <NUM> may be configured to receive the sensed conditions from the wireless device <NUM> via wireless communication. In some instances, the central controller <NUM> may be configured to use the sensed conditions (i.e., signals received from the sensors 36a, 36b) to operate or coordinate operation of the wireless devices <NUM>, <NUM>, the boiler/boiler interface <NUM> (e.g., any form of heating or cooling plant/plant interface), and/or the other accessories <NUM> (not shown in <FIG>). In one example, the wireless device <NUM> may use the wireless antenna <NUM> for wirelessly sending and/or receiving messages to/from the central controller <NUM> (as shown in <FIG>). Alternatively, or in addition, the wireless device <NUM> may wirelessly send and/or receive messages via the antenna <NUM> to/from another wireless device (i.e., wireless device <NUM>) and/or to/from the internet devices <NUM>.

The illustrative wireless device <NUM> of <FIG> includes a controller <NUM>. In the example shown, the controller <NUM> communicates with the battery <NUM>, the sensor 36a and/or 36b, the antenna <NUM>, the actuator <NUM>, and the memory <NUM>. With regard to the battery <NUM>, the controller <NUM> may receive power from, and in some cases, monitor the current flowing from the battery <NUM> and/or the voltage provided by the battery <NUM>. In some cases, the controller <NUM> may be programmed to operate differently depending on the amount of battery life that remains in the battery <NUM>. With regard to the sensor 36a and/or 36b, the controller <NUM> may poll the sensor 36a, 36b at a particular time/rate and may receive a reading from the sensor 36a, 36b. With regard to the antenna <NUM>, the controller <NUM> may receive and interpret messages that arrive through the antenna <NUM>, and may compose and transmit messages and/or commands via the antenna <NUM>. With regard to the actuator <NUM>, the controller may send control signals to the actuator <NUM> to drive, for example, a radiator valve (and/or any other suitable wireless device) to a commanded position. With regard to the memory <NUM>, the controller <NUM> may store and retrieve particular parameter values, algorithms, and other data as needed or desired. The memory <NUM> may be any suitable type of storage device including, but not limited to, RAM, ROM, EPROM, flash memory, a hard drive, and/or the like.

To conserve battery power, the controller <NUM> may be configured to wirelessly receive messages during scheduled communication times, and switch the wireless device <NUM> into a low power sleep mode between communication times. In some instances, the controller <NUM> may be configured to receive one or more commands and/or parameter setting messages from the central controller <NUM> and/or another wireless device (i.e., wireless device <NUM>, or other suitable wireless device) via the antenna <NUM> during the communication times. The one or more commands and/or parameter setting messages may provide one or more parameter values, such as a temperature set point, for example, which may be stored in the memory <NUM>. The controller <NUM> of the wireless device <NUM> may use the stored temperature set point along with a sensed condition (e.g. temperature) to control an actuator of the wireless device <NUM> (i.e., the eTRV).

In some cases, the central controller <NUM> may send a message to the wireless device <NUM> during a communication time of the wireless device <NUM>. The message may include a synchronization signal along with time duration until the next communication time referenced to the synchronization signal. The controller <NUM> may start a timer in response to the synchronization signal, and then enter a low power sleep mode. When the time duration specified in the previous message has expired, the controller <NUM> may wake up the wireless device <NUM> from the low power sleep mode and again enter the communication period for a brief period of time to listen for another message from the central controller <NUM> and/or communicate a message to the central controller <NUM>. Increasing the time between the communication times, and thus increasing the time that the wireless device <NUM> remains in the lower power sleep mode, tends to increase the battery life of the wireless device <NUM>. However, it has the effect of decreasing the responsiveness of the system. To alleviate this apparent tension, the wireless device <NUM> may be configured to wake up and communicate more frequently during those periods in a day when a user is more likely to interact with the system, and may wake up and communicate less frequently during those periods in a day when a user is not likely to interact with the system. In some cases, the periods when a user is most likely to interact with the system and/or not likely to interact with the system may be learned based on prior user interactions.

A pattern of prior user interactions with the building control system <NUM> may be stored in the memory <NUM> of the wireless device <NUM> and/or in the central controller <NUM>. Stored user interactions can be used to learn those periods of a day during which a user is more likely to interact with the wireless device <NUM> and/or the building control system <NUM>. During those periods, the wireless device <NUM> may enter a communication period more frequently. For example, during periods where user interaction is more likely to occur (e.g. 6AM-9AM), the wireless device <NUM> may repeatedly wake up for a short communication period (e.g. ten (<NUM>) milliseconds) every ten (<NUM>) seconds, and remain in the lower power sleep state between communication periods. This may provide adequate responsiveness to the user. During periods in the day at which a user is not likely to interact with the wireless device <NUM> and/or the building control system <NUM>, the wireless device <NUM> may enter a communication period far less frequently. For example, during periods where user interaction is not likely to occur (e.g. 1AM-6AM), the wireless device <NUM> may repeatedly wake up for a short communication period (e.g. one hundred (<NUM>) milliseconds) every four (<NUM>) minutes, and remain in the lower power sleep state between communication periods. This may help increase the life of the battery of the wireless device <NUM>. In some cases, the periods of a day where user interaction is more likely to occur and/or the periods where user activity is not likely to occur may be programmed by the user. In other cases, the periods of a day where user interaction is more likely to occur and/or the periods where user activity is not likely to occur may be learned by the system based on prior user interactions.

<FIG> is a schematic block diagram of an illustrative central controller <NUM> of the building control system <NUM> shown in <FIG>. As shown in <FIG>, the central controller <NUM> may include an antenna <NUM> for transmitting and/or receiving signals over a wireless network. In some instances, antenna <NUM> can be a wireless communications port for wirelessly sending and/or receiving messages over the wireless network. In one example, the antenna <NUM> may include a low frequency radio frequency (RF) transceiver for transmitting and/or receiving RF signals over a Redlink™ network, but this is just one example. More generally, the central controller <NUM> may include a suitable transceiver for communicating with the wireless devices <NUM>, <NUM> over any suitable communications path. In some cases, the central controller <NUM> may communicate with one or more remote temperature sensors, humidity sensors, lighting sensors, and/or occupancy sensors, which may be located throughout the building, via the antenna <NUM>. In some cases, the central controller <NUM> may communicate with a temperature sensor and/or humidity sensor located outside of the building or structure for sensing an outdoor temperature and/or humidity, if desired. The central controller <NUM> may further include a processor (e.g. microprocessor, microcontroller, etc.) <NUM> and a memory <NUM>. The memory <NUM> may be any suitable type of storage device including, but not limited to, RAM, ROM, EPROM, flash memory, a hard drive, and/or the like. In some cases, the central controller <NUM> may also include a user interface <NUM>, sometimes with a display (not shown).

The central controller <NUM> may send a message to the wireless device <NUM> during a communication time of the wireless device <NUM>. In some cases, the message may include a synchronization signal along with time duration until the next communication time referenced to the synchronization signal. The wireless device <NUM> may start a timer in response to the synchronization signal, and then subsequently enter a low power sleep mode to conserve battery power. When the time duration specified in the previous message has expired, the wireless device <NUM> may wake up from the low power sleep mode and listen for another message from the central controller <NUM> and/or communicate a message to the central controller <NUM>. Increasing the time between these communication times, and thus increasing the time that the wireless device <NUM> remains in the lower power sleep mode, tends to increase the battery life of the wireless device <NUM>. However, it has the effect of decreasing the responsiveness of the system.

To alleviate this apparent tension, the central controller <NUM> may detect a current user interaction and/or may learn when a user interaction is likely to occur, and during these times, may include in the next message to the wireless device <NUM> a shortened time duration referenced to the synchronization signal. Then, when the shortened time duration specified in the message has expired, the wireless device <NUM> may wake up from the low power sleep mode and listen for another message from the central controller <NUM> and/or communicate a message to the central controller <NUM>. This may increase the apparent responsiveness of the system. This may continue for a period of time after no further user interaction is detected and/or until further user interaction is no longer likely to occur. Then, the central controller <NUM> may send messages that include a lengthened time duration referenced to the synchronization signal. When the lengthened time duration specified in the message has expired, the wireless device <NUM> may wake up from the low power sleep mode and listen for another message from the central controller <NUM> and/or communicate a message to the central controller <NUM>. This may increase the battery life of the wireless device <NUM>. More generally, it is contemplated that the wireless device <NUM> may be configured to wake up and communicate more frequently during those periods in a day when a user is more likely to interact with the system, and may wake up and communicate less frequently during those periods in a day when a user is not likely to interact with the system. In some cases, the periods when a user is most likely to interact with the system and/or not likely to interact with the system may be learned based on prior user interactions.

In some cases, a pattern of prior user interactions with the building control system <NUM> may be stored in the memory of the wireless device <NUM> and/or the central controller <NUM>. Stored user interactions can be used to learn those periods of a day during which a user is more likely to interact with the wireless device <NUM> and/or the central controller <NUM>. During those periods, the wireless device <NUM> may wake up and enter a communication mode more frequently. For example, during periods where user interaction is more likely to occur (e.g. 6AM-9AM), the wireless device <NUM> may repeatedly wake up for a short communication period (e.g. ten (<NUM>) milliseconds) every ten (<NUM>) seconds, and remain in the lower power sleep state between communication periods. This may provide adequate responsiveness to the user. During periods in the day at which a user is not likely to interact with the wireless device <NUM> and/or the central controller <NUM>, the wireless device <NUM> may enter a communication mode far less frequently. For example, during periods where user interaction is not likely to occur (e.g. 1AM-6AM), the wireless device <NUM> may repeatedly wake up for a short communication period (e.g. one hundred (<NUM>) milliseconds) every four (<NUM>) minutes, and remain in the lower power sleep state between communication periods. This may help increase the life of the battery of the wireless device <NUM>. In some cases, the periods of a day where user interaction is more likely to occur and/or the periods where user activity is not likely to occur may be programmed by the user. The user may program an interaction schedule via the user interface <NUM>. In other cases, the periods of a day where user interaction is more likely to occur and/or the periods where user activity is not likely to occur may be learned by the system based on prior user interactions.

<FIG> shows an illustrative method <NUM> for communicating between a first device and a second device of a building control system <NUM>. The first device and/or the second device may be one of central controller <NUM>, wireless device <NUM>, wireless device <NUM>, one of the other accessories <NUM>, a thermostat, a radiator valve, a damper actuator, a temperature sensor, a humidity sensor, and/or any other suitable device. The illustrative method <NUM> includes wirelessly communicating between the first device and the second device during scheduled communication times, as shown at <NUM>. During the scheduled communication times, the second device may be placed in a listening state, where the second device enters a non-listening state between at least some of the scheduled communication times, as shown at <NUM>. The method may further include receiving a plurality of user inputs each at a user interaction time, wherein each of the plurality of user inputs cause a corresponding communication between the first device and the second device, as shown at <NUM>. The plurality of user inputs may be stored in a memory of the first device and/or the second device. Based on the stored user inputs, the method may include identifying one or more active periods of a day that user input is more likely to occur, and one or more inactive periods of the day that user input is less likely to occur, based at least on part on the user interaction times, as shown at <NUM>. During active periods, the second device is maintained in the listening state more than during inactive periods <NUM> to increases the responsiveness of the building control system. In some cases, the first device (e.g., a master device) sends a message during a scheduled communication time that notifies the second device (e.g. a slave device) of a next scheduled communication time. The next scheduled communication time may be scheduled to be sooner during active periods than during inactive periods.

The one or more active periods and the one or more inactive periods may be identified over time by learning one or more patterns in the user interaction times. For example, as illustrated in <FIG>, user interaction time periods can be established by developing an interaction profile <NUM> that may include, for example, a table with each of seven (<NUM>) columns representing one of the days of the week, and each row representing a time period during each day. In some cases, each day may be divided into eight (<NUM>) time periods, with each time period representing a three (<NUM>) hour time window. In this example, a counter may be maintained for each of the eight (<NUM>) time periods of each of the seven (<NUM>) days of the week, as shown.

On power up, each counter may be initialized to a default value such as seven (<NUM>). During the course of a week, as time passes, each time period is reached sequentially, and the corresponding counter is decremented by one (<NUM>). In other words, on Sunday at <NUM>:00am the counter initially has a value of seven (<NUM>). If a user does not interact with the system (e.g. change a set point) at any time during that three (<NUM>) hour window, the corresponding counter would be decrement by one (<NUM>) and become a six (<NUM>). Thus, on the following Sunday (one week later), the counter will have a value of (<NUM>). So long as the user does not interact with the system at any time during that three (<NUM>) hour time window on subsequent Sundays, this would continue week-by-week until the corresponding counter reaches a value of zero (<NUM>). However, if a user interacts with the building control system <NUM> during the Sunday <NUM>:00am-<NUM>:59am time period, the counter may be reset back to seven (<NUM>). Thus, in the shown in <FIG>, the counter that corresponds to the Sunday <NUM>:00am-<NUM>:59am time period is reset to an active time window when a user interaction is detected, and then declines over the coming weeks to zero when no further user interactions are detected on subsequent Sundays during this time period. The counter values for each of the other time periods may be maintained in a similar manner.

During operation, and with reference to the illustrative building control system <NUM> of <FIG>, the wireless device <NUM> (and/or central controller <NUM>) may wake up and communicate more frequently during those time periods that have a counter value of seven (<NUM>), and may wake up and communicate less frequently during those periods that have a counter value of zero (<NUM>). In some cases, a counter threshold value may be provided, wherein for those time periods that have a counter value that is above the threshold value, the wireless device <NUM> (and/or central controller <NUM>) may wake up and communicate more frequently thereby increasing the apparent responsiveness, and for all time periods that have a counter value below the threshold value, the wireless device <NUM> (and/or central controller <NUM>) may wake up and communicate less frequently thereby increasing the battery life of the wireless device. In some cases, the threshold value may be set to <NUM>, <NUM>, <NUM> or any other suitable threshold value.

<FIG> shows another illustrative method <NUM> to determine when a user is more likely to interact with a building control system. As illustrated in <FIG>, user interaction times may be monitored over time (a day, week or longer) and stored in a user interaction log. The user interaction log may be analyzed to identify clusters of user interactions. For example, a cluster may identified by starting a timer when a first user interaction is detected. If another user interaction is detected before the time expires, the timer is reset. This is continued until no user interaction is detected and the timer expires. Then all user interactions from the first user interaction until the time expires are grouped together in a cluster. For example, in <FIG>, cluster A <NUM> includes four (<NUM>) user interactions, cluster B <NUM> includes one (<NUM>) user interaction, and cluster C <NUM> includes four user interactions. The timer may be reset to <NUM> hours, <NUM> hours, <NUM> hour or any other suitable time period. The clusters may occur at particular times of a day or week. For example, cluster A <NUM> may have occurred on Monday at <NUM>:00am-<NUM>:35am, cluster B <NUM> at Thursday at <NUM>:05pm-<NUM>:05pm and cluster C <NUM> at Saturday at <NUM>:05pm-<NUM>:10opm. These cluster periods may be applied going forward to future weeks to identify periods that user interaction is more likely to occur. In some cases, if a user interaction does not occur during a subsequent cluster period during each of two or more subsequent weeks, the cluster may be removed. Also, future interactions may cause new clusters may be added.

During operation, and with reference to the illustrative building control system <NUM> of <FIG>, the wireless device <NUM> (and/or central controller <NUM>) may wake up and communicate more frequently during those time periods during a day or week that correspond to each of the clusters, and may wake up and communicate less frequently during those periods between clusters. For example, the wireless device <NUM> (and/or central controller <NUM>) may wake up and communicate more frequently on Mondays at <NUM>:00am-<NUM>:35am, which corresponds to cluster A <NUM>, on Thursday at <NUM>:05pm-<NUM>:05pm, which corresponds to cluster B <NUM>, and on Saturday at <NUM>:05pm-<NUM>:10pm, which corresponds to cluster C <NUM>. The wireless device <NUM> (and/or central controller <NUM>) may wake up and communicate less frequently during those times between cluster A <NUM>, cluster B <NUM> and cluster C <NUM>. In some cases, if a user interaction does not occur on Mondays at <NUM>:00am-<NUM>:35am (cluster A <NUM>) for two or more subsequent weeks, cluster A <NUM> may be removed. If a user interaction is detected at other times in the future, new clusters may be added. In this manner, the central controller <NUM> and/or the wireless device <NUM> may "learn" periods when a user is most likely to interact with the system and/or not likely to interact with the system may be learned, based on prior user interactions.

<FIG> is timing diagram <NUM> of the operation of another illustrative building control system. As shown, a controller <NUM> may employ a set point of twenty (<NUM>) degrees Celsius. Initially, the wireless device <NUM> may wake up to communicate with the controller <NUM> less frequently to conserve battery power of the wireless device <NUM>. In the example shown, the wireless device <NUM> may wake up to receive an updated set point from the controller <NUM> every eighty (<NUM>) seconds, namely at <NUM>, <NUM>, <NUM>, <NUM> and <NUM> seconds. At <NUM> seconds, a user interaction with the controller <NUM> is detected that changes the set point to twenty-four (<NUM>) degrees Celsius. The new set point is not immediately relayed from the controller <NUM> to the wireless device <NUM> until twenty (<NUM>) seconds later (i.e. at <NUM> seconds), as the wireless device <NUM> is currently set to listen every eighty (<NUM>) seconds to conserve battery power. At three hundred twenty (<NUM>) seconds, the wireless device <NUM> wakes up and the controller <NUM> sends a message that includes the updated set point of twenty-four (<NUM>) degrees Celsius, a synchronization signal along with a shortened time duration until the next communication time referenced to the synchronization signal. In this example, the shortened time duration is ten (<NUM>) seconds. As can be seen, the user interaction <NUM> at <NUM> seconds causes the controller <NUM> and the wireless device <NUM> to communicate on a more frequent basis to increase the responsiveness of the system. In some cases, this may continue for a pre-set time period and then switch back to communicating on a less frequent basis to conserve battery power, where the pre-set time may be, for example, three (<NUM>) hours, one (<NUM>) hour, thirty (<NUM>) minutes, sixty (<NUM>) minutes, forty (<NUM>) minutes, or any other suitable time period. In other cases, this may continue for a time period that is based on prior user interactions, such as a distribution of prior user interactions over time.

Continuing with the example of <FIG>, at <NUM> seconds, a user interaction with the controller <NUM> is detected that changes the set point back to twenty (<NUM>) degrees Celsius. This updated set point is relayed to the wireless device <NUM> the next time the wireless device wakes up, or in this case at <NUM> seconds. As can be seen, this may significantly increase the responsiveness of the system.

<FIG> shows an illustrative user interaction profile having scheduled occupancy periods. An example interaction profile <NUM> may include scheduled occupancy times. The scheduled occupancy times may be based on a programmable operating schedule which may include two or more time periods for each of two or more days. In some cases, the time periods may correspond to the time periods of a temperature schedule, where each time period has a corresponding temperature set point, but this is not required.

The building control system <NUM> may be configured to wake up and communicate more frequently when the user is expected to be home and not sleeping (Home "H" periods), and may be configured to wake up and communicate less frequently when the user is expected to be sleeping (Sleep "S" periods) or is away, such as at work (Work "W" periods). In the example shown, the building control system <NUM> may be configured to wake up and communicate every ten (<NUM>) seconds when the user is expected to be home and not sleeping (Home "H" periods) as shown at <NUM>, and may be configured to wake up and communicate every four (<NUM>) minutes when the user is expected to be sleeping (Sleep "S" periods) as shown at <NUM> or is away, such as at work (Work "W" periods) as shown at <NUM>. In some cases, the schedule periods may be programmed by the user. In other cases, the schedule periods may be set based at least in part on detected prior user behavior.

<FIG> shows an illustrative geo-fence crossing event <NUM> which may be used by the building control system <NUM> to identify when a building is expected to be occupied and unoccupied. When the building is expected to be occupied, the building control system <NUM> may be configured to wake up and communicate more frequently to increase the responsiveness of the system. When the building is expected to be unoccupied, the building control system <NUM> may be configured to wake up and communicate less frequently to conserve battery power.

A user of the building may have a mobile device with location services. The mobile device and/or the building control system <NUM> may store a geo-fence associated with the building, and provide geo-fence functionality that identifies when the mobile device crosses the geo-fence, as indicated by arrows <NUM> crossing-into the geofence and <NUM> crossing-out of the geo-fence, resulting in corresponding geo-fence crossing events. The building control system <NUM> may include a memory that is configured to store a log of the detected geo-fence crossing events. For each geo-fence crossing event, the log may include an indication of the geo-fence crossing event as well as whether the geo-fence crossing event was a crossing-in event or a crossing-out event. When the user is determined to be inside the geo-fence, the building may be considered to be occupied, and the building control system <NUM> may be configured to wake up and communicate more frequently to increase the responsiveness of the system. When the user is determined to be outside the geo-fence, the building may be considered to be unoccupied, the building control system <NUM> may be configured to wake up and communicate less frequently to conserve battery power. This is just one example. This embodiment may be used in conjunction with the programmed schedule of <FIG>, where the schedule is over-ridden (even when in the "H" periods) when the user is determined to be outside the geo-fence, and the building control system <NUM> may wake up and communicate less frequently to conserve battery power. When the user is determined to be inside the geo-fence, and the schedule of <FIG> may be followed.

Claim 1:
A method for communicating between a first device (<NUM>) and a second device (<NUM>) of a building control system (<NUM>), the method comprising:
wirelessly communicating between the first device (<NUM>) and the second device (<NUM>) during scheduled communication times (<NUM>), wherein the scheduled communication times are based at least in part on a pattern of user interaction times and wherein the frequency of the communication times are based at least in part on the pattern of user interaction times,
placing the second device (<NUM>) in a listening state during the scheduled communication times,
placing the second device (<NUM>) in a non-listening state between at least some of the scheduled communication times (<NUM>);
receiving a plurality of user inputs each at a user interaction time, wherein each of the plurality of user inputs cause a corresponding communication between the first device (<NUM>) and the second device (<NUM>); (<NUM>) and
identifying one or more active user input periods of a day and one or more inactive user input periods of the day to determine the pattern of user interaction times (<NUM>);
wherein the identifying of the one or more active user input periods and the one or more inactive user input period to determine the pattern of user interaction times comprises:
clustering the user interaction times into a plurality of clusters (<NUM>, <NUM>, <NUM>), wherein each cluster (<NUM>, <NUM>, <NUM>) corresponds to a corresponding cluster period;
identifying each of the plurality of cluster periods as an active user input period; and
identifying each of the times between the plurality of cluster periods as an inactive user input period.