[Zigbee-mesh] How to initiate the route discovery manually?

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Fri, 16 Jul 2021 07:26:30 GMT

Hi Tu,

You can use the function zb_zdo_get_diag_data() to get RSSI. This will be the last known RSSI from a device with a specified short address. This will give the RSSI in energy level, but you can convert it to dBm with the function nrf_802154_dbm_from_energy_level_calculate().

zb_uint8_t lqi, rssi;
int8_t rssi_dbm;
zb_zdo_get_diag_data(0x0000, &lqi, &rssi);
rssi_dbm = nrf_802154_dbm_from_energy_level_calculate(rssi);

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Fri, 16 Jul 2021 02:38:12 GMT

Hi Marte,

Thank you very much for your help,

I understand the problem now, may be i will try to reduce the power of the coordinator sufficiently to be out of range, but to do so, can i measure the RSSI to approximately determine the range. I know there are some tools in NRF connect but it is for bluetooth, zigbee has the same antena so can i check the link symetry by that.

Once again, thank you and have a good day,

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Mon, 12 Jul 2021 11:41:08 GMT

Hi Tu,

[quote user="Tu Hoang"]the new route is unused because after some time, the router recognized that it could send the packet directly to the coordinator while actually it could not (due to router still receive the link status from coordinator). This makes the link is not maintain and expired after some time due to link asymetry.[/quote]

Yes, that seems to be the case. Because of the asymmetry in the coordinator's and router's transmit power, the coordinator is able to send packets to the router, but not the other way around, because the transmit power of the router is too low for the packet to reach the coordinator. Since the router receives link status from the coordinator, it believes the coordinator to be a neighbor, so it tries to send directly. So the solution would be to reduce the transmit power of the coordinator as well, so that it is unable to reach the router.

[quote user="Tu Hoang"] Is there a way for us to set the "send_via_routing" by ourself ?[/quote]

This is a part of the internal stack, which is precompiled, and is not forwarded to the SDK, so this is unfortunately not available in the code.

[quote user="Tu Hoang"]is there any way i can avoid the problem i currently have with this link symetry? [/quote]

If you are just going to test things as you have been doing now, it does not need to be symmetrical. In that case, you just need to make sure that the transmit power of both devices are such that they are unable to send packets to each other. Since the router still receives broadcasted messages from the coordinator, the transmit power of the coordinator is high enough that the router is still in range. Reducing the transmit power of the coordinator sufficiently so that the router is out of range would solve the problem.

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Sat, 10 Jul 2021 01:19:39 GMT

Hi Marte,

Thank you for your detail answer, but i just want to clarify this answer a little bit.

So, basically, the sum up of your this answer is that the new route is unused because after some time, the router recognized that it could send the packet directly to the coordinator while actually it could not (due to router still receive the link status from coordinator). This makes the link is not maintain and expired after some time due to link asymetry. Is this correct, if it is it align with what i guess from previous message.

Then, the reason i have nrf_802154_tx_power_set() is because i want to change the transmit power of the device so that its link become symetric. But it did not work so well, so as you can see in my code, i commented those lines.

Next, your team said "if it continues to send indirectly even after receiving a direct packet, the device is marked in the neighbor table as "send_via_routing" in order to not send directly." in the third part of the answer. Is there a way for us to set the "send_via_routing" by ourself ?. Because, as you can see, the router could only send 1 2 packet via routing and then it stopped.

Finally, I just want to ask another question, is there any way i can avoid the problem i currently have with this link symetry? beside tuning the antena to a point where the transmit and receive ability is equal (which is kind of hard and i could not think of a way to do that since we do not have enough measure instrument). And then, How can i check to see if the 2 antena on two separate board have link symetry problem by using code or any other means? Next, if i use the nrf_802154_tx_power_set() to change the tx power to compensate for the antena, could it work for me. Finally, is there any recommendation for me to avoid this problem in the future.

