Wireless event notification system

Abstract

The event notification system includes a wireless device, an access point device, a server, and a user application. The server is configured to receive multiple heartbeats from the wireless device and through the access point device, and to send a heartbeat response in response to a corresponding heartbeat among the multiple heartbeat responses. The user application is configured to send enable and disable commands to the server. The enable command is sent to the wireless device as part of the next heartbeat response among the multiple heartbeat responses. After the server receives the event status from the wireless device through the access point device, the disable command is sent to the wireless device.

Description

Background Technology

[0001] This disclosure relates to wireless communication systems, and more particularly to wireless event notification systems.

[0002] Wireless communication systems can include intelligent, battery-powered wireless devices (such as Internet of Things (IoT) devices). Such wireless devices can operate in different energy modes (such as sleep mode and wake-up mode) to at least partially maintain battery life. The wake-up frequency and duration of the wireless device in different energy modes may not always be optimal in terms of maintaining battery life and may depend on other parameters and / or characteristics of the communication system.

[0003] Wi-Fi Power Saving Mode (PSM) is an example of a communication technology used by battery-powered IoT devices to establish and maintain a Wi-Fi link with an access point (AP) device. Using Wi-Fi PSM, after the AP device is notified of a state change (i.e., from wake-up to sleep), the IoT device can enter a sleep state for a predetermined amount of time to conserve energy. When notified, the AP device can begin buffering packets for the sleeping IoT device. The IoT device must periodically wake up to check for beacons from the AP device indicating the presence of buffered packets for the IoT device. If buffered packets are indeed present, the IoT device retrieves the packets via power saving (PS) polling messages.

[0004] Unfortunately, IoT devices must wake up frequently to monitor beacons for buffered data packets, thus consuming power from the IoT device's battery. Furthermore, the duration for which the AP device buffers packets for IoT devices (i.e., the time before the AP device loses packets) is finite and manufacturer-dependent, and therefore can vary between different AP devices. Consequently, the wake-up cycle of IoT devices is typically conservatively extended to reduce the possibility of any buffered packets being lost. Moreover, communication with the cloud can introduce unpredictable latency, resulting in suboptimal system performance. System improvements to maintain the battery life of IoT devices and / or manage the idle time of AP devices are desirable.

[0005] As an example, a wireless communication system could be a security system where IoT devices must periodically communicate with a controller to signal their presence and receive commands such as arming and disarming. For the security system to function effectively, this communication must be frequent. Unfortunately, such frequent communication or responses consume a considerable amount of energy through IoT devices and shorten battery life. Summary of the Invention

[0006] An event notification system according to a non-limiting embodiment of the present disclosure includes: a wireless device including sensors for detecting events; an access point (AP) device; a controller configured to receive a plurality of heartbeats from the wireless device and via the AP device, and to send a heartbeat response of the plurality of heartbeat responses to a corresponding heartbeat of the plurality of heartbeats; and a user application configured to send sensor enable and disable commands to the controller, wherein the sensor enable command is sent to the wireless device as part of a next heartbeat response of the plurality of heartbeat responses, and the sensor disable command is sent to the wireless device after the controller receives an event status from the wireless device via the AP device.

[0007] In addition to the embodiments described above, the event notification system is a security system, the sensor enable command is an arming command, and the sensor disable command is a disarming command.

[0008] In alternatives or otherwise, in the embodiments described above, the controller is at least a part of the cloud server.

[0009] In alternatives or otherwise, in the embodiments described above, the cloud server includes a virtual security panel.

[0010] In alternatives or otherwise, in the embodiments described above, the user application is a mobile application.

[0011] In alternatives or otherwise, in the embodiments described above, the wireless device is a power-saving mode (PSM) device.

[0012] In an alternative or other embodiment described above, the controller is configured to send a disable response to the user application in response to receiving a disable command and without sending the disable command to the wireless device via the AP device.

[0013] In an alternative or other embodiment described above, the controller is configured to buffer the disable command and suppress the event condition before sending the disable command to the wireless device after receiving the event condition.

[0014] In an alternative or other embodiment described above, the controller is configured to buffer the enable command before sending it to the wireless device via the next heartbeat response.

[0015] In alternatives or otherwise, in the embodiments described above, the wireless device includes multiple wake states that are interfered with by multiple sleep states, and each of the multiple heartbeats is transmitted during the corresponding wake state in the multiple wake states.

[0016] In alternatives or otherwise, in the embodiments described above, the event notification system is a non-beacon tracking security system.

[0017] A method for an operational event notification system according to another non-limiting embodiment includes: sending a disable command from a user application to a controller; sending a valid disable response from the controller to the user application in response to the disable command; and buffering the disable command by the controller.

[0018] In addition to the embodiments described above, the controller is a virtual panel that is part of a cloud server.

