Appendix B: Attribute reporting

Attribute reporting involves sending attribute values unsolicited from the cluster server to a client - that is, pushing values from server to client without the client needing to request the values. This mechanism reduces network traffic compared with the client polling the server for attribute values. It also allows a sleeping server to report its attribute values while it is awake.

The server sends an ‘attribute report’ to the client, where this report can be issued in one of the following ways:

  • by a function call in the user application (on the server device)

  • automatically by the ZCL (triggered by a change in the attribute value or periodically)

The rules for automatic reporting (see Appendix B.1) can be configured by a remote client by sending a ‘configure reporting’ command to the server. The same rules apply to ‘default reporting’ (see Appendix B.2), but are configured locally on the server. The configuration of attribute reporting is described in Appendix B.3. Remote devices can also query the attribute reporting configuration of the server, as described in Appendix B.6.

Sending and receiving attribute reports are described in Appendix B.4 and Appendix B.5.

Attention: Attribute reporting is an optional feature and is not supported by all devices.

Appendix B.1: Automatic attribute reporting

Automatic attribute reporting involves two mechanisms:

  • A report is triggered by a change in the attribute value of at least a configured minimum amount

  • Reports are issued for the attribute periodically at a configured frequency

These mechanisms can operate at the same time. In this case, reports will be issued periodically and additional reports will be issued between periodic reports if triggered by changes in the attribute value.

If reports are triggered by frequent changes in the attribute value, they may add significantly to the network traffic. To manage this traffic, the production of reports for an attribute can be ‘throttled’. This involves defining a minimum time-interval between consecutive reports for the attribute. If the attribute value changes within this time-interval since the last report, a new report will not be generated.

Note: If triggered reports are throttled, periodic reports will still be produced as scheduled.

Periodic reporting can be disabled, leaving only triggered reports to be automatically generated. Automatic reporting can also be disabled altogether (both mechanisms). For information on the configuration of automatic reporting, refer to Appendix B.3.

Parent topic:Appendix B: Attribute reporting

Appendix B.2: Default reporting

For each cluster, the ZCL specification states that certain attributes must be reportable. These attributes are specified in the cluster descriptions in this manual. Reports on these attributes are optional and can be enabled on an individual basis using a ‘reportable flag’, as described in Appendix B.3.6. The attributes for which the flag is set will always be reported, defining a set of attributes for ‘default reporting’.

Default reporting is a form of automatic reporting (see Appendix B.1) for the restricted set of attributes described above. It is configured on the cluster server as described in Appendix B.3.6. The attributes enabled for default reporting are also included in attribute reporting initiated by the server application though a call to the function eZCL_ReportAllAttributes().

Parent topic:Appendix B: Attribute reporting

Appendix B.3: Configuring attribute reporting

If attribute reporting is to be used by a cluster then the feature must be enabled at compile-time, as detailed in Appendix B.3.1. Then:

  • If automatic attribute reporting is to be implemented then the reports must be configured as described in Appendix B.3.5.

  • If default reporting is to be implemented then the reports must be configured as described in Appendix B.3.6.

The ZCL configuration for attribute reporting is described in Appendix B.3.7 for users who wish to modify this configuration.

B.3.1: Compile-time Options

Attribute reporting is enabled at compile-time by setting the appropriate macros in zcl_options.h. The compile-time options relevant to the cluster server and client are listed separately below.

Parent topic:Appendix B.3: Configuring attribute reporting

B.3.2: Server Options

Generate Attribute Reports

To enable a server to generate attribute reports according to configured reporting rules, add the following option:

#define ZCL_ATTRIBUTE_REPORTING_SERVER_SUPPORTED

Note: Attribute reporting does not need to be enabled with this macro if the reports are generated only via function calls.

Handle ‘Configure Reporting’ Commands

To enable a server to handle ‘configure reporting’ commands and reply with ‘configure reporting’ responses, add the following option:

