[参考译文] CC2530：器件关联- Linux 网关未报告-无跟踪。

您好！

通常、在成功响应关联后、传输密钥很快就会发生、因此延迟这一事实可能是一个很好的调查点。 传输密钥由 ZNP 处理、因此我认为网关不存在故障。

您能否分享您如何进入该状态？ 重置 ZNP 后、您能在多快的时间内重新创建此问题？

.bin 的生成方式与" /Documents/CC2530/Serial 用于 CC2530.pdf"的引导加载程序。

此致、
Toby

你好

感谢您的反馈。  我将首先回答您的问题、然后再发布另一条测试消息。

传输密钥在关联请求后的1.2秒内进行通信-这不会减慢 IMHO。

问题是未更新设备列表。

我注意到、该器件之后不会发出器件通知。  我不知道这是否是强制性的。  我今天设法获得了另一个器件发布的序列、但不管怎样、它不会添加到器件列表中。

关于二进制文件、我在一段时间前创建了脚本、但我从未尝试从软件包中的十六进制文件中重新创建相同的 bin 文件、因此我对生成的 bin 文件不信心。
下面是一个示例 Makefile。  该脚本会对参考二进制文件和从 hex 文件创建的文件进行 hexdump。  然后对这些进行比较、以检查脚本是否正常。  当我对 CC2531文件执行此操作时、有太多的差异需要相信。  另一种方法需要重新编译栈、但我没有许可证。

objcopy=arm-linux-gnueabihf-objcopy

HEXFILE_PROD=CC2530-GW-ZNP.hex
HEXFILE_PRODBIN=CC2530-GW-ZNP.bin
HEXFILE_PROD_TESTBIN=CC2530-GW-ZNP_test.bin

转换：
$(objcopy)-I ihex --output-target=binary $(HEXFILE_PROD)--GAP-FLOC=255 $(HEXFILE_PROD_TESTBIN).Full
DD skip=8192 Bs=1 if=$(HEXFILE_PROD_TESTBIN)。full of =$(HEXFILE_PROD_TESTBIN)
#truncate -s-1 $(HEXFILE_PROD_TESTBIN)
RM $(HEXFILE_PROD_TESTBIN).FULL
hexdump -C $(HEXFILE_PRODBIN)> A
hexdump -C $(HEXFILE_PROD_TESTBIN)> b
-@DIFF a b >$(HEXFILE_PROD_TESTBIN).DIFF
错误 a b

这是与同一器件的另一个会话。

在上一会话中、加入的设备在收到传输链接密钥后未发出"设备通知"。

一个良好的滤波器开始位置是：frame.time_epoch >= 1593709799

设备会发出设备通知：
17：10：00、156032 0x4ece 广播 ZigBee ZDP 65器件公告、NWK 地址：0x4ece、外部地址：Ember_00：11：61：86：52 3076

但它不会显示在器件列表中。

当设备报告一些在网关报告中也报告(部分)的属性时，这些属性会报告给应用程序并与设备"00：00：.....相关联 "。

[202020-07-02T17：10：05] Raw = 17：00：53：22：08：22：12：0F：08：00：11：00：00：00：00：00：28：01：30：01：18：25：20：00
[202020-07-02T17：10：05]========= >SNSR_process_zone_status_change_ind：Addr = 0、EP = 00000001、zonestatus = 00000025、ExtendedStatus = 00000000
[202020-07-02T17：10：05] attr_update_attribute_in_dev_table、IEEE=00：00：00：00：00：00：00 EP=01、clstr=0500
VLD=1、id=0002、tp=25、val=00000025
[202020-07-02T17：10：05]从网关接收：len=12、cmd_id=21、subsystems=83
[202020-07-02T17：10：05] Raw=0C：00：53：15：08：15：10：17：18：04：22：02：08：00：28：00
[202020-07-02T17：10：05] attr_process_read_attribute_response：错误：状态超时-< type=0 >。
[202020-07-02T17：10：06]###### EMIT 试运转剩余((int) DS_network_status.permit_remain_time)######
[202020-07-02T17：10：06]从网关接收：len=41、cmd_id=26、subsystems=83
[202020-07-02T17：10：06] Raw=29：00：53：1A：08：1A：10：00：1A：0F：08：00：11：00：00：00：00：00：00：28：01：30：01：20：01：2A：07：08：20：20：20：20：20：00：01：01：1A：01：01：01：01：01：1A：01：01：01：01：01：01：1A：01：01：01：01：01：1A：01：01：01：01
[202020-07-02T17：10：06] attr_process_attribute_report_ind：状态成功。
[202020-07-02T17：10：06] addr=< type=0 ieeeedr=00：00：00：00：00：00 endpointd=00000001 >、msg->n_attributterecordlist = 2.
[202020-07-02T17：10：06] attr_id =-1280963515，val = 2000000020，attr_type = 1，len =-1246599224
[202020-07-02T17：10：06] attr_id =-1280963475，val = 2000000021，attr_type = 1，len =-1246599224
[202020-07-02T17：10：06] attr_update_attribute_in_dev_table、IEEE=00：00：00：00：00：00：00 EP=01、clstr=0001
VLD=1、id=0020、tp=32、val=78B5B21C
VLD=1、id=0021、tp=32、val=48B5B296

