CC2531: CC2531 - zigbee NV-items, endpoints, data, initialization

Mark Galich

Part Number: CC2531
Other Parts Discussed in Thread: Z-STACK, SYSCONFIG

Good day!

I use a USB stick based on CC2531 chip to build my zigbee network.

I'm trying to find a solution how to initialize properly the USB stick and get started with it.

There is a number of questions I cannot find the answer in zigbee documentation. Is this probably something specific to this chip?

1. What are these NV-items for:
8200 [0x0082]
000F [0x0F00]
2100 [0x0021]
3A00 [0x003A]
3B00 [0x003B]

Where can I find any information about these items? What are they responsible for? What is stored in them and in which format?

2. EndPoint's.

EndPoints used for initialization:
01/02/03/04/05/06/08 / 0A / 0B / 6E / 0C / 0D / 2F / F2

What are they responsible for? Are they all necessary to start working?

Thanks.

over 3 years ago

0 Ryan Brown1 over 3 years ago

TI__Guru**** 218057 points

Good day Mark,

All NV item ID definitions are located in ZComDef.h. 0x82 = ZCD_NV_NWKKEY for the NWK key, 0x0021 = ZCD_NV_NIB for the Network Information Base, 0x003A = ZCD_NV_NWK_ACTIVE_KEY_INFO for active NWK key information, and 0x003B = ZCD_NV_NWK_ALTERN_KEY_INFO for alternate NWK key information. Each key entry is 16 bytes long and the nwkIB_t struct is available in the nwk.h file. 0x0F00 is not a valid entry under the default configuration and could be custom application entry.

Endpoint 0x00 is reserved for the Zigbee Device Object (ZDO) and 0xF2 corresponds to Green Power applications, all other endpoints are configurable per the Zigbee application. You will need to understand more about the program loaded on the CC2531 to further determine the purpose of each endpoint registered.

Regards,
Ryan

0 Mark Galich over 3 years ago in reply to Ryan Brown1

Prodigy 60 points

Good day!

Thanks for the answer.

1. Where can I read more about the format and purpose of these NV-items?
Particularly interesting is ZCD_NV_NIB. I have a value there now:
5F050215141500140000000105018F070002051E00000B00000000000000000000621A08000800000F0F0500010000000100000000DDDDDDDDDDDDDDDD010000000000000000000000000000000000000000000000000000000000000000000000000F030009D1600100

What is the format of the data? How do understand what this data means?

2. Where can I get more information about all Items / Constants and other necessary items?
I have a document called "Z-Stack Monitor and Test API" but it doesn't have a lot of information. And using it, it is not clear exactly how to work with devices: what actions are needed to initialize them, to maintain the network.

3. AREQ on "AF_INCOMING_MSG" contains the "Data" field. Where can I find its format?

4. How to correctly scan the network and get a list of all devices and their relationships with each other?

Thanks!

0 Ryan Brown1 over 3 years ago in reply to Mark Galich

TI__Guru**** 218057 points

1. Here is the NIB struct