#define ZCL_CONFIGURE_ATTRIBUTE_REPORTING_SERVER_SUPPORTED

Handle ‘Read Reporting Configuration’ Commands

To enable a server to handle ‘read reporting configuration’ commands and reply with ‘read reporting configuration’ responses, add the following option:

#define ZCL_READ_ATTRIBUTE_REPORTING_CONFIGURATION_SERVER_SUPPORTED

Number of Attribute Reports

The number of reportable attributes can be set (to n) using the following line:

#define ZCL_NUMBER_OF_REPORTS   n

The default value is 10.

Number of String Attribute Reports

The number of reportable string attributes can be set (to n) using the following line:

#define ZCL_NUMBER_OF_STRING_REPORTS   n

The default value is 0 (meaning that string attribute reports are disabled by default).

Maximum Size of Reportable String Attribute

The maximum size, in bytes, of a string attribute that can be reported can be set (to n) using the following line:

#define ZCL_ATTRIBUTE_REPORT_STRING_MAXIMUM_SIZE   n

The default value is 32 bytes.

Minimum Attribute Reporting Interval

The minimum time-interval, in seconds, between consecutive attribute reports can be set (to n) using the following line:

#define ZCL_SYSTEM_MIN_REPORT_INTERVAL   n

The default value is 1 second.

Maximum Attribute Reporting Interval

The maximum time-interval, in seconds, between consecutive attribute reports can be set (to n) using the following line:

#define ZCL_SYSTEM_MAX_REPORT_INTERVAL   n

The default value is 61 seconds.

Parent topic:Appendix B.3: Configuring attribute reporting

B.3.3: Client Options

Receive Attribute Reports

To enable a client to receive attribute reports from a server, add the following option:

#define ZCL_ATTRIBUTE_REPORTING_CLIENT_SUPPORTED

Send ‘Configure Reporting’ Commands

To enable a client to send ‘configure reporting’ commands and handle the ‘configure reporting’ responses, add the following option:

#define ZCL_CONFIGURE_ATTRIBUTE_REPORTING_CLIENT_SUPPORTED

Send ‘Read Reporting Configuration’ Commands

To enable a client to send ‘read reporting configuration’ commands and handle the ‘read reporting configuration’ responses, add the following option:

#define ZCL_READ_ATTRIBUTE_REPORTING_CONFIGURATION_CLIENT_SUPPORTED

Parent topic:Appendix B.3: Configuring attribute reporting

B.3.4: General (Server and Client) Options

If attribute reporting is to report any attributes of the ‘floating point’ type, the following macro must also be enabled in zcl_options.h on both the server and client:

#define ZCL_ENABLE_FLOAT

This enables the use of the floating point library to calculate differences in attribute values. If this library is not already used by the application code, enabling it in this way increases the build size of the application by approximately 5 Kbytes.

Parent topic:Appendix B.3: Configuring attribute reporting

B.3.5: Configuring Automatic Attribute Reports (from Client)

If automatic attribute reporting is to be employed between a cluster server and client, the reporting rules must be configured. These rules include the following parameters for each attribute:

  • Time-interval between consecutive reports in periodic reporting

  • Minimum time-interval between consecutive triggered attribute reports

  • Minimum change in the attribute value that will trigger an attribute report

Note 1: Setting the periodic reporting time-interval to the special value of 0x0000 disables periodic reporting for the attribute. Setting this time-interval to the special value of 0xFFFF disables automatic reporting completely (periodic and triggered) for the attribute.

Note 2: Automatic attributes reports are normally produced on a timescale of seconds. However, reports generated on the change of an attribute value can be speeded up to occur on a timescale of milliseconds, as described in Appendix B.3.8.

Note 3: Before automatic reporting can be configured on an attribute, the ‘reportable flag’ must be set for the attribute on the cluster server using the function eZCL_SetReportableFlag().

This configuration is conducted on the cluster server but is normally directed from a remote device via ‘configure reporting’ commands.

