Setting of data request count for device join

[iot_abel]

Hello!

When the terminal device enters the network, if the coordinator does not reply to the key after the association response or the key transmits a packet loss, the device will send multiple data requests (about 14 count). Can the number of data requests be reduced? What should I do? Please give me some guidance.

Thank you

[iot_abel]

Can this number be reduced? Is there a way?

thanks!

[Sebastian_Del_Rio]

Hi Abel, I hope you're doing well!

The event you're seeing in the APP_vGenCallback print on the console corresponds to a ZPS_EVENT_NWK_POLL_CONFIRM event, meaning that the device successfully polled for information. If you want to reduce the times this message is displayed, you could try reducing awake time, so that the device doesn't poll as much.

Could you please try that?

Best regards,

Sebastian

[iot_abel]

Hello Sebastian

We tested it according to your method. Look at the picture below

We use PWRM? Escheduleactivity to sleep, but the system will continue to send data reply after waking up

Is the interface we call wrong?

We want to reduce the number of requests, so as to enter the next channel in advance or the coordinator to scan the network. We test that failedtojoin snwkjoinfailedevent. U8status = 235!!! Then we will enter the next channel. Do we have any way to achieve this?

Thank you for your support！

[Sebastian_Del_Rio]

Hi Abel,

Could you please let me know which Application Note did you use for each of the devices? For both your coordinator and your end device.

Could you please provide a sniffer log to see if devices are allowed to join the network?

Best regards,

Sebastia

[iot_abel]

Hi Sebastia

When the coordinator does not allow the device to join, the device will frequently request the key on the coordinator (frequently report data repuest). We just want to modify the number of times the coordinator does not send the key (because the coordinator does not allow the join) data repuest after the coordinator sends the associated reply to the device

Best regards,

Abel

[Sebastian_Del_Rio]

Hi Abel,

Could you please let me know which application notes are you using for each of your devices?

Also, could you please attach the sniffer log itself by using the advanced editor?

 

From there, the option to attach a file to your reply becomes available.

Best regards,

Sebastian

[iot_abel]

Hi Sebastian

Test environment: Coordinator does not use device code (Install code)。But the end  device is used install code.

So the device will frequently request the key 14 times。（send data request 14 cnt）.

The purpose we want to achieve is that when the coordinator does not transmit the key or there is a packet loss or error in the key, the terminal device should not perform

Multiple data requests because we are low power devices.

    Do we have a way to achieve this?

thank you!

------------------------------------------------------------------------------------------------------------------------------------

你好！

   我们的测试环境是：协调器没有使用install code,但是终端设备是有使用。所有设备入网的时候传输的key协议栈会认为是错误的。

就会频繁的发送data request 请求key，我们想要实现的目的是，当协调器没有传输key 或者 key 出现丢包或者错误的情况，终端设备不要进行

多次的data request，因为我们是低功耗设备。

   请问我们有办法实现吗？

谢谢你！

[Sebastian_Del_Rio]

Hi Abel,

The purpose for sleep mode is that, after connection between devices is established, the end device can go to sleep and not consume as much power.

Is it possible for you to provide a little more information about your end project? Could you please let me know which JN-AN-xxxx did you base your devices on? This is so I can further help you solve your problem.

Best regards,

Sebastian

[iot_abel]

Hi Sebastian

We are based on JN-AN-1219-Zigbee-3-0-Controller-and-Switch 。

The end device join process should be the same, is it related to the project based on?

The process of end device join is the same, you can easily simulate our problem。

Please guide us on what to do? Can we achieve the reduction of data requests?

thanks!

-------------------------------------------------------------

你好！

我们基于 JN-AN-1219-Zigbee-3-0-Controller-and-Switch 修改

end device 的join流程应该都是相同的，跟基于的项目有关吗？

end device join 的流程相同，你们可以很方便的模拟出来我们的问题。

请指导我们该怎么做？我们减少data request 的要求能够实现吗？

[Sebastian_Del_Rio]

Hi Abel,

The retry mechanism is part of both the ZigBee and 802.15.4 specifications.

An alternative way of joining devices is through the binding process, which is described in section 2.6.2 of the ZigBee 3.0 Stack user guide, which can be found here.

Maybe that type of connection could be useful for your use case?

Please let me know if you need any more information.

Best regards,

Sebastian