• 状态 Resolved
  • 已锁定 已锁定
  • 回复 11 回复
  • 订户 0 订户
  • 视图 689 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CC2531：CC2531 - ZigBee NV 项目、端点、数据、初始化

admin
Guru**** 2378720 points
Other Parts Discussed in Thread: CC2531, Z-STACK, SYSCONFIG
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1058850/cc2531-cc2531---zigbee-nv-items-endpoints-data-initialization

器件型号：CC2531
Thread 中讨论的其他器件： Z-stack、 SysConfig

美好的一天！

我使用基于 CC2531芯片的 USB 记忆棒构建我的 ZigBee 网络。

我正在尝试找到一个解决方案、如何正确初始化 USB 记忆棒并开始使用它。

在 ZigBee 文档中有许多问题我找不到答案。 这可能是特定于此芯片的东西吗？

1、以下非易失性物品的用途：
8200 [0x0082]
000f [0x0F00]
2100 [0x0021]
3A00 [0x003A]
3B00 [0x003B]

在哪里可以找到有关这些商品的任何信息？ 他们的责任是什么？ 存储在这些存储器中的内容是什么以及以哪种格式？

2、端点。

用于初始化的端点：
01/02/03/04/05/06/08 / 0A/0B/6E / 0C / 0D / 2F / F2

他们的责任是什么？ 他们是否都有必要开始工作？