[0019] In an alternative or other embodiment described above, the method includes: sending an event condition from a power saving mode (PSM) device via an access point (AP) device and to a controller; suppressing the event condition at the controller while a disable command is buffered; and in response to receiving the event condition, sending the buffered disable command from the controller via the AP device and to the PSM device.

[0020] In alternative or other embodiments, in the foregoing embodiments, the method includes: sending an enable command from a user application to a controller; buffering the enable command by the controller; sending a heartbeat from a PSM device via an AP device and to the controller; and sending a heartbeat response from the controller via the AP device and to the PSM device, wherein the heartbeat response includes the enable command and is responsive to the heartbeat.

[0021] In alternative or other embodiments, in the foregoing embodiments, the method includes: enabling the PSM device after receiving a heartbeat response; and sending an enable confirmation signal from the PSM device via a controller and to a user application.

[0022] In alternatives or otherwise, in the embodiments described above, the AP device is a router.

[0023] In alternatives or otherwise, in the embodiments described above, the user application is a smartphone.

[0024] In alternatives or otherwise, in the embodiments described above, the event notification system is a security system, the enable command is an arming command, and the disable command is a disarming command.

[0025] An event notification system according to another non-limiting embodiment includes: a wireless device including sensors for detecting events; a gateway device; a controller configured to send commands to the wireless device and via the gateway device; and a user application configured to send sensor enable and disable commands to the controller, wherein the sensor enable command is sent to the wireless device via the gateway during periodic wake-up intervals of the wireless device, and the sensor disable command is sent to the wireless device during periodic wake-up intervals of the wireless device or after the controller receives an event status from the wireless device via the gateway.

[0026] Unless otherwise expressly indicated, the foregoing features and elements may be combined in various combinations without exclusivity. These features and elements, and their operation, will become more apparent from the following description and drawings. However, it should be understood that the following description and drawings are intended to be illustrative in nature and not restrictive. Attached Figure Description

[0027] Various features will become apparent to those skilled in the art from the following detailed description of the disclosed non-limiting embodiments. The accompanying figures can be briefly described as follows:

[0028] Figure 1 This is a schematic diagram of a wireless communication system as a non-limiting exemplary embodiment of the present disclosure;

[0029] Figure 2 This is a schematic diagram of a "PSM device-initiated non-beacon tracking wireless communication system" as an embodiment of a wireless communication system, and is also a schematic diagram illustrating a method for retrieving packets from the buffer.

[0030] Figure 3 This is a schematic diagram of an event notification system as a non-limiting example of a wireless communication system, and the diagram illustrates two scenarios depicting methods for enabling and disabling wireless devices in the system.

[0031] Figure 4 yes Figure 3 The flowchart of the method shown in the figure;

[0032] Figure 5 It is a chart showing how the frequency of the awakening interval changes with the armed and disarmed states;

[0033] Figure 6 It is a flowchart of the method for operating the system and Figure 5 The charts and graphs shown in the figure reflect this.

[0034] Figure 7 This is a schematic diagram of a second embodiment of the event notification system;

[0035] Figure 8 The diagram is in Figure 7 A table showing the historical communication model between the control components of the event notification system and the wireless device;

[0036] Figure 9 This is a schematic diagram of a "server-initiated non-beacon tracking wireless communication system" as a second embodiment of a wireless communication system; and

[0037] Figure 10A and 10BThis is a flowchart illustrating the method for operating a "server-initiated non-beacon tracking wireless communication system". Detailed Implementation

[0038] refer to Figure 1 The illustration shows an exemplary embodiment of a wireless communication system 20. The wireless communication system 20 may include a wireless device 22, a control component 23, and a user application 26, which may be a mobile application. The control component 23 may include a gateway or access point (AP) device 24 and a controller 28. The controller 28 may be a server and may be a cloud 30 or part thereof. The controller 28 may include a computing processor 32 and a storage medium 34. The wireless device 22 may be configured to communicate with the AP device 24 via a wireless path (see arrow 36). The AP device 24 may be configured to communicate with the wireless device 22, the controller 28, and / or the mobile application 26 via appropriate paths that may serve as wireless paths (see arrows 38, 40, 42). The cloud 30 and / or the controller 28 may be configured to communicate with the AP device 24 via a path that may be wireless (see arrow 44) and with the mobile application 26 via a path that may be wireless (see arrow 45). Mobile application 26 can be configured to communicate with wireless device 22 via path 46, which may be wireless, with AP device 24 via a wireless path (see arrow 47), and / or with controller 28 via a path that may be wireless (see arrow 49). In one example, mobile application 26 can connect directly to cloud 30 via third-generation mobile telecommunications technology (i.e., 3G), or indirectly to cloud 30 via AP device 24 (i.e., home Wi-Fi).

