Patent Description:
Wireless sensors are used to detect a wide variety of remote, physical conditions, such as the status of a door or window (i.e., open, closed), the occurrence of motion, the presence of heat, ambient temperatures, vibration, glass breakage, thermal readings, light detection, etc. Such sensors find widespread application in a variety of industries, including home security, home automation and industrial HVAC. These sensors are often wireless, battery-powered devices, enabling them to be placed in remote locations around a home or industrial setting.

Until recently, in order to preserve battery life, sensors were designed as transmit-only devices, i.e., they did not contain a receiver, due to the additional power consumption required by such a receiver. However, recent technological improvements have made battery-powered, two-way sensors (comprising a transmitter and a receiver), a reality. For example, new Z-Wave® <NUM> series transceiver chips are available from Silicon Laboratories, Inc. of Austin, Texas that contain both a transmitter and a receiver and consume very low power during operation.

The Z-wave <NUM> series transceiver chips operate in accordance with a Z-wave <NUM> series communication protocol offered by Silicon Laboratories, Inc. , headquartered in Austin, Texas, that allows sensors to relay information over relatively large distances. Sensors that operate in this way are commonly referred to as "mesh" sensors that operate together with other mesh sensors to form a "mesh" network. Other common mesh network technologies include the well-known Zigbee® and Insteon® technologies.

Many wireless communication protocols utilize acknowledgement messages, known as "ACKs", to allow a transmitter to know whether a message transmitted by the transmitter was received by a receiver. Retransmissions are possible, however in battery-powered sensors, each time that a retransmission occurs, the battery life is diminished.

It would be desirable to transmit messages by wireless sensors that maximize battery life while ensuring that messages are received.

<CIT> discloses systems and methods for controlling devices such as lights, by sending control message from a controller to devices with an efficient protocol.

<CIT> discloses a computer network system using encryption to prevent network peripheral takeover activity.

<CIT> discloses methods and systems for joining a wireless connection advertisement which include connecting to a commissioning device via a wireless point-to-point communication.

The embodiments described herein relate to methods, systems, and apparatus for efficient message transmission by sensors in a system, such as in a home security system, industrial monitoring system, or any system comprising a central controller in communication with one or more wireless sensors.

In one embodiment, a wireless sensor is described, comprising a detector for detecting an event in proximity to the wireless sensor, a memory for storing processor-executable instructions, a mesh-network transceiver for transmitting information to and receiving information from a controller, either directly or via another wireless security sensor or a repeater, a processor, coupled to the detector, the memory and the mesh-network transceiver, for executing the processor-executable instructions that causes the processor to determine that the event has occurred via a signal received from the detector. In response to determining the event has occurred, generate an encrypted frame, comprising an unencrypted identification of the wireless security sensor and an encrypted event identification that identifies the type of event that has occurred, transmit the encrypted frame, receive an acknowledgement from the controller that the encrypted frame was received, and receive a response from the controller that the frame was decrypted successfully.

In another embodiment, a method is described, performed by a wireless sensor, for efficient message transmission by the wireless sensor, comprising determining that the event has occurred via a signal received from the detector. In response to determining that the event has occurred, generating an encrypted frame, comprising an unencrypted identification of the wireless security sensor and an encrypted event identification that identifies the type of event that has occurred, transmitting the encrypted frame, receiving an acknowledgement from the controller that the encrypted frame was received, and receiving a response from the controller that the frame was decrypted successfully.

The features, advantages, and objects of the present invention will become more apparent from the detailed description as set forth below, when taken in conjunction with the drawings in which like referenced characters identify correspondingly throughout, and wherein:.

The present application relates to a system, method and apparatus for efficient message transmission by wireless sensors. While the remainder of this disclosure discusses an embodiment of the invention in the context of a home security system and, specifically, a home security door/window sensor, it should be understood that the principles described herein could be used in other types of sensors, such as motion, temperature, pressure, humidity, vibration, shock, and other wireless sensor types.

<FIG> is a simplified block diagram of a security system <NUM> comprising a central controller <NUM> in wireless communication with a number of devices <NUM>, <NUM>, <NUM>, and <NUM>, either directly (as shown by wireless signal <NUM>) or indirectly (as shown by wireless signals <NUM>, <NUM> and <NUM>). In some embodiments, two-way communications between/among central controller <NUM> and one or more devices is possible while in other embodiments, only one-way communications are possible. In the embodiment shown in <FIG>, two-way communications are possible between/among central controller <NUM> and the devices.