The configuration of automatic attribute reporting follows the process:

  1. The client sends a ‘configure reporting’ command to the server.

  2. The server receives and processes the command, configures the attribute reporting and generates a ‘configure reporting’ response, which it sends back to the requesting client.

  3. The client receives the ‘configure reporting’ response and the ZCL generates events to indicate the status of the request to the client.

These steps are described separately below.

1. Sending a ‘Configure Reporting’ Command (from Client)

The application on the cluster client device can configure attribute reporting for a set of attributes on the cluster server using the function eZCL_SendConfigureReportingCommand(). This function sends a ‘configure reporting’ command to the server.

In this function call, a pointer must be provided to an array of tsZCL_AttributeReportingConfigurationRecord structures, where each structure contains the configuration details for one attribute on which reporting is to be configured (see Section 6.1.5).

2. Receiving a ‘Configure Reporting’ Command (on Server)

The server will automatically process an incoming ‘configure reporting’ command and perform the required configuration without assistance from the application. For each attribute (in the configuration request), the reporting configuration values are parsed, after which the ZCL generates an event of the type:

E_ZCL_CBET_REPORT_INDIVIDUAL_ATTRIBUTES_CONFIGURE

In the tsZCL_CallBackEvent structure (see Section 6.2) for this event:

  • The uMessage field contains a structure of the type tsZCL_AttributeReportingConfigurationRecord (see Section 6.1.5).

  • The eZCL_Status field indicates the outcome of parsing the configuration values for the attribute (success or failure)

Thus, the configuration of reporting for a set of attributes will result in a sequence of events of the above type, one for each attribute. The application should copy the contents of the tsZCL_AttributeReportingConfigurationRecord structure for each attribute to RAM (for information on storage format, refer to Appendix B.7.2).

Note that the tsZCL_AttributeReportingConfigurationRecord structure for an attribute contains the field u16MaximumReportingInterval which specifies a time-period for periodic reporting. Periodic reporting should not be too frequent, since a sleepy device must wake to send a report and frequent reports are be a significant drain on power resources. Therefore, the period for periodic reporting is not allowed to be set to a value less than sConfig.u16SystemMaximumReportingInterval in the ZCL configuration (see Appendix B.3.7). If a ‘configure reporting’ command attempts to set a smaller (non-zero) value, the ZCL discards the reporting configuration for this attribute and set the status for this attribute configuration to E_ZCL_CMDS_INVALID_VALUE in the ‘configure reporting’ response (see below).

Once attribute reporting has been configured (or not) for all the attributes (in the request), a single event is generated of the type:

E_ZCL_CBET_REPORT_ATTRIBUTES_CONFIGURE

Finally, the server generates a ‘configure reporting’ response and sends it back to the requesting client.

Note: The application and ZCL hold the attribute reporting configuration data in RAM. To preserve this data through episodes of power loss, the application should also save the data to NVM, as described in Appendix B.7.

3. Receiving a ‘Configure Reporting’ Response (on Client)

A ‘configure reporting’ response from the cluster server contains an Attribute Status Record for each attribute that was included in the corresponding ‘configure reporting’ command. For each attribute in the response, the ZCL on the client generates an event of the type:

E_ZCL_CBET_REPORT_INDIVIDUAL_ATTRIBUTES_CONFIGURE_RESPONSE

In the tsZCL_CallBackEvent structure (see Section 6.2) for this event, the uMessage field contains a structure of the type tsZCL_AttributeReportingConfigurationResponse (see Section 6.1.6). In this structure:

  • The eCommandStatus field indicates the status of the attribute reporting configuration for the attribute.

  • The tsZCL_AttributeReportingConfigurationRecord structure (Section 6.1.5) contains other data but only the following fields are used:

    • u16AttributeEnum which identifies the attribute

    • u8DirectionIsReceived which should read 0x01 to indicate that reports of the attribute value are received by the client