Once again thank you for your support,

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Fri, 09 Jul 2021 11:28:57 GMT

Hi Tu,

I am sorry for the delayed response. Our Zigbee team started an internal ticket with the developers of the ZBOSS stack, and got a response now with some comments regarding the stack's behavior and your tests. I will share their response with you here:

Routing table entry lifetime is not infinite. When the routing table entry is used, an internal function to reset route expiry is called. If routing table entry is not used, i.e. this function is not called, it will expire after a timeout. This expiration timeout is decided by ZB_NWK_ROUTING_TABLE_EXPIRY and ZB_NWK_EXPIRY_PENDING:
ZB_NWK_ROUTING_TABLE_EXPIRY (60) times * ZB_NWK_EXPIRY_PENDING (5s) = 300s.
Sending a packet directly is better than sending it via routing. So it is not that the router forgets that it must send the packet via routing, but instead that it discovered that the packet can be sent directly, and will thus do that instead.
Changing the transmit power with nrf_802154_tx_power_set() is probably causing an asymmetric link, where the TX power differs significantly, such that packets can go in one direction, but not in another.
By default ZBOSS tries to send packets directly, but if another device has problems receiving the packets, there are other problems (bad RSSI/LQA), or it continues to send indirectly even after receiving a direct packet, the device is marked in the neighbor table as "send_via_routing" in order to not send directly.

I hope this answers some of the questions you had!

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Fri, 11 Jun 2021 11:11:05 GMT

Hi Marte,

Thank you for your extremely detailed answer.

I now understand the setting of members in the routing table struct. It is very thoughtful of you to explain them in such elaborated manner. So in your answer, you mentioned "You are mentioning gc_neighbor_table, which is the neighbor table. This will not affect the routing table, as they are two different things. Additionally, the only thing you can change regarding this is the size of the table" Does this means that the only thing that I can change in the neighbor table and routing table is the size of them? And if, for example, i just read out a few entry in the routing table and neighbor table, if i change parameter like the aging counter in the neighbor table to 3 so that routing request happen faster. Is it possible?

Then, in the part where you got confuse, let me explain more clearly. The neighbor table and routing table here are refer to the data that i can log. I printed them both in every 5 seconds by using a loop. At that time, the node that i am monitor see like 3 neighbor (including the coordinator) and all the entry in the gc routing table are 0 which make it looks like the route for coordinator. So I just want to know if this is a normal behavior for zigbee.

Thank you for your help,

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Thu, 10 Jun 2021 13:24:53 GMT

Hi Tu,

I do not see any wrong with how you are sending the commands. Thank you for providing additional information!

I have not gotten a response from the team yet, but I have pinged them. I also looked more into some of your earlier questions myself, and I do have some thoughts regarding them.

Regarding next-hop address, you are correct that according to the specification it should be two octets, in order to contain the 16 bit network address. From my understanding, next_hop_addr_ref in zboss_api_internal.h does not contain the actual network address, but it is a reference to the address. This is why it is of type zb_uint8_t, and the size is 8 bits, because it is a pointer or reference, not the address. If you for example look at zb_zdo_routing_table_record_s, which is the format of the RoutingTableList record format of the mgmt_rtg_rsp command (Table 2.132 in the documentation you attached), then you will see that this has next_hop_addr (without the added _ref at the end), which is of the correct size (zb_uint16_t).

As for the status field, it references zb_nwk_route_state_t which could give some more information, but that is not available in the SDK. A lot of the ZBOSS stack is precompiled and unavailable in the SDK, and sometimes you might find references to something, but not the actual definition of this. The file zboss_api_internal.h is used to move some internal parts so they are accessible, but this means that it might be difficult to understand everything that is going on, as a lot is still hidden in the stack. However, I looked up the same file in NCS (nRF Connect SDK), which is another SDK we have. Zigbee in this is also based on the ZBOSS stack, as nRF5 SDK is, but it is using a newer version of the stack. There I found that the status field of zb_nwk_routing_t instead referenced nwk_route_state, which can actually be found in NCS (though not in nRF5 SDK). It can be found here, but I have also copied it here:

/**
 * @name NWK route state
 * @anchor nwk_route_state
*/
/** @{ */
#define ZB_NWK_ROUTE_STATE_ACTIVE               0U
#define ZB_NWK_ROUTE_STATE_DISCOVERY_UNDERWAY   1U
#define ZB_NWK_ROUTE_STATE_DISCOVERY_INACTIVE   2U
#define ZB_NWK_ROUTE_STATE_VALIDATION_UNDERWAY  3U
/* actually ZB_NWK_ROUTE_STATE_DISCOVERY_FAILED never used, so 2 bits are
 * enough for state */
#define ZB_NWK_ROUTE_STATE_DISCOVERY_FAILED     4U
#define ZB_NWK_ROUTE_STATE_NUM                  5U
/** @} */

So there you can both see what the different states are defined as, as well as the following:

actually ZB_NWK_ROUTE_STATE_DISCOVERY_FAILED never used, so 2 bits are enough for state

So I guess that is the explanation for why the status field is only 2 bits, and not 3 as in the specification.

I believe changing gc_neighbor_table should have an affect. Usually, in order to configure parameters like these, you would have to recompile the ZBOSS stack (which is already precompiled for the SDK, as I mentioned above). However, the file zb_mem_config_context.h gives the ability to change and configure some of these storage parameters without having to do so. So it seems like using that you can change this. You are mentioning gc_neighbor_table, which is the neighbor table. This will not affect the routing table, as they are two different things. Additionally, the only thing you can change regarding this is the size of the table.

gc usually stands for garbage collection in regards to computer science. This is a form of memory management, where the garbage collector deallocate memory occupied by garbage, where garbage is memory that was allocated by the program, but is no longer referenced. It is used so that developers do not have to manually perform this memory management, but it instead happens automatically, depending on what and when the developer has specified it to do so.

[quote user="Tu Hoang"]And I also notice that when I print out the neighbor table of a node connected directly to the coordinator, all entry by default will have the destination address is 0x0000 along every others parameters in zb_nwk_routing_t is 0, Is it means that they are not currently using any route from the routing table?[/quote]

I am a bit confused by this. Are you checking both the neighbor and routing table of the node? If you are talking about the neighbor entry of the coordinator, it makes sense that the address is 0x0000, as that will be the address of your coordinator. Which parameters in zb_nwk_routing_t are 0? And by zb_nwk_routing_t, do you mean the routing table entry in Table 3.56 in the documentation?

This was what I was able to figure out after some digging. I hope it clarifies some of your questions, and if not, I will try to ask the developers again. As for your other questions, I am still waiting for an answer to them, but I will let you know when I have anything more to share.

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Thu, 10 Jun 2021 01:21:23 GMT

Hi Marte,

Thank you for your reply, the way i used to send report was by using this

        ZB_ZCL_FINISH_PACKET(buffer, cmd_ptr)                                                           \
        ZB_ZCL_SEND_COMMAND_SHORT(buffer, addr, dst_addr_mode, dst_ep, ep, profile_id, cluster_id, cb); \

It is what i wrote by referencing the write attribute command in zb_zcl_commands.h which is used in CLI example. And I do the reporting at a constant interval of 10s by using a timer.

I do not know if it has anything wrong with this method then so please forward this to them as well. If they need more information on the way i send, please let me know.

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Wed, 09 Jun 2021 14:09:40 GMT

Hi Tu,

Sorry for the delay. I have an update from the Zigbee team regarding the sniffer log you attached. I have copied their response below:

In pcap file, the first procedure when the router 0xf392 started to look for a new route to the coordinator begins around 248th packet and seems to end successfully. I think the router was reset in that point. Then it sends ZCL commands to trigger looking for a new route one more time. A new route is also found this time but at 1008th packet the router 0xf392 seems to forget that it should send packets thru 0x1b67 instead of directly. It looks like a stack issue.
How is reporting triggered? By ZBOSS or manually by the customer?

I got this before I updated them about what you wrote in your last reply, so not all of it might be relevant if the problem is that the router still sees the coordinator. I have updated our Zigbee team with the updated information from you, and I have asked for clarification regarding your questions.

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Tue, 08 Jun 2021 08:15:47 GMT

Hi Marte,

I have something to update and ask for your advice.

So I did some other test and try to get the neighbor table along with the routing table from the node. Then i came up with some really weird outcome. So for the case i sent you the sniffer,when i logged the neighbor table for inside the node, it looks like the router can still listen to the coordinator, but it never get to the link status. The entry corresponding to the coordinator have lqi varied close the zero and the aging changing from 0 and 1 repeatedly. When the node receive route reply, the newly created entry inside the

After doing some investigation, I have a theory like this. Let's say the broadcast range of one node (coordinator) is larger than the other node (router) (because i do not have a large enough area to move the devkit out of range so i reduce the transmitting power by nrf_802154_tx_power_set()), when putting them apart, while the router can not send any messages to coordinator, once in a while, it still can receive a link status from the coordinator. And the link status messages are coincidentally receive so that it the router see the coordinator as its neighbor for just a short period of time. That is why it some time does not start a route request and sometime even it establish a new route the the destination, it never use that route for long because the node never gets out the the transmitting range of the coordinator. It never stops considering the coordinator as a neighbor.

So my question is, if there is already an entry in neighbor table, is it true that the node will do anything but send the message directly to the address of that entry. And is it true if even there is an entry in routing table with the same address, the node will prioritize the entry in neighbor table and delete the entry from routing table?If all of the suspicions are correct, can you tell me some way to get rid of this problem.

Thank you in advance,

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Fri, 04 Jun 2021 10:02:27 GMT

Hi Marte,

Thank you very much for your kindness. I want to update something to you. So I found this answer that help me to see the neighbor table of a device

https://devzone.nordicsemi.com/f/nordic-q-a/70780/nrf52840-zigbee-router-s-neighbour-table-management-lqi-is-not-updating-even-if-the-end-device-is-disconnected.

So I did a similar jobs based on the code snippet for getting the routing table but i notice something very weird about the struct zb_nwk_routing_t, which should have all the field contained in the routing table. It does but there is mismatch with next_hop_addr_ref where in the zigbee spec (here) it is 2 octes but in the zboss_api_internal.h it is only maximum 8 bits. So is it because I have an old version of zigbee spec that the structure of routing table change? Or is it because of they are different parameter? Does this have something to do with some routing table malfunction? Also, a similar problem with status bit, in the document they use 3 bits but in the struct only 2 bits is used.

In addition, i have another question, so if I modified gc_neighbor_table, will it change directly the routing table that the stack used, and what gc stands for. And I also notice that when I print out the neighbor table of a node connected directly to the coordinator, all entry by default will have the destination address is 0x0000 along every others parameters in zb_nwk_routing_t is 0, Is it means that they are not currently using any route from the routing table? If the answer is yes then, when an new route is create, the device can know to use the new route by looking at status bit or used bit to choose the path the transmit data.

Thank you and please inform me if there is something new.

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Thu, 03 Jun 2021 12:42:26 GMT

Hi Tu,

I am still notified about updates on this, so you do not have to worry about that. If the questions are no longer relevant to the original topic in the ticket, we prefer that customers create new tickets, but this is still very relevant, so there is no need to create a new ticket. No inconvenience at all, I am just happy to help.

From what I can see in the sniffer it does not look like either the router or the coordinator believes the other to be a neighbor. I looked through some of the Link Status messages, both from the router and the coordinator, and none of them had the other in the link status list field. This field contains the list of all router neighbors, including the coordinator. The only neighbor the router had in the link list was 0x1b67, so it should not think the coordinator is a neighbor. The link list seems to be correct for 0x1b67 and the coordinator as well.

I am sorry, but I have not been able to see why the connection is broken. I have forwarded your sniffer capture to our developers to see if they can find anything.

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Wed, 02 Jun 2021 15:03:05 GMT

Hi Marte,

Sorry I just click the wrong button.

So to answer your question let me sum up the way route discovery happen in my case. After about 10-12 no ACK packets, the route request started to send. Then a nearby node reply and a new route is formed. But for about 20 secs usually after the link status message, the connection is broken. I have a wild guess that may be when the coordinator send the link status, some how the router receive it So it realise that the coordinator is in the neighbor and try to send packets.

I did retry the experiment but this time with the addition of Many To one Route Request sent at every minute. The problem here is that everytime the Many To One Route Request is sent, it is like the router delete the entry in routing table of 0x0000. So I guess there is something going on with the routing table that cause this behavior.

Thank you in advance,

PS: Can you still be noticed about the update of this ticket. I am very sorry of any inconvinient. Please tell me if i need to create a new thread to continue.

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Wed, 02 Jun 2021 14:34:41 GMT

Hi,

I have started looking at your sniffer capture, but I have not been able to figure out the problem yet, so I will keep looking. Is the problem the additional NWK addr req messages, the APS Acks, and the additional Route Requests before the Link Status message from the router?

[quote user="Tu Hoang"]Or is it because that there is some link status message of the coordinator reaching the router without the sniffer sniffing so the routing table was update.[/quote]

The Coordinator should not receive any Link Status messages from the router if they are not in range of each other without going through other routers. This message is a one-hop broadcast message, so it will only be broadcasted to neighbors with a radius of 1. It will not be forwarded to other devices in the network.

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Wed, 02 Jun 2021 05:37:35 GMT

Hi Marte,

I want to give you some update on this problem. So, this time, follow your instruction, i decided to be more patient with the route discover and yes, after 12 no-ACKs packets, the route discovery did happen. Each packets i wait for 20s to send so it is about 4 minutes. Not bad at all, isn't it.

But this time there is another problem when the router receive route reply there will be some packets sending through that route until the next link status sent. I check for the link status, it is only having 1 link to the node that reply the route request. I guess that the link status somehow reset the routing table or temperary routing table. I am still using the custom user message. So, I capture the result and send it to you.

In my mind i have some suspection that need your help. Is there something wrong with the route request/ route reply in my capture because when i read the command option in replay, all of the bit is false. Or is it because that there is some link status message of the coordinator reaching the router without the sniffer sniffing so the routing table was update.

Thank you and please reply soon, here is the packet sniffer capture you can apply the filter (zbee_nwk.src == 0xf392) || (zbee_nwk.dst == 0xf392) to check the data. Also, the network key is 660413b435c99c87763e8bc10c7abc49. devzone.nordicsemi.com/.../route_5F00_request_5F00_after_5F00_12_5F00_no_5F00_ack_5F00_packet.-.pcapng

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Mon, 31 May 2021 06:25:16 GMT

Hi Tu,

I am glad to help!

For the other devices in the network it will be the same, as turning it off or moving it out of range will make it unreachable. The other devices do not know whether it was turned off or moved away, only that they do not get any ACKs from it.

When you send a new message, the sequence number should increase. The stack will try to resend the packet, so if you look at the network traffic, you will see multiple packets with the same sequence number being sent. But in order to make the device initiate route discovery you will have to send multiple packets with different sequence numbers before it does so.

They used the CLI Agent to control the light bulb from the Light control example. So they sent a match_desc request to discover the bulb, then a simple_desc_req to discover the clusters of the bulb. After this they just sent a normal ZCL On/Off command (from the On/Off cluster) to the bulb multiple times. So it should be the same as when you are sending a custom ZCL packet.

Sending the command at a more frequent interval should make the process faster, as long as you do not send it too fast. Also remember that the stack will by itself try to resend the same packet if it does not get any ACK (without increasing the sequence number, as it is still the same packet being sent).

I have attached some screenshots of the network traffic capture of this behavior below.

The first picture is the first time the CLI Agent sends the On/Off command to the bulb, and you can see that it is being resent multiple times, as it does not receive an ACK. You can see they are the same packet, as they all have the same sequence number, which is 4.

Now we are at sequence number 12, so multiple packets have been sent without receiving ACK. So the CLI Agent realizes that the bulb is out of range, and it sends a route request to try to find the bulb (without success here as well, since the bulb is turned off).

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Mon, 31 May 2021 02:02:16 GMT

Hi Marte,

I am very happy to hear that your team can reproduce the issue i have. But I still have to ask for some more detail just to be sure.

So, when you wrote "when using only a coordinator and some routers, and turning off one of the routers to simulate it moving out of range." Does this mean turning off one router will have the same effects as moving it out of range. If yes, then can you explain why. Secondly, does it means that the sequence number of ZCL packet should be different from message to message in order to trigger route discovery? Then, in your experiment, do they use binding and configure report to send message or just make a custom user ZCL packet like me. Does this 2 methods have the same effect on creating route? And finally, If missing a number of ACKs from message will initiate route discovery, can i just have ZCL command sent at a more frequent interval to make the process faster? and what is your Zigbee team set up for doing the experiment

Anyway, by looking at your answer, i think that the hack that hubitat use have the same mechanism here. They turn off the coordinator to make sure that its routers not receive any ACK to initalize route request. And I think that the reason why i stil can not initialize route request is because routers still receive some ACK from the coordinator. May be this time i will try to have a more precise testing environment.

Thank you very much for your support, I will update if there is some progress in the re-test. You have been a great help to me.

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Fri, 28 May 2021 07:20:28 GMT

Hi Tu,

It is generally recommended not to move the devices around too much in Zigbee. They should be able to notice broken routes and repair them, but it is still best to place them where they are supposed to be from the beginning. However, I do not see why you should turn the coordinator off and restart it after the other devices has joined the network. I have not heard anything about this optimizing the network in our stack at least, and I cannot say I have seen anything about it in the general Zigbee specifications either. And as far as I understand, the mesh network should be formed when a device joins the network and is then added to the coordinator or routers neighbor table, so it is a part of the joining process.

As for your issue with the route discovery, I got an update from the Zigbee team today. They were able to reproduce your issue when using only a coordinator and some routers, and turning off one of the routers to simulate it moving out of range. What they saw was that despite many retries, just one ZCL command that does not reach the destination is not enough to trigger route discovery to search for a new path in the stack. This was observed by looking at the network traffic and the sequence numbers of the packets. However, when they continued sending packets, and the sequence number thus increased, it eventually sent the commands to trigger route discovery. So it seems like after enough packets without ACKs the node will initiate route discovery.

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Thu, 27 May 2021 08:19:33 GMT

Hi Marte,

I have just found a this guide on google about a Zigbee hub, here is the link:

docs.hubitat.com/index.php

In there, I noticed that they said that the mesh is formed automatically but not instantaneously. Then, they recommended to add devices from close to far and suggest not to move the routers after connecting them to the coordinator but rather connect routers to the network at the place they suppose to be. Then, turn off the coordinator for >20min and restart. They say that it will "expedite" the mesh forming of Zigbee and the mesh will be optimized in the next 24 hours.

From my point of view, I do not know what zigbee stack they use for their network layer, but does this also apply to the Zboss version by Nordic Zigbee SDK? Furthermore, It sounds like a hack to me more than a fix to make route discovery start faster. So, can you verify for me if Zigbee really need time to form a mesh? and does doing like what they told is the only way to accelerate the process of forming a zigbee mesh?. If it is the case, why i could not find such important infomation anywhere on Zigbee spec rev22 and can you show me the part where i miss this infomation so that i can have some ground for the slow recovery of the network.

Thank you very much, please help and reply soon.

Have a good day,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Thu, 27 May 2021 07:51:38 GMT

Hi Marte,

Here is the capture file i did for the experiement, I added a router(addr 0x6d9c) to the network of one coordinator and another router (0x2277) then i move the 0x6d9c gradually out of range until it can not receive ACK from the coordinator anymore (i adjust the tx power of the coordinator and the routers to 0dB since the antena is covering a very large areas and getting it out of range is very difficult). To be more colaborated, at packet 368, I started to move the router out of range to receive the ACK from coordinator until packet 474 i move it back.

devzone.nordicsemi.com/.../Mesh_5F00_zigbee_5F00_route_5F00_discovery_5F00_not_5F00_working.pcapng

Please tell me when there is something new,

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Tue, 25 May 2021 07:50:44 GMT

Hi Marte,

Thank you for the reply, so I want to clarify something for you and the team is that with a network where i try to use an end device to send out a message, the end device did managed to find a new parents to join. But when i just use a router to send a message, the router did not do anything. And the mesh that i am trying to make is contribute of a lot of routers so i need some ways to make it work.

So to answer your question

Did the device that was moved out of range have at least one other router in range?

- Yes, I check the link status message of the router, it still have at least 1 nodes in its neighbor table.

What was included in Link Status packets sent from that device?

- I do not remember exactly but the outgoing cost and incoming cost of each device in the neighbor are around 4-7

What was the behavior of that device when trying to send a package to coordinator?

- The device send package to coordinator repeatedly and without ACK and it keeps going like that until the next 3 minutes when i try to reset the device.

Did it just try to send via another router or directly to the coordinator?

-It did try to send to the coordinator apparently since the destination is 0x0000 and the radius is 30.

I think i will redo the experiment again and get a full capture of what happened to send it to you.

Thank you very much, please inform me for any new information.

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Tue, 25 May 2021 06:48:30 GMT

Hi,

I heard back from them today. They tested with the light control examples, sending On/Off commands from the switch to the bulb and the coordinator. After turning off the parent node of the switch (the bulb), such that the switch did not receive ACK from the packets, the switch rejoined the network via the coordinator, after some failed retransmissions of the packet. So they saw the same as you did, that the end device rejoined when they could not reach their parent node.

They also have some questions:

Did the device that was moved out of range have at least one other router in range?
What was included in Link Status packets sent from that device?
What was the behavior of that device when trying to send a package to coordinator?
Did it just try to send via another router or directly to the coordinator?

Best regards,

Marte

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Tue, 25 May 2021 02:15:05 GMT

Hi Marte,

Is there any update on this problem?

I have some other information to update. So when i add an end device to the network, whenever the device wakes up from sleep, it start to send a rejoint request and also route request if its parent is down. Is there any how i can apply this to the router. Like i init the router to do a rejoin request since it already has the key.

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Tu Hoang — Thu, 20 May 2021 02:39:55 GMT

Hi Marte,

Thank you very much for your support. Please let me know whenever you have any additional information on this problem.

Best regards,

RE: [Zigbee-mesh] How to initiate the route discovery manually?

Marte Myrvold — Wed, 19 May 2021 14:17:45 GMT

Hi Tu,

Thank you for clarifying!

The Zigbee team confirmed that the function to initiate route discovery is part of the ZBOSS internals and not exported to the SDK, so it is not available to the application.

From what I understand, the device should discover a new route when the old route is broken, so I do not know why your router does not start route discovery when it cannot reach the coordinator anymore. I do not know if this is expected behavior, a bug, or if there is something you can do in your application to make the router try to fix the broken route. I have asked internally to get a clarification regarding this, so I will come back to you when I know more.

Best regards,

Marte