LQI on coordinator

[abe]

Hello, I developed for my customer, a ZigBee coordinator in last 2019, using nRF5 SDK for Thread and Zigbee v3.2.0.
Now my customer ask me if it possible to have the LQI value for each end node
There are any ways to get this value from Coordinator?
I see the function zdo mgmt_lqi ... is this helpful?
Thaks
Abele Barbieri

[abe]

Sorry, I forgot to inform about my coding ...
The steering and network formation of all end node is trough the Coordinator
The custom application of my "Coordinator" needs to receive also information (battery, on/off status, ... ) to take some actions related
Then, for all end nodes that are allowed to entry on the network, my "Coordinator" custom application make some binding and subscription for needed clusters
If I chek the communication "over the air" I see that some end nodes send directly to coordinator, but they are not on the Coordinator neighbor table

[Marte Myrvold]

When you say that you check the communication over the air, do you mean by capturing a sniffer log? If so, can you upload the sniffer log here?

[abe]

Yes, over the air communication was sampled using ZigBee sniffer.
Unfortunately I have not available logs.
In any case, I try to add more info to this case, as I have have observed
- On my "desk" setup I have my Coordinator, one bulb, one smart pulg, and one SED Door Sensor. The door Sensor is closer to Coordinator; the Bulb is farther
- smart plugs and bulbs (that are also ZR) some times (I have not understood how and why) immediatly after the Coordinator allow access and give Network address to end node, takes some "network" actions
- as a result for the actions above, the end node is no more on Coordinator neighbors table
- the end node is now on neigbours table of ZR
- when send the autoreporting, it is addressed directly to coordinator
- The kit I'm using (as requeste by my customer) is composed by Heiman ZigBee products

[Marte Myrvold]

Hi,

abe said:

takes some "network" actions
- as a result for the actions above, the end node is no more on Coordinator neighbors table

Are these "network actions" responses to packets from the SED, such as end device timeout and node descriptor request? I would guess so since the result is that the SED is in the neighbor table of the ZR and not the ZC, meaning that the ZR is the parent, but without knowing what the packets actually are I cannot tell you more about what is happening besides what the expected behavior is. When an end device joins a network it will look for a suitable parent device. The end device might find more than one suitable parent, and in that case it will select one of them. 

abe said:

when send the autoreporting, it is addressed directly to coordinator

Is it sent directly to the coordinator without going via the router, or is it just that the destination address is the coordinator?

Best regards,

Marte

[abe]

Hi Marte
I found WireShark log that show one of case I noted.
to explain the contents:

Door Sensor short = 0x7d09, 0x92dc
Bulbs short = 0x91d4

- line 14703 Door Sensor (0x7d09) send IAS status to coordinator
- line 14705 coordinatore reset (only for test)
- line 14717 iniziate rejoin
- line 14723 update sensor address to 0x92dc
- line 14749 Door Sensor (0x92dc) send IAS status to coordinator

rejoin_bulb_nw_add_change.pcapng