Security system <NUM>, utilizing indirect communications as shown, may be referred to as a "mesh" network. A mesh network provides for relaying messages between and among devices, or "nodes", in order to extend the range of the network. In <FIG>, device is out-of-range from communicating directly with central controller <NUM>, but may nevertheless communicate with central controller <NUM> via device <NUM>, which relays messages between device <NUM> and central controller <NUM>. Similarly, device <NUM> communicates with central controller <NUM> via device <NUM> and <NUM>. As such, in general, each device in system <NUM> is capable of both transmitting and receiving messages from other devices and/or central controller <NUM>.

The devices shown in <FIG> may comprise one or more different types of security sensors (door or window sensors, motion detectors, garage door tilt sensors, glass break sensors, etc.) and one or more "repeaters" that are typically AC-powered devices whose sole function is to relay messages between devices. In <FIG>, device <NUM> is such a repeater, device <NUM> comprises a garage door tilt sensor, device <NUM> comprises a door/window sensor and device <NUM> comprises a motion sensor. While only three types of sensors are shown in <FIG>, and only one of each sensor type, typically a plurality of door/window sensors are used in a security system, each to monitor a particular door or widow, and in some cases, more than one motion detector is used to detect motion in more than one area of a home or business. Additionally, other types of sensors could be used, such as one or more glass break sensors, shock sensors, cameras, etc. Finally, other components could be used in system <NUM>, such as one or more remote keypads that can arm and disarm system <NUM>, audio smoke alarm detectors, etc. Each one of the aforementioned components may embody the transmission efficiency techniques discussed herein.

Door/window sensor <NUM> is used for monitoring a status of a door or a window, such as when the door or window is opened or closed and, in some embodiments, when a door or window is locked or unlocked. In one embodiment, door/window sensor <NUM> comprises a well-known reed-switch and magnet combination, where door/window sensor <NUM> detects door or window movement as the reed switch changes state when the magnet is moved via door or window movement. In other embodiments, other techniques are used to determine that status of a door or a window, such as using an accelerometer to determine door or window movement.

When a door/window event occurs, door/window sensor <NUM> transmits an event signal comprising an encrypted data packet or "frame" to central controller <NUM>, either directly or through one or more other devices in system <NUM>. The event signal comprises an identification of a sensor that transmitted the event signal (such as its serial number, a pre-assigned string of numbers and/or letters such as a NodeID in an embodiment where a Z-Wave® protocol is used, or some other unique identifier), and an event type indicating the type of event that occurred (i.e., door open, window closed, etc.). Door/window sensor <NUM> may, in addition, transmit encrypted status messages, either at predetermined times or in response to a request from central controller <NUM>. Such encrypted status messages indicate whether a door or a window is currently open, closed, locked and/or unlocked, etc..

After transmitting an event signal or status signal, door/window sensor <NUM> waits a predetermined, configurable amount of time to receive an acknowledgement message, or ACK, from central controller <NUM> to ensure that the signal was successfully received by central controller <NUM>. After an ACK is received, door/window sensor <NUM> waits a predetermined, configurable amount of time to receive a response from central controller <NUM>, indicating that the encrypted event signal or status signal was successfully decrypted. If either the ACK or the response is not received with the configurable, predetermined time limits, door/window sensor <NUM> may retransmit the signal. This process may be repeated a configurable number of times, as described in more detail later herein.

Central controller <NUM> comprises a security panel, which is a well-known device used to monitor all of the sensors in system <NUM>, and also may be used to notify one or more persons when an event is detected by one of the sensors. For example, if a door monitored by door/window sensor <NUM> is opened, door/window sensor <NUM> transmits a message to central controller <NUM> via repeater <NUM> indicative of the event, e.g., that a door has been opened. In response, when security system <NUM> is armed, central controller <NUM> may cause a siren located inside and/or outside a premises monitored security system <NUM> to produce a very loud, audible siren, to cause one or more lights to turn on, to lock or unlock one or more wireless locks, etc. Alternatively, or in addition, central controller <NUM> may send an alert to a remote monitoring station that monitors thousands of security systems in order to dispatch relevant authorities when an alarm is received from one of the security systems, typically after verification of the event by an employee of the remote monitoring station.