[0039] AP device 24 may be a router with firmware supporting Wi-Fi Power Saving Mode (PSM). Mobile application 26 may be a smartphone, digital media player, tablet, and other applications. Examples of wireless devices 22 may include smart home sensors or intrusion sensors configured to detect the opening of windows or doors in security systems, passive infrared (PIR) sensors, image sensors (i.e., PIR sensors with cameras), thermal sensors configured to measure the temperature of ambient air in heating systems, gas sensors configured to detect the presence of gases, smoke detectors as part of security systems, and many other types of devices that utilize batteries and communicate wirelessly.

[0040] The wireless device 22 may further be a smart device, Internet of Things (IoT) device, and / or Wi-Fi PSM device configured to communicate with the cloud 30 via the AP device 24. The wireless device 22 may include a power management module 48 (i.e., a battery and components for managing battery power), sensors and / or actuators 50, a computing processor 52 (e.g., a microcontroller), and a wireless transceiver 54. As a PSM device, the wireless device 22 is configured to enter a sleep state and a wake-up state at a predetermined frequency and duration.

[0041] In one embodiment, while in sleep mode, one or more internal timers 55 of the processor 52 of the wireless device 22 may remain powered, but all other components of the wireless device 22 are generally disconnected. The wireless device 22 can wake from sleep mode when a pre-specified wake-up time occurs, or when an enabled interrupt is triggered (i.e., an event sensed by the sensor 50 occurs). Generally, maximizing the duration of sleep mode and / or minimizing or eliminating the need for tracking AP beacons optimizes battery life. In one example, a preferred battery life for a low-power IoT device is approximately four to five years.

[0042] Wireless communication system 20 eliminates the need for more traditional tracking of beacons broadcast from AP device 24 to wireless device 22, thereby maximizing the standby time (i.e., sleep state duration) of wireless device 22. There is no need to track beacons to receive buffered packets from AP device 24 because power-saving (PS) polling (i.e., PS polling signals) can be sent directly from wireless device 22 to AP device 24. AP device 24 can then respond to PS polling with an ACK (i.e., an ACK signal) following a buffered packet (if the signal or data has been buffered by AP device 24 for retrieval by wireless device 22), or directly with the buffered packet. If no packet is buffered, the response is either no data packet or an ACK following a data packet. In the case of no data packet received by wireless device 22, wireless device 22 can return to sleep state. If no packet is received by wireless device 22, the wireless device can return to sleep state after a pre-specified wake-up time has expired (i.e., timeout). After another pre-specified period of sleep, the wireless device 22 will wake up again and send a PS poll to retrieve buffered packets as previously described. This process will repeat until a data packet is received or a pre-specified counter reaches its limit.

[0043] PSM device-initiated non-beacon tracking wireless communication system

[0044] refer to Figure 2The diagram illustrates a general overview of communications between wireless device 22, AP device 24, server 28 (i.e., and / or cloud 30), and mobile application 26 along a timeline (see arrow 56). This particular series of communications is generally depicted as follows: wireless device 22 initiates Wi-Fi PSM without requiring wireless device 22 to track beacons broadcast by AP device 24. That is, wireless device 22 is configured to ignore beacons broadcast by AP device 24.

[0045] More specifically, when in the first wake-up state 60 (i.e., PSM), the wireless device 22 of the communication system 20 can send a first request 58 (i.e., a heartbeat or request signal) via the AP device 24 and forward it to the server 28. Upon receiving the first request 58, the AP device 24 can send an acknowledgment (ACK) 62 to the wireless device 22. The ACK 62 can be a Wi-Fi ACK at the MAC level. After receiving the ACK 62, the wireless device 22 can enter a minor sleep state 64. The minor sleep state 64 has a conservative duration that is longer than the uplink latency (see arrow 68) but may be shorter than the sum of the uplink latency 68 and the buffer timeout duration. In one embodiment, the duration of the minor sleep state 64 may be shorter than the buffer timeout duration.

[0046] In one embodiment, and generally, while the wireless device 22 is in a light sleep state 64, the server 28 can receive a first request 58 from the AP device 24 and send a first response 66 to the AP device 24. Generally, the uplink latency 68 can be measured from the time the AP device 24 receives the first request 58 to the time the AP device 24 receives the first response 66. It is understood that the first response 66 may not contain any command language or command data, and may instead be an empty packet, a registration request, information about the status, and / or other relevant responses. In one embodiment, the uplink latency 68 may be less than the sum of the durations of the first awake state 60 and the light sleep state 64.

[0047] The first response 66 can be buffered by the AP device 24 and thus awaited retrieval by the wireless device 22 as data packet 70 (i.e., the buffered packet). Since the duration of the light sleep state 64 is generally less than the sum of the uplink latency 68 and the AP buffer timeout duration, data packet 70 will not be lost by the AP device 24. Unlike other data packets described below, data packet 70 may not contain commands from the mobile device 26 and may instead contain information such as registration information, status information, etc.

[0048] Wireless device 22 can transition from a light sleep state 64 to a second awake state 72. While in the second awake state 72, wireless device 22 can send a first power saving (PS) poll 74 to AP device 24. In response to the first PS poll 74, AP device 24 can send a buffered data packet 70 to wireless device 22. After receiving the data packet 70, wireless device 22 can send an ACK 76 to AP device 24 and then enter a major sleep state 78.

