• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 357 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LP-CC2652RB: Reportable change attribute implementation issues

A V
Prodigy 220 points
Part Number: LP-CC2652RB


Programming a ZED to be used as a temperature sensor, we've encountered several issues with the reporting mechanism, namely with the minimum reportable changes. The problem is that, seemingly, Reportable Change attribute does not work and has no effect over the device's behaviour.

Lets say we configure the measuredValue of Temperature cluster's minimum reporting time to be 10 seconds, maximum reporting time to be 20, and Reportable Change to be 4 degrees. If, on my uC, i only poll the sensor and update the variable holding the measured value within the attribute list without explicitly issuing a Zstackapi_bdbRepChangedAttrValueReq(appServiceTaskId, zReq), no reporting is issued until maximum reporting interval expires (case 1). However, with the same reporting settings, if i explicitly call Zstackapi_bdbRepChangedAttrValueReq(appServiceTaskId, zReq) after each polling loop, the measuredValue attribute will be updated even if delta is smaller than Reportable Change was configured to (case 2).

My questions are the following:

  1. For (case 1), does the zstack not handle reporting by itself, outside of responding to Reportable Attribute requests when maximum reporting time expires?
  2. Again for (case 1), do i have to specially handle Reportable Change configurations myself and provide my own implementation for handling this specific configuration? e.g.: by always checking that last reported value and current value differ by Reportable Change and manually trigger Zstackapi_bdbRepChangedAttrValueReq(appServiceTaskId, zReq)
  3. If question 2 is not true, then for (case 2), what is the point of Reportable Change if i can send values that differ with less than that?

Is there something else that i am misunderstanding about this reporting mechanism?

Also, on the side, are there some guidelines or resources for developing sleepy end devices?

  • 0
    TI__Guru**** 218837 points

    Hi A V,

    Here are some similar E2E threads:

    https://e2e.ti.com/f/1/t/1169911 
    https://e2e.ti.com/f/1/t/1228134 

    You can evaluate a default zed_temperaturesensor example and find it to work exactly as intended (explicit Zstackapi_bdbRepChangedAttrValueReq calls with no reports less than delta).  You will need to review your reportableChange value, how the ZCL_CLUSTER_ID_MS_TEMPERATURE_MEASUREMENT cluster's ATTRID_TEMPERATURE_MEASUREMENT_MEASURED_VALUE attribute is modified, and debug bdb_RepChangedAttrValue -> bdb_isAttrValueChangedSurpassDelta after they are called by Zstackapi_bdbRepChangedAttrValueReq 

      if( zclAnalogDataType(attrRec.dataType) )
  {
    //Checking if   | lastvaluereported - currentvalue | >=  | changevalue |
    if( bdb_isAttrValueChangedSurpassDelta(attrRec.dataType, attrNodeFound->data->reportableChange, attrRec.dataPtr, attrNodeFound->data->lastValueReported ) == BDBREPORTING_FALSE )
    {
      //current value does not excced the delta, dont report
      return ZSuccess;
    }
  }

    Regards,
    Ryan