LQI on coordinator

RE: LQI on coordinator

Marte Myrvold — Fri, 18 Mar 2022 09:40:43 GMT

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

Coordinator: 0x0000
Light bulb (router): 0xe370
Light switch (end device): 0xfc07, previously 0x086b

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

RE: LQI on coordinator

abe — Thu, 17 Mar 2022 12:22:21 GMT

Then if Coordinator remain power off for bit time, the routers reconfigure the network address of all end nodes and will not inform the coordinator?
This is very dangerous!!

Have a suggest to solve, in other words how to allow coordinator to get all new end-node address?

RE: LQI on coordinator

Marte Myrvold — Thu, 17 Mar 2022 11:58:21 GMT

Hi Abele,

No, not if the coordinator is off when the update device command is sent. You see that the parent (bulb) tries to send the update device command to the coordinator in packets 14759-14762, but since the coordinator is it does not receive the packets. The router will not resend the update device packets when/if the coordinator joins the network again.

Best regards,

Marte

RE: LQI on coordinator

abe — Thu, 17 Mar 2022 11:11:32 GMT

Hi Marte
many thanks for the clear explain ... he had been fooled by log shows sender-receiver
After this, when coordinator awakes, it should receive the ZB_ZDO_SIGNAL_DEVICE_UPDATE, correct?

Abele

RE: LQI on coordinator

Marte Myrvold — Wed, 16 Mar 2022 15:07:50 GMT

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

RE: LQI on coordinator

abe — Wed, 16 Mar 2022 12:43:16 GMT

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

devzone.nordicsemi.com/.../rejoin_5F00_bulb_5F00_nw_5F00_add_5F00_change.pcapng

RE: LQI on coordinator

Marte Myrvold — Wed, 16 Mar 2022 12:08:39 GMT

Hi,

[quote user="Abele"]takes some "network" actions
- as a result for the actions above, the end node is no more on Coordinator neighbors table[/quote]

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.

[quote user="Abele"]when send the autoreporting, it is addressed directly to coordinator[/quote]

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

RE: LQI on coordinator

abe — Tue, 15 Mar 2022 15:21:10 GMT

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

RE: LQI on coordinator

Marte Myrvold — Tue, 15 Mar 2022 14:48:49 GMT

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?

RE: LQI on coordinator

abe — Tue, 15 Mar 2022 14:24:55 GMT

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

RE: LQI on coordinator

Marte Myrvold — Tue, 15 Mar 2022 13:45:57 GMT

What kind of data are you thinking about? An end device will always route packets via its parent device, so all communication with other devices on the network will go through the parent.

RE: LQI on coordinator

abe — Tue, 15 Mar 2022 13:23:25 GMT

Thanks Marte,
I tried the function cmd_zb_mgmt_lqi on my stack 3.2.0 and I get same result on my side, the "router" resturn the LQI to Coordinator / LQI to SED (Coordinator -- smart plug -- SED device)
Note that when SED awakes, the data are sent "directly" to coordinator, right?

RE: LQI on coordinator

Marte Myrvold — Tue, 15 Mar 2022 13:08:25 GMT

Hi Abele,

Yes, you can find LQI of non neighbor devices as well. LQI indicates the quality of a link between two devices, so for a non neighbor device you will have one LQI for each link. In the case where you have a coordinator, a router, and an end device, and the router is the parent of the end device you will have two links between the coordinator and end device (coordinator --- router --- end device), where each link will have their own LQI.

To do this you can send a Mgmt_lqi_req command, for example with zdo mgmt_lqi if you're using Zigbee shell commands. If the coordinator sends this to the router then the router will respond with its neighbor table, which will contain LQI for each entry in the neighbor table. You can see this yourself if you test with Zigbee shell. This is an example where I sent zdo mgmt_lqi from my coordinator to a light bulb (router), and the resulting neighbor table from the light bulb:

> zdo mgmt_lqi 0x3f4d
[idx] ext_pan_id ext_addr short_addr flags permit_join depth lqi
[ 0] f4ce36ab839f2ac6 f4ce36ab839f2ac6 0x0000 0x84 1 0 228
[ 1] f4ce36ab839f2ac6 f4ce36314cd4585a 0xd0f2 0x16 0 2 248

The light bulb has two entries in its neighbor table, where the first one (short addr 0x0000) is the coordinator, and the second (0xd0f2) is a light switch, which is an end device with the light bulb as its parent.

Best regards,

Marte

RE: LQI on coordinator

abe — Tue, 15 Mar 2022 09:04:14 GMT

Ok, it is clear.
Then, there are NO way for coordinator to know the LQI of end nodes that aren't neighbors?

RE: LQI on coordinator

Marte Myrvold — Tue, 15 Mar 2022 07:36:51 GMT

Hi Abele,

You can use zdo mgmt_lqi for this, but if you want to know the LQI between the coordinator and its neighbor then you do not need to send a Mgmt_Lqi_req command. This command is for obtaining the neighbor table of a remote devices. One of the fields of the neighbor table is LQI, so if you want to know the LQI between a remote device and all of its neighbors, then this command is useful. On the coordinator you can check the entries of its neighbor table locally.

I have made a function that will iterate through the neighbor table and print to log the short address and LQI of each neighbor:

static zb_void_t get_lqi()
{
    uint32_t i;
    zb_uint16_t addr;

    /* If gc_neighbor[i].used is 0, the entry is not used */
    /* If gc_neighbor[i].ext_neighbor is 1, this is ext neighbor record, else base neighbor */
    for (i = 0; i < gc_neighbor_table_size; i++) {
        if ((gc_neighbor[i].used == 0) ||
            (gc_neighbor[i].ext_neighbor != 0))
        {
            continue;
        }
        zb_address_short_by_ref(&addr, gc_neighbor[i].u.base.addr_ref);
        NRF_LOG_INFO("short_addr: 0x%04x, #LQI: %d", addr, gc_neighbor[i].lqi);
    }
    
}

Be aware that this will only show the LQI of the devices that are neighbors to the coordinator. If they are not neighbors, either because they are out of range or because the remote device is an end device with a parent that is not the coordinator, then you cannot use the above. In that case you do not have a direct link between the coordinator and the remote device, so you would not have a LQI between the coordinator and remote device anyway.

Best regards,

Marte