STM32WB55: Zigbee - Unable to read Electrical Measurement Cluster Attributes

[naanichilakalapudi]

 

Hi,

I'm new to Zigbee and STM32WB55, and I need to retrieve certain electrical measurement attributes through Zigbee Server and Client communication. While examining the electrical measurement header file (zcl.elec.meas.h), I observed that some attributes are currently disabled (as given below, they are marked as False in the same header file comments).

 

 

Comment description
=======================
* EMR.S.A0505 | RMSVoltage | False | Optional
* EMR.S.A0508 | RMSCurrent | False | Optional

 

 

I'd like to inquire whether it's possible to access the attributes listed below. If these attributes are initially deactivated, what steps can be taken to enable them for functionality? 

These are some Electrical Measurement Server Attribute IDs 

 

 

enum ZbZclElecMeasSvrAttrT {
ZCL_ELEC_MEAS_ATTR_RMS_VOLT = 0x0505, /**< RMSVoltage (Optional) */
ZCL_ELEC_MEAS_ATTR_RMS_CURR = 0x0508, /**< RMSCurrent (Optional) */
}

 

 

--
Thanks & Regards,
Naani Ch

 

 

[Ouadi]

 Hello @naanichilakalapudi,

Welcome to the community and thanks for your post.

In fact, the listed disabled attributes on the Electrical Measurement Cluster are not supported by the STM32WB.

Please have a look to the User Manual UM2977  chapter 5.12 describing all supported attributes.

Best regards

Ouadi

[naanichilakalapudi]

Hello @Ouadi,

To enable the Electrical Measurement attributes, what steps should I take? In which parts of the code should I implement the necessary changes?

--
Thanks & Regards,
Naani Ch

[Ouadi]

Hello @naanichilakalapudi ,

When initializing clusters in ZigBee, the stack will use the default ZCL implementation provided by the ZigBee spec, as you mentioned: some attributes are optional and won't be allocated in RAM to optimize memory footprint, however you can still allocate and use any optional / custom attributes simply by using ZbZclAttrAppendList() as described in document AN5491.

Please find below an example of the implementation of 2 optional attributes  ( ZCL_ELEC_MEAS_ATTR_RMS_VOLT/ZCL_ELEC_MEAS_ATTR_RMS_CURR)

/* Initialization */

static const struct ZbZclAttrT zcl_elec_attr [] = {
     {
         ZCL_ELEC_MEAS_ATTR_RMS_VOLT, ZCL_DATATYPE_UNSIGNED_16BIT,
         ZCL_ATTR_FLAG_REPORTABLE | ZCL_ATTR_FLAG_PERSISTABLE, 0, NULL, {0, 0}, {0, 0}
     },
     {
         ZCL_ELEC_MEAS_ATTR_RMS_CURR, ZCL_DATATYPE_UNSIGNED_16BIT,
         ZCL_ATTR_FLAG_REPORTABLE | ZCL_ATTR_FLAG_PERSISTABLE, 0, NULL, {0, 0}, {0, 0}
      },

};
/* Allocate the attributes */
if (ZbZclAttrAppendList(zigbee_app_info.elec_server_1, zcl_elec_attr, ZCL_ATTR_LIST_LEN(zcl_elec_attr)) != ZCL_STATUS_SUCCESS)
{

    /*Failed to allocate attributes */
    ZbZclClusterFree(zigbee_app_info.elec_server_1);
    return ;
}
Call the ZbZclAttrAppendList() API after ZbZclElecMeasServerAlloc() in endpoint configuration step.
In this code example both of attributes are set to be reportable and persistable.

After attributes allocation you can use ZbZclAttrReportConfigDefault() to locally configure reporting .
You can also refer to a project example implementing an optional attribute following this link : Project Example Optional Attribute 

Best regards
Ouadi

[naanichilakalapudi]

 

Hello @Ouadi,

Thanks for your response! I'm curious to understand more about the decision to disable or not support certain attributes on the Electrical Measurement Cluster for the STM32WB.

Could you please provide some insights into the reasons behind this decision and any factors that were taken into account when choosing to exclude those particular attributes?

Your expertise on this matter would be greatly appreciated.

--
Best regards,
Naani Ch

[Roger SHIVELY]

Hello @naanichilakalapudi ,

There has been a case created to resolve this question and we will be reaching out to you directly.

Regards,
Roger

[naanichilakalapudi]

Thank you for the suggestion!

I was searching for a prompt solution initially, but unfortunately, your response came too late. I had already implemented a similar logic on November 1st. It might still be beneficial, but the timing wasn't ideal.

Nevertheless, I appreciate the update.