谢谢。

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Mark、

    所有 NV 项目 ID 定义均位于 ZComDef.h 中。 0x82 = ZCD_NV_NWKKEY 表示 NWK 密钥、0x0021 = ZCD_NV_NIB 表示网络信息库、0x003A = ZCD_NV_NWK_ACTIVE_KEY_INFO 表示活动 NWK 密钥信息、0x003B = ZCD_NV_NwK_KEY 表示备用信息。  每个密钥条目的长度为16字节、 nwkIB_t 结构在 nwk.h 文件中可用。  0x0F00不是默认配置下的有效条目、可以是自定义应用程序条目。

    端点0x00保留用于 Zigbee 设备对象(ZDO)、0xF2对应于绿色电源应用、所有其他端点均可根据 Zigbee 应用进行配置。  您需要更详细地了解 CC2531上加载的程序、以进一步确定每个注册的端点的用途。

    此致、
    Ryan

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    美好的一天！

    感谢您的回答。

    1.在哪里可以阅读有关这些非易失性商品的格式和用途的更多信息？
    特别有趣的是 ZCD_NV_NIB。 我现在有一个值：
    5F050215141500000140000000105018F070002051E00000B000000000000000000000000000000000000000000621A08000800000F0F0500010000000100000000DDDDDDDDDDDDDDDDDDDD0100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

    数据的格式是什么？ 如何了解此数据的含义？

    2.在哪里可以获得有关所有项目/常量和其他必要项目的更多信息？
    我有一个名为"Z-Stack 监控和测试 API"的文档、但它没有很多信息。 使用它并不清楚如何使用设备：初始化设备、维护网络需要采取哪些措施。

    3."AF_INVING_MSG"上的 AREQ 包含"Data"字段。 在哪里可以找到它的格式？

    4.如何正确扫描网络并获取所有设备及其彼此关系的列表？

    谢谢！

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    这里是 NIB 结构 

    {
  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;

    您可以推断 PassiveAckTimeout 是如何为0x05、MaxBroadcastRetries 是0x02、 MaxChildren 是0x15等、这遵循 Z-Stack 项目的默认设置。

    2.浏览 Z-Stack 代码是最好的资源。  所有这些问题也是如此

    3.这是在 afIncomingMSGPacket_t 结构的 afMSGCommandFormat_t cmd 中捕获的 

    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.有多个 MT API 用于获取网络拓扑，包括 UTIL_GET_DEVICE_INFO、UTIL_Assoc_*和 ZDO_IEEE_ADDR_REQ。

    此致、
    Ryan

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Ryan。

    感谢您的回答。

    有用的信息解释了很多。
    2.好的、这很有帮助。 是否有任何文档、但 Z-Stack 代码？
    3.1. afIncomingMSGPacket_t struct -文档中的问题示例。

    文档指定了以下字段：
    组 ID - 2.
    群集- 2.
    SrcEndpoint - 1.
    DstEndpoint - 1.
    WasBroadcast - 1.
    联系质量- 1.
    安全使用- 1.
    时间戳- 4.
    TransSeqNumber - 1.
    Len - 1.
    数据- 0-128

    它们与您发送的结构不匹配。

    我怀疑收到的消息与这两种结构不符。 温度传感器消息：
    FE1C4481000002049C010101000D000526BA000008180D0A00002901073B2F1CE6

    文档结构：
    组 ID - 0000
    clusterid - 0204
    SrcEndpoint - 9C
    DstEndpoint - 01
    WasBroadcast - 01
    LinkQuality - 01
    SecurityUse - 00
    时间戳- 0D000526
    TransSeqNumber - BA
    Len - 00
    数据- 0008180D0A00002901073B2F1C

    方案错误。 9C01 -地址。 和01 и 01 -端点；

    Z-Stack 代码的结构：
    组 ID - 0000
    clusterid - 0204
    srcAddr - 9C01
    macDestAddr - 0101
    端点- 00
    水广播- 0D
    LinkQuality - 00
    相关性- 05
    RSSI - 26
    SecurityUse - BA
    时间戳- 00000818
    nwkSeqNum - 0D
    应用数据- 0A0000290107
    macSrcAddr - 3B2F
    半径- 1C

    看起来更好。 但 macDestAddr 和端点看起来非常可疑。
    它似乎是两种结构的某种组合。

    哪里出了问题？

    3.2.特别关注的是"应用程序数据"的格式。
    代码中有一个结构：
    typedef 结构
    ｛
    uint8 TransSeqNumber；
    uint16 DataLength；
    uint8 *数据；
    ｝afMSGCommandFormat_t；

    但我接收到的数据不适合这个结构：0A0000290107

    可能还有其他结构吗？

    Util_get_device_info 和 ZDO_IEEE_ADDR_REQ 是类似的方法。
    为协调器发送 Util_get_device_info、为任何器件发送 ZDO_IEEE_ADDR_REQ。 对吧？
    4.1.协调员和路由器回答了 ZDO_IEEE_ADDR_REQ，但传感器没有。
    传感器是否对此请求没有响应？

    5. Util_get_device_info 和 ZDO_IEEE_ADDR_REQ 返回 AssocDeviceList。
    协调员返回了7个条目，其中6个对我来说是未知的。 是否应将其丢弃？ 如何正确执行？

    再次感谢。

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    中提供了所有文档 /文档。  您将数据解释为 MSB 优先、MT API 先经过 LSB。  因此、 需要在分析中反转两个字节或更大字节的数据。  因此、由于给定0x0402为 ZCL_CLUSTER_ID_MS_TEMP_TEMP_measurement、而不是对应 于 ZCL_CLUSTER_ID_HVAC_USER_INTERFIT_CONFIG 的0x0204。

    组 ID - 0000
    clusterid - 0402
    srcAddr - 019C
    srcEndpoint - 01
    DstEndpoint - 01
    wasBroadcast - 00
    LinkQuality - 0D
    安全使用- 00
    时间戳- 00BA2605
    TransSeqNumber - 00
    Len - 08
    数据(未修改)-  180D0A0000290107  

    来自 Z-Stack 3.0.2 MT API 的 AF_INGING_MSG 提供了对软件包的充分说明。  0x2F3B 仍然是 macSrcAddress、0x1C 是半径。   我之前的响应是在 Zigbee 应用的上下文中进行的、这对于 ZNP 并非如此、而 是将数据  结构为 mtAfInMsgList_t    最好使用监听器日志来验证和进一步了解传入数据包的预期数据。

    Util_get_device_info 返回本地数据(即不是通过无线发送的)、如果 ZDO_IEEE_ADDR_REQ 消息在 ZED 轮询其父设备的数据之前超时、其他设备将响应 ZDO_EIE_ADDR_REQ、但不会响应休眠终端设备。  对于 Zigbee 3.0、如果已关联的终端设备在分配 的超时时间内不轮询数据、则它们将被淘汰。  否则、这些器 件必须响应 ZDO_Mgmt_leave REQ 并离开网络、以便协调器解除它们的关联。

    此致、
    Ryan

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Ryan
    感谢您的回复。

    >>您首先将数据解释为 MSB、MT API 先经过 LSB。
    >>>因此，您的分析中需要颠倒两个字节或更大字节的数据。
    >>自给定0x0402以来、这就成为 ZCL_CLUSTER_ID_MS_TEMP_TEMP_measurement
    >>而不是与 ZCL_CLUSTER_ID_HVAC_USER_INTERFIT_CONFIG 相对应的0x0204。

    是的、得到它0x0402 =温度组。 我的示例中有原始数据。
    BU 我无法理解您解析消息的方式。 结构中有字段：
    macDestAddr
    相关性
    RSSI
    1.您是否跳过了它们？ 为什么？

    >>>来自 Z-Stack 3.0.2 MT API 的 AF_INVING_MSG 对软件包进行了充分的描述。
    >>0x2F3B 仍然是 macSrcAddress、0x1C 是半径。
    好的。 但数据呢？

    数据(未修改)- 180D0A0000290107
    最后两个字节似乎是温度。
    "0107"= 0x0701 = 1793
    1793/100 = 17.93°С

    什么是其余字节"180D0A000029"？
    我找不到它的描述。 我尝试向传感器制造商写入数据。 他的答复是："没有文件。 所有内容都符合协议"。 但我在哪里可以找到它呢？

    >> UTIL_GET_DEVICE_INFO 返回本地数据(即不通过无线发送)、
    >>其他器件将响应 ZDO_IEEE_ADDR_REQ、但不会响应休眠终端器件
    >>>如果消息在 ZED 轮询其父级数据之前超时。
    这是否意味着没有理由使用 ZDO_IEEE_ADDR_REQ 轮询睡眠端器件？
    还是休眠设备应在确定的时间进行轮询？

    >> ZDO_Mgmt_lefore_Req
    已尝试这个

    我有一台路由器，带有 addr：
    nwkAddr - 0x2F3B
    ieeeAddr - 0x00124b001cd4bf20

    我发出命令：FE0B 2534 2F3B 00124b001cd4bf20 02
    响应为：FE0165340050
    状态=正常
    命令已完成、对吧？

    正在尝试 UTIL_GET_DEVICE_INFO、响应：FE10670000B738DD1C004B120000000709013B2F7B
    AssocDeviceList - 3B2F

    尝试反转字节：
    FE0B 2534 3B2F 00124b001cd4bf20 02
    没有影响。

    正在尝试：
    FE0B 2534 3B2F 20bfd41c004b1200 02
    FE0B 2534 3B2F 20bfd41c004b1200 01
    FE0B 2534 3B2F 20bfd41c004b1200 00
    FE0B 2534 0000 20bfd41c004b1200 02
    (笑声)
    FE0B 2534 0000 000000000000000000000000 02
    (笑声)
    结果相同。

    4.我在哪里犯了错误？ 如何删除路由器？

    ps.两天 前、我收到了协调器和路由器针对 ZDO_IEEE_ADDR_REQ 的 ARSP 响应。 但发生了一些事情。 现在我没有 ARSP。 已试用的时间：
    FE04 2501 3B2F 0100
    FE04 2500 0000 0100

    唯一的响应 FE0165000064、没有其他内容。 我不时得到 FE0345C43B2F0096、但没有 ARSP。 文档中有 UTIL_callback_sub_cmd。 已订阅所有回调 FE032706FFFF01。 没有用处。

    已尝试重新启动并重新初始化协调器。 无结果。
    5.有什么问题？

    PPS。 使用命令自定义来自传感器的数据间隔：
    FE172401 9C01 010102040B001E0D 100C06000000290500 B400 3200

    当传感器直接与协调器通信时、此命令有效。 有时我会失败。 但总的来说、它可以正常工作。
    现在、传感器通过路由器进行通信。 此命令不起作用。 有两个答案：
    FE03448000010BCD
    FE0164010064
    但它不会更改数据间隔。

    6.1."传感器直接连接到协调器"和"传感器连接到路由器"之间有何区别？ 如何在两种情况下控制相同的传感器？ 应该使用不同的命令吗？
    6.2.为什么在发生故障时状态= OK？
    6.3. AF_DATA_QUEST 中的"TransId"是什么意思？(0x2401) 从何处获取？ 要使用什么 TransId？

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    1. macDestAddr 、 相关性和  RSSI 不会被跳过、而是永远不会传递到 MT 层、以使用 AF_INVING_MSG 传输到主机。
    2. 0x29是数据类型(ZCL_datatype_Int16)、0x0000是属性 ID (ATTRID_TEMPERATE_measuring_measured_value)、0x180D0A 是 ZCL 头文件(帧控制0x18、事务序列编号0x0D、命令 ID 0x0A/ZCL_CMD_REPORT)。
    3. 我的意思是、仅当 ZED 轮询数据(POLL_RATE)时才会发送用于 ZED 的消息、如果这比间接消息的超时值(NWK_INDIRECT MSG_TIMEOUT)慢、则在到达 ZED 之前可能会丢弃该消息。
    4. 我假设"FE0B 2534 0000 20bfd41c004b1200 02"几乎正确、但 当然 应该是来自 ZR 的 ZDO_Mgmt_ley_RSP 响应  您可以验证是否使用监听器器件发出了正确的消息、以及 ZR 是否确认了此消息并做出相应的响应。  此外，ZR 还应宣布其离开网络，然后 ZNP 将其指示为 ZDO_LEASE_IND，从而将其从关联表中删除。
    5. ZR 可能不在线、可通过 ZDO_IEEE_ADDR_RSP 对 ZDO_IEEE_ADDR_REQ 做出响应。
    6. 不应使用不同的命令、因为这都是通过 Zigbee 网状路由层处理的。  第一个响应是 AF_DATA_CONFIRM、这意味着路由器确认收到了来自本地设备的消息、第二个响应是本地设备发送给 AF_DATA_REQUEST 的 SRSP、以告知主机 AF_DATA_REQUEST 将通过无线方式发送。  如果没有端到端确认、ZNP 永远不会知道消息是否从 ZR 传送到 ZED、也许消息在等待 ZED 数据轮询时超时。  TransID 由用户设置为任何值、在 确定另一个器件(如 ZR)确认已通过 AF_DATA_CONFIRM 回调接收到哪条 AF_DATA_REQUEST 消息时尤其有用。

    此致、
    Ryan

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Ryan
    感谢您的回复。

    1.是的、明白了。 但我无法理解这条规则。 我如何从结构中获取它、而不是再次询问您？
    目的是获取信息、并了解如何获取信息、而无需提出大量问题。
    2.宾果游戏。 非常有用的信息。
    唯一的困惑是、我在源代码中找不到 ATTRID_TEMATE_TEMATE_measure_measured_value。 有许多类似的表达式等于0x0000、但不完全是 ATTRID_TEMP_TEMATE_measure_measured_value。 是从另一个地方获取的吗？

    2.1.要配置传感器、我发送"100D06000000290500B4003200"
    10 -帧控制？
    0D -事务序列号?
    0600 -它是 ZCL_HA_DEVICEID_REMOTE 控制吗？
    0000 - ATTRID_TEMATE_measuring_measured_value
    29 - ZCL_datatype_Int16
    0500 -值更改级别
    B400 -最小周期
    3200 -最大周期

    2.2."事务序列号"显示在 Zigbee 消息和"数据"中。 为什么？
    在"数据"中、它比1更大。 正确吗？
    如果不这样做、会发生什么情况？

    4.1.在多次尝试"FE0B 2534 0000 20bfd41c004b1200 02"之后、发生了这种情况。 ZR 确实被删除。 通信停止。
    接下来、我尝试恢复路由器
    FE0B 2535 0000 20bfd41c004b1200 0E //路由器关联的904D [0x4D90]

    添加相同的传感器
    FE0B 2535 904D 7ae29d23004b1200 00
    无通信。

    但在手动加入按钮后、通信会恢复、无需任何其他设置。
    这是否意味着无法用 ZDO_Mgmt_direct_join_Req 替换手动加入？

    4.2. ZDO_IEEE_ADDR_REQ 仍然存在问题。
    ZR 确实处于联机状态。 我通过它从传感器获取消息。
    为了重新验证、我将 ZR 放置在协调器旁边。 无结果。
    然后重新编程 ZR。 无结果。
    ZDO_IEEE_ADDR_REQ 无 ARSP。 SRSP 是 ZR 的唯一回复
    FE01 6501 00 65

    但奇怪的是、协调器没有对 ZDO_IEEE_ADDR_REQ 作出任何答复。
    FE04 2501 0000 0100

    同一答复
    FE01 6501 00 65

    协调器回复 ZR 是否脱机？

    我阅读文档并仅查看其链接到 UTIL_callback_sub_CMD。 已尝试、无结果。
    FE03 2706 FFFF 01

    是否还有其他限制因素？

    6.我重新组装网。 尝试直接从协调器向终端设备发送消息
    FE17 2401 9C01 010102040C001E0D 100D06000000290500B4003200

    响应是
    FE01 6401 CD A9

    CD =状态
    源代码中找到
    #define afStatus_NO_route ZNWKNORoute // 0xCD */

    是我的错吗？
    如何打败它？
    已尝试：
    MAC_SCAN_REQ
    ZDO_Mgmt_NWK_DISC_REQ
    ZDO_Mgmt_LQI_REQ
    ZDO_EXT_route_disc
    无结果。 如何获取路线？

    6.1.ZDO_EXT_route_DISC 需要"选项"。 无法找到其描述。 从何处获取？

    7.什么是设备在关联列表中？
    有两个与协调器相关的传感器。 然后、我使用 ZDO_Mgmt_leave REQ 删除了其中一个
    它从 AssocDeviceList 中消失，仍继续发送消息。 这是可以的吗？ 如何使传感器在取消关联后不发送消息？

    谢谢。

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    1. 您无法从默认的 Z-Tool 中获取此信息。  您必须添加 MT_MAC_CB_FUNC 才能访问 MT_DATA_IND 或创建自定义 MT 函数。
    2. 我讲错了、因为 它实际上是 CC253X Z-Stack 中的 ATTRID_MS_TEMP_TEMP_TEMATE_measored_Value、可以在 zcl_ms.h 中找到、而不包含在没有 ZCL 应用层的 ZNP 项目中。  但是、这现在似乎是您尝试创建的内容、以便向您的器件发送 ZCL 命令。  您必须更仔细地遵守 ZCL 规范、以完全了解如何发送 ZCL 消息、并在调试期间使用监听器确认过程。  您是否考虑  改用 www.zigbee2mqtt.io/等现有主机解决方案？  对于序列号、这是 NWK 层序列号和 ZCL 层事务序列号之间的差异。  APS 层上还有 APS 计数器以及 MAC 层序列号，但 ZNP 不会通告这些计数器。
    3. 不适用
    4. 一旦删除了不允许重新加入的路由器，它必须在网络引导过程中从关联开始重新启动加入过程。  因此，ZNP 必须启用“允许加入”以允许 ZR 完成新的加入。   SRSP 从 ZNP 发出指示它接收到 ZDO_IEEE_ADDR_REQ 消息、但它不指示与 ZR 的通信。  确保您具有正确的短地址、因为如果 ZR 执行了新的联接或清除了 ZNP NV 存储器、该地址将会发生更改。
    5. 不适用
    6. 如果 ZNP 被出厂复位或重新编程 并建立了一个新网络、那么目标地址可能会再次不正确。  短地址由 ZNP 以 ZC 角色的方式随机分配。
    7. 关联表包含 可以与节点直接通信的设备，例如子终端设备和邻居路由器。  是否在 ZDO_Mgmt_leave Req 中设置了重新加入位、以及您请求离开的节点是否使用 ZDO_Mgmt_leave RSP 和 ZDO_leave _IND 进行响应？  不可能强制非法设备不发送消息、 但您可以使用 UTIL_SRC_MATCK_DEL_Entry 将其从源地址表中删除、并使用 ZDO_SEC_DEVICE_REMOVE 和 ZDO_REMOVE_LINK_KEY 将其删除。

    此致、
    Ryan

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Ryan
    感谢您的回复。
    是的、我使用 https://www.zigbee2mqtt.io。 侦听流量并尝试理解。
    这就是为什么我有一些问题。

    您的支持非常有用。 我在源代码和 Zigbee 集群库规范中发现了很多内容、但仍然有一些问题。

    1.当我发送"AF_DATA_Request"时、我通常会得到：
    FE03 4480 F0 01 03 35

    状态= 0xF0。

    我在 AF.h 中找到了超过30个状态、但没有0xF0。
    0xF0是什么意思？
    ZED 的消息在超时内未发送时是否出错？

    我在到达"AF_INVING_MSG"后一直在发送"AF_DATA_Request"。 我以前获得状态0xF0、有时是0x00 (成功)。
    我无法理解何时应发送"AF_DATA_Request"以获得成功。

    侦听 zigbee2mqtt。 到达 ZDO_TC_DEV_IND 后、它会发送：
    ZDO_NODE_DESC_REQ
    ZDO_EXT_route_disc
    ZDO_ACTIVE_EP_REQ
    ZDO_SIMPLE_DESC_REQ
    因此、我也执行同样的操作、只有在配对后发送这些命令时、才会获得这些命令的响应。
    如果延迟-无响应。
    它们是否真的只能在配对过程中发送？
    如果我需要重新申请该怎么办？ 我该怎么做？

    4.我继续从 AF_INVING_MSG 解析"数据"。
    属性0x0005的数据
    "18 03 01 05 00 42 04 54 48 30 31"

    0x03–事务序列号
    0x01 - ZCL_CMD_READ_RSP
    0x0005 -来自 ZCL 的 ModelIdentifier
    0x00 -???
    0x42 - ZCL_datatype_char_STR
    0x04 -字符串长度
    "54 48 30 31"-字符串

    中间的0x00是什么？

    属性0x0002的数据
    "18 08 01 02 00 86"
    0x03–事务序列号
    0x01 - ZCL_CMD_READ_RSP
    0x0002 -来自 ZCL 的 StackVersion
    0x00 -???
    0x86 -??? 它不是数据类型、对吧？ 这是什么？

  • 0
    TI__Guru**** 2378720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    1. 0xF0为 ZMacTransactionExpired、这意味着终端器件在超时时间内没有轮询数据、因此数据缓冲区被删除。
    2. 根据 ZED 的轮询速率、您 可以从  上次成功发送消息的时间开始同步 AF_DATA_REQUEST 和/或 增加 SysConfig 在 ti_zstack_config.h 中为 ZNP 项目生成的 NWK_INDIRECT MSG_TIMEOUT。
    3. 这些数据可以随时发送、因为它们不依赖于调试过程、区别最有可能是 终端设备在此期间更频繁地轮询数据。
    4. 0x00是状态、正确 为 ZCL_STATUS_SUCCESS、这意味着 ZCL 层理解并正确响应了读取命令。
    5. 分析增加了额外的0x00、但状态返回为0x86 、即 ZCL_STATUS_UNSUPPORTED_ATTRIBUTEXTE。

    此致、
    Ryan