In some embodiments, the functionality of central controller <NUM> may be performed by a server located in "the cloud", i.e., a server coupled to a gateway device within a home or business via the Internet. In this embodiment, the gateway device receives event signals from the sensors in system <NUM> and forwards them to the Internet-based server. The server processes the signals and, as a result, may send commands to the gateway device, such as commands that cause the gateway device to activate a loud siren, to cause one or more lights to turn on, to lock or unlock one or more wireless locks, etc. The server could, additionally, notify a remote monitoring station of events that occur. Thus, references made to "central controller <NUM>" herein shall also include Internet-based processing devices, such as the cloud-based server.

<FIG> is a functional block diagram of one embodiment of door/window sensor <NUM> in accordance with the teachings herein. Specifically, <FIG> shows processor <NUM>, memory <NUM>, detector <NUM>, mesh-network transceiver <NUM>, and tamper detection device <NUM>. It should be understood that the functional blocks may be coupled to one another in a variety of ways, and that not all functional blocks necessary for operation of door/window sensor <NUM> are shown (such as a battery), for purposes of clarity. It should be further understood that sensors other than a door/window sensor could comprise the same or similar functional blocks as shown in <FIG>, each having a different detector <NUM> and different processor-executable instructions stored in memory <NUM>. For example, in a door/window embodiment, detector <NUM> may comprise a reed switch and magnet combination, but in a motion detector, detector <NUM> may comprise a passive infra-red detector, a tilt sensor in a garage door sensor, a lens/camera in a digital camera, a microphone in a glass break sensor, an accelerometer for a shock sensor, etc..

Processor <NUM> is configured to provide general operation of the door/window sensor <NUM> by executing processor-executable instructions stored in memory <NUM>, for example, executable code. Processor <NUM> may comprise a general purpose processor, such as an ADuC7024 analog microcontroller manufactured by Analog Devices, Inc. of Norwood Massachusetts, although any one of a variety of microprocessors, microcomputers, and/or microcontrollers may be used alternatively. In one embodiment, processor <NUM> comprises a Z-Wave <NUM> series processor, such as a ZGM130S SIP Module, sometimes used in combination with a general purpose processor, in an embodiment that utilizes the Z-wave <NUM> protocol. Due to the relative small size of door/window sensor <NUM>, and the fact that most door/window sensor <NUM> are battery-powered, processor <NUM> is typically selected to have low power consumption, small in size, and inexpensive to purchase.

Memory <NUM> is coupled to processor <NUM> and comprises one or more information storage devices, such as RAM, ROM, flash, or other type of electronic, optical, or mechanical memory device. Memory <NUM> is used to store processor-executable instructions for operation of the door/window sensor <NUM> as well as any information used by processor <NUM>, such as threshold information, parameter information, identification information, current or previous door or window status information, etc..

Detector <NUM> is coupled to processor <NUM> and reports, monitors or determines a state, physical condition, attribute, status, or parameter of something, such as the status of a door, window, gate, or other entrance or exit barrier (e.g., open, closed, locked, unlocked, etc.), a temperature, a humidity, motion, shock/vibration, glass breakage, etc. Detector <NUM> may comprise a reed switch, an ultrasonic transceiver, an infrared transceiver, a tilt sensor, an accelerometer, a motion sensor, microphone, or some other device to report, monitor or determine a state, physical condition, attribute, status, or parameter of a thing or area in proximity to a sensor.

Mesh-network transceiver <NUM> is coupled to processor <NUM> and comprises circuitry necessary to wirelessly transmit event signals and/or status messages between door/window sensor <NUM> and central controller <NUM>, either directly or through one or more intermediate devices, such as repeater <NUM>, commonly used in popular mesh networks. Mesh-network transceiver <NUM> also is configured to receive wireless messages sent from central controller <NUM> and/or other devices in security system <NUM>, including relaying messages from one device to another or to central controller <NUM>. Such circuitry is well known in the art and may comprise transceivers configured in accordance with a Z-Wave®, Zigbee®, RF4CE, 6LoWPAN, or WirelessHART EnOcean, ISAIOO. lla, or IEEE <NUM>. <NUM> protocol, or some other mesh network protocol. In one embodiment, mesh-network transceiver is integrated with processor <NUM> and memory <NUM>, comprising the aforementioned ZGM130S SIP Module.