{
  byte  SequenceNum;
  byte  PassiveAckTimeout;
  byte  MaxBroadcastRetries;
  byte  MaxChildren;
  byte  MaxDepth;
  byte  MaxRouters;

  byte  dummyNeighborTable;     // to make everything a byte!!

  byte  BroadcastDeliveryTime;
  byte  ReportConstantCost;
  byte  RouteDiscRetries;

  byte  dummyRoutingTable;      // to make everything a byte!!

  byte  SecureAllFrames;
  byte  SecurityLevel;
#if defined ( COMPATIBILITY_221 )   // Obsolete - do not use
  byte  nwkAllFresh;
#endif
  byte  SymLink;
  byte  CapabilityFlags;

  uint16 TransactionPersistenceTime;

  byte   nwkProtocolVersion;

  // non-standard attributes
  byte  RouteDiscoveryTime;
  byte  RouteExpiryTime;        // set to 0 to turn off expiration of routes

  // non-settable
  uint16  nwkDevAddress;
  byte    nwkLogicalChannel;
  uint16  nwkCoordAddress;
  byte    nwkCoordExtAddress[Z_EXTADDR_LEN];
  uint16  nwkPanId;

  // Other global items - non-settable
  nwk_states_t  nwkState;
  uint32        channelList;
  byte          beaconOrder;
  byte          superFrameOrder;
  byte          scanDuration;
  byte          battLifeExt;
  uint32        allocatedRouterAddresses;
  uint32        allocatedEndDeviceAddresses;
  byte          nodeDepth;

  // Version 1.1 - extended PAN ID
  uint8         extendedPANID[Z_EXTADDR_LEN];

  // Network key flag
  uint8      nwkKeyLoaded;
  // Key information - Moved out of the NIB structure after ZStack 2.3.0
  // If these elements are going to be reused make sure to consider the size
  // of the structures and padding specific to the target where the stack is
  // going to be running.
  nwkKeyDesc spare1;    // Not used
  nwkKeyDesc spare2;    // Not used

  // Zigbee Pro extensions
  uint8      spare3;                // nwkAddrAlloc deprecated - not used anymore
  uint8      spare4;                // nwkUniqueAddr deprecated - not used anymore
  uint8      nwkLinkStatusPeriod;   // The time in seconds betwee link status
                                    // command frames
  uint8      nwkRouterAgeLimit;     // The number of missed link status
                                    // command frames before resetting the
                                    // link cost to zero
  uint8      nwkUseMultiCast;
  // ZigBee Pro extentions: MTO routing
  uint8      nwkIsConcentrator;             // If set, then the device is concentrator
  uint8      nwkConcentratorDiscoveryTime;  // Time period between two consecutive MTO route discovery
  uint8      nwkConcentratorRadius;         // Broadcast radius of the MTO route discovery

#if defined ( COMPATIBILITY_221 )   // Obsolete - do not use
  uint8      nwkMaxSourceRoute;
  uint8      nwkSrcRtgExpiryTime;
#else
  uint8      nwkAllFresh;
#endif

  uint16     nwkManagerAddr;        // Network Manager Address
  uint16     nwkTotalTransmissions;
  uint8      nwkUpdateId;
} nwkIB_t;

You can infer how PassiveAckTimeout is 0x05, MaxBroadcastRetries is 0x02, MaxChildren is 0x15, etc. which follows the default settings of a Z-Stack project.

2. Looking through the Z-Stack code is the best resource. The same applies to all of these questions

3. This is captured in afMSGCommandFormat_t cmd of the afIncomingMSGPacket_t struct

typedef struct
{
  osal_event_hdr_t hdr;     /* OSAL Message header */
  uint16 groupId;           /* Message's group ID - 0 if not set */
  uint16 clusterId;         /* Message's cluster ID */
  afAddrType_t srcAddr;     /* Source Address, if endpoint is STUBAPS_INTER_PAN_EP,
                               it's an InterPAN message */
  uint16 macDestAddr;       /* MAC header destination short address */
  uint8 endPoint;           /* destination endpoint */
  uint8 wasBroadcast;       /* TRUE if network destination was a broadcast address */
  uint8 LinkQuality;        /* The link quality of the received data frame */
  uint8 correlation;        /* The raw correlation value of the received data frame */
  int8  rssi;               /* The received RF power in units dBm */
  uint8 SecurityUse;        /* deprecated */
  uint32 timestamp;         /* receipt timestamp from MAC */
  uint8 nwkSeqNum;          /* network header frame sequence number */
  afMSGCommandFormat_t cmd; /* Application Data */
  uint16 macSrcAddr;        /* MAC header source short address */
  uint8 radius;
} afIncomingMSGPacket_t;

4. There are several MT APIs for getting network topology including UTIL_GET_DEVICE_INFO, UTIL_ASSOC_*, and ZDO_IEEE_ADDR_REQ.