Once the above event has been generated for each valid attribute in the response, a single E_ZCL_CBET_REPORT_ATTRIBUTES_CONFIGURE_RESPONSE event is generated to conclude the response.

Parent topic:Appendix B.3: Configuring attribute reporting

B.3.6: Configuring Default Reporting (on Server)

Default reporting is a form of automatic reporting for a restricted set of attributes (see Appendix B.2). It is configured on the cluster server.

An individual attribute can be configured as potentially reportable through default reporting by setting the ‘reportable flag’ E_ZCL_AF_RP in either of the following ways:

  • The flag can be incorporated in the line for the attribute in the tsZCL_AttributeDefinition structure for the cluster server. For example, in the following line of code, attribute reporting is enabled for the bOnOff attribute of the On/Off cluster:

E_CLD_ONOFF_ATTR_ID_ONOFF, (E_ZCL_AF_RD|E_ZCL_AF_SE|**E\_ZCL\_AF\_RP**), E_ZCL_BOOL,     
    (uint32)(&((tsCLD_OnOff*)(0))->bOnOff),0},

  • The flag can be set by the server application by calling the function eZCL_SetReportableFlag().

The reporting of these attributes can be configured by the server application by calling the function eZCL_CreateLocalReport() for each attribute. The configuration values are similar to those for automatic reporting, described in Appendix B.3.5. The reporting configuration is passed to the function in a sZCL_AttributeReportingConfigurationRecord structure. The application can then enable default reporting for reportable attributes using the function vZCL_SetDefaultReporting(), which checks whether the E_ZCL_AF_RP flag has been set for each attribute and, if so, sets the ‘default reporting flag’ E_ZCL_ACF_RP.

Parent topic:Appendix B.3: Configuring attribute reporting

B.3.7: ZCL Configuration for Attribute Reporting

This section describes aspects of ZCL configuration related to attribute reporting.

Note: The information in this section is only useful to developers who wish to adjust the standard ZCL configuration for attribute reporting.

Each attribute for which automatic reporting is enabled requires a tsZCL_ReportRecord structure. These structures are maintained internally by the ZCL and space for them is allocated on the ZCL heap. The heap is allocated using the u32ZCL_Heap macro - for example:

PRIVATE uint32 u32ZCL_Heap[
ZCL_HEAP_SIZE(ZCL_NUMBER_OF_ENDPOINTS,
ZCL_NUMBER_OF_TIMERS,
ZCL_NUMBER_OF_REPORTS)];

The number of reportable attributes and the maximum/minimum reporting intervals are passed into the internal eZCL_CreateZCL structure via the sConfig parameter - for example:

sConfig.u8NumberOfReports = ZCL_NUMBER_OF_REPORTS;
sConfig.u16SystemMinimumReportingInterval = 
                            ZCL_SYSTEM_MIN_REPORT_INTERVAL;
sConfig.u16SystemMaximumReportingInterval =   
                            ZCL_SYSTEM_MAX_REPORT_INTERVAL;

The above macros have default values that can be over-ridden in the application’s zcl_options.h file, as indicated in Appendix B.3.1.

A server that supports automatic attribute reporting should have the ‘reportable flag’ E_ZCL_AF_RP set for any attributes that are reportable. While creating a cluster instance, the vZCL_SetDefaultReporting() function should be called, which will set the ‘default reporting flag’ E_ZCL_ACF_RP to enable default reporting for all the attributes that have the E_ZCL_AF_RP flag set. If a server receives a ‘configure reporting’ command for an attribute that does not have E_ZCL_ACF_RP flag set, it will return an error and not allow the attribute to be reported. This bit setting is also required for attribute reports generated through calls to the function eZCL_ReportAllAttributes().

Attribute definitions will normally have the ‘reportable flag’ set only for the mandatory reportable attribute. The application on the server can set the E_ZCL_ACF_RP flag for those attributes on which reporting is not mandatory. This can be done using the function eZCL_SetReportableFlag().

