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 Abele,
Since the door sensor lost connection to its parent when the coordinator was reset it will try to rejoin the network to get a new (or the same) parent. You can see that the bulb is the new parent since the door sensor sends an end device timeout request to it (packet 14735). Later, the door sensor sends a network address request to find the short address of the coordinator (packet 14746), and from this it will find that the coordinator is in the neighbor table of the bulb, so it knows the route to the coordinator (door sensor -> bulb -> coordinator), and can now send packets to it via its parent. It might seem like the packet is sent directly, but if you inspect the packet and compare it to similar packets sent when the coordinator was the parent you will see that there is a difference.
Coordinator as parent:
Bulb as parent:
As you can see, the destination in the network layer frame is still the coordinator in both cases, because the final destination of the packet is still the coordinator. However, in the case where the bulb is the parent device the destination in the 802.15.4 MAC data frame is the bulb, and not the coordinator. So the packet is routed via the bulb when it is sent from the door sensor and to the coordinator in this case.
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