Regards,
Ryan

0 Mark Galich over 3 years ago in reply to Ryan Brown1

Prodigy 60 points

Dear Ryan.

Thanks for the answer.

1. Useful information, explains a lot.
2. Ok, this is helpful. Is there any documentation, but Z-Stack code?
3.1. afIncomingMSGPacket_t struct - great example of problems in the documentation.

The documentation specifies the fields:
GroupId - 2
ClusterId - 2
SrcEndpoint - 1
DstEndpoint - 1
WasBroadcast - 1
LinkQuality - 1
SecurityUse - 1
TimeStamp - 4
TransSeqNumber - 1
Len - 1
Data - 0-128

They do not match the structure you sent.

I suspect the message I receive does not correspond to both structures. Temperature sensor message:
FE1C4481000002049C010101000D000526BA000008180D0A00002901073B2F1CE6

Structure from the documentation:
GroupId - 0000
ClusterId - 0204
SrcEndpoint - 9C
DstEndpoint - 01
WasBroadcast - 01
LinkQuality - 01
SecurityUse - 00
TimeStamp - 0D000526
TransSeqNumber - BA
Len - 00
Data - 0008180D0A00002901073B2F1C

The scheme is wrong. 9C01 - address. And 01 и 01 - endpoint's;

Structure from the Z-Stack code:
groupId - 0000
clusterId - 0204
srcAddr - 9C01
macDestAddr - 0101
endPoint - 00
wasBroadcast - 0D
LinkQuality - 00
correlation - 05
rssi - 26
SecurityUse - BA
timestamp - 00000818
nwkSeqNum - 0D
Application Data - 0A0000290107
macSrcAddr - 3B2F
radius - 1C

Looks better. But macDestAddr and endPoint look very suspicious.
It seems to be some kind of combination of two structures.

Where did I go wrong?

3.2.Particular interest is the format of "Application Data".
There is a structure in the code:
typedef struct
{
uint8 TransSeqNumber;
uint16 DataLength;
uint8 *Data;
} afMSGCommandFormat_t;

But the data I received do not fit this structure: 0A0000290107

May there be another structure?

4. UTIL_GET_DEVICE_INFO and ZDO_IEEE_ADDR_REQ are similar methods.
UTIL_GET_DEVICE_INFO is sent for coordinator, ZDO_IEEE_ADDR_REQ for any device. Right?
4.1. Coordinator and router answered for ZDO_IEEE_ADDR_REQ, but the sensor did not.
Do sensors not respond for this request?

5. UTIL_GET_DEVICE_INFO and ZDO_IEEE_ADDR_REQ return AssocDeviceList.
The coordinator returned 7 entries, 6 of them are unknown to me. Should them be dropped? How to do it correctly?

Thanks again.

0 Ryan Brown1 over 3 years ago in reply to Mark Galich

TI__Guru**** 218057 points

All documentation is provided in <Z-Stack install directory>/Documents. You are interpreting the data as MSB first, the MT API goes by LSB first. Therefore, the data of two bytes or greater needs to be reversed in your analysis. this makes since given 0x0402 is ZCL_CLUSTER_ID_MS_TEMPERATURE_MEASUREMENT instead of 0x0204 corresponding to ZCL_CLUSTER_ID_HVAC_USER_INTERFACE_CONFIG.

groupId - 0000
clusterId - 0402
srcAddr - 019C
srcEndpoint - 01
DstEndpoint - 01
wasBroadcast - 00
LinkQuality - 0D
securityUse - 00
Timestamp - 00BA2605
TransSeqNumber - 00
Len - 08
Data (unmodified) - 180D0A0000290107

AF_INCOMING_MSG from the Z-Stack 3.0.2 MT API gives an adequate description of the package. 0x2F3B is still the macSrcAddress and 0x1C is the radius. My previous response was under the context of a Zigbee application which is not the case for the ZNP, instead the data is structured as mtAfInMsgList_t. It would be good having a sniffer log to verify and further understand the intended data of the incoming packet.

