[参考译文] 简单描述符请求：请求类型无效

忘记说：在监听器中、您可以看到"简单描述符请求：无效请求类型"

我还得到：  

Pacchetto：ZDO_State_change_IND
状态：26.

或  

Pacchetto：ZDO_State_change_IND
状态：67

该问题似乎与 智能降速湿度传感器更相关、我建议您联系制造商。

另外、因为考虑到智能仪表、我能够实现它、可能是因为一个是电池供电、另一个是电源插座供电？

但它是什么  

Pacchetto：ZDO_State_change_IND
州：76.

是什么意思？ 为什么发送简单的 Desc rqst 时会发生这种情况？

尊敬的 Ayman：

我无法解释 Wireshark 3.0.X 中的监听器日志、因为它显示了多个 Zigbee 数据包的"未知命令"。  此外、我不理解 ZDO_SIMPLE_DESC_REQ 与 ZDO_State_change_IND 的对应关系。  状态更改适用于本地器件、不应达到14以上的值。  ZDO_SIMPLE_DESC_REQ SRSP 或 ZDO_SIMPLE_DESC_RSP 的状态应为0 (成功)或1 (失败)。  请提供屏幕截图图像以进一步强调您遇到的问题。

此致、
Ryan

下面是给出总体想法的3个屏幕截图。

e2e.ti.com/.../Screenshots.rar

我不知道原因、但在发送 SimpleDescRQST 后、我会得到 state_change_ind、这可能是湿度传感器发送了一些奇怪的消息吗？

您的网络中似乎有 Zigbee 路由器(短地址为0x244a)、您的速度智能湿度传感器通过路由器连接协调器。 我建议您关闭路由器以再次进行测试。

通过关闭路由器进行测试、没有任何变化。

根据监听器日志、Evelco 智能湿度响应无效的请求类型、因此我仍然建议您先联系制造商。

我联系了他们、很快就会告诉您。

但是 INVALID_REQTYPE (值：0x80)意味着什么？ 进行编 程

ZDP_INVALID_REQTYPE 表示 目标节点无法处理 ZDO_SIMPLE _DISC_REQ 的参数。  因此、Nwk Addr 0x6943可能没有端点38或该端点内的任何有效输入/输出集群可供报告。

此致、
Ryan

在"SimpleDescREQ as dstAddr"中、协调器的 nwkAddr 和器件的 nwkAddrOfInterest 是 nwkAddr？ (ZStack 监视和测试 API)

如果您打算向器件发送简单的描述符请求、dstAddr 和 nwkAddrOfInterest 均应为 器件的网络地址。

然后我正确地执行了。  

跟进：经过一些测试后、我发现模型和制造商标识符群集已在第二个 EP 上实现。 最终获得了他们的价值、关于 DeviceID 的问题仍然没有得到解决。

主题外问题：我是否必须激活 CODEComposerStudio 中的任何标志才能使 IAS_zone 正常工作？ 通过监听器、我接收到 IAS_ZARE_REGANG_REQUEST、但通过串行读取、我没有读取它。

无法理解这意味着什么。

我建议您为这个新主题创建另一个帖子。

我的意思是、我仍然无法接收器件 ID、仍然获得无效的请求类型

您是否收到制造商的任何回复？

制造商告诉我，由于我们(我的公司和他们的公司)没有建立支持协议，他们不会帮助我。 足够公平。

如果制造商不想提供帮助，您可能应该考虑放弃使用此类设备。

我注意到的一件有趣的事情：SimpleDescRequest 的源端点和目标端点等于0 (您能解释一下原因吗？) 即使我将 SimpleDescRequest 发送到端点1、响应也会发送到 DestinationEP = 0、这是正确的行为吗？

您好！

消息源端点和目的端点可以相同。 这是因为这些端点位于不同的器件上。 例如，deviceA.endpoint0和 DeviceB.endpoint0。 "完整地址"是唯一的、因为 deviceA 和 DeviceB 应该具有不同的短地址。

通常、响应的目的端点将设置为请求的源端点。

但是、对于 ZDO 请求(例如 Simple Descriptor Request)、由于这些目标端点0、它有点不同。 (端点0为 ZDO 保留)。 而目标端点将位于有效负载本身中(与标头相比)。

这可能是您看到 SimpleDescRequest 使 srcEP = 0和 dstEP = 0的原因。

请尝试查看我们指南中的以下部分： ZigBee ZCL：keepalive/Poll 控制集群和组/场景(TI.com)

请参阅"在器件加入后发送匹配描述符请求"的代码片段。

谢谢、
Toby

Toby Pan 我认为 Ayman 确认问题已解决、我们应该能够关闭此主题。

感谢您的解释、不幸的是、我仍然收到 INVALID_REQUEST_TYPE、有时还收到该值、不知道原因

您 现在何时看到 INVALID_REQUEST_TYPE？

只需发送 SimpleDescRQST、就会得到无效的请求类型、而在其他情况下、我会得到"电平控制开关"器件 ID

错误实例和成功实例之间是否存在明显的网络差异？  最好提供 MT API 请求的准确内容和收到的响应。  但是，YK 之前提到，您需要制造商进一步参与才能进一步了解此设备的行为。

此致、
Ryan

据我所知、成功案例和失败案例之间不应有网络差异。
MT API 请求：简单描述、其中两个网络地址字段等于器件 NA 和 EP (器件的第一个)。

MT API 响应：请求类型无效(我不通过串行端口接收、而是通过监听器检查)

除非我 与他们达成支持协议、否则无法获得支持。 进行工作。

您能否附加监听器日志来详细说明当前问题？

当然。 在这里。
e2e.ti.com/.../1134.SmokeAlarmCantReceiveValue.rar

密钥：0xaabbccddeeff00112233445566778899

您希望我们检查哪个封装编号？

45至60

我看不到您的简单描述符请求有什么问题、也不知道器件为什么响应无效的请求类型。 您可能需要联系制造商并等待其响应。

响应甚至不会发送到正确的 EP。  
除非我有支持协议、否则制造商不想与我打交道。 我想我必须处理它

如果我在发送 SimpleDescREQUEST 后收到 ZDO_State_change_IND、这意味着什么？ 仅此品牌的商品才会发生这种情况

ZDO_State_change 指示本地器 件已更改其状态、其类型由 zd_app.h 内的 devstates_t typedef 定义、其状态不应受加入器件的影响。  由于您之前提供的状态值不符合 sensical devstates_t 值、因此应进一步调试本地应用程序以确定  触发 ZDUApp_ChangeState 的位置/原因。

此致、
Ryan

按本地设备、您是指协调器？