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
Hi,
The coordinator will find the device again by sending a network address request if it has the IEEE addr of the device. It should do this automatically when it is unable to reach the device, unless it gets the short address in some other way.
In your case the coordinator receives a packet, an attribute report, from the sensor before it tries to send anything to the sensor itself, so it will get the new nwk addr from this and will use it to send a route request to update the routing table:
I also captured a sniffer log where the device sends a network address request to show and explain the procedure for you.
In the following sniffer I have
Originally the light bulb was the parent of the light switch (with addr 0x086b). I then turned off the bulb. The switch got the same nwk addr after rejoining under the coordinator, so for the sake of simplicity I just deleted the stored network data of the switch so that it would be commissioned again with a new nwk addr, since the IEEE addr will be the same anyway. When it joined the next time, with the coordinator as parent, it got 0xfc07 as nwk addr.
After this I turned the bulb on again, and I tested by sending an read attributes request (zcl attr read) from the bulb to the previous nwk addr of the switch, but since the bulb does not have the switch in either it's neighbor table or routing table it will send a route request to find it:
As you can see the extended dst (the IEEE addr) is correct, but the nwk dst is the old nwk addr of the switch. Because of this the bulb does not get any replies to the route request and will keep trying:
After multiple retries and realizing that it will not get a response it will send a network address request to get the new nwk addr of the switch, since it knows the IEEE addr:
Best regards,
Marte
Hi,
The coordinator will find the device again by sending a network address request if it has the IEEE addr of the device. It should do this automatically when it is unable to reach the device, unless it gets the short address in some other way.
In your case the coordinator receives a packet, an attribute report, from the sensor before it tries to send anything to the sensor itself, so it will get the new nwk addr from this and will use it to send a route request to update the routing table:
I also captured a sniffer log where the device sends a network address request to show and explain the procedure for you.
In the following sniffer I have
Originally the light bulb was the parent of the light switch (with addr 0x086b). I then turned off the bulb. The switch got the same nwk addr after rejoining under the coordinator, so for the sake of simplicity I just deleted the stored network data of the switch so that it would be commissioned again with a new nwk addr, since the IEEE addr will be the same anyway. When it joined the next time, with the coordinator as parent, it got 0xfc07 as nwk addr.
After this I turned the bulb on again, and I tested by sending an read attributes request (zcl attr read) from the bulb to the previous nwk addr of the switch, but since the bulb does not have the switch in either it's neighbor table or routing table it will send a route request to find it:
As you can see the extended dst (the IEEE addr) is correct, but the nwk dst is the old nwk addr of the switch. Because of this the bulb does not get any replies to the route request and will keep trying:
After multiple retries and realizing that it will not get a response it will send a network address request to get the new nwk addr of the switch, since it knows the IEEE addr:
Best regards,
Marte