Parent topic:Appendix B.3: Configuring attribute reporting

B.3.8: Speeding Up Automatic Attribute Reports

Automatic attribute reports (configured as described in Appendix B.3.5) that are produced on changes in attribute values can be speeded up to occur with millisecond resolution. Normally, these reports can occur on a timescale of seconds, as they are dependent on the E_ZCL_CBET_TIMER (one second) ticks for sampling. However, they can be made to occur on a timescale of milliseconds by providing E_ZCL_CBET_TIMER_MS (one millisecond) ticks.

In order to do this, the following code must be included in the application:

sCallBackEvent.eEventType = E_ZCL_CBET_TIMER_MS; 
vZCL_EventHandler(&sCallBackEvent);

Note that the E_ZCL_CBET_TIMER ticks still need to be generated, as they are used by UTC time and by the ZCL report manager to keep track of time.

Parent topic:Appendix B.3: Configuring attribute reporting

Parent topic:Appendix B: Attribute reporting

Appendix B.4: Sending attribute reports

If automatic attribute reporting has been configured between the cluster server and a client (as described in Appendix B.3), the reporting of the relevant attributes will begin immediately after configuration. Attribute reports are automatically generated:

  • periodically with the configured time-interval between consecutive reports

  • when the attribute value changes by at least the configured minimum amount

Automatic reporting normally employs both of the above mechanisms simultaneously but can be configured to operate without periodic reporting, if required.

If a periodic report becomes overdue, the event E_ZCL_CBET_REPORT_TIMEOUT is generated on the server.

The application on the server can also generate an attribute report, when needed, by calling one of the following functions:

  • eZCL_ReportAllAttributes(), which sends an attribute report for all the reportable attributes

  • eZCL_ReportAttribute(), which sends an attribute report for an individual reportable attribute

The above functions send an attribute report containing the current attribute value(s) to one or more clients specified in the function call. Only the standard attributes can be reported - this does not include manufacturer-specific attributes. Use of these functions for attribute reporting requires no special configuration on the server (but a recipient client will need attribute reporting to be enabled in its compile-time options).

Note: The event E_ZCL_CBET_REPORT_REQUEST is automatically generated on the server before sending an attribute report, allowing the application to update the attribute values in the shared structure, if required.

CAUTION:

The application must not rely on the above event as a prompt to update the shared structure when an attribute changes its value. The event is only generated when the change in attribute value is large enough for an attribute report to be produced. Smaller changes will not result in the event or a report.

Parent topic:Appendix B: Attribute reporting

Appendix B.5: Receiving attribute reports

In order to receive and parse attribute reports from the cluster server, a client must have attribute reporting enabled in its compile-time options (see Appendix B.3.1).

When an attribute report is received from the server, events are generated and the ZCL software performs the following steps:

  1. For each attribute in the attribute report, the ZCL generates an E_ZCL_CBET_REPORT_INDIVIDUAL_ATTRIBUTE message for the endpoint callback function, which may or may not take action on this message.

  2. On completion of the parsing of the attribute response, the ZCL generates a single E_ZCL_CBET_REPORT_ATTRIBUTES message for the endpoint callback function, which may or may not take action on this message.

Note that:

  • The E_ZCL_CBET_REPORT_INDIVIDUAL_ATTRIBUTE event has the same fields as the E_ZCL_CBET_READ_INDIVIDUAL_ATTRIBUTE_RESPONSE event. In the uMessage field of the tsZCL_CallBackEvent structure (see Section 6.2) for these events, the same structure is used, which is of the type tsZCL_IndividualAttributesResponse.         However, the eAttributeStatus field is not updated for an attribute report (only for a ‘read attributes’ response).

  • The E_ZCL_CBET_REPORT_ATTRIBUTES event has the same fields as the E_ZCL_CBET_READ_ATTRIBUTES_RESPONSE event.

Parent topic:Appendix B: Attribute reporting

