Since migrating to the Zigbee 3.1 SDK I have noticed a few oddities with the behavior of attribute reporting that I am thinking are related to the following bugfix:
- Added configuring Default Reporting automatically for all attributes that support reporting, with MinInterval equal to 5 sec, MaxInterval equal to 0 sec (no periodic reports), and Delta (analog attributes) equal to 0.
The end device that I am working on is connected to a SmartThings hub. The device handler I have written for the end device configures reporting for a number of attributes when the device is commissioned and all seems to work fine. Once my device establishes a connection I adjust the long poll interval and I log the sleep interval to the console. In SDK 3.0 the end device, upon reboot, would connect to the ST hub, report its attribute values, and eventually settle down and poll at the long poll interval. After moving to SDK 3.1 however, if the device is rebooted it never settles down and constantly polls at a shortened interval, behavior I usually observe after an attribute has been reported.
Prior to migrating to SDK 3.1 I came across this question in which the solution was to configure attribute reporting from the device. Although it seems the API has changed a little in SDK 3.1 I have the following for my configure reporting function and call this function in zboss_signal_handler on device first start/reboot.:
void configure_attribute_reporting()
{
zb_zcl_reporting_info_t temp_rep_info;
memset(&temp_rep_info, 0, sizeof(temp_rep_info));
temp_rep_info.direction = ZB_ZCL_CONFIGURE_REPORTING_SEND_REPORT;
temp_rep_info.ep = MULTI_SENSOR_ENDPOINT;
temp_rep_info.cluster_id = ZB_ZCL_CLUSTER_ID_TEMP_MEASUREMENT;
temp_rep_info.cluster_role = ZB_ZCL_CLUSTER_SERVER_ROLE;
temp_rep_info.attr_id = ZB_ZCL_ATTR_TEMP_MEASUREMENT_VALUE_ID;
temp_rep_info.dst.profile_id = ZB_AF_HA_PROFILE_ID;
temp_rep_info.u.send_info.min_interval = 30; // 30 seconds
temp_rep_info.u.send_info.max_interval = 300; // 5 minutes
temp_rep_info.u.send_info.delta.s16 = 0x0032; // 0.5 degrees
zb_zcl_reporting_info_t humid_rep_info;
memset(&humid_rep_info, 0, sizeof(humid_rep_info));
humid_rep_info.direction = ZB_ZCL_CONFIGURE_REPORTING_SEND_REPORT;
humid_rep_info.ep = MULTI_SENSOR_ENDPOINT;
humid_rep_info.cluster_id = ZB_ZCL_CLUSTER_ID_REL_HUMIDITY_MEASUREMENT;
humid_rep_info.cluster_role = ZB_ZCL_CLUSTER_SERVER_ROLE;
humid_rep_info.attr_id = ZB_ZCL_ATTR_REL_HUMIDITY_MEASUREMENT_VALUE_ID;
humid_rep_info.dst.profile_id = ZB_AF_HA_PROFILE_ID;
humid_rep_info.u.send_info.min_interval = 60; // 60 seconds
humid_rep_info.u.send_info.max_interval = 600; // 10 minutes
humid_rep_info.u.send_info.delta.u16 = 0x0064; // 1% rh
zb_zcl_reporting_info_t batt_rep_info;
memset(&batt_rep_info, 0, sizeof(batt_rep_info));
batt_rep_info.direction = ZB_ZCL_CONFIGURE_REPORTING_SEND_REPORT;
batt_rep_info.ep = MULTI_SENSOR_ENDPOINT;
batt_rep_info.cluster_id = ZB_ZCL_CLUSTER_ID_POWER_CONFIG;
batt_rep_info.cluster_role = ZB_ZCL_CLUSTER_SERVER_ROLE;
batt_rep_info.attr_id = ZB_ZCL_ATTR_POWER_CONFIG_BATTERY_REMAINING_ID;
batt_rep_info.dst.profile_id = ZB_AF_HA_PROFILE_ID;
batt_rep_info.u.send_info.min_interval = 30; // 30 seconds
batt_rep_info.u.send_info.max_interval = 21600; // 5 minutes
batt_rep_info.u.send_info.delta.u8 = 0x01; // 1%
// Prior to SDK 3.1 this function was zb_zcl_put_default_reporting_info(zb_zcl_reporting_info_t*)
zb_zcl_put_reporting_info(&temp_rep_info, ZB_TRUE); // Assume the override parameter here is to override the new default configuration.
zb_zcl_put_reporting_info(&humid_rep_info, ZB_TRUE);
zb_zcl_put_reporting_info(&batt_rep_info, ZB_TRUE);
}
With the device now configuring attribute reporting I seem to have fixed the problem above in that now between attribute updates (every minute), the device uses the long poll interval when sleeping unless an attribute is to be reported (without having to issue an attribute report configuration through SmartThings). This now leaves me with another set of issues that have me scratching my head a little.
- The temperature attribute to update every half degree with a maximum interval of 300 seconds. The problem, that is illustrated in the attached image, is that I am getting random reporting intervals that seem to completely ignore maximum interval.
- While writing this post it occurred to me that I am working with temperature in celsius on the device and it is translated to fahrenheit in SmartThings. I was expecting half degrees F, not C (doh).
- Relative humidity is configured to report every 600 seconds or every 1%. Again, the maximum interval appears to be ignored.
- Battery remaining percent changes too infrequently for me to have any data but given the points above I think I can safely assume it does not work as I want it to.
This leaves me with the following questions:
- When configuring the reporting value delta should we be using the hex value or integer value? I am leaning towards a hex value based on the observations in the above image and when configuring reporting in SmartThings, they use a hex value. Which is correct?
- What could be the cause of my maximum interval being ignored? I am wondering if just because I am configuring reporting locally to the device perhaps the central is not acknowledging it. I'm guessing a "re-binding" needs to occur on the central for reporting.
- Would setting temp_rep_info.dst.short_addr have any effect in triggering the central/hub to bind to the report?
- Regardless of the settings the end device configures for reporting, the central has to explicitly bind to these correct?
- If the device does not configure reporting as I have done above and relies on the hub to configure reporting, as my ST device handler does, what is the process for saving those parameters so that when the device reboots it does not have to be configured by the hub/device handler (or any other way other hubs handle devices). Are we to utilize zb_zcl_reporting_info_nvram_t?
Thanks in advance
-Patrick
