Z-Wave Sleeping Nodes#

The purpose of this training is to explain the behavior of sleeping Z-Wave devices.

Topics covered:

  • Sleeping Devices Overview

  • Frequently Listening Routing Slaves (FLiRS)

  • Reporting Sleeping Slaves (RSS)

  • Wakeup Procedures

  • Behavior While Awake

In the corresponding lab exercise, the following tasks will be performed:

  • Identifying Z-Wave Plus Role Types by packet trace

  • Inclusion of RSS/FLiRS devices

  • On the air analysis of the FLiRS Beam transmission

  • On the air analysis of retransmission attempts when communicating with sleeping devices

  • On the air analysis of the Wakeup Command Class

  • Getting and setting the Wake Up Interval

  • Evaluation of the ZIP Gateway Mailbox

  • Deep packet inspection of the Expected Delay Header Extension

  • Evaluation of Z/IP / DNS and zipgateway.log traffic related to sleeping nodes and their failure modes

Sleeping Devices Overview#

To permit devices in the Z-wave ecosystem to switch off high-power components, the Z-Wave specification defines "Sleeping" role types which designate devices that enter a low-power state in a controlled manner. The two Sleeping Role Types outlined in the Z-Wave Plus Role Type Specification are Listening Sleeping Slaves (FLiRS) that can be controlled at any time, whereas Reporting Sleeping Slaves notify a controller device when it is available to receive messages. The figure, below, duplicates the overview of Z-Wave Plus Sleeping Role Types that appear in this specification.

Overview of Sleeping Role TypesOverview of Sleeping Role Types

Note that neither Sleeping Role Type allows a device to act as a repeater, an SIS, or a setup controller, and that both Sleeping Role Types MUST be battery powered and support the Battery Command Class.

Frequently Listening Routing Slaves (FLiRS)#

A device that needs to respond to commands, for example, a battery-powered doorlock that conserves energy but still wakes to receive lock and unlock commands is called a Frequently Listening Reporting Slave (sometimes also known as a Listening Sleeping Slave or Sleeping Actuator). The primary distinguishing characteristic of this sleeping device type is the 'Beam' signal - a special extended Z-Wave preamble that instructs FLiRS devices to wake from the sleep state.

A FLiRs device, in addition to adhering to Section 3 of the Z-Wave Plus Role Type Specification, MUST:

  • Be battery powered and support the Battery Command Class

  • Set the 'Listening' flag in its Node Information Frame (NIF) to zero

  • Support 'Beaming' to receive frames within 1[s] of a beam

  • Remain awake for at least 2[s] after any communication

  • Communicate via the Lifeline Association, if one exists

In a Z-Wave network, a FLiRS device can only be added, has no network role requirement (Primary/Secondary/Inclusion Controller, SUC, SIS).

Reporting Sleeping Slaves (RSS)#

At regular intervals, or in response to local events, a Reporting Sleeping Slave wakes up to inform a controller it is available to receive commands or has detected a local event. An example is a battery powered contact sensor, which remains in a low-power state until it detects that contact has been made (or released), whereupon it awakes and notifies the controller.

An RSS, in addition to adhering to Section 3 of the Z-Wave Plus Role Type Specification, must do the following:

  • Be battery powered and support the Battery Command Class

  • Set the 'Listening' flag in its Node Information Frame (NIF) to zero

  • Support the Wake Up Command Class

  • Implement a 'Minimum Wake Up Interval' between 0..4200 [s], where 'zero' means 'wake on event'

  • Have a nonzero Maximum Wake Up Interval if Minimum Interval is zero

  • Communicate via the Lifeline Association, if it exists

In a Z-Wave network, RSS devices can only be added and have no network role requirement (Primary/Secondary/Inclusion Controller, SUC, SIS), and in addition, an RSS has the following additional inclusion requirements:

  • If a Central Static Controller (CSC) includes an RSS, that CSC must configure the Wake Up Interval with its Node ID as destination

  • If a Static Identification Server (SIS) is present on a network, a Static Sub Controller (SSC) should not send a Wake Up Interval Set when including an RSS, but if it does, it MUST set its Node ID as destination. This means that the RSS will subsequently NOT be reachable from Secondary Controllers.

  • Alternately, if no SIS is present, an SSC SHOULD send a Wake Up Interval Set with the default Wake Up Time advertised by the node, and the SSC's Node ID as destination.

Wakeup Procedures#

The Primary delineation between FLiRS and RSS are the methods by which they awaken to receive commands. This section will discuss both the Beam Signal utilized by FLiRS, as well as the Wakeup Command Class used by RSS.

Beaming#

In a Beam Signal, the traditional Z-Wave preamble is replaced by an extended, repeated, series of 'Beam Frames' whose duration is longer than the sleep interval of the destination device.