UTIL_GET_DEVICE_INFO returns local data (i.e. not sent over-the-air), other devices will respond to ZDO_IEEE_ADDR_REQ but not from a sleepy end device if the message times out before the ZED polls for data from its parent. For Zigbee 3.0, end devices which have been associated will be aged out if they do not poll for data within the allotted timeout. Otherwise these device would have to respond to the ZDO_MGMT_LEAVE_REQ and leave the network in order for the coordinator to disassociate them.

Regards,
Ryan

0 Mark Galich over 3 years ago in reply to Ryan Brown1

Prodigy 60 points

Dear Ryan
Thanks for your reply.

>>> You are interpreting the data as MSB first, the MT API goes by LSB first.
>>> Therefore, the data of two bytes or greater needs to be reversed in your analysis.
>>> this makes since given 0x0402 is ZCL_CLUSTER_ID_MS_TEMPERATURE_MEASUREMENT
>>> instead of 0x0204 corresponding to ZCL_CLUSTER_ID_HVAC_USER_INTERFACE_CONFIG.

Yes, got it 0x0402 = Temperature cluster. There were raw data in my example.
Bu I cannot understand the way you parsed the message. There are fieldas in the structure:
macDestAddr
correlation
rssi
1.Do you skipped them? Why?

>>> AF_INCOMING_MSG from the Z-Stack 3.0.2 MT API gives an adequate description of the package.
>>> 0x2F3B is still the macSrcAddress and 0x1C is the radius.
Ok. But what about Data?

Data (unmodified) - 180D0A0000290107
The last two bytes seems to be temperature.
"0107" = 0x0701 = 1793
1793 / 100 = 17.93 °С

2.What mean the rest bytes "180D0A000029"?
I could not find its description. I tried to write to the sensor manufacturer. His reply "No docs. Everything according to protocol". But where can I find it?

>>> UTIL_GET_DEVICE_INFO returns local data (i.e. not sent over-the-air),
>>> other devices will respond to ZDO_IEEE_ADDR_REQ but not from a sleepy end device
>>> if the message times out before the ZED polls for data from its parent.
3.Does that mean there is no reason to poll sleeping end device with ZDO_IEEE_ADDR_REQ?
Or sleeping devices should be polled at a definite time?

>>> ZDO_MGMT_LEAVE_REQ
Tried this one

I have a router with addr:
nwkAddr - 0x2F3B
ieeeAddr - 0x00124b001cd4bf20

I form the command: FE0B 2534 2F3B 00124b001cd4bf20 02
Response is: FE0165340050
Status = OK
Command completed, right?

Trying UTIL_GET_DEVICE_INFO, response: FE10670000B738DD1C004B120000000709013B2F7B
AssocDeviceList - 3B2F

Trying to reverse bytes:
FE0B 2534 3B2F 00124b001cd4bf20 02
No effect.

Trying:
FE0B 2534 3B2F 20bfd41c004b1200 02
FE0B 2534 3B2F 20bfd41c004b1200 01
FE0B 2534 3B2F 20bfd41c004b1200 00
FE0B 2534 0000 20bfd41c004b1200 02
...
FE0B 2534 0000 0000000000000000 02
...
Same result.

4.Where I make a mistake? How to remove the router?

PS.Two days ago I had ARSP responses from coordinator and router for ZDO_IEEE_ADDR_REQ. But something happened. Now I have no ARSP. Tried dosen times:
FE04 2501 3B2F 0100
FE04 2500 0000 0100

The only response FE0165000064 and nothing else. From time to time I get FE0345C43B2F0096, but no ARSP. There is UTIL_CALLBACK_SUB_CMD in docs. Subscribed for all callbacks FE032706FFFF01. Useless.