Tamper detection device <NUM> is coupled to processor <NUM> and is used to detect tampering with door/window sensor <NUM>, for example, disabling door/window sensor <NUM>, typically by removing a cover of door/window sensor <NUM> and removing the battery. Tamper detection device <NUM> typically comprises a switch that is depressed when a cover of door/window sensor <NUM> is installed over a reciprocal housing that contains the electronics of door/window sensor <NUM>. The cover is typically manufactured with a physical protrusion that is designed to depress tamper detection device <NUM> when the cover has been installed. When the cover is removed, the switch changes state, causing processor <NUM> to detect this state change. In some embodiments, processor <NUM> "latches" any indication of tampering from tamper detection <NUM>, noting the day and time that a tamper was detected, and stores this information in memory <NUM>. In this way, processor <NUM> may indicate tampering to central controller <NUM> at a later time, thus potentially saving battery life.

<FIG> is a flow diagram illustrating one embodiment of a method performed by door/window sensor <NUM> for efficient transmission of messages to central controller <NUM>, either directly or indirectly via repeater <NUM> and/or other devices in security system <NUM>. It should be understood that although the method is described in terms of a home security door or window sensor, the concepts described with respect to the method could be used in other types of security and non-security sensors, such as motion sensors, garage door tilt sensors, glass break detectors, shock sensors, cameras, temperature sensors, pressure sensors, or any type of wireless sensing device. It should be understood that in some embodiments, not all of the steps shown in <FIG> are performed. It should also be understood that the order in which the steps are carried out may be different in other embodiments.

At block <NUM>, detector <NUM> detects that a door or window being monitored by door/window sensor <NUM> has changed state, i.e., has been opened or closed, typically when a reed switch inside detector <NUM> opens or closes as a result of a loss of a magnetic field produced by a magnet attached to the door or window. Upon detection of the changed state, detector <NUM> provides a signal to processor <NUM> indicative of the change.

At block <NUM>, processor <NUM> receives the signal from detector <NUM>, and in response, determines that an event is present, by processing the signal.

At block <NUM>, processor <NUM> generates an encrypted data packet, or frame, in response to determining that an event has occurred, i.e., that the door has been opened. The encrypted frame comprises an encrypted portion and an unencrypted portion. The unencrypted portion comprises an identification of door/window sensor <NUM> and the encrypted portion comprises an event identification that identifies the type of event that has occurred. In one embodiment, encryption is performed using an S2 encryption method, well known in the art, although other types of encryption may be used alternatively. The identification of door/window sensor <NUM> comprises a unique identification number or other alpha-numeric sequence stored in memory <NUM>, typically a serial number or, if door/window sensor <NUM> is configured in accordance with the Z-Wave <NUM> series protocol, a NodeID.

The event identification comprises, for a door or window sensor, a value that indicates when a door or window has been opened and, in some embodiments, when a door or window has been closed. Other events identifications may include an identification when a door or window has been locked or when a door or window has been unlocked. The event identification may, in some cases, also comprise a sensed reading, such as a temperature, pressure, humidity or other physical characteristic of an area proximate to a sensor. Similarly, in other sensor types, an event identifications may identify when motion is present or not in a motion detector, when a garage door has been opened or closed in a garage door sensor, etc. An identification of one or more of these events, typically in the form of a hexadecimal number, is stored in memory <NUM> for use by processor <NUM> to generate the encrypted frame.

In one embodiment, the encrypted frame comprises a double encapsulated command as defined by the Z-Wave protocol, with one encapsulation comprising a Supervision encapsulation and another encapsulation comprising an Encryption encapsulation. Encapsulation is defined as a placement, or "nesting", of one command or function into another. For example, a "Notification command" in accordance with the Z-Wave <NUM> series protocol may be the payload of a Supervision Get command, while the Supervision Get command may be the payload of an encryption command.

A Notification command is defined in the Z-Wave <NUM> series protocol, for providing event information to central controller <NUM>. Other types of Z-wave <NUM> commands may be used instead of the Notification command, for example, commands that fall under a Barrier Operator command class, commands that fall under a Basic command class, commands that fall under a Binary Sensor command class, etc. The Z-Wave <NUM> series protocol offers numerous ways to convey event information to central controller <NUM>.