[0049] The duration of deep sleep state 78 can be reasonably long, but shorter than the idle time of AP device 24, to prevent AP device 24 from unlinking from wireless device 22. The duration of deep sleep state 78 is significantly longer than the duration of shallow sleep state 64, and thus promotes a reduction in the power consumption of wireless device 22. In one embodiment, the duration of shallow sleep state 64 may be approximately one (1) second, and the duration of deep sleep state 78 may be approximately fifty (50) seconds. Furthermore, deep sleep state 78 can be more energy efficient than shallow sleep state 64 because, in shallow sleep state 64, only the transceiver and some additional hardware can be turned off. In deep sleep state 78, the transceiver, various hardware components, the processor (e.g., CPU), and some voltage regulators can be turned off. That is, for deep sleep state 78, only the real-time counter or oscillator can remain on to trigger an interrupt, thereby waking the processor.

[0050] In one embodiment, receiving the first data packet 70 enables the wireless device 22 to determine whether further action (e.g., a command to take a picture) is required. More specifically, the data packet 70 may contain a command requiring processing by the wireless device 22 and the execution of that command that can cause a command response (not shown) to be sent from the wireless device via the AP device 24 and to the server 28. Further understood, ACK 76 (i.e., the ACK portion of data packet 70) is used to indicate the presence of multiple packets to be retrieved. If multiple packets exist, multiple PS polling will be sent until all buffered packets have been retrieved.

[0051] It is anticipated and understood that, before the AP device 24 receives and buffers the data packet 70, and thus before the second wake-up state 72, the wireless device 22 may wake up and send at least one PS polling (not before the AP device 24 receives and buffers the data packet 70) that is affirmatively acknowledged by the AP device 24. Figure 2As shown in the diagram, the AP device 24 then sends a no-data packet (not shown) to the wireless device 24. As a result of the associated PS polling and the fact that the wireless device 22 has no buffered packets, the no-data packet originates from the AP device 24, and therefore, the no-data packet is not buffered by the AP device. Once the no-data packet is received by the wireless device 22, the wireless device can return to sleep mode until the next PS polling.

[0052] Server 28 can be configured to receive command signal 80 from mobile application 26. In one example, command signal 80 may be associated with a learned buffer timeout duration, which will be discussed further below. Once received, server 28 can buffer command signal 80 while waiting for it to be retrieved by wireless device 22 via AP device 24. Generally, it is understood that the buffer timeout duration of the cloud server can be substantially longer than the buffer timeout duration of AP device 24, which may depend on the manufacturer.

[0053] While command signal 80 is buffered by server 28, wireless device 22 can transition from second sleep state 78 to third wake-up state 82. In third wake-up state 82, wireless device 22 can send second request 84 via AP device 24 to server 28. After sending second request 84, wireless device 22 can enter second light sleep state 86. Second request 84 can generally be a query for data or commands from the cloud. In this example, second request 84 specifies the retrieval of command signal 80 from server 28 for buffering at AP device 24. That is, in response to second request 84, server 28 forwards command signal 80 to AP device 24, where command signal 80 is again buffered as data or commands, packets.

[0054] While command signal 80 can be buffered by AP device 24, wireless device 22 can transition from second light sleep state 86 to fourth wake-up state 88. In fourth wake-up state 88, wireless device 22 can send a second PS poll 90 to AP device 24. In response to the second PS poll 90, AP device 24 can send a data packet associated with command signal 80 to wireless device 22. Upon receiving the data packet, wireless device 22 can send an ACK 92 to AP device 24, can perform actions based on the data packet, and can then enter second deep sleep state 94. It is understood that the process of AP polling and cloud requests to retrieve data packets from cloud 30 via AP device 24 can generally be repeated automatically during normal operation. Such requests and polling eliminate any need for more traditional beacon tracking, thus enhancing the operation of power management module 48 and maintaining battery life.

[0055] Generally, this disclosure considers time-related characteristics such as uplink latency 68, buffer timeout duration of AP device 24, and idle time of AP device 24. Uplink latency 68 can generally be the time it takes for cloud 30 to respond to a request or heartbeat from wireless device 22. More specifically, uplink latency 68 is the duration measured from the time the heartbeat leaves AP device 24 to the time the response is received by AP device. Once the response is received by AP device 24, the response can be buffered and generally becomes a packet that may or may not contain commands or other data. The time it takes for wireless device 22 to retrieve the buffered packet is not typically part of the uplink latency period.

