Overview

Cluster ID (0x0020):

The Poll Control Cluster was designed for the management of an end device’s MAC Data Request rate. In respect to this cluster, the term “poll” always refers to the sending of a MAC Data Request from the end device to the end device’s parent.

The MAC Data Request rate or simply “poll rate” is the frequency with which an end device sends a MAC Data Request to its parent. A parent device is only required to store a single message for its child for 7.68 seconds. Therefore if an end device wants to retrieve messages from its parent, it must send a MAC Data Request at least every 7.68 seconds.

Poll Rates:

End devices have two different rates at which they send MAC Data Polls to their parents.

1. Fast Rate (Short Poll Interval):
   1. This faster rate is used for when the device is expecting data
   2. Short Poll Interval: Defined as 'The amount of time between MAC Data Requests when the device is either expecting data or has been put into “Fast Poll Mode”(see below) by the controlling device.'
   3. Fast Poll Mode: When the device is polling frequently to retrieve data from its parent we say that the device is in “Fast Poll Mode”. The entire purpose of this cluster is to provide a means of managing when an end device goes into and out of Fast Poll Mode so that it can be made responsive for a controlling device.
2. Slow Rate (Long Poll Interval):
   1. This slower rate is used for when the device is not expecting data.
   2. The Fast Poll Interval is defined as 'The amount of time between MAC Data Requests when the device is in its normal operating state and not expecting any messages.'

End devices only know that they are expecting data when they have initiated some sort of transaction. This cluster provides a mechanism for forcing this state to make the end device responsive to asynchronous messaging.

Use Cases

Outlined below are some common use cases for using the Poll Control Cluster:

1. User would like a sleepy end device to stay 'awake' for a period of time and communicate with it's parent at a faster rate. This can be useful if the users needs to configure some aspect of the device after initial commissioning or read/write a number of attributes.
2. User Would like to use the Checkin command as an indication of the end device still being on the network.

Exploring the Poll Control Cluster Using RapidConnect Desktop

As is the case for most Zigbee features, the easiest way to become familiar with the Poll Control Cluster is to use RapidConnect Desktop and a network sniffer.

The RapidConnect Desktop simplifies many of the operations required when working with Clusters and the network sniffer allows you to see what is being send over-the-air.

Pre-requisites

1. Coordinator device configured with the Poll Control client-end cluster. See here for instructions on configuring a RapidConnect Device and adding a cluster to the device configuration.
2. Coordinator device configured to *passthrough the CheckIn command from the end device. See the 'Registering a Command Passthrough' section in the instruction linked in 1 above.
3. Coordinator has formed a network. See here for instructions on forming, leaving and joining a network using RapidConnect Desktop.
4. Device joined to the network that supports the Poll Control server-end cluster. For this article, we will be using the Lightify Wireless Dimmer Switch.

Step 1: Binding the Poll Control Cluster

A binding is a unidirectional logical link between a source endpoint/cluster identifier pair and a destination endpoint, which may exist on one or more devices.

In layman's terms, a binding allows a device to automatically send commands out to all devices in it's binding table for a given endpoint/cluster pair. So switch A could have bindings to multiple bulbs B,C,D. A single on/off button push on the switch would generate commands for each bulb and get send out over-the-air....A→ B, A→ C, A→ D

Once the end device been joined to the network, click on the 'Bindings' menu to create a binding entry between the device and coordinator.

A binding is created on the Poll Control Cluster endpoint in order for the end device to know who to 'CheckIn' with to determine whether it should go into 'Fast Poll Mode' or not.

Creating a binding() is simple using the RapidConnect Desktop:

1. Destination: Destination device and endpoint of commands send, via this binding. In this case we want the device to send commands to our coordinator so we select Local Device (RapidConnect Desktop is interfacing with the Coordinator).
2. Source: The device and endpoint which will generate commands sent via this endpoint. 
3. Cluster: Cluster that commands are generated for.
4. Bind Request: Send out the bind request command. *May need to retry the request multiple times when sending to sleepy-end devices.
5. Binding Table Entry: Once the Bind request succeeds, a new entry is shown in the Bindings table list. This list is generated by reading the binding tables of each device in the network.

Step 2: Set the Poll Control Cluster Attributes

To view the attribute of the Poll Control Cluster for the device:

1. Click on the 'Device Management' menu
2. Select the end device from the 'Devices' list
3. Expand the Poll Control: Server cluster details
4. See list of attribute values.
   1. The default values are as follows:
      1. Checkin Interval (1 hr)
      2. Long Poll Interval (5 seconds)
      3. Short Poll Interval (.5 seconds)
      4. Fast Poll timeout  (10 seconds)

The poll control cluster allows you to set the following attribute values:

1. CheckIn Interval:  Write attribute value using Attribute Write command.
2. Long Poll Interval: Set using the 'Set Long Poll Interval' Command (0x02)
3. Short Poll Interval: Set using the 'Set Short Poll Interval' Command'(0x03)
4. Fast Poll Timeout: Parameter of the server-end 'CheckIn' Command (0x00)

Step 3: Listen for the 'CheckIn' Command

The end device will send out a CheckIn command (at the CheckIn Interval rate) to the device(s) in it's binding table (that have been bound on the Poll Control Cluster).

When the coordinator received a CheckIn command, it is required to reply with a client-end command 'CheckIn Response' (0x00). The CheckIn Response command has the following payload:

With the command passthrough enabled earlier, the CheckIn command is passed through to the host as a a RHAZCLPassthroughMessage, as follows.

Step 4: Put device into 'Fast Poll' Mode

Once the 'CheckIn' command is received, the user can reply with the 'CheckIn Response' command .This can easily be done using the 'ZCL Message' component and by sending a value or true for the 'Start Fast Polling' attribute in the payload. See below.