In one embodiment, rather than generating a single command that identifies a particular event, as described above, it may be desirable to transmit other information as well. In this case, processor <NUM> may generate a single command that contains an identification of the event that occurred, plus one or more ancillary statuses of door/window sensor <NUM>, or it may contain two or more ancillary status statuses without an event identification, as in the case of a status message. An "auxiliary status" is a state of a sensor other than its primary function. For example, a state of a battery (i.e., "low", remaining battery life, an actual or relative battery life, etc.) used by a door/window sensor is considered to be auxiliary status, as a battery status is auxiliary to the function detecting when a door or window has been opened by a door/window sensor. Similarly, a tamper status (i.e., whether a sensor has been tampered with) of a motion detector is an auxiliary status to the motion detector's primary function - to detect motion.

Bundling multiple statuses with transmission of an event identification may be used to limit the number of transmissions and to extend battery life. For example, if processor <NUM> determines that an event occurred, processor <NUM> may, in response, determine one or more auxiliary statuses of door/window sensor <NUM>, such as whether the battery is low, an amount of remaining battery life, whether door/window sensor <NUM> has previously been tampered with as reported by tamper detection device <NUM>, or, in general, a fault of some kind generated by processor <NUM> and stored in memory <NUM>. In one embodiment utilizing the Z-wave <NUM> protocol, processor <NUM> generates a "Multi Command Encapsulated" command, which is one type of command from a "Multi Command Encapsulated command class" used to bundle multiple "commands" (i.e., event and status notifications) into a single encapsulation command.

<FIG> shows the structure of a Multi Command Encapsulated command, comprising x number of commands.

In any case, a single command or a Multi Command Encapsulated command may be inserted as a payload of a "Supervision Get" command as shown in <FIG>. A Supervision Get command is a command defined by the Z-Wave <NUM> series protocol that requests an immediate and/or future status of a process initiated by the command. For example, when a door is opened, processor <NUM> generates an encrypted frame comprising the Notification command, which requires central controller <NUM> to respond to door/window sensor <NUM> with a response indicating that central controller <NUM> decrypted the Notification command successfully.

The Supervision Get command, comprising either a single command or a Multi Command Encapsulated command, is then encrypted by processor <NUM>, in one embodiment, in accordance with S2 encryption defined by the Z-Wave <NUM> series protocol, which is a framework for allowing devices to communicate securely in a Z-wave <NUM> network. In this embodiment, processor <NUM> encrypts the Supervisory Get command using one of several available encryption types, such as AES-<NUM>, and then places the encrypted result into a Security <NUM> Message Encapsulation command as its payload.

Once the Security <NUM> Message Encapsulation command has been created, processor <NUM> creates a transport frame, as shown in <FIG>, comprising an unencrypted Preamble, an unencrypted Home ID of system <NUM>, an unencrypted Source ID (i.e., an identification of door/window sensor <NUM> in system <NUM>), an unencrypted a Data Length indicating the length of the transport frame, the encrypted Supervision Get command, and an unencrypted Checksum.

Once the transport frame has been constructed, processor <NUM> generates an encrypted PHY/MAC frame, also shown in <FIG>, comprising a Start of Frame (SOF) symbol, frame data (i.e., the encrypted Supervision Get command and the unencrypted other data, such as Home ID, Source ID, etc.) and an End of Frame (EOF) symbol. The frame data is the encrypted Supervision Get command contained in the Security <NUM> Message Encapsulation command.

After the encrypted PHY/MAC frame has been generated, processor <NUM> causes it to be transmitted by mesh-network transceiver <NUM>, either directly to central controller <NUM>, or to another device in system <NUM> for relaying the encrypted PHY/MAC frame to central controller <NUM>.