[0056] The advantages and benefits of the non-beacon-tracking wireless communication system 20 include: reduced power consumption of the wireless device 22 by avoiding the need for the wireless device 22 to track the AP beacon and maximizing the time the wireless device can remain in sleep mode without losing packets at the AP device. The method of operating system 20 can be applied to legacy AP devices and can be more efficient than legacy Wi-Fi PSM protocols (when the wireless device is confident that the AP device is buffering packets for the wireless device). This may indeed be the case for wireless devices that remain in sleep mode most of the time, as periodic heartbeats can be exchanged between the cloud and the device. This method can help the wireless device 22 maximize the duration of deep sleep based on its idle time capabilities and optimize the duration of light sleep based on the buffering capabilities of the AP device 24 and cloud latency, which can lead to a more energy-efficient device.

[0057] Event notification system and method for intelligently enabling / disabling IoT devices

[0058] refer to Figure 3 An example or application of the wireless communication system 20 could be an event notification system. Figure 3The diagram generally illustrates two separate operational scenarios of the same event notification system (such as a security system). The first scenario, located above the dashed line L, depicts a scenario where event condition 100 is triggered and the event detection and notification function of sensor 50 of wireless device 22 is enabled. The second scenario, located below the dashed line L, depicts a scenario where an event detection and notification function disable command 102 is sent to server 28 (e.g., a virtual panel), followed by event condition 100. Non-limiting examples of the event notification system 20 may include a security system, a fire detection system, or any alarm / notification system triggered by a sensed event. In the example of a security system, the system may be associated with an alarm condition, which is an example of event condition 100. For the same embodiment, the function disable command 102 for security system 20 may be a disarming command, and the enable command 104 may be an arming command.

[0059] Event notification system 20 facilitates intelligent function enabling / disabling methods for battery-powered wireless devices 22. Generally, event notification system 20 can be applied to any secure IoT device with relatively long sleep intervals. That is, applicable event notification system 20 can be any wireless event notification system with nodes entering sleep mode to conserve energy. Two non-limiting examples of such a system 20 are the "PSM device-initiated non-beacon tracking wireless communication system" described above and the "server-initiated non-beacon tracking wireless communication system" described herein.

[0060] The event notification system 20 may be a panelless security system with distributed wireless devices 22 (e.g., PSM devices), wherein at least some of the wireless devices 22 are configured to periodically sleep to conserve energy. Each wireless device 22 (i.e., or sensor 50 of wireless device 22) may generally maintain an enabled state and an actually disabled state locally. Alternatively, the enabled and disabled states may also be maintained by a central controller 28. The controller 28 may be part of a server, which may be part of a cloud 30. Furthermore, the controller 28 may generally be a virtual panel in the cloud 30. In embodiments of the wireless security system 20, the enabled state may be an armed state, and the actually disabled state may be an actually disarmed state.

[0061] To simplify the explanation, the event notification system 20 will be further described in relation to the security system implementation. In operation, when a user armes or disarms the security system 20 (i.e., one or more sensors 50 of the wireless device 22) via a user application 26 (e.g., a mobile application), the associated arming and disarming commands 102, 104 are sent to the virtual panel 28 in the cloud 30. The cloud 30 then sends commands 102, 104 to the individual wireless devices 22 based on wireless device wake-up scheduling or in response to messages received from the wireless devices 22.

[0062] refer to Figure 3 and Figure 4 The diagram illustrates methods for arming and disarming wireless device 22 of wireless security system 20. In block 200, an arming command 104 can be sent from user application 26 to controller 28. In block 202, the arming command 104 can be buffered by controller 28. In block 204, a heartbeat 106 can be sent from wireless device 22 via AP device 24 to controller 28. In block 206, a heartbeat response 108 can be sent from controller 28 via AP device 24 to wireless device 22. The heartbeat response 108 may include the arming command 104, which may originate from user application 26.

[0063] In block 208, the computing processor 52 of wireless device 22 can arm the sensor 50 of wireless device 22 by receiving the result of arming command 104 via heartbeat response 108. In block 210, an arming confirmation signal 110 can be sent from wireless device 22 via controller 28 and to user application 26. Although not illustrated, it is contemplated and understood, as is known to those skilled in the art, various ACKs can be sent between AP device 24 and wireless device 22.

[0064] In box 212, and generally at any time (see arrow 56), the disarm command 102 can be initiated or entered by the user into the user application 26. Then, regardless of whether the wireless device 22 is in sleep or wake-up mode, the user application 26 can send the disarm command 102 to the controller 28. In box 214, the controller 28 can, in response to the disarm command 102, send a disarmed state response 112 to the user application 26, thereby notifying the user of the disarmed state. More specifically, the security system 20 is in an "active" disarmed state (see arrow 116), but the wireless device 22 is not yet in one or more "actual" disarmed states (see arrow 118). Therefore, the "actual" alarm state of the wireless device 22 (see arrow 120) can be longer than the "active" alarm state of the security system 20 (see arrow 122), generally by an amount equal to the buffer interval 114.