Appendix B.6: Querying attribute reporting configuration

Any authorised device in a ZigBee wireless network can obtain the attribute reporting configuration of a cluster server. Such a query follows the process below:

  1. The cluster client sends a ‘read reporting configuration’ command to the server.

  2. The server receives and processes the command, retrieves the required configuration information and generates a ‘read reporting configuration’ response, which it sends back to requesting client.

  3. The client receives the ‘read reporting configuration’ response and the ZCL generates events to inform the application of the reporting configuration.

These steps are described separately below.

Sending a ‘Read Reporting Configuration’ Command (from Client)

The application on the cluster client device can request the attribute reporting configuration on the server using eZCL_SendConfigureReportingCommand(). This function sends a ‘read reporting configuration’ command to the server.

In this function call, a tsZCL_AttributeReadReportingConfigurationRecord structure must be specified which indicates the required configuration information - this structure includes a pointer to an array of records, one per attribute for which reporting configuration information is needed (see Section 6.1.7).

Receiving a ‘Read Reporting Configuration’ Command (on Server)

The server automatically processes an incoming ‘read reporting configuration’ command without assistance from the application. Callback events are not generated. However, the server generates a ‘read reporting configuration’ response and send it back to the requesting client.

Receiving a ‘Read Reporting Configuration’ Response (on Client)

A ‘read reporting configuration’ response from the cluster server contains an Attribute Reporting Configuration Record for each attribute that was included in the corresponding ‘read reporting configuration’ command. For each attribute in the response, the ZCL on the client generates an event of the type:

E_ZCL_CBET_REPORT_READ_INDIVIDUAL_ATTRIBUTE_CONFIGURATION_RESPONSE

In the tsZCL_CallBackEvent structure (see Section 6.2) for this event, the uMessage field contains a structure of the type tsZCL_AttributeReportingConfigurationResponse (see Section 6.1.6) - this is the same structure as used in attribute reporting configuration, described in Appendix B.3.5.

In this structure:

  • The eCommandStatus field indicates the status of the request.

  • The tsZCL_AttributeReportingConfigurationRecord structure (see Section 6.1.5) includes:

    • u16AttributeEnum which identifies the attribute

    • other fields containing the attribute reporting configuration information

Once the above event has been generated for each valid attribute in the response, a single E_ZCL_CBET_REPORT_READ_ATTRIBUTE_CONFIGURATION_RESPONSE event is generated to conclude the response.

Parent topic:Appendix B: Attribute reporting

Appendix B.7: Storing an attribute reporting configuration

During the configuration of automatic attribute reporting, described in Appendix B.3.5, the application on the server must store attribute reporting configuration data in RAM and, optionally, in Non-Volatile Memory (NVM). The storage of this data is described in the sub-sections below.

Persisting an attribute reporting configuration

The attribute reporting configuration data is stored in RAM on the cluster server. To allow the server device to recover from an interruption of service involving a loss of power, this configuration data should also be saved in Non-Volatile Memory (NVM). In this case, the attribute reporting configuration data can be recovered from NVM during a ‘cold start’ of the device and automatic attribute reporting can resume without further configuration.

The storage of attribute reporting configuration data in NVM should be performed during the updates of this data on the server, described in Appendix B.3.5. When an E_ZCL_CBET_REPORT_INDIVIDUAL_ATTRIBUTES_CONFIGURE event is generated for an attribute, the contents of the incorporated structure tsZCL_AttributeReportingConfigurationRecord should be saved to NVM as well as to RAM (for information on storage format, refer to Appendix B.7.2). Data storage in NVM can be performed under application control using the Non-Volatile Memory Manager (NVM), described in the Connectivity Framework Reference Manual.