At block <NUM>, processor <NUM> waits a configurable, predetermined time to receive an acknowledgement from central controller <NUM>, either directly or via one or more other devices, that the encrypted PHY/MAC frame was successfully received. Successful reception by central controller <NUM> may mean that the encrypted PHY/MAC frame was received without an error in the checksum of the transport frame, or by using some other technique well-known in the art. If an acknowledgement from central controller <NUM> is not received within the configurable, predetermined time, then processor <NUM> retransmits the encrypted PHY/MAC frame. This cycle continues for a configurable, predetermined number of times until either an acknowledgement is received from central controller <NUM>, or mesh-network transceiver <NUM> has retransmitted the PHY/MAC frame the configurable, predetermined number of times, at which point processor <NUM> ceases in any further attempts to transmit the encrypted PHY/MAC frame. For example, processor <NUM> may wait five seconds after transmitting an original PHY/MAC frame or retransmission and retransmit <NUM> times if no acknowledgement is received. In another embodiment, processor <NUM> may wait a variable amount of time before retransmitting each, successive retransmission, i.e., a first retransmission may occur after waiting <NUM> seconds from retransmission of the PHY/MAC, then wait <NUM> seconds after another retransmission, then wait <NUM> seconds after another transmission, etc. A random amount of time is also generally added to these wait times, in order to avoid collisions between other transmitting devices in system <NUM>, on the order of tens or hundreds of milliseconds.

At block <NUM>, after an acknowledgement is received from central controller <NUM>, processor <NUM> waits a configurable, predetermined time period (which may be different than the configurable, predetermined time period, described above, to wait for acknowledgements) to receive a response to the encrypted PHY/MAC frame, in a Z-Wave <NUM> series embodiment referred to as a Supervision Report. The response is different than the acknowledgement: the response indicates that the information in the encrypted PHY/MAC frame has been successfully decrypted or, more generally, that central controller <NUM> has taken an action in response to receiving the PHY/MAC frame (such as causing a siren to sound, alerting a remote monitoring center, alerting an individual via SMS messaging, etc.), and therefore the information in the encrypted PHY/MAC was properly conveyed to central controller <NUM>. If a response from central controller <NUM> is not received within the configurable, predetermined time, then processor <NUM> retransmits the encrypted PHY/MAC frame and then processor <NUM> waits for an acknowledgement from central controller <NUM>, as before. This cycle continues for a configurable, predetermined number of times until either a response is received from central controller <NUM>, or mesh-network transceiver <NUM> has retransmitted PHY/MAC frame the configurable, predetermined number of times. For example, if the number of retransmissions for acknowledgements is set to <NUM>, and the number of retransmissions for responses is set to <NUM>, and if processor <NUM> receives an acknowledgement after the second retransmission, processor <NUM> may transmit the original encrypted PHY/MAC frame a total of <NUM> times (original transmission plus <NUM> more retransmissions) before processor <NUM> ceases any more attempts to transmit the encrypted frame.

The configurable, predetermined times discussed with respect to either acknowledgements, responses, or both, may be actively managed by processor <NUM> to account for actual, round-trip times between when an event or status signal is transmitted by door/window sensor <NUM> and when an acknowledgement and/or a response is received. Round-trip times may vary, depending on whether door/window sensor <NUM> communicates directly with central controller <NUM> (resulting in relatively fast round-trip times) or whether door/window sensor <NUM> must communicate through one or more repeaters and/or other mesh devices in system <NUM> to reach central controller <NUM> (resulting in longer round-trip times due to the additional processing required by each repeating device). In one embodiment, processor <NUM> determines one or more round-trip times for respective acknowledgements and/or responses after transmission/retransmission of event or status signals, and stores the results in memory <NUM>. Then, processor <NUM> may determine an expected response-time based on the results. For example, processor <NUM> may average the round-trip time of the last <NUM> transmission and use the average as the predetermined time to wait for acknowledgements and/responses, use a last-recorded round-trip time as the predetermined time, use a median of a previous <NUM> round-trip times, etc..

<FIG> is a flow diagram illustrating a method performed by door/window sensor <NUM> for stopping an intruder from quickly opening then closing a door monitored by door/window sensor <NUM>, without being detected. It should be understood that in some embodiments, not all of the steps shown in <FIG> are performed, and that the order in which the steps are carried out may be different in other embodiments.

In some prior art security systems, a door/window sensor typically sends a signal when it detects that a door or window has been opened. However, for a variety of reasons, the signal may not be received by a central controller. An intruder may quickly close the door or window, causing the door/window sensor to transmit another signal, indicating that the door or window is closed. Thus, the central controller fails to detect the intruder, because the signal indicating "closed" may be received without the central controller ever receiving the initial signal that the door or window had been opened. The method described by <FIG> eliminates this problem.