A Beam FrameA Beam Frame

In this way, the FLiRS device is likely to wake while a portion of the Beam is still on the air. After receiving a Beam, FLiRS nodes MUST remain awake until they receive the data link header and compare the destination address to their own node ID. If the destination of the Beam is the same as the receiving node's ID, it captures the header and payload and the commands within are then parsed. Otherwise, the FLiRS device can return to sleep immediately. This allows FLiRS devices to remain responsive (within 1[s] of receiving a command) to external commands.

Wake Up Command Class#

The Wake Up Command Class allows a sleeping node to notify an always-listening device that it is awake and ready to receive commands. The Wake Up Command Class is REQUIRED by Reporting Sleeping Slaves, which only awaken on a pre-negotiated events, such as a button press or specific time interval. The frame flow between the sleeping device and its wake up destination appear in the figure, below.

Wake Up Command Class Frame FlowWake Up Command Class Frame Flow

When devices supporting the Wake Up Command Class awaken, they notify their Wake Up Destination of their availability and then MUST remain awake until the shorter of: 10 [s] after the last exchanged packet, or receiving a Wake Up No More packet - which signifies no further commands are pending.

Supervision and Wake On Demand#

When a device supporting Security Encapsulation sends a Supervision Get command, a Wake Up Destination can respond by setting the 'Wake Up Requested' bit in a subsequent Supervision Report. This bit notifies the sleeping device to contact its Wake Up Destination to receive messages. The figure below illustrates the frame flow for this process which is known as 'Wake On Demand.

Wake On DemandWake On Demand

Note that devices supporting Wake Up can continue sending unsolicited commands before notifying the Wake Up Destination after receiving a Wake On Demand request. In the preceding figure, the device proceeds sending its unsolicited commands (for example, consider an alert from a sleeping motion detector) to their respective destinations before notifying the Wake Up Destination it is available for commands. This is to ensure that the unsolicited command responsible for waking the device is delivered without delay.

The Mailbox#

The Z/IP Gateway reference design implements a 'Mailbox Service' which it uses to queue frames to sleeping nodes and, upon receiving a Wake Up Notification, the mailbox messages are delivered to the notifying destination.

'More Information' Flag#

After receiving a Wake Up Notification, a Wake Up Destination facilitates delivery of any messages pending for the sleeping device that originated the Wake Up Notification. After waking, a sleeping device will remain awake for at least ten seconds from the last transmitted frame, or the arrival of a Wake Up No More frame. During this process, the "More Information" flag can be set on a Z/IP sent to a Wake Up Destination to prevent Z/IP Gateway from transmitting a "Wake Up No More Information" frame at its normally-scheduled timeout. This leaves the sleeping device awake, allowing the Z/IP client to send more frames than merely those already already-enqueued in the Wake Up Destination. This is useful for conditional transactions, such as firmware updates, where an incremental firmware download may make use of this flag to ensure the device remains awake to receive the whole payload.

'Expected Delay' Header Extension#

When an IP client contacts a sleeping device through Z/IP Gateway, it may receive a response containing an "Expected Delay" Header Extension. This header extension contains a 24-bit time-in-seconds value that describes the time in the sleeping device's Wake Up Interval remaining until its next Wake Up Notification is expected. This extension allows clients to conserve power, mailbox message space, or on-the-air transmissions until the device is about to wake up. For example, if a sleeping device is halfway through its one minute Wake Up Interval, an "Expected Delay" of 30 seconds would be communicated to the client - the client may then decide to pause for 29 [s] before attempting retransmission.

If a client contacts a sleeping device with a frame that has the "Acknowledge (ACK) Request" bit set, the Z/IP Gateway will periodically notify the client with a "Negative Acknowledge (NACK), Waiting" frame until the original "ACK-Request" enabled transmission is delivered to its destination. The "NACK Waiting" frame from the gateway also contains an "Expected Delay" extension header, which can be evaluated with a packet trace tool like Wireshark. See the traffic analysis lab exercise to learn about using Wireshark for decoding Z/IP packets, and the sleeping nodes lab for decoding sleeping device specific frames.

Detection of Sleeping Device Failure#

Because FLiRS devices should always be available through use of Beam Signaling, a FLiRS device is considered 'failed' after all retransmission attempts of a Beam have failed to wake the device. For example, the Z/IP Gateway will attempt to beam a FLiRs device for 10 [s] before recording it as 'failed.'

By contrast, RSS devices cannot receive communication until they send a Wake Up Notification. In this case, if a duration of longer than (2 * [Wake Up Interval] + 10%) passes without receipt of a Wake Up Notification from the RSS, it can be marked as 'failed.' Recall that for a device whose Wake Up Interval is '0', no predictable pattern of expected Wake Up Notifications can be determined. As a result, failure of these devices cannot be detected.