Cannot GetAttribute in BeeStack5.0

[randolfhu]

Hi,

We are working on BeeStack 5.0. We add the test code AppReadTemperature() in BeeAppHandleKeys() in pure Beestack5.0 as following , we found the return value of ZCL_GetAttribute is always not gZbSuccess_c.

if(gZbSuccess_c==ZCL_GetAttribute(appEndPoint,aClusterId,gZclAttrTemperatureMeasurement_MeasuredValueId_c,gZclServerAttr_c,&tmp, &Attrlen))

{  Temperature = OTA2Native16(tmp); /* Convert to Big Indian */}

else{

Temperature=4477;}

We dig into the ZCL_GetAttributePtr and found the pData is 0x0000

  if (ZclAttrIsInSceneData(flags))

    pData = pDeviceDef->pSceneData;

  else

    pData = pDeviceDef->pData;

  if(ZclAttrIsInstance(flags))

  {

    if ((NULL != pDeviceDef) && (NULL != pData))

    {  pAttrPtr = &pData[pClusterDef->dataOffset + pAttrDef->data.offset];

          }

     else

     {

          // go to this case }

  }

  else

    pAttrPtr = pAttrDef->data.pData;

We checked the afClusterDef_t const gaHaTemperatureSensorClusterList[] in HaTempSensorEndPint.c, 5 parameters but in typedef afClusterDef_tag in AppAfInterface.h (as listed below), there are 6 parameters. We also check previous BeeStack, there are 6 parameters in gaHaTemperatureSensorClusterList[] .

/* Used by BeeKit to pull in only the handling code needed for a set of clusters */

typedef PACKED_STRUCT afClusterDef_tag

{

  zbClusterId_t    aClusterId;    /* cluster ID */

  pfnIndication_t  pfnServerIndication; /* server indication handler for this cluster */

  pfnIndication_t  pfnClientIndication; /* client indication handler for this cluster */

  void            *pAttrSetList;     /* ptr to attribute set list (zclAttrSetList_t) */

  uint16_t         dataOffset;    /* offset of this cluster's data within instance data */

#if gAddValidationFuncPtrToClusterDef_c 

  pfnValidationFunc_t pfnValidationFunc; /* ptr to the attribute validation function */

#endif 

  void            *pCommandsDefList;  /* ptr to commands def list (zclCommandsDefList_t) */ 

} afClusterDef_t;

Is the test method correct?

[karel_povalac]

Hello randolfhu‌,

please follow the instructions in attached zip file. It contains the Readme.txt with source codes and over the air capture files. Those files shows the behavior of working example. So you should be able to get the same results. I hope this helps.

Regards,

Karel

[mario_castaneda]

Hi Randolf,

Could you please provide the source code what you made? Would be easier for replication the whole issue.

Best Regards

Mario

[randolfhu]

Hi Mario, 

we downloaded the Beestack5.0 from the link below and used clone tool to exctract ZC and ZED.  The test method is using ZCL command of Test tool to get the temperature attribute. 

https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fwww.nxp.com%2Fwebapp%2FDownload%3Fcol... 

Thanks,

Jake

[karel_povalac]

Hello randolfhu‌,

can you please tell me what application do you use as a coordinator? I would recommend to use the zigbee_HACombinedInterface as a coordinator. It contains the end point output cluster for the temperature measurement in EndPointConfig.c. As you mentioned the zigbee_HATempSensor is probably your End device. Do you also have any over the air log? It can help during the investigation.

Thank you.

Karel

[randolfhu]

Hi Karel, kajac‌

zigbeeHATempSensor is my End Device. What's the defferent between zigbee_HACombineInterface and zigbee_HATempSensor?

In our test ,we use two sensors, one is the ZC, the other is ZED, by ZTC command of Test tool. I don't have OTA log now. But I recall that we track this issue by the wireshark log and found that the Temprature attribute did not send out, the get attribute process was correct.  So we used J-link to detect this issue and found the root cause. 

I woud like to know the "afDeviceDef_t const gHaTemperatureSensorDeviceDef"  have 7 members in HaTempSensorEndPoint.c and afDeviceDef_t have 8 members in AppAfInterface.h? It is the root cause right?  If my analysis is wron, please correct me.

Thanks,

Jake

[karel_povalac]

Hello randolfhu‌,

the zigbee_HACombineInterface already contains more clusters including the output cluster for the temperature measurements (see the Endpoint8_OutputClusterList[] in EndPointConfig.c). The input cluster of one device must match the output cluster of the other. The coordinator as a zigbee_HATempSensor has set the input cluster only. So you probably have two devices defined with input temperature measurement clusters.

It's not necessary to use all the STRUCT members. The last member will be NULL.

Regards,

Karel

[alanled]

Hey Randolf, I have not used BeeStack for a while, and I dont have the code in front of me, but let´s see if I can help you somehow. Within the device definition there are several clusters that are mandatory while others are optional, so by default most of them are disabled by using metaproggraming (#ifdef , etc), these can be enabled / disabled by Beekit (if still available) or processor expert... but it can be also changed directly in the code. So My suggestion is that you follow the code from BeeAppInit , there is an endpoint array that gets initialized, in there you can see the device definition with multiple clusters for input - output. All the clusters that have attributes need to be allocated in memory, so that happens during the initialization, somewhere there should be an #ifdef that is messing around with your demo. It will endup being something very simple, but this investigation helps you to get up to speed with the code architecture. I will try to download Beestack 5.0 later tonight, to see if I can help you further.

[alanled]

sorry dude, I downloaded KSDK 1.2, beestack 5 and IAR 7.7, and I am tired enough to call it a day... I will try later this week. I hope you can find the answer sooner. Cheers!!

[randolfhu]

Hi Alan,

Thank you very much for your investigation.

In these days, we found that the structure of gHaTemperatureSensorDeviceDef  is mismatched in beestack 5.0. The attriubute, "gZclAttrIdTemperatureMeasurement_MeasuredValueId_c" can be read successfully after we add a NULL.  But we still don't know if it will cause any side effect.

But we are still struggling with so many mismatch data and logic in Beestack5.0 and think that if it is a good build for the emregency upgrade. We are trying to add a function to automatically report the attrubute (Temperature and Humidity) value to ZC in ZR/ZED, like "BeeAppInitializeReporting" and found that some crash while we changed the parameter .

My contact information is listed below, hope we can have a skype meeting.

Skype id is "hom_yea"

Linkedin is "Jake.yeah@gmail.com"

BeeStack 4.0

BeeStack5.0

Original

Fixed

Thanks,

Jake

[alanled]

That pReportSetup pointer is new to me. I am not sure if I understood correctly, but you should not build a function for reporting. as long as you configure your attributes as reportable, you have the ZCL foundation to handle reporting of attributes. This means that from the client you can access the server to enable auto reporting. you can configure to report every x seconds, or else every time the value changes, etc... I know this should be supported by the stack itself, you don't need to create extra functions. So my suggestion is, you need to download one of the code examples without modifications, like on/off light and on/off switch, and use Test Tool on the client (that will be the switch), to enable reporting of the on/off light. I don't remember if these two demos have their attributes enabled by default... probably you need to use different example. Have you used test tool before? You can send serial commands to your ZigBee node, to monitor or inject messages at any layer of the protocol stack. For this you need ZCL foundation messages, like Read attribute, enable reporting, etc. I NXP have documents describing this, you should navigate on the BeeSTack docs.

Once you have that demo running, you have a living example on how to make sure all the metaproggraming should be configured to enable reporting on a specific attribute. So you will have an example on what you need to have as "pReportSetup "...

Let me know how it goes.

I will add you to my skype.

[alanled]

I could not sleep, so here is what I found:

You need to follow the memory allocation for that specific endpoint inside the "endpointconfig" file:

const endPointList_t endPointList[1] = {

  {&Endpoint8_EndPointDesc, &gHaTemperatureSensorDeviceDef}

};

If you follow the device definition "gHaTemperatureSensorDeviceDef"  from "HaTempSensorEndPoint" file, you will find the "gHaTemperatureSensorData" variable which is where the data associated to that specific cluster will be stored. You may see the full structure definition here "haTemperatureSensorAttrRAM_t"

The pointer to that data should not be NULL, unless you are trying to use the temp sensor cluster in a demo that does not have properly registered the cluster in a valid endpoint. Or else, somewhere in the initialization, there is a #ifdef preventing to allocate that array correctly. follow the initialization to get more clues ("AppInit" file).

I hope this helps better. Perhaps if you keep having trouble we can have a skype meeting. Let me know the outcome.

Cheers,

Alan Collins

[randolfhu]

Hi,

Is there any respopnse?

Thanks,

Jake

[randolfhu]

Hi Team,

The BeeStack and KSDK version are listed below,

BeeStack ZigBee Protocol Stack (rev. 5.0.0) - RTOS and KSDK 1.2.0.

Is there any Beestack 5.0 architecture documentation or how to add a attribute.

Thanks,