At block <NUM>, door/window sensor <NUM> is monitoring a door and operating normally, in communication with central controller <NUM>, either directly or via one or more other sensors and/or repeaters, which is in an armed-home or armed-away state. In an armed-home state, perimeter sensors (such as door/window sensors, garage door tilt sensors, etc.) are monitored, while indoor motion sensors are not.

At block <NUM>, an intruder opens the door, and in response, processor <NUM> generates an event signal with a code that indicates that the door has been opened. In one embodiment, the event signal comprises an encrypted, double-encapsulated Z-wave <NUM> command, as described above, with the event identification indicating that the door has been opened. In this embodiment, a response from central controller <NUM> is expected that indicates that the "open" event was successfully decrypted, as the double-encapsulated command comprises the Supervision Get command requiring a response from central controller <NUM>.

At block <NUM> processor <NUM> causes transceiver <NUM> to transmit the event signal.

At block <NUM>, processor <NUM> waits to a configurable, predetermined time to receive an acknowledgement from central controller <NUM>, either directly or via one or more other devices, that the event signal was successfully received, as described above. If an acknowledgement from central controller <NUM> is not received within the configurable, predetermined time, then processor <NUM> retransmits the event signal. This cycle continues for a configurable, predetermined number of times until either an acknowledgement is received from central controller <NUM>, or the event signal has retransmitted the configurable, predetermined number of times, at which point processor <NUM> ceases in any further attempts to transmit the event signal.

At block <NUM>, after an acknowledgement is received from central controller <NUM>, processor <NUM> waits a configurable, predetermined time period (which may be different than the configurable, predetermined time period, described above, to wait for acknowledgements) to receive a response to the event signal. In an embodiment utilizing the Z-Wave protocol, the response is referred to as a Supervision Report. The response is different than the acknowledgement: the response indicates that the information in the event signal has been successfully decrypted or, more generally, that central controller <NUM> has taken an action in response to receiving the event signal (such as causing a siren to sound, alerting a remote monitoring center, alerting an individual via SMS messaging, etc.), and therefore the information in the event signal was properly conveyed to central controller <NUM>. If a response from central controller <NUM> is not received within the configurable, predetermined time, then processor <NUM> retransmits the event signal. This cycle continues for a configurable, predetermined number of times until either a response is received from central controller <NUM>, or the event signal has been retransmitted the configurable, predetermined number of times.

At block <NUM>, while waiting for an acknowledgement and a response from central controller <NUM>, the door is closed. Processor <NUM> detects the door closure as detector <NUM> changes state. However, processor <NUM> does not immediately generate and transmit a signal indicating to central controller <NUM> that the door has been closed. Rather, processor <NUM> first determines whether any open event signals are outstanding, i.e., that both an acknowledgement and a response have not been received for any open event signals sent in the recent past. If no open event signals are outstanding, processor <NUM> immediately thereafter causes mesh-network transceiver <NUM> to transmit the closed event signal. If there are any outstanding open event signals, i.e., signals that have yet to be acknowledged and/or responded to by central controller <NUM>, processor <NUM> stores an indication of the door closure in memory <NUM>, typically also storing the time and date that the closure occurred, and does not transmit the closed event signal.

At block <NUM>, while still waiting for an acknowledgement and/or a response from central controller <NUM> as a result of the first door opening, and during any retransmission attempts, if the door is opened again, processor <NUM> detects the opening as detector <NUM> changes state.

At block <NUM>, in response to sensor <NUM> changing state, i.e., a door or window is opened again, processor <NUM> immediately generates a second event signal indicative of the state change and causes transceiver <NUM> to immediately transmit the second event signal to central controller <NUM>. The second event signal is transmitted while the door closed indication is still resident in memory <NUM>. In one embodiment, after the second event signal is transmitted, processor <NUM> erases the indication stored in memory <NUM> of the door closure. In another embodiment, processor <NUM> erases the indication stored in memory <NUM> of the door closure only after receiving an acknowledgement from central controller <NUM> that the second event signal was received. In yet another embodiment, utilizing the Z-Wave <NUM> series protocol, processor <NUM> erases the indication stored in memory <NUM> of the door closure only after receiving both an acknowledgment and a response from central controller <NUM>.