[0065] In box 216, the disarming command 102 can be buffered via controller 28 (i.e., see [link]). Figure 3 (Buffer interval 114). It is anticipated and understood that buffering begins immediately upon receiving the disarming command 102, thus allowing the command to be buffered while the disarmed state response 112 is sent simultaneously. Furthermore, the disarming command 102 can be buffered regardless of whether the wireless device 22 is in a sleep or wake-up state. In one embodiment, if a heartbeat is received from the wireless device 22 during the buffer interval 114, the disarming command 102 can be integrated into the heartbeat response to the wireless device 22. In this case, the wireless device 22 will be disarmed. The buffer interval 114 therefore depends on what occurs first (alarm or heartbeat).

[0066] In block 218, the sensed event can occur at wireless device 22 (i.e., before the heartbeat is sent), and the subsequent alarm condition 100 can be sent from wireless device 22 via AP device 24 and to controller 28. It is generally understood that block 218 may occur even if disarm command 102 is buffered, if wireless device 22 is armed, and the alarm occurs before wireless device 22 sends a heartbeat to retrieve disarm command 102 in cloud 30. In one scenario, the heartbeat can be sent before the alarm / event occurs, then the system is disarmed, and no sensing of the event will occur.

[0067] In box 220, once alarm condition 100 is received by controller 28, the controller can check the system status (i.e., armed or disarmed). If the system is disarmed, controller 28 can discard the alarm and send a disarm command to wireless device 22 to synchronize the status. This occurs when alarm command 100 is received and cloud 30 is in a disarmed state. That is, the buffer for disarm command 102 generally stops, and alarm condition 100 is generally suppressed. It is expected and understood that wireless device 22 can generally receive disarm command 102 immediately after sending alarm condition 100, without waiting for the next heartbeat response. In this way, the responsiveness of security system 20 is not hindered.

[0068] Although not specifically illustrated, the wireless device 22 can be associated with a line-powered device. For example, the line-powered device could be an audible alarm device that is hardwired to receive power. The line-powered device can communicate directly with the wireless device and controller 28 via a path that can be wireless or hardwired.

[0069] The advantages and benefits of security system 20 include a method for directly arming and disarming wireless devices, eliminating the need for field hubs or panels. Furthermore, the system maintains the same user experience for disarming battery-powered devices, which do not require periodic wake-up to receive disarm commands. Other advantages include a method for automatic disarming that may not require external devices to track user or object locations, may not increase or require additional communication load due to message exchange, and can maintain similar costs and overall system energy savings.

[0070] Event notification system with dynamically configurable communication frequency

[0071] refer to Figure 3 and Figure 5 The event notification system 20 (e.g., a security system) can be configured to dynamically adapt to the wake-up intervals of one or more wireless devices 22. One embodiment of dynamically configurable frequency communication can depend on the system's arming state. For example, when system 20 is in an "actually" disarmed state 118, wireless device 22 can send a large number of heartbeats 106 to AP device 24 at a first heartbeat frequency or rate, and when system 20 is in an "actually" armed state 120, wireless device 22 can send a large number of heartbeats 106 to AP device 24 at a second heartbeat frequency. To improve the efficient operation of wireless device 22 (i.e., improve responsiveness and / or reduce power consumption), the first frequency can be greater than the second frequency. More specifically, the duration of each successive sleep state when the wireless device is in an "actually" armed state 120 (see arrow 124) is greater than the duration of each successive sleep state when the wireless device 22 is in an "actually" disarmed state 118 (see arrow 126). Furthermore, the duration of the "actual" armed state 120 can generally be equal to the duration of the "active" armed state 122 plus the buffer interval 114 completed when an alarm or heartbeat is received. It is anticipated and understood that the term "heartbeat" can include any communication between the wireless device 22 and the control component 23 (see [link to documentation]). Figure 1 ).

[0072] In one embodiment, the wireless device 22 may be a smart device and may be programmed to increase the frequency of the heartbeat 106 when the device 22 receives the disarming command 112. In another embodiment, the controller 28 may include instructions to the wireless device 22 as part of the disarming command 112 and facilitating a change in the heartbeat frequency. The frequency of the heartbeat in relation to the arming and disarming states may be configurable from the cloud 30.

[0073] In one embodiment, and as previously described, controller 28 may be configured to buffer the disarm command 102 before controller 28 sends the disarm command 102 to wireless device 22 via the next heartbeat response 108, or in direct response to (i.e., disarm command 102) alarm 102 (see [link to relevant documentation]). Figure 3 (Buffer interval 114 in the middle).

[0074] refer to Figure 6 The method of operating security system 20 includes placing the wireless device in a disarmed state 118 in block 300. In block 302, when the wireless device transitions to and is in the "actually" disarmed state 118, communication on a first frequency is established between the wireless device 22 and the control component 23. In block 304, the wireless device can be placed in an "actually" armed state 120. In block 306, when the wireless device 22 transitions to and is in the "actually" armed state 120, communication on a second frequency is established between the wireless device 22 and the control component 23. It is anticipated and understood that during the buffer interval 114, the wireless device 22 can communicate with the control component 23 on the second frequency.