Tried to reboot and reinitialize coordinator. No result.
5. What is wrong?

PPS. Use the command to customize data interval from the sensor:
FE172401 9C01 010102040B001E0D 100C06000000290500 B400 3200

When the sensor speaks directly to coordinator, this command works. Sometimes I get Failure. But in general it works.
Now the sensor speaks via router. This command does not work. There are two responses:
FE03448000010BCD
FE0164010064
But it does not change data interval.

6.1.What the difference between "sensor joined directly to coordinator" and "sensor joined to the router"? How to control the same sensor in both cases? Should different commands be used?
6.2.Why there is Status = OK in case of Failure?
6.3.What means "TransId" in AF_DATA_REQUEST" (0x2401)? Where to get it? What TransId to be used?

0 Ryan Brown1 over 3 years ago in reply to Mark Galich

TI__Guru**** 218057 points

1. macDestAddr, correlation, and rssi are not skipped, rather they are never passed down to the MT layer to be transported to the host with AF_INCOMING_MSG.
0x29 is the dataType (ZCL_DATATYPE_INT16), 0x0000 is the Attribute ID (ATTRID_TEMPERATURE_MEASUREMENT_MEASURED_VALUE), and 0x180D0A is the ZCL Header (Frame Control 0x18, Transaction Sequence Number 0x0D, Command ID 0x0A/ZCL_CMD_REPORT.
What I mean is that messages intended for a ZED are only sent when the ZED polls for data (POLL_RATE), and if this is slower than the timeout value for indirect messages (NWK_INDIRECT_MSG_TIMEOUT) then it is possible that the message is discarded before ever reaching the ZED.
I assume "FE0B 2534 0000 20bfd41c004b1200 02" would be near correct, but there of course should be a ZDO_MGMT_LEAVE_RSP response from the ZR You can verify that the proper message is sent out with sniffer device and that the ZR acknowledges this message and responds accordingly. Also the ZR should announce its leaving to the network which would then be indicated by the ZNP as a ZDO_LEAVE_IND which would remove it from the association table.
There is a possibility that the ZR is not online and available to respond to ZDO_IEEE_ADDR_REQ with ZDO_IEEE_ADDR_RSP.
Different commands should not be used as this is all handled through the Zigbee mesh routing layer. The first response is an AF_DATA_CONFIRM meaning that the router acknowledged received the message from the local device, the second is the SRSP to the AF_DATA_REQUEST which the local device sends to the host to let it know that the AF_DATA_REQUEST will be sent over-the-air. Without end-to-end acknowledgements the ZNP never knows whether the message was delivered from the ZR to the ZED, perhaps the message timed out while waiting for the ZED data poll. TransID is set to any value by the user and can be particularly useful when determining which AF_DATA_REQUEST message another device (such as the ZR) is confirming having received through the AF_DATA_CONFIRM callback.

Regards,
Ryan

0 Mark Galich over 3 years ago in reply to Ryan Brown1

Prodigy 60 points

Dear Ryan
Thanks for your reply.

1.Yes, got it. But I cannot understand the rule. How can I take it from the structure, not to asking you again?
The purpose is to get the information, and to understand how to get it without asking a lot of questions.
2.Bingo. Quite helpful info.
The only confuse, I did not find ATTRID_TEMPERATURE_MEASUREMENT_MEASURED_VALUE in the source code. There is a number of similar expressions equal to 0x0000, but not exactly ATTRID_TEMPERATURE_MEASUREMENT_MEASURED_VALUE. Is it taken from another place?

2.1. To config the sensor I send "100D06000000290500B4003200"
10 - Frame Control as well?
0D - Transaction Sequence Number ?
0600 - Is it ZCL_HA_DEVICEID_REMOTE_CONTROL ?
0000 - ATTRID_TEMPERATURE_MEASUREMENT_MEASURED_VALUE
29 - ZCL_DATATYPE_INT16
0500 - Value change level
B400 - Min period
3200 - Max period

2.2."Transaction Sequence Number" is presented in Zigbee message and in "Data". Why?
In "Data" it is bigger per 1. Is it correct?
What will happen if not to follow this?

4.1.After a number of attempts "FE0B 2534 0000 20bfd41c004b1200 02" it happened. ZR was really deleted. Communication stopped.
Next I try to recover the router
FE0B 2535 0000 20bfd41c004b1200 0E //Router associated 904D [0x4D90]

Add the same sensor
FE0B 2535 904D 7ae29d23004b1200 00
No communication.

But after manual joining with the button, communication resumed without any additional settings.
Does that mean it is impossible to replace manual joining with ZDO_MGMT_DIRECT_JOIN_REQ ?

4.2.Still have problem with ZDO_IEEE_ADDR_REQ.
ZR is online for sure. I get messages from sensors via it.
To reverify it I placed ZR next to coordinator. No result.
Then I reprogram ZR. No result.
No ARSP for ZDO_IEEE_ADDR_REQ. SRSP is the only reply from ZR
FE01 6501 00 65

But it is strange, there is no reply for ZDO_IEEE_ADDR_REQ from coordinator.
FE04 2501 0000 0100

The same reply
FE01 6501 00 65

Would coordinator reply is ZR was offline?

I read documentation and see only it links to UTIL_CALLBACK_SUB_CMD. Tried it, no result.
FE03 2706 FFFF 01

May there be something else limiting it?

6.I reassembled the net. Trying to send message to end device directly from coordinator
FE17 2401 9C01 010102040C001E0D 100D06000000290500B4003200

The response is
FE01 6401 CD A9

CD = Status
Found in source code
#define afStatus_NO_ROUTE ZNwkNoRoute /* 0xCD */

Is it my mistake?
How to defeat it?
Tried:
MAC_SCAN_REQ
ZDO_MGMT_NWK_DISC_REQ
ZDO_MGMT_LQI_REQ
ZDO_EXT_ROUTE_DISC
No result. How to get the route?

6.1.ZDO_EXT_ROUTE_DISC needs "Options". Unable to find its description. Where to get it?

7.What means device to be in list of associated?
There were two sensors associated to coordinator. Then I removed one of them with ZDO_MGMT_LEAVE_REQ
It disappeared from AssocDeviceList, still continue sending messages. Is that Ok? How to make sensor not to send messages after disassociation?

Thanks.

0 Ryan Brown1 over 3 years ago in reply to Mark Galich

TI__Guru**** 218057 points

You can't obtain this information from the default Z-Tool. You either have to add MT_MAC_CB_FUNC to access MT_DATA_IND or create a custom MT function.
I misspoke as it's actually ATTRID_MS_TEMPERATURE_MEASURED_VALUE in the CC253X Z-Stack and can be found in zcl_ms.h which is not included with the ZNP projects which exists without the ZCL application layer. However, this now appears to be what you are trying to create in order to send ZCL commands to your devices. You will have to more closely observe the ZCL spec to fully understand how to accomplish sending ZCL messages, and use a sniffer to confirm the process during debugging. Have you considered using an existing host solution such as https://www.zigbee2mqtt.io/ instead? As for Sequence Numbers, this is the difference between the NWK layer Sequence Number and ZCL layer Transaction Sequence Number. There is also an APS Counter on the APS layer, as well as a MAC layer Sequence Number, but these are not advertised by the ZNP.
N/A
Once you remove a router that is not allowed to rejoin, it must restart the joining process starting at association during the network steering process. Thus the ZNP must enable permit join to allow the ZR to complete a fresh join. SRSP comes from the ZNP to indicate that it receives the ZDO_IEEE_ADDR_REQ message, but it does not indicate communication with the ZR. Make sure you have the proper short address, as it will have changed if the ZR has performed a fresh join or the ZNP NV memory was erased.
N/A
Once again, the Destination Address could be incorrect if the ZNP was factory reset or reprogrammed and established a new network. Short addresses are stochastically assigned by the ZNP acting in the ZC role.
The association table contains devices which can have direct communication with the node, like child end devices and neighbor routers. Is the rejoin bit set in the ZDO_MGMT_LEAVE_REQ and does the node you ask to leave respond with a ZDO_MGMT_LEAVE_RSP and ZDO_LEAVE_IND? It is not possible to force rogue devices to not send messages, but you can remove it from the source address table with UTIL_SRC_MATCH_DEL_ENTRY, as well as device security with ZDO_SEC_DEVICE_REMOVE and ZDO_REMOVE_LINK_KEY.

Regards,
Ryan

0 Mark Galich over 3 years ago in reply to Ryan Brown1

Prodigy 60 points

Dear Ryan
Thanks for your reply.
Yes, I use https://www.zigbee2mqtt.io. Listening traffic and trying to understand.
That is why I have a number of questions.

Your support is quite helpful. I found a lot of in source code and in Zigbee Cluster Library Specification, but still have some foundamental questions.

1. When I send "AF_DATA_REQUEST", I often get:
FE03 4480 F0 01 03 35

Status = 0xF0.

I found over 30 statuses in Af.h, but there is no 0xF0.
What does 0xF0 mean?
Is it the mistake when the message for ZED has not been delivered within timeout?

2.I tryed to send "AF_DATA_REQUEST" just after arriving "AF_INCOMING_MSG". I used to get status 0xF0 and sometimes 0x00 (Success).
I cannot understand when "AF_DATA_REQUEST" should be sent to get success.

3.Listening zigbee2mqtt. After arriving ZDO_TC_DEV_IND it sends:
ZDO_NODE_DESC_REQ
ZDO_EXT_ROUTE_DISC
ZDO_ACTIVE_EP_REQ
ZDO_SIMPLE_DESC_REQ
So I do the same and get responses for these commands only if they sent just after pairing.
If delayed - no response.
Should they really be sent during pairing process only?
What if I need to re-request? How should I do it?

4. I continue parsing "Data" from AF_INCOMING_MSG.
Data for attribute 0x0005
"18 03 01 05 00 00 42 04 54 48 30 31"

0x03 - Transaction Sequence Number
0x01 - ZCL_CMD_READ_RSP
0x0005 - ModelIdentifier from ZCL
0x00 - ???
0x42 - ZCL_DATATYPE_CHAR_STR
0x04 - len of string
"54 48 30 31" - String

What is 0x00 in the middle?

5. Data for attribute 0x0002
"18 08 01 02 00 86"
0x03 - Transaction Sequence Number
0x01 - ZCL_CMD_READ_RSP
0x0002 - StackVersion from ZCL
0x00 - ???
0x86 - ??? It is not DataType, right? What is it?

0 Ryan Brown1 over 3 years ago in reply to Mark Galich

TI__Guru**** 218057 points

0xF0 is ZMacTransactionExpired, meaning the end device has not polled for data within the timeout and thus the data buffer is deleted.
Depending on the poll rate of the ZED you can synchronize the AF_DATA_REQUEST from the last time a message was successfully sent and/or increase the NWK_INDIRECT_MSG_TIMEOUT, which is generated in ti_zstack_config.h by SysConfig for the ZNP project.
These can be sent at any time as they are not dependent on the commissioning process, the difference most likely being that the end devices are likely to poll for data more frequently during this time.
0x00 is the status, which is correctly ZCL_STATUS_SUCCESS meaning that the read command was understood and responded to properly by the ZCL layer.
The analysis added an extra 0x00, however the status is returned as 0x86 which is ZCL_STATUS_UNSUPPORTED_ATTRIBUTE.

Regards,
Ryan

Zigbee & Thread

Zigbee & Thread forum

CC2531: CC2531 - zigbee NV-items, endpoints, data, initialization