At block <NUM>, an acknowledgement is received from central controller <NUM> by transceiver <NUM> as a result of transmitting the first event signal or the second event signal, or any retransmissions associated with either signal. In one embodiment, processor <NUM> additionally receives a response from central controller <NUM>, in accordance with the Z-Wave <NUM> series protocol.

At block <NUM>, only after receiving the response from central controller <NUM>, processor <NUM> may cause transceiver <NUM> to transmit the indication stored in memory <NUM>, indicative of the door closure that occurred at block <NUM>. This may be performed for record-keeping purposes of central controller <NUM>, or to alert a user that an anomaly occurred (i.e., that a door closure occurred before either the first or second event signal was received and/or the door was first opened). In an embodiment utilizing the Z-Wave <NUM> series protocol, the indication is transmitted only after receiving both an acknowledgement and a response from central controller <NUM>.

In one embodiment, at block <NUM>, when a door or window is closed, and there are no outstanding acknowledgements or responses, i.e., any door open or closed signals have been acknowledged and responded to by central controller <NUM>, the door or window may be opened, prompting processor <NUM> to cause transmission of a door or window open signal by mesh-network transceiver <NUM>, as described above. Processor <NUM> receives an acknowledgement and a response from central controller <NUM>, also described above.

At block <NUM>, the door or window is closed, causing processor <NUM> to transmit a door or window closed signal (i.e., event signal).

At block <NUM>, if the door/window closed signal is not acknowledged and/or responded to, processor <NUM> retransmits the door/window closed signal.

At block <NUM>, before processor <NUM> receives an acknowledgement and/or a response from central controller <NUM>, either during the initial door/window closed signal transmission or subsequent re-transmissions, processor <NUM> may detect, via detector <NUM>, that the door or window has been opened.

At block <NUM>, in response to detecting the door or window being opened, processor <NUM> stops any further retransmission of the door/window closed signal and transmits a door/window open signal to central controller <NUM>. In this way, door or window openings are given a higher priority than door or window closings, because door or window openings may indicate an unauthorized intrusion, while door or window closings may or may not indicate such an unauthorized intrusion.

The same prioritization scheme may be implemented vis-à-vis other events or states determined by door/window sensor <NUM>. For example, if processor <NUM> has transmitted a door/window open or closed command, and is awaiting an acknowledgement and/or response from central controller <NUM>, and then processor <NUM> detects tampering with door/window sensor <NUM> via tamper detection device, processor <NUM> may immediately stop any further retransmissions of the door/window open or close signal, and immediately transmit a tamper signal. Similarly, door/window open or close signals may be prioritized over other transmissions, such as a battery report signal (indicating remaining battery life) or wake up notifications.

The methods or algorithms described in connection with the embodiments disclosed herein may be embodied directly in hardware or embodied in processor-readable instructions executed by a processor. The processor-readable instructions may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. In the alternative, the processor and the storage medium may reside as discrete components.

Accordingly, an embodiment of the invention may comprise a computer-readable media embodying code or processor-readable instructions to implement the teachings, methods, processes, algorithms, steps and/or functions disclosed herein.

Claim 1:
A wireless sensor (<NUM>, <NUM>, <NUM>, <NUM>), comprising:
a detector (<NUM>) for detecting an event in proximity to the wireless sensor (<NUM>);
a memory (<NUM>) for storing processor-executable instructions;
a mesh-network transceiver (<NUM>) for transmitting information to and receiving information from a central controller (<NUM>), either directly or via another wireless sensor (<NUM>, <NUM>, <NUM>, <NUM>) or a repeater;
a processor (<NUM>), coupled to the detector (<NUM>), the memory (<NUM>) and the mesh-network transceiver (<NUM>), for executing the processor-executable instructions that causes the processor (<NUM>) to:
determine that the event has occurred via a signal received from the detector (<NUM>);
in response to determining the event has occurred, generate an encrypted frame, comprising an unencrypted identification of the wireless sensor (<NUM>, <NUM>, <NUM>, <NUM>) and an encrypted event identification that identifies the type of event that has occurred;
transmit the encrypted frame;
receive an acknowledgement from the central controller (<NUM>) that the encrypted frame was received; and
receive a response from the central controller (<NUM>) that the frame was decrypted successfully.