[0075] refer to Figure 7 and Figure 8 The illustration shows a second embodiment of the security system 20, in which the frequency of communication between the wireless device 22 and the control component 23 is dynamically configurable. In this second embodiment, the server 28 or cloud service can be configured to monitor and determine the most likely time when a user connects to the wireless device 22 via an interface. The server 28 can typically develop and store one or more models 128 (see [reference]) associated with user habits and interaction history. Figure 8 As a result, the wake-up interval of wireless device 22 can be dynamically adapted based on learned user habits indicated by server 28, which will maximize energy savings and minimize the impact of long latency. Furthermore, such usage probabilities can be used to enable / disable other subsystems and / or devices of security system 20.

[0076] In one example, model 128 may include the probability of user interaction 130, which can resemble a bell curve. The higher the probability of user interaction, the more frequently communication occurs between control component 23 and wireless device 22.

[0077] Model 128 can be developed using statistical and probabilistic inference (i.e., Markov chains, statistical regression, and others) or machine learning techniques (i.e., neural networks, support vector machines, and others). Model 128 can generally find relevance in any information that might affect the probability of activation (including but not limited to user presence, time of day, system state, weather forecasts, and others). Model 128 can be periodically updated using new data learned through interaction with the system. Model 128 can be initialized using default values ​​established through reasonable assumptions. If desired, the computation and learning of probabilistic model 128 can be performed in a separate, non-low-power system or device, rather than in the cloud 30, mobile device, application 26, or controller 28, which can then pass the results back to wireless device 22 or cloud 30.

[0078] The advantages and benefits of the security system 20, which utilizes configurable frequency communication between the control component 23 and the wireless device 22, include an operating method with lower command latency than more conventional systems. Other advantages include an improved user experience with faster arming capability, extended battery life of the wireless device 22 (i.e., longer sleep intervals when armed), and reduced network traffic (i.e., reduced packet switching).

[0079] Server-initiated non-beacon tracking wireless communication system

[0080] refer to Figure 9 This provides a schematic diagram of another embodiment of communication between wireless device 22, AP device 24, server 28 (i.e., and / or cloud 30), and mobile application 26, generally outlining the communication along a timeline (see arrow 56). This particular series of communications is generally depicted as a process in which power consumption in Wi-Fi PSM device 22 can be reduced by eliminating the need to send heartbeats from PSM device 22 and eliminating AP beacon tracking, and by synchronizing the wake-up (i.e., entering a wake-up state) of PSM device 22 using a startup request from cloud 30.

[0081] Server 28 can generate server heartbeats. Attached to the server heartbeat can be the heartbeat interval for PSM device 22 and any kind of command. In operation, PSM device 22 will wake up, receive one or more server heartbeats, respond to any command / request as part of the heartbeat, and return to sleep until the heartbeat interval 402, which was part of a previously sent heartbeat, expires. In the event of a loss of synchronization with server 28, PSM device 22 can remain awake until the next heartbeat (i.e., the complete server heartbeat interval) for resynchronization with server 28.

[0082] More specifically, in the initial wake-up state 400, the wireless communication process can begin from the synchronization phase (see arrow 399), where server 28 sends a synchronization heartbeat 402 via AP device 24 to wireless device 22. Wireless device 22 can then send a synchronization heartbeat response 404 via AP device 24 to server 28. Similarly, during the synchronization phase 399, and in the initial wake-up state 400, wireless device 22 can send a Wi-Fi enabled PSM signal 406 to AP device 24 and can respond by receiving an ACK 408 from AP device 24. Upon receiving ACK 408, wireless device 22 can enter sleep state 410. Synchronization heartbeat 402 may contain information related to a heartbeat interval (see arrow 412) representing the duration measured from the moment wireless device 22 enters the wake-up state to the end of the next sleep state.

[0083] refer to Figure 9 , Figure 10A as well as Figure 10B The diagram generally illustrates a method of operating a "server-initiated non-beacon-tracking wireless communication system" 20. In block 500, a synchronization heartbeat 402 can be sent from server 28 via AP device 24 and to wireless device 22 (e.g., a PSM device). The synchronization heartbeat 402 includes information related to the heartbeat interval 402 and thus instructs when wireless device 22 to wake up. In block 502, a first heartbeat response 404 is sent from PSM device 22 via AP device 24 and to server 28 (i.e., and / or cloud 30) to synchronize the PSM device with the server.

[0084] In block 504, when in wake state 400, a Wi-Fi enabled PSM signal 406 is sent from PSM device 22 to AP device 24. In block 506, an ACK signal 408 is sent from AP device 24 to PSM device 22 in response to the Wi-Fi enabled PSM signal 406. In block 508, PSM device 22 enters a first sleep state 410 from the first wake state 400. In the example where the wake state begins when a heartbeat is received, the sum of the durations of the first wake state 400 and the first sleep state 410 is approximately equal to the heartbeat interval 412.