e2e.ti.com/.../DeviceAnnouncementNotAddedToDeviceList.zip

我再试一次。  我对协调器进行了下电上电。

然后、我对 objjet 进行下电上电-用户可以在监听器的日志中找到"离开"通知。

我在系统重新启动大约8分钟后继续执行加入过程。

这一次、器件确实被添加到器件列表中(在过去几天中多次尝试将其添加到器件列表中之后)。

问题是：有什么不同/在一个案例中它失败并在 anothere2e.ti.com/.../WorkingAssociation.zip?中成功的原因是什么

与之前的跟踪一样、有一个器件通告、并且在通告之后会报告属性。  只有这样、当器件处于 DEVICE_LIST 中时、情况会很好。

我已经升级到最新可用的网关(以及几乎最新的 ZStack)、以查看这种问题是否在过去的切换建议之后得到了解决。

我该怎么做来确定哪里发生了问题？

附加了日志文件和捕获文件(日志文件也可作为.pcap 文件提供)。

是的、终端设备需要在加入/重新加入时发送设备通知。

在 WorkingAssociation\zigbeeapp.log 中、应用程序接收 NWK_ZigBee_DEVICE_IND 的两种情况表明这是一个新器件(ieeedr = 0xd6f0011618652)。

在 DeviceAnnouncementNotAddedToDeviceList 中、一 个 NWK_ZigBee_DEVICE_IND 指示此器件已在器件列表中("在索引3中找到现有条目")。

在所有 Nwk_ZigBee_device_IND 情况下、Nwk_Mgr 服务器都会将其发送到其所有连接(OTASRVR、 网关和 CON007)。

您能否检查数据库文件 DbDeviceInfo.csv 是否包含您所期望的所有设备？

你好

感谢您对此进行深入研究。

我感兴趣的器件为"0xD6F0011618652"。

在 DeviceAnnouncementNotAddedToDeviceList 中、一 个 NWK_ZigBee_DEVICE_IND 用于另一个器件(0xcccfffe3a2f33)。

[202020-07-02T17：08：27] DEVICE_PROCESS_CHANGE_IND：接收 NWK_ZigBee_DEVICE_IND
[202020-07-02T17：08：27] DEVICE_PROCESS_CHANGE_INDI写：在索引3处找到现有条目
[20202020-07-02T17：08：27] update_device_table_entry：添加/更新0xctrad1 0xccdr 0x36846_inese_endr 1 0xccpu_ines1 necu_ines1 nedr_ines1 

器 件"0xD6F0011618652" 在17：09：13接收到关联响应、并在17：09：59重复发出关联请求。
它在17：10：00发布了“设备公告”。
 应用日志中没有对应的 NWK_ZigBee_DEVICE_IND。
网关日志中的最后一个 NWK_ZigBee_DEVICE_IND 条目是[202020-07-02 17：08：28]-用于另一个器件。

我不会一直检查 DbDeviceInfo.csv 文件，但它此时确实有预期的条目，因为关联成功。

    00：0D：6F：00：11：61：86：52、0xD869、0x00、0x1163、1、 00：12：4B：00：10：22：82：77、0xF0

因此，《国际海事组织》 (IMHO)在《设备通告》(DeviceAnnouncementNotAddedToDeviceList)中的神秘仍然存在。
(供参考、对于此器件、我的滤波器当前设置为：
WPAN.dst64=0xD6F0011618652||WPAN.src64=0xD6F0011618652 || WPAN.dst16 =0x15e4 || WPAN.src16=0x15e4 || WPAN.src16=0xd869 || WPAN.dst16=0xd869
)

好的、感谢您的澄清。

是否可以在 NWKMGR (可能还有 ZLSZNP)上启用完整日志？