On a ‘cold start’ of the device, the application must retrieve the Attribute Reporting Configuration Record for each attribute from NVM and update the ZCL with the reporting configuration (this must be done after the ZCL has been initialized). To do this, the NVM can be used to retrieve the configuration record for an attribute and the function eZCL_CreateLocalReport() must then be called to register this data with the ZCL. This function must not be called for attributes that have not been configured for automatic attribute reporting (e.g. those for which the maximum reporting interval is set to REPORTING_MAXIMUM_TURNED_OFF).

Note: The maximum reporting interval in NVM must be set to REPORTING_MAXIMUM_TURNED_OFF (0xFFFF) during a factory reset in order to prevent reporting from being enabled for attributes for which reporting was not previously enabled.

Parent topic:Appendix B.7: Storing an attribute reporting configuration

Formatting an attribute reporting configuration record

The format in which the server application stores attribute reporting configuration data in RAM and, optionally, in NVM is at the discretion of the application developer.

The most general method is to store this data in an array of structures, in which there is one array element for each attribute for which automatic reporting is implemented (the size of this array should correspond to the value of the compile-time option SE_NUMBER_OF_REPORTS - see Appendix B.3.1). The information stored for each attribute may include the relevant cluster ID and endpoint number, as well as details of the configured change that can result in an attribute report. However, this method of data storage may require significant memory space and may only be necessary for more complex applications.

Alternative storage formats for this data are possible which economize on the memory requirements. These methods are outlined below.

Reduced Data Storage

A simple extension of the above general scheme uses application knowledge of the attributes being reported. In this case, certain static information about the reportable attributes is built into the compiled application and only the changeable information about these attributes is saved to an array in RAM (and NVM). In this way, the required memory space to store the attribute reporting configuration data is reduced.

An example of this method with five reportable attributes is given below.

#define SE_NUMBER_OF_REPORTS 5
typedef struct
  {
   uint16 u16Min;
   uint16 u16Max;
   tuZCL_AttributeReportable uChangeValue;
  } tsLocalStruct;
static tsLocalStruct asLocalConfigStruct[SE_NUMBER_OF_REPORTS];
typedef struct
 {
  uint16 u16AttEnum;
  teZCL_ZCLAttributeType eAttType;
 }tsLocalDefs;
static const tsLocalDefs asLocalDefs[SE_NUMBER_OF_REPORTS] = {
   {TPRC_MATCH_1,E_ZCL_UINT32}, 
   {TPRC_MATCH_6,E_ZCL_BMAP48}, 
   {TPRC_MATCH_7,E_ZCL_GINT56}, 
   {TPRC_MATCH_5,E_ZCL_UINT56}, 
   {TPRC_MATCH_3,E_ZCL_BOOL}
  };

In the above example:

  • The fixed data (attribute identifier and type) is held in an array of tsLocalDefs structures, with one array element per attribute - this array is defined at compile-time and therefore does not need to be updated in RAM or persisted in NVM.

  • The attribute reporting configuration data is held in an array of tsLocalStruct structures, with one array element per attribute - only this array needs to be updated in RAM and persisted in NVM, thus saving storage space.

Note that both arrays have SE_NUMBER_OF_REPORTS elements and there is a one-to-one correspondence between the elements of the two arrays - elements with the same number relate to the same attribute.

Minimized Data Storage

It may be possible to optimize the format in which the attribute reporting configuration data is saved in order to suit the attributes reported. For example, if there are only two attributes to be reported, then it may be sufficient to store the attribute reporting configuration data in a single structure, like the following:

typedef struct
{
    uint16   u16MinimumReportingIntervalForAttA;
    uint16   u16MaximumReportingIntervalForAttA;
    zint32   u32AttAReportableChange;
    uint16   u16MinimumReportingIntervalForAttB;
    uint16   u16MaximumReportingIntervalForAttB;
        // Attribute B is a discrete type (for example, a bitmap), so does not have a reportable change
} tsZCL_PersistedAttributeReportingConfigurationRecord;

Parent topic:Appendix B.7: Storing an attribute reporting configuration

Parent topic:Appendix B: Attribute reporting