[0085] In box 510, and during normal operation, application command 414 is sent from mobile application 26 to server 28. In box 512, application command 414 can be buffered by server 28 until the concurrently occurring heartbeat interval 412 has expired. In box 514, and once the relevant heartbeat interval 412 expires, the buffered application command 414 proceeds to AP device 24 via a second heartbeat 416, which is sent upon the expiration of the concurrently occurring heartbeat interval 412 and the initialization of the next interval. In box 516, the second heartbeat 416 and thus application command 414 can be buffered by AP device 24. It is anticipated and understood that AP buffering of heartbeat 416 may not occur or may generally be brief. However, this AP buffering capability provides a degree of system tolerance if wireless device 22 is not accurately synchronized with server 28 or becomes somewhat out of sync.

[0086] In box 518, wireless device 22 can enter a second wake-up state 418 from a previous sleep state, almost immediately after the expiration of the associated heartbeat interval 412. In box 520, power saving (PS) polling 420 can be sent from PSM device 22 to AP device 24. In box 522, a second heartbeat 416 can be sent from AP device 24 to PSM device 22. In box 524, an ACK 422 can be sent from PSM device 22 to AP device 24. In box 526, a second heartbeat response 424 can be sent from PSM device 22 via AP device 24, via server 28, and to mobile application 26. In box 528, PSM device 22 enters a second sleep state 426 from the second wake-up state 418. In box 530, almost immediately after the expiration of the associated heartbeat interval 412, PSM device 22 enters a third wake-up state 428 from the second sleep state 426, and the PS polling process generally repeats itself.

[0087] The benefits and advantages of the “cloud-initiated non-beacon tracking wireless communication system” can include the ability of PSM device 22 to ignore the beacon of AP device 24 and the extended time during which the PSM device can remain in sleep mode without losing packets. Other advantages include a more efficient non-beacon tracking operation method than conventional Wi-Fi PSM because PSM device 22 does not need to wake up to track beacons, thus allowing it to sleep for longer time intervals (i.e., up to the AP deassociation time). Server synchronization allows message exchange to begin on the server 28 side, reducing the time that device 22 must be active due to heartbeat generation and uplink latency 68. Furthermore, implementation of this method in multi-core systems (i.e., one processor for Wi-Fi communication and another for applications) can become even more efficient because the application core does not need to wake up if a command is not received by the Wi-Fi core.

[0088] The various functions described above can be implemented or supported by a computer program formed of computer-readable program code and embodied in a computer-readable medium. Computer-readable program code can include source code, object code, executable code, and others. Computer-readable medium can be any type of medium accessible by a computer and can include read-only memory (ROM), random access memory (RAM), hard disk drive, compact disc (CD), digital video disc (DVD), or other forms.

[0089] The terms used herein (such as component, module, system, etc.) are intended to refer to computer-related entities (hardware, a combination of hardware and software, or software execution). By way of example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, and / or a computer. It is understood that a server and an application running on a server can be a component. One or more components may reside within a process and / or a thread of execution, and components may be centralized on a single computer and / or distributed across two or more computers.

[0090] While this disclosure has been described with reference to exemplary embodiments, those skilled in the art will understand that various changes can be made and equivalents can be substituted without departing from the spirit and scope of this disclosure. Furthermore, various modifications can be applied to adapt the teachings of this disclosure to particular situations, applications, and / or materials without departing from its basic scope. This disclosure is therefore not limited to the specific examples disclosed herein, but includes all embodiments falling within the scope of the appended claims.

Claims

1. A method for operating an event notification system, comprising: Send the disable command from the user application to the controller; In response to the disable command, a valid disable response is sent from the controller to the user application; as well as The controller buffers the disable command. This further includes: The event status is sent from the power saving mode (PSM) device to the controller via the access point (AP) device; The event condition is suppressed at the controller, while the disable command is buffered; and In response to receiving the event status, a buffer disable command is sent from the controller through the AP device and to the PSM device. The valid disabled response indicates that the event notification system is in a disabled state, while the PSM device is not in a disabled state.

2. The method according to claim 1, wherein, The controller is a virtual panel that is part of a cloud server.

3. The method according to claim 1 or 2, further comprising: The enable command will be sent from the user application to the controller; The controller buffers the enable command; The heartbeat is transmitted from the PSM device to the AP device and then to the controller. The heartbeat response is sent from the controller through the AP device and to the PSM device, wherein the heartbeat response includes the enable command and is in response to the heartbeat.

4. The method of claim 3, further comprising: Upon receiving the heartbeat response, the PSM device is activated; as well as An enable confirmation signal will be sent from the PSM device through the controller and to the user application.

5. The method according to claim 4, wherein, The AP device is a router.

6. The method according to claim 4, wherein, The user application is a smartphone.

7. The method according to claim 4, wherein, The event notification system is a security system, the enable command is an arming command, and the disable command is a disarming command.

Images