ZigBee 3.0 Simple Metering集群API实战：从属性读取到镜像与历史数据查询

1. ZigBee 3.0 简单计量集群：从协议栈到工程实践

如果你正在基于NXP JN516x或JN517x系列芯片开发智能电表、水表或燃气表，那么ZigBee Cluster Library (ZCL)中的Simple Metering（简单计量）集群就是你绕不开的核心。这份来自NXP官方用户指南的API文档，乍一看全是函数原型和枚举定义，显得冰冷而抽象。但当你真正动手去实现一个能稳定上报数据、支持远程查询历史记录、甚至能在设备休眠时通过镜像服务器保存数据的智能计量节点时，你就会发现，这些API是连接ZigBee协议栈抽象世界与你具体业务逻辑的桥梁。我经历过从对着文档发懵，到一步步调试通第一个属性读取请求，再到构建出完整计量系统的过程。今天，我就结合这些“硬核”的API，和你聊聊在工程实践中，如何让这些代码真正“活”起来，打造一个稳定可靠的ZigBee智能计量设备。这不是一份简单的翻译文档，而是融合了踩坑经验、设计思路和调试技巧的实战指南。

2. 核心设计思路：理解Simple Metering集群的“角色”与“对话”

在深入代码之前，我们必须跳出单个API的局限，从系统层面理解Simple Metering集群的设计哲学。你可以把它想象成一场精心编排的双人舞，有两个固定的角色：服务器（Server）和客户端（Client）。

服务器，通常就是你的计量设备本身，比如那块智能电表。它的核心职责是“持有数据”和“响应请求”。它内部维护着一整套属性（Attributes），例如CURRENT_SUMMATION_DELIVERED（当前累计用电量）、INSTANTANEOUS_DEMAND（瞬时功率）等。它被动地等待客户端来询问或命令。

客户端，通常是数据收集器、网关或手机App。它的核心职责是“发起询问”和“处理响应”。它会主动向服务器发送“读属性”、“获取档案”等命令，以获取所需的计量数据。

而镜像（Mirror）功能，则是为支持休眠的计量设备（如电池供电的燃气表）设计的“替身”机制。计量设备（服务器）可以将自己的数据“镜像”到一个常供电的协调器或路由器（称为ESP，Energy Services Portal）上。这样，即使本尊（计量设备）在睡觉，客户端依然可以向它的“替身”（镜像服务器）查询数据，实现了功耗与实时性的平衡。

理解了这三个核心概念，我们再去看那些API，就会发现它们无非是在完成三件事：1）客户端如何向服务器要数据；2）服务器如何更新和提供数据；3）如何建立和管理“替身”。整个通信的基石，是ZCL定义的标准属性、命令和数据结构。NXP的ZigBee协议栈（BeeStack）已经实现了底层的通信、组网和安全，我们的工作就是在应用层，正确地调用这些API来驱动这场“舞蹈”。

3. 关键API深度解析与实战要点

官方文档列出了十多个函数，但在实际项目中，我们最常打交道、也最容易出问题的就是下面这几个。我会结合代码片段和场景，告诉你每个参数该怎么填，返回错误码又意味着什么。

3.1 数据读取基石：eSE_ReadMeterAttributes与eSE_HandleReadMeterAttributesResponse

这是客户端获取服务器所有计量属性的“一站式”函数。虽然文档说也可以用eZCL_SendReadAttributesRequest()读取特定属性，但在计量场景下，我们通常需要周期性地拉取全部数据（如总电量、瞬时功率、状态等），eSE_ReadMeterAttributes()更为方便。

teZCL_Status eSE_ReadMeterAttributes( uint8 u8SourceEndPointId, uint8 u8DestinationEndPointId, tsZCL_Address *psDestinationAddress, uint8 *pu8TransactionSequenceNumber);

参数实战解析：

• u8SourceEndPointId：本地端点号。这不仅仅是发送端口，更是本地共享设备结构体实例的标识符。调用eSE_RegisterMeteringDevice()注册端点时，会绑定一个tsSE_SimpleMetering结构体。读取到的属性值，最终会写回这个结构体。所以，你必须确保这个端点号与你想接收数据的那个设备实例绑定。
• psDestinationAddress：目标地址结构体。这是最容易出错的地方之一。tsZCL_Address不仅包含64位IEEE长地址或16位短地址，还包含一个eZCL_AddressMode地址模式。如果你想发给一个具体的设备，使用E_ZCL_AM_SHORT或E_ZCL_AM_IEEE。但请注意：如果你使用了绑定（Binding），想发给所有绑定的设备，或者想进行组播，这里的设置就完全不同。文档提到当使用E_ZCL_AM_BOUND或E_ZCL_AM_GROUP模式时，u8DestinationEndPointId参数会被忽略，因为地址本身已经隐含了目标信息。
• pu8TransactionSequenceNumber：事务序列号（TSN）指针。这是一个输出参数。函数会生成一个TSN并写入你传入的指针指向的位置。你必须保存这个TSN！因为随后到来的响应消息会携带相同的TSN，这是你将异步响应与特定请求匹配起来的唯一凭证。我建议为每个发出的请求在应用层维护一个简单的映射表或状态机。

核心流程与陷阱：

调用eSE_ReadMeterAttributes()只是发送了请求，它是非阻塞的，函数会立刻返回E_ZCL_SUCCESS（仅表示发送成功）。真正的数据在响应中。

响应通过ZCL的回调机制异步送达。你需要在注册端点时指定的回调函数里，等待特定的事件E_ZCL_CBET_READ_ATTRIBUTES_RESPONSE。一旦收到这个事件，就必须调用eSE_HandleReadMeterAttributesResponse()来处理。

teSE_Status eSE_HandleReadAttributesResponse( tsZCL_CallBackEvent *psEvent, uint8 *puTransactionSequenceNumber);

这里有一个关键细节：由于ZigBee单次报文（APDU）大小有限，服务器的所有属性数据可能无法一次性传完。eSE_HandleReadAttributesResponse()这个函数的神奇之处在于，它会自动检查响应是否完整。如果不完整，它会内部自动重新发送“读属性”请求，直到拿到所有数据。对于开发者来说，你只需要调用它一次，它就会帮你处理完整个“请求-响应-可能再请求”的循环，直到所有属性都安全地写入了本地的共享结构体。你只需要比较它返回的TSN和你之前保存的是否一致，就能知道这是哪次请求的结果。

实操心得：在调试初期，最容易卡在收不到响应上。请按以下顺序排查：1）确认两个设备的端点（EndPoint）上都正确实例化并注册了Simple Metering集群，且角色（Server/Client）匹配。2）确认编译时已为目标集群的属性启用了读访问权限（参考文档Section 1.3）。3）使用抓包工具（如Ubiqua）监听空中报文，直接查看请求是否发出、目标地址是否正确、以及服务器是否返回了响应（甚至可能是错误响应，如E_ZCL_ERR_EP_UNKNOWN）。空中报文是最可靠的“法官”。

3.2 镜像功能：为休眠设备配备“数据秘书”

镜像功能是Simple Metering集群的精华，尤其适用于电池供电、需要长时间休眠以省电的计量设备。其核心思想是：计量设备（Server）在休眠前，在网络上找一个常电的“大佬”（ESP，通常是协调器），请求它为自己创建一个镜像端点。之后，计量设备上报的数据会被自动转发并存储在这个镜像端点上。客户端可以直接向镜像查询数据，而无需唤醒休眠的设备。

3.2.1 计量设备端：申请与销毁镜像

计量设备作为“请求方”，主要使用两个函数：

// 申请镜像 teZCL_Status eSM_ServerRequestMirrorCommand( uint8 u8SourceEndpoint, uint8 u8DestinationEndpoint, // ESP的主端点号 tsZCL_Address *psDestinationAddress); // ESP的设备地址 // 移除镜像 teZCL_Status eSM_ServerRemoveMirrorCommand( uint8 u8SourceEndpoint, uint8 u8DestinationEndpoint, // 存放镜像的ESP端点号 tsZCL_Address *psDestinationAddress);

关键流程与注意事项：

1. 事前检查：在调用eSM_ServerRequestMirrorCommand()之前，强烈建议先检查ESP是否“心情好”愿意接收请求。方法是读取ESP设备Basic集群的u8PhysicalEnvironment属性。如果该值非零，表示ESP当前接受“添加镜像”请求。这是一个很好的流控和状态同步机制。
2. 异步响应：这两个函数都是非阻塞的。发送请求后，你需要监听响应事件。
   • 对于RequestMirror，成功后会收到E_CLD_SM_SERVER_RECEIVED_COMMAND事件，其中命令为E_CLD_SM_REQUEST_MIRROR_RESPONSE，事件结构里会包含分配到的镜像端点号。你必须保存这个端点号，因为后续的RemoveMirror命令和镜像数据上报都需要指定它。
   • 对于RemoveMirror，成功后会收到包含E_CLD_SM_MIRROR_REMOVED命令的同一事件。如果失败，则会收到一个ZCL默认响应，状态为E_ZCL_CMDS_NOT_AUTHORIZED。
3. 数据上报：一旦镜像建立成功，计量设备后续通过eZCL_SendReportAttributes()等函数上报的属性，如果目标地址设置为ESP的镜像端点，数据就会被自动镜像存储。更常见的是，在支持镜像的系统中，计量设备的上报目标地址在应用层会被自动重定向到其对应的镜像端点。

3.2.2 镜像服务器端（ESP）：管理与验证

ESP作为“服务提供方”，其API更侧重于管理：

// 创建镜像 teSM_Status eSM_CreateMirror(uint8 u8MirrorEndpoint, uint64 u64RemoteIeeeAddress); // 移除镜像 teSM_Status eSM_RemoveMirror(uint8 u8MirrorEndpoint, uint64 u64RemoteIeeeAddress); // 获取空闲镜像端点 teZCL_Status eSM_GetFreeMirrorEndPoint(uint16 *pu16FreeEP); // 验证镜像数据来源 eSM_IsMirrorSourceAddressValid(tsZCL_ReportAttributeMirror *psZCL_ReportAttributeMirror);

• eSM_CreateMirror和eSM_RemoveMirror：通常在ESP设备启动后，从非易失存储器中读取之前保存的镜像关系表，并调用CreateMirror进行恢复。这两个函数是主动管理接口。
• eSM_GetFreeMirrorEndPoint：在ESP处理“添加镜像请求”的回调函数中，需要先调用此函数检查是否有空闲端点可供分配。如果没有（返回0xFFFF），则需要将Basic集群的u8PhysicalEnvironment属性设置为0，告知网络它已无法接受新的镜像请求。
• eSM_IsMirrorSourceAddressValid：这是镜像数据流的关键守门员。当ESP收到标记为镜像报告的数据时，会生成E_ZCL_CBET_ATTRIBUTE_REPORT_MIRROR事件。你必须在对应的回调函数中调用此函数。它的作用是：
  1. 检查上报数据的源IEEE地址，是否在ESP的镜像关系表中注册过（即是否为合法的镜像设备）。
  2. 如果合法，函数内部会将事件状态设置为E_ZCL_ATTR_REPORT_OK，并自动将数据存储到对应的镜像端点。
  3. 如果不合法，函数会代表ESP向源设备发送一个E_ZCL_CMDS_NOT_AUTHORIZED的默认响应，拒绝其镜像请求。

踩坑记录：镜像功能调试的复杂性较高。一个常见问题是镜像建立成功，但数据没有存储。请确保：1）计量设备上报数据时，使用的Profile ID和Cluster ID是正确的Simple Metering集群ID。2）ESP端的回调函数正确配置，并且对E_ZCL_CBET_ATTRIBUTE_REPORT_MIRROR事件调用了eSM_IsMirrorSourceAddressValid。3）使用抓包工具，清晰地看到“Add Mirror”请求/响应、以及后续属性报告的报文流向，确认目标地址是否指向了正确的镜像端点。

3.3 历史数据归档与查询：Get Profile功能实现

对于能耗分析，历史数据至关重要。Simple Metering集群的“Get Profile”功能，允许客户端查询服务器上一段时间内的详细能耗档案。

3.3.1 服务器端：周期性地更新消费数据

服务器需要维护一个循环缓冲区来存储历史数据。每个缓冲区条目是一个tsSEGetProfile结构，包含一个时间间隔内的能耗值（u24CurrentPartialProfileIntervalValueDelivered/Received）和该间隔的结束时间（UTC）。

核心API是：

teZCL_Status eSM_ServerUpdateConsumption(uint8 u8SourceEndPointId, uint32 u32UtcTime);

工作流程：

1. 在每次计量间隔结束时（例如每15分钟），你的应用需要先更新u24CurrentPartialProfileIntervalValueDelivered或u24CurrentPartialProfileIntervalValueReceived属性，记录下这个间隔内的能耗值。
2. 然后，调用eSM_ServerUpdateConsumption()，传入当前的UTC时间（可通过u32ZCL_GetUTCTime()获取）。这个函数会将上一步更新的能耗值，连同传入的UTC时间（作为间隔结束时间），打包成一个新的tsSEGetProfile条目，压入（Push）循环缓冲区。
3. 缓冲区大小在编译时确定（SM_MAX_NUMBER_OF_PERIODS）。当缓冲区满时，新的条目会覆盖最老的条目（FIFO）。这意味着服务器始终保存着最近N个时间间隔的能耗数据。

关键点：调用eSM_ServerUpdateConsumption的周期，必须与eProfileIntervalPeriod属性设置的档案间隔周期严格一致。ZCL定义了一系列标准周期枚举，从2.5分钟到1天不等。如果你的应用是每分钟更新一次瞬时功率，但档案周期是15分钟，那么你需要累加15个1分钟的读数，再去调用一次eSM_ServerUpdateConsumption。

3.3.2 客户端端：查询与解析档案数据

客户端通过以下函数发起查询：

teZCL_Status eSM_ClientGetProfileCommand( uint8 u8SourceEndpoint, uint8 u8DestinationEndpoint, tsZCL_Address *psDestinationAddress, uint8 u8IntervalChannel, // E_CLD_SM_CONSUMPTION_DELIVERED 或 _RECEIVED uint32 u32EndTime, // 截止时间 uint8 u8NumberOfPeriods); // 请求的间隔数量

• u32EndTime：这是一个UTC时间戳，表示“我要查询在这个时间点及之前的数据”。如果设为0，则表示“给我最新的数据”。
• u8NumberOfPeriods：你想要多少个时间间隔的数据。注意，服务器可能没有那么多历史数据，它会返回实际拥有的、从指定结束时间往前推的连续数据。

这个函数也是非阻塞的。发送请求后，需要在客户端的回调函数中等待E_CLD_SM_CLIENT_RECEIVED_COMMAND事件，且命令为E_CLD_SM_GET_PROFILE_RESPONSE。

收到响应后，使用u32SM_GetReceivedProfileData()来提取数据：

uint32 u32SM_GetReceivedProfileData(tsSM_GetProfileResponseCommand *psSMGetProfileResponseCommand);

这是一个需要循环调用的函数。每次调用，它返回一个32位值，对应一个时间间隔的能耗数据（单位由服务器端的UnitOfMeasure等属性定义）。你需要反复调用它，直到它返回0xFFFFFFFF，表示所有数据已读取完毕。响应结构体中的u8NumberOfPeriodsDelivered会告诉你本次响应包含多少个间隔的数据。

工程实践提示：历史数据查询对时间同步有要求。服务器和客户端最好能通过ZigBee的Time Cluster或其他方式（如网络时间同步）保持时间基本一致，否则u32EndTime参数可能无法准确命中��想要的数据区间。另外，处理返回的32位能耗数据时，要结合服务器的Multiplier和Divisor属性进行换算，才能得到以实际单位（如kWh）表示的值。

4. 工程实践：构建一个完整的智能电表客户端示例

理论说再多，不如看一段模拟代码。假设我们是一个数据集中器（客户端），需要定时读取一个智能电表（服务器）的数据，并支持查询其过去24小时的历史用电档案。

4.1 初始化与配置

首先，在系统初始化时，我们需要注册一个端点并配置Simple Metering客户端集群。

// 定义本地端点号 #define APP_SOURCE_ENDPOINT 10 // 定义远程电表设备地址和端点号 static tsZCL_Address sDestinationAddress; static uint8 u8MeterEndpoint = 1; // 假设电表的Simple Metering服务器在端点1上 // 共享设备结构体 - 用于存储读取到的属性 tsSE_SimpleMetering sMeteringDevice; void vAppInitMeteringClient(void) { teZCL_Status eStatus; tsZCL_ClusterInstance sClusterInstance; tsZCL_EndPointDefinition sEndPointDefinition; tsZCL_ClusterDefinition sClusterDefinition; // 1. 初始化地址结构（这里使用短地址） sDestinationAddress.eAddressMode = E_ZCL_AM_SHORT; sDestinationAddress.uAddress.u16DestinationAddress = 0x1234; // 假设电表短地址 sDestinationAddress.u8DestinationEndpoint = u8MeterEndpoint; // 2. 初始化Simple Metering客户端集群结构 // 这里需要调用 eSE_CreateMetering() 来初始化 sMeteringDevice 结构体 // 并配置必要的回调函数 eStatus = eSE_CreateMetering(&sMeteringDevice, TRUE, // 这是一个客户端 &sClusterDefinition, &sClusterInstance, APP_SOURCE_ENDPOINT, &sEndPointDefinition, &vAppMeteringCallback); // 应用回调函数 if(eStatus != E_ZCL_SUCCESS) { DBG_vPrintf(TRUE, "Metering Client Creation Failed: %d\n", eStatus); return; } // 3. 注册端点 eStatus = eZCL_RegisterEndPoint(APP_SOURCE_ENDPOINT, &sEndPointDefinition); // ... 错误处理 }

4.2 定时读取属性与处理响应

我们设置一个定时器，每30秒读取一次电表的所有属性。

static uint8 u8LastTSN = 0; // 用于保存上一次请求的TSN void vTimerCallbackForReading(void) { teZCL_Status eStatus; uint8 u8TSN; eStatus = eSE_ReadMeterAttributes(APP_SOURCE_ENDPOINT, u8MeterEndpoint, &sDestinationAddress, &u8TSN); if(eStatus == E_ZCL_SUCCESS) { u8LastTSN = u8TSN; // 保存TSN，用于匹配响应 DBG_vPrintf(TRUE, "Read request sent with TSN: %d\n", u8TSN); } else { DBG_vPrintf(TRUE, "Failed to send read request: %d\n", eStatus); } }

在注册的回调函数vAppMeteringCallback中处理响应：

void vAppMeteringCallback(tsZCL_CallBackEvent *psEvent) { teZCL_Status eStatus; switch(psEvent->eEventType) { case E_ZCL_CBET_READ_ATTRIBUTES_RESPONSE: // 处理读属性响应 eStatus = eSE_HandleReadAttributesResponse(psEvent, &u8LastTSN); if(eStatus == E_ZCL_SUCCESS) { // 此时，sMeteringDevice结构体中的属性已被更新 // 我们可以访问这些值了 uint32 u32TotalConsumption = sMeteringDevice.u48CurrentSummationDelivered; int32 i32InstantPower = sMeteringDevice.i24InstantaneousDemand; DBG_vPrintf(TRUE, "Read Success! Total: %lu, Power: %ld\n", u32TotalConsumption, i32InstantPower); // 注意：实际值需要根据Multiplier/Divisor进行换算 } else { DBG_vPrintf(TRUE, "Handle Read Response Failed: %d\n", eStatus); } break; // ... 处理其他事件，如 E_CLD_SM_CLIENT_RECEIVED_COMMAND (Get Profile响应) default: break; } }

4.3 实现历史数据查询

当我们需要查询过去24小时、每15分钟一条的用电档案时（即96个间隔点）：

void vRequestHistoricalData(void) { teZCL_Status eStatus; uint32 u32EndTime = 0; // 0表示获取最新的数据 uint8 u8NumPeriods = 96; // 24小时 * 4 (每15分钟一个点) eStatus = eSM_ClientGetProfileCommand(APP_SOURCE_ENDPOINT, u8MeterEndpoint, &sDestinationAddress, E_CLD_SM_CONSUMPTION_DELIVERED, // 查询用电量 u32EndTime, u8NumPeriods); if(eStatus != E_ZCL_SUCCESS) { DBG_vPrintf(TRUE, "Get Profile command failed: %d\n", eStatus); } }

在回调函数中增加对Get Profile响应的处理：

void vAppMeteringCallback(tsZCL_CallBackEvent *psEvent) { // ... 之前的 READ_ATTRIBUTES_RESPONSE 处理 case E_CLD_SM_CLIENT_RECEIVED_COMMAND: if(psEvent->uMessage.sMeteringMessage.eCommandId == E_CLD_SM_GET_PROFILE_RESPONSE) { tsSM_GetProfileResponseCommand *psResponse = &(psEvent->uMessage.sMeteringMessage.uMessage.sGetProfileResponseCommand); uint8 u8PeriodsReceived = psResponse->u8NumberOfPeriodsDelivered; uint32 u32Consumption; uint8 i; DBG_vPrintf(TRUE, "Get Profile Response received. Periods: %d\n", u8PeriodsReceived); for(i = 0; i < u8PeriodsReceived; i++) { u32Consumption = u32SM_GetReceivedProfileData(psResponse); if(u32Consumption == 0xFFFFFFFF) { break; // 数据已读完 } // 这里可以存储或处理每个时间间隔的能耗值 u32Consumption DBG_vPrintf(TRUE, "Period %d Consumption: %lu\n", i, u32Consumption); } } break; }

5. 常见问题排查与调试技巧实录

在实际开发中，你几乎一定会遇到各种问题。下面是我总结的一些常见“坑”及其排查思路。

5.1 问题：调用API后返回E_ZCL_ERR_CLUSTER_NOT_FOUND或E_ZCL_ERR_EP_UNKNOWN

排查思路：

1. 端点注册检查：确认本地端点（u8SourceEndPointId）是否已通过eZCL_RegisterEndPoint()成功注册，并且注册时包含了Simple Metering集群的定义。
2. 集群实例化检查：在注册端点之前，是否正确地调用了eSE_CreateMetering()来创建并初始化集群实例？务必确认创建时指定的角色（Client/Server）与你的应用意图一致。客户端调用服务器的API，或者反之，都会导致错误。
3. 目标端点确认：你传入的u8DestinationEndPointId是否确实是远程设备上Simple Metering服务器集群所在的端点？可以通过读取远程设备的“简单描述符”来确认。
4. 编译配置：检查ZigBee协议栈的编译配置（通常是ZCL_OPTIONS或CLD_xxx相关的宏），确保Simple Metering集群已被启用，并且客户端和服务器功能根据你的设备角色正确配置。

5.2 问题：能收到响应，但属性值全是0或明显错误

排查思路：

1. 本地共享结构体：确认eSE_ReadMeterAttributes使用的源端点号，与调用eSE_CreateMetering时绑定的结构体是同一个实例。响应数据是写入这个结构体的。
2. 数据类型与转换：Simple Metering集群的许多属性使用了特殊的数据类型，如uint48（6字节）表示累计电量，int24（3字节有符号）表示瞬时功率。NXP的协议栈通常会用uint32或int32的变量来存储，但高位字节可能未使用。直接打印时要注意。更重要的是，原始值需要根据Multiplier和Divisor属性进行换算。例如，CurrentSummationDelivered的原始值是X，实际值 =X * Multiplier / Divisor。如果Multiplier和Divisor都是1，那原始值就是实际值。
3. 服务器端数据更新：属性值错误，也可能是服务器端根本没有更新这些属性。确保服务器端的计量应用在正确地采样、计算并写入到它的tsSE_SimpleMetering结构体对应的属性中。对于InstantaneousDemand，可能需要定时计算功率并更新；对于CurrentSummationDelivered，则需要持续累加。
4. 抓包分析：使用抓包工具查看响应报文。直接看空中传输的原始数据是什么。如果空中数据就是0，那问题出在服务器端。如果空中数据正确，但你的程序读出来是错的，那问题可能出在数据解析或结构体映射上。

5.3 问题：镜像功能建立失败，或建立后数据不镜像

排查思路：

1. ESP状态检查：计量设备在发送RequestMirror前，是否检查了ESP Basic集群的u8PhysicalEnvironment属性？确保其值非零。
2. 地址与端点：RequestMirror调用时，目标地址psDestinationAddress是否指向了正确的ESP设备？目标端点u8DestinationEndpoint是否是ESP上注册了Simple Metering服务器集群的主端点（通常不是镜像端点本身）？
3. ESP回调函数：这是最关键的环节。在ESP设备上，你是否为Simple Metering集群注册了正确的回调函数？并且在该回调函数中，是否对E_ZCL_CBET_ATTRIBUTE_REPORT_MIRROR事件调用了eSM_IsMirrorSourceAddressValid？这个调用是触发数据自动存储到镜像端点的必要条件。
4. 镜像端点管理：ESP在收到RequestMirror请求后，其应用逻辑是否正确调用了eSM_GetFreeMirrorEndPoint获取空闲端点，并调用eSM_CreateMirror创建镜像关系？创建成功后，是否将分配的镜像端点号通过响应返回给了计量设备？
5. 计量设备上报目标：镜像建立后，计量设备上报数据时，其目标地址是否设置为ESP的地址，且目标端点号设置为分配到的镜像端点号？很多SDK或示例代码会在应用层自动处理这个重定向，但你需要确认你的代码逻辑。
6. 网络稳定性：镜像建立和后续数据上报依赖于稳定的父-子链路。如果计量设备是休眠的终端设备（End Device），请确保其父节点（通常是ESP）稳定，且子设备在唤醒后能成功进行数据轮询（Polling）。

5.4 问题：Get Profile请求超时或无响应

排查思路：

1. 服务器功能使能：确认服务器设备在编译时使能了Get Profile功能（通常是定义CLD_SM_CMD_GET_PROFILE宏）。否则服务器无法识别该命令。
2. 缓冲区与更新：确认服务器端是否在定期调用eSM_ServerUpdateConsumption()来更新循环缓冲区。如果缓冲区是空的，Get Profile响应可能包含0个间隔的数据，或者直接返回错误。
3. 时间同步：检查u32EndTime参数。如果你传入了一个未来的UTC时间，服务器自然没有数据可返回。如果传入0，是请求最新数据。如果你想要过去某段时间的数据，请确保服务器和客户端的时间大致同步。
4. 响应大小：请求的间隔数量（u8NumberOfPeriods）可能过大，导致响应报文超过ZigBee单帧最大长度（约100字节）。协议栈可能会分片，但配置不当可能导致问题。可以尝试先请求少量间隔（如1个）进行测试。
5. 抓包确认：抓包查看Get Profile请求命令是否发出，以及服务器是否返回了Get Profile Response。如果没有响应，看服务器是否返回了Default Response，其中会包含错误状态码（如UNSUP_CLUSTER_COMMAND）。

调试ZigBee应用，一个高效的抓包分析工具（如Ubiqua, TI Packet Sniffer）是必不可少的。它能让你直观地看到空中究竟在传输什么，是定位通信问题最快的手段。同时，充分利用芯片的调试串口，在各个关键节点（函数入口、回调触发、收到特定事件）打印详细的日志，能帮你快速理清程序执行流和数据流。记住，耐心和细致的日志是解决复杂嵌入式网络问题的利器。