• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 591 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.

CC2530: *_RegisterCmdCallbacks - Documentation for "default" implementations?

Mario DW
Genius 3145 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK, SIMPLELINK-CC13X2-26X2-SDK

AFAICS, the sample applications only use the zclGeneral_RegisterCmdCallbacks function and therefore none of the other cluster implementations available in the ZSTACK3.0.2 code.

The Thermostat implementation could have used the zclHVAC_RegisterCmdCallbacks() method for instance.

I've looked through tthe documatation, I could not find a lot of information about this.  At best, the generic app example says:

  // GENERICAPP_TODO: Register other cluster command callbacks her

As I didn not notice this previously, I have used the SampleThermostat as example.

In the sample Thermostat App the temperature setpoints are provided by usint the LCD+UI Key interface, but I am using Zigbee commands.
When the setpoint changes, it is useful to get notifiied about that change.
I expected the SYS_EVENT_MSG / ZCL_INCOMING_MSG to help me with this.

while I can send an updated setpoint temperature to the application (see sniffer log below), and see this change in the application variable associated with the attribute value, my breakpoints do not trigger on SYS_EVENT_MSG / ZCL_INCOMING_MSG .

ZigBee Cluster Library Frame, Command: Write Attributes, Seq: 249
    Frame Control Field: Profile-wide (0x00)
        .... ..00 = Frame Type: Profile-wide (0x0)
        .... .0.. = Manufacturer Specific: False
        .... 0... = Direction: Client to Server
        ...0 .... = Disable Default Response: False
    Sequence Number: 249
    Command: Write Attributes (0x02)
    Attribute Field, Int16: 2500
        Attribute: OccupiedHeatingSetpoint (0x0012)
        Data Type: 16-Bit Signed Integer (0x29)
        Int16: 2500

Questions:

  1. When not using the *_RegisterCmdCallbacks, how can I make sure that the application is notified about attribute changes?
  2. Can the *_RegisterCmdCallbacks be used (outside the ZNP, etc)?
  3. What should I be careful about when using them? 
    1. Do I need to add all the attributes that they potentially use?
    2. Are there any expectations about the READ/WRITE/REPORTABLE/GLOBAL configuration of the attributes, or are those configuration strictly respected?
  4. Is attribute change notification different when using the *_RegisterCmdCallbacks, ?
  5. Are the attribute values stored and retrieved from NV when using the *_RegisterCmdCallbacks ?
    For instance, when the Heating setpoint changed, is it recoverd after startup?  What about the localTemperature?
  6. Anything else?  Documentation?

  • 0
    Genius 3145 points

    Apparently I missed the SWRA197 - "Z-Stack ZigBee Cluster Library Application Programming Interface" pdf file.

    The Resource "Designing a Custom Ziebee 3.0-Certifiable Product Using GenericApp" also refers to this as zcl<module>_AppCallbacks_t

    It has the answers to most of the questions but does not talk about HVAC for instance.

    This documentation does not seem to indicate if (some) attributes are stored in Non-Volatile memory, so that is an open question

  • 0
    TI__Guru**** 219977 points

    Hi le_top,

    SampleThermostat handles attribute reporting inside of zclSampleThermostat_event_loop -> ZCL_INCOMING_MSG -> zclSampleThermostat_ProcessInReportCmd and only registers zclSampleThermostat_BasicResetCB in zclSampleThermostat_CmdCallbacks, not making any use of zclHVAC_RegisterCmdCallbacks.  However you will be able to reference an application example of writing attributes from SampleLight, which utilizes zclGCB_OnOff_t of the zclGeneral_AppCallbacks_t struct for zclSampleLight_OnOffCB.  You should be able to take a similar approach for zclHVAC_SetpointRaiseLower_t of zclHVAC_AppCallbacks_t after calling zclHVAC_RegisterCmdCallbacks with a valid endpoint which has the required ATTRID_HVAC_THERMOSTAT_OCCUPIED_HEATING_SETPOINT attribute record stored as part of the ZCL_CLUSTER_ID_HVAC_THERMOSTAT HVAC thermostat cluster.

    1. You need to use these callbacks so that the ZCL layer can notify your application accordingly.
    2. Yes, they are for application purposes and the ZNP is not particularly involved here.
    3a. This is not required, callbacks need only be generated for the attributes you are interested in.
    3b. Read/Write/Report commands are handled in *_ProcessFoundationMsg.
    4. Reported attributes are still handled in zclSampleThermostat_ProcessInReportCmd.
    5. You can refer to the ZCL API and Z-Stack Developer's Guides inside the Documents folder for more information.  And although for a different platform, perhaps reviewing the Designing a Custom Zigbee 3.0-Certifiable Product Using GenericApp SLA from SIMPLELINK-CC13X2-26X2-SDK could provide some further guidance.

    Non-volatile memory is covered in the Z-Stack Developer's Guide and an application example is provided in the DoorLock/DoorLockController examples.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    Thank you for the details, I'll get a callback working to write attribute values to NV Memory.

    Concerning 5 (writing attributes to NV memory), the osal_nv_* examples in the DoorLock examples are done from the UI, and in the doorlock example this is for the MaterPINCode or doorLockPin.

    My question was mainly about the registration in NV Memory of attributes declared in the attributes list.using  zcl_registerAttrList(...).  I would like to avoid storing values to memory if they are already stored or not rely on zcl functionnality if it is already provided.

  • 0 in reply to Mario DW
    TI__Guru**** 219977 points

    You can review ZComDef.h to find that ZCL items are not stored in NV memory by default, therefore it is the developer's responsibility to initialize/read/write application items into the reserved NV area (0x0401 - 0x0FFF) using the OSAL_Nv API.  An example of this is ZCD_NV_APS_DOORLOCK_PIN from SampleDoorLock, although the UI is used to create the value it is stored in NV all the same.  You can use the osal_nv_item_init return value to determine whether a value has already been initialized or not.  zcl_registerAttrList re-allocates memory on each device startup but does not create them inside NV to restore during restarts.

    Regards,
    Ryan