Overview

ZCL Configure Reporting Command: 0x06

Zigbee uses the Configure Reporting Command to configure the reporting mechanism for one or more attributes of a cluster.

Each cluster definition specifies which attributes are reportable and are available to this reporting mechanism. 

Which attributes are reportable?

The Zigbee ZCL specification has 3 ways of denoting reportable attributes (depends on the cluster), these can be:

1. A column in the Attribute declarations table marked as 'Reportable' with 'Yes' or 'No' values.
2. A section in the cluster definition with the heading 'Attribute Reporting' that lists out the reportable attributes of that cluster.
3. A sentence in the attribute definition section with 'This attribute SHALL be configurable for attribute reporting'.

Guide

Pre-requisites

1. Network formed using a MMB Networks device configured as a Coordinator.
2. A remote device joined to the Coordinator with at least one reportable attribute, such as a dimmable light.
3. A RapidConnect Desktop application instance open, connected to the Coordinator device.

Step 1: Enable the Attribute Report Passthrough

1. Open the RapidConnect Desktop instance.
2. Click on the 'Binding' button .
3. Check the 'Enable Report Passthrough' checkbox. This will enable the Attribute Report Passthrough (PH:0x03, SH:0x26) command.

Step 2: Create a Binding

Bindings are used to configure a source and target of attribute reports and commands. In this case, the binding will tell our remote device where to send attribute reports when generated for a particular cluster. Follow the steps below to send the bind request.

1. Destination: Select a destination for the attribute report. In this case, the coordinator or Local Device.
2. Source: Device the attribute will be reported from.
3. Cluster: The cluster that the reported attribute is associated with.
4. Bind Request: Click to send the bind request to the reporting device.
5. Bindings: Shows the current device bindings.

Step 3: Configure Attribute Reporting

To access the attribute reporting window, double-click on the Binding entry of interest.Marked below with a blue arrow.

The attribute reporting window shows a list of reportable attributes for that specific cluster and binding instance.

For the screenshot above you will see a single attribute is reportable for the On/Off cluster and that the status is 'Not Found' and we have not configured a report for this attribute.

The window components are outlined below:

1. Reportable Attribute: Shows a configurable table that contains the necessary fields to send a Configure Attribute command.
2. Direction: The direction field specifies whether values of the attribute are to be reported, or whether reports of the attribute are to be received. 0x00 = Sending a Report, 0x01 =  Expect to receive a report.
3. Min Reporting Interval: Specifies the minimum interval, in seconds, between issuing reports of the specified attribute.
4. Max Reporting Interval: Specifies the maximum interval, in seconds, between issuing reports of the specified attribute.
   1. If the Maximum Reporting Interval is set to 0x0000, there is no periodic reporting, but change based reporting is still operational.

   2. If the Maximum Reporting Interval is set to 0xffff, no reports shall be generated, whatever other conditions are satisfied.

5. Timeout: Specifies the maximum expected time, in seconds, between received reports for the attribute specified in the attribute identifier field. If more time than this elapses between reports, this may be an indication that there is a problem with reporting. Only included when configuring for an expected incoming report.
6. Reportable Change: The reportable change field shall contain the minimum change to the attribute that will result in a report being issued. Omitted for attributes with a 'Discrete' data type, e.g. Integers.
7. Configure For Reporting: Sends the request to the relevant device.

Once the report configuration has been processed by the reporting device, the 'Status' will change to "Success" (1)

Periodic reports will be generated, and on receipt, will passed up from the Module to Host wrapped in a RHAZCLPassthroughMessage, as seen below (2).