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

Hi everyone,

I am making a zigbee mesh with just coordinator and routers only. I intended to have the mesh to cover a very large areas with nodes that can be moved (not frequently). I am using SDK4.1.0, for coordiantor , i uploaded the CLI example inside and for the router  i used the exact same example of lilght bulb with the only change is that i exclude every parts relating to notification led or button.

Tell my if i am wrong but from what i learn, when the nodes send a message to another node, without having the address in the routing table it will initalise the route discovery by (1) sending route request or (2) after some time out when it did not received a MAC ACK from the node it try to send to. My expectation is that i will work like a charm since it is almost the same as the example but it did not. It has a really annoying that even with the router is very far from the coordinator, even with very low LQI and miss a lot of MAC ACKs, it still persistently try to send to the coordinator and not every try to broadcast route requeset. And for the first condition to start a route discovery, when the router send route requests, the coordinator can definitely hear it (i have a sniffer just right by coorfinator side).

So my question is that i want to start the route discovery manually to have better control over the mesh. is there any way i can do that. If not, is there any solution for the route discovery. 

Thank you in advances,

Best regards,

Tu

Parents
  • Hi Tu,

    I do not know of any functions to manually initiate route discovery that are visible to the application in our SDK. A lot of the NWK management and functions are internal parts of the ZBOSS stack, and thus not available to use. I have asked our developers if they know of any way to do this.

    I also have some questions to help me better understand your set up. Was the router originally in range of the coordinator, had it in it's neighbor table, and were able to communicate with it, before you moved it out of range? What kind of messages are the router trying to send to the coordinator? 

    And for the first condition to start a route discovery, when the router send route requests, the coordinator can definitely hear it

     Could you clarify this for me? Is the router sending route request commands to the coordinator, but the command is not received on the coordinator's side? From further up in your description it seemed like the problem is that the router does not try to initiate route discovery, even though the router is out of range and does not receive the packets, but now you are saying the router is sending a route request command and the coordinator is in range to receive this (but does not for some reason)?

    Best regards,

    Marte

  • Hi Marte,

    Here are some more elaborate infomation about my set up

    "Was the router originally in range of the coordinator, had it in it's neighbor table, and were able to communicate with it, before you moved it out of range? "   

    -Yes, they can communicate with the coordinator before they get out of range. For the neigbor table, i investigate the link status message of each and every one of the node, all of them have link to every other nodes. but the incomming cost and outgoing cost  of some links are very bad like 6 or 7.


    "What kind of messages are the router trying to send to the coordinator?"

    -i try to send a report attribute message made with  the function zb_aps_send_user_payload(). I just made up some data (data send, cluster, atrribute, etc) to do it. 


    "Is the router sending route request commands to the coordinator, but the command is not received on the coordinator's side? "  " Could you clarify this for me?"

    - Sorry for confusing you with my bad writing. So as I said i'd learnt that there are 2 cases for the router to start a route discovery, so i try to test them one by one. So, so for the first case, when the link status of the router is not having the link to coordinator(addr 0x0000), it did send route request. that is what i mean by "And for the first condition to start a route discovery, when the router send route requests, the coordinator can definitely hear it"

    But with the second case when i try to move the router out of range so that the message it sent does not have any MAC ACK return and the LQI very low (<20). I wait for about 2 mins and then i reset the device but notthing happen, no route request send.


    So for some more information, i only used the board as pca10059, pca10100, pca10056 with Zigbee SDK 4.1.0 The code for coordinator i used is the zigbee cli and the code for the router and the sdk_config is attach below

    /**
     * Copyright (c) 2018 - 2020, Nordic Semiconductor ASA
     *
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without modification,
     * are permitted provided that the following conditions are met:
     *
     * 1. Redistributions of source code must retain the above copyright notice, this
     *    list of conditions and the following disclaimer.
     *
     * 2. Redistributions in binary form, except as embedded into a Nordic
     *    Semiconductor ASA integrated circuit in a product or a software update for
     *    such product, must reproduce the above copyright notice, this list of
     *    conditions and the following disclaimer in the documentation and/or other
     *    materials provided with the distribution.
     *
     * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
     *    contributors may be used to endorse or promote products derived from this
     *    software without specific prior written permission.
     *
     * 4. This software, with or without modification, must only be used with a
     *    Nordic Semiconductor ASA integrated circuit.
     *
     * 5. Any software provided in binary form under this license must not be reverse
     *    engineered, decompiled, modified and/or disassembled.
     *
     * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
     * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
     * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
     * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
     * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
     * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
     * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
     * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
     * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
     * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     *
     */
    /** @file
     *
     * @defgroup zigbee_examples_light_bulb main.c
     * @{
     * @ingroup zigbee_examples
     * @brief Dimmable light sample (HA profile)
     */
    
    #include "sdk_config.h"
    #include "zboss_api.h"
    #include "zboss_api_addons.h"
    #include "zb_mem_config_med.h"
    #include "zb_ha_dimmable_light.h"
    #include "zb_error_handler.h"
    #include "zb_nrf52_internal.h"
    #include "zigbee_helpers.h"
    #include "nrf_timer.h"
    #include "bsp.h"
    #include "boards.h"
    #include "app_pwm.h"
    #include "app_timer.h"
    
    #include "nrf_log.h"
    #include "nrf_log_ctrl.h"
    #include "nrf_log_default_backends.h"
    
    #include "nrf_802154.h"
    
    
    #undef ZB_NWK_LINK_STATUS_PERIOD
    #define ZB_NWK_LINK_STATUS_PERIOD 0xa
    
    #undef ZB_NWK_ROUTER_AGE_LIMIT 
    #define ZB_NWK_ROUTER_AGE_LIMIT 1
    
    #define MAX_CHILDREN                      10                                    /**< The maximum amount of connected devices. Setting this value to 0 disables association to this device.  */
    #define IEEE_CHANNEL_MASK                 (1l << ZIGBEE_CHANNEL)                /**< Scan only one, predefined channel to find the coordinator. */
    #define HA_DIMMABLE_LIGHT_ENDPOINT        10                                    /**< Device endpoint, used to receive light controlling commands. */
    #define ERASE_PERSISTENT_CONFIG           ZB_FALSE                              /**< Do not erase NVRAM to save the network parameters after device reboot or power-off. */
    #define BULB_PWM_NAME                     PWM1                                  /**< PWM instance used to drive dimmable light bulb. */
    #define BULB_PWM_TIMER                    2                                     /**< Timer number used by PWM. */
    
    /* Basic cluster attributes initial values. */
    #define BULB_INIT_BASIC_APP_VERSION       01                                    /**< Version of the application software (1 byte). */
    #define BULB_INIT_BASIC_STACK_VERSION     10                                    /**< Version of the implementation of the Zigbee stack (1 byte). */
    #define BULB_INIT_BASIC_HW_VERSION        11                                    /**< Version of the hardware of the device (1 byte). */
    #define BULB_INIT_BASIC_MANUF_NAME        "Nordic"                              /**< Manufacturer name (32 bytes). */
    #define BULB_INIT_BASIC_MODEL_ID          "Dimable_Light_v0.1"                  /**< Model number assigned by manufacturer (32-bytes long string). */
    #define BULB_INIT_BASIC_DATE_CODE         "20180416"                            /**< First 8 bytes specify the date of manufacturer of the device in ISO 8601 format (YYYYMMDD). The rest (8 bytes) are manufacturer specific. */
    #define BULB_INIT_BASIC_POWER_SOURCE      ZB_ZCL_BASIC_POWER_SOURCE_DC_SOURCE   /**< Type of power sources available for the device. For possible values see section 3.2.2.2.8 of ZCL specification. */
    #define BULB_INIT_BASIC_LOCATION_DESC     "Office desk"                         /**< Describes the physical location of the device (16 bytes). May be modified during commisioning process. */
    #define BULB_INIT_BASIC_PH_ENV            ZB_ZCL_BASIC_ENV_UNSPECIFIED          /**< Describes the type of physical environment. For possible values see section 3.2.2.2.10 of ZCL specification. */
    
    #ifdef  BOARD_PCA10059                                                          /**< If it is Dongle */
    #define IDENTIFY_MODE_BSP_EVT             BSP_EVENT_KEY_0                       /**< Button event used to enter the Bulb into the Identify mode. */
    #define ZIGBEE_NETWORK_STATE_LED          BSP_BOARD_LED_0                       /**< LED indicating that light switch successfully joind Zigbee network. */
    #else
    #define IDENTIFY_MODE_BSP_EVT             BSP_EVENT_KEY_3                       /**< Button event used to enter the Bulb into the Identify mode. */
    #define ZIGBEE_NETWORK_STATE_LED          BSP_BOARD_LED_2                       /**< LED indicating that light switch successfully joind Zigbee network. */
    #endif
    #define BULB_LED                          BSP_BOARD_LED_3                       /**< LED immitaing dimmable light bulb. */
    
    #if (APP_BULB_USE_WS2812_LED_CHAIN)
    #define LED_CHAIN_DOUT_PIN                NRF_GPIO_PIN_MAP(1,7)                 /**< GPIO pin used as DOUT (to be connected to DIN pin of the first ws2812 led in chain) */
    #endif
    
    /* Declare endpoint for Dimmable Light device with scenes. */
    #define ZB_HA_DECLARE_LIGHT_EP(ep_name, ep_id, cluster_list)                         \
    ZB_ZCL_DECLARE_HA_DIMMABLE_LIGHT_SIMPLE_DESC(ep_name, ep_id,                       \
      ZB_HA_DIMMABLE_LIGHT_IN_CLUSTER_NUM, ZB_HA_DIMMABLE_LIGHT_OUT_CLUSTER_NUM);      \
    ZBOSS_DEVICE_DECLARE_REPORTING_CTX(reporting_info## device_ctx_name,               \
     ZB_HA_DIMMABLE_LIGHT_REPORT_ATTR_COUNT);        \
    ZBOSS_DEVICE_DECLARE_LEVEL_CONTROL_CTX(cvc_alarm_info## device_ctx_name,           \
     ZB_HA_DIMMABLE_LIGHT_CVC_ATTR_COUNT);       \
    ZB_AF_DECLARE_ENDPOINT_DESC(ep_name, ep_id, ZB_AF_HA_PROFILE_ID,                   \
      0,     \
      NULL,                 \
      ZB_ZCL_ARRAY_SIZE(cluster_list, zb_zcl_cluster_desc_t),\
      cluster_list,                                          \
      (zb_af_simple_desc_1_1_t*)&simple_desc_##ep_name,      \
      ZB_HA_DIMMABLE_LIGHT_REPORT_ATTR_COUNT,                \
      reporting_info## device_ctx_name,                      \
      ZB_HA_DIMMABLE_LIGHT_CVC_ATTR_COUNT,                   \
      cvc_alarm_info## device_ctx_name)
    
    #if !defined ZB_ROUTER_ROLE
    #error Define ZB_ROUTER_ROLE to compile light bulb (Router) source code.
    #endif
    
    APP_TIMER_DEF(timer);
    
    /* Main application customizable context. Stores all settings and static values. */
    typedef struct
    {
      zb_zcl_basic_attrs_ext_t         basic_attr;
      zb_zcl_identify_attrs_t          identify_attr;
      zb_zcl_scenes_attrs_t            scenes_attr;
      zb_zcl_groups_attrs_t            groups_attr;
      zb_zcl_on_off_attrs_ext_t        on_off_attr;
      zb_zcl_level_control_attrs_t     level_control_attr;
    } bulb_device_ctx_t;
    
    typedef struct
    {
        zb_uint16_t     attr_id;  /**< Attribute ID specific to cluster */
        zb_uint8_t      attr_type; /**< Attribute type (see @ref zb_zcl_attr_type_t) */
        zb_uint8_t      *data_p;   /**< Attribute data */
        zb_uint16_t     *data_p_16;   /**< Attribute data */
        zb_uint32_t     *data_p_32;   /**< Attribute data */
    } attr_info_t;
    
    typedef struct {
        zb_uint8_t      src_endpoint;  /*!< Source endpoint */
        zb_uint8_t      dst_addr_mode; /*!< Destinition address mode*/
        zb_addr_u       dst_addr;       /*!< Destinition address */
        zb_uint8_t      dst_endpoint;  /*!< Destinition endpoint */
        zb_uint16_t     profile_id;   /*!< Profile ID for reporting */
        zb_uint16_t     cluster_id;   /*!< Cluster ID for reporting */
        attr_info_t     attr_info[10];
    } reporting_info_t;
    
    static bulb_device_ctx_t m_dev_ctx;
    
    ZB_ZCL_DECLARE_IDENTIFY_ATTRIB_LIST(identify_attr_list, &m_dev_ctx.identify_attr.identify_time);
    
    
    ZB_ZCL_DECLARE_GROUPS_ATTRIB_LIST(groups_attr_list, &m_dev_ctx.groups_attr.name_support);
    
    ZB_ZCL_DECLARE_SCENES_ATTRIB_LIST(scenes_attr_list,
      &m_dev_ctx.scenes_attr.scene_count,
      &m_dev_ctx.scenes_attr.current_scene,
      &m_dev_ctx.scenes_attr.current_group,
      &m_dev_ctx.scenes_attr.scene_valid,
      &m_dev_ctx.scenes_attr.name_support);
    
    ZB_ZCL_DECLARE_BASIC_ATTRIB_LIST_EXT(basic_attr_list,
     &m_dev_ctx.basic_attr.zcl_version,
     &m_dev_ctx.basic_attr.app_version,
     &m_dev_ctx.basic_attr.stack_version,
     &m_dev_ctx.basic_attr.hw_version,
     m_dev_ctx.basic_attr.mf_name,
     m_dev_ctx.basic_attr.model_id,
     m_dev_ctx.basic_attr.date_code,
     &m_dev_ctx.basic_attr.power_source,
     m_dev_ctx.basic_attr.location_id,
     &m_dev_ctx.basic_attr.ph_env,
     m_dev_ctx.basic_attr.sw_ver);
    
    /* On/Off cluster attributes additions data */
    ZB_ZCL_DECLARE_ON_OFF_ATTRIB_LIST_EXT(on_off_attr_list,
      &m_dev_ctx.on_off_attr.on_off,
      &m_dev_ctx.on_off_attr.global_scene_ctrl,
      &m_dev_ctx.on_off_attr.on_time,
      &m_dev_ctx.on_off_attr.off_wait_time);
    
    ZB_ZCL_DECLARE_LEVEL_CONTROL_ATTRIB_LIST(level_control_attr_list,
     &m_dev_ctx.level_control_attr.current_level,
     &m_dev_ctx.level_control_attr.remaining_time);
    
    ZB_HA_DECLARE_DIMMABLE_LIGHT_CLUSTER_LIST(dimmable_light_clusters,
      basic_attr_list,
      identify_attr_list,
      groups_attr_list,
      scenes_attr_list,
      on_off_attr_list,
      level_control_attr_list);
    
    ZB_HA_DECLARE_LIGHT_EP(dimmable_light_ep,
     HA_DIMMABLE_LIGHT_ENDPOINT,
     dimmable_light_clusters);
    
    ZB_HA_DECLARE_DIMMABLE_LIGHT_CTX(dimmable_light_ctx,
     dimmable_light_ep);
    
    
    /**@brief Function for initializing the application timer.
     */
    static void timer_init(void)
    {
      uint32_t error_code = app_timer_init();
      APP_ERROR_CHECK(error_code);
    }
    
    /**@brief Function for initializing the nrf log module.
     */
    static void log_init(void)
    {
      ret_code_t err_code = NRF_LOG_INIT(NULL);
      APP_ERROR_CHECK(err_code);
    
      NRF_LOG_DEFAULT_BACKENDS_INIT();
    }
    
    
    void zboss_signal_handler(zb_bufid_t bufid)
    {
        /* Update network status LED */
      zb_zdo_app_signal_hdr_t  * p_sg_p      = NULL;
      zb_zdo_app_signal_type_t   sig         = zb_get_app_signal(bufid, &p_sg_p);
        /* No application-specific behavior is required. Call default signal handler. */
      switch (sig)
      {
        default:
        ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));
        break;
      }
    
      if (bufid)
      {
        zb_buf_free(bufid);
      }
    }
    
    
    void _my_own_handler (void *p_context)
    {
      // static zb_bufid_t last_bufid = 0;
      // if(last_bufid != 0) zb_buf_free(last_bufid);
      zb_bufid_t bufid;
      bufid = zb_buf_get_out_func();
      if(bufid == 0 || bufid == 28) {
        zb_buf_free(bufid);
        return;
      }
      zb_addr_u addr = {
        .addr_short = 0x0000,
      };
      
      NRF_LOG_INFO("bufid %d", bufid);
      zb_uint8_t payload[8] = {0x08, 0, 0x0a, 0x55, 0x00, 0x21, 0x03, 0x00};
      payload[1] = bufid;
      if(ZB_JOINED() == 1)
        zb_aps_send_user_payload(bufid, addr, 0x0104, 0x55, 1, 1, 2, ZB_FALSE, payload, sizeof(payload));
      app_timer_start(timer, APP_TIMER_TICKS(6000), NULL);
    }
    /**@brief Function for application main entry.
     */
    int main(void)
    {
      zb_ret_t       zb_err_code;
      zb_ieee_addr_t ieee_addr;
    
        /* Initialize timer, logging system and GPIOs. */
      timer_init();
      log_init();
    
        /* Initialize Zigbee stack. */
      ZB_INIT("led_bulb");
        /* Set Zigbee stack logging level and traffic dump subsystem. */
      ZB_SET_TRACE_LEVEL(ZIGBEE_TRACE_LEVEL);
      ZB_SET_TRACE_MASK(ZIGBEE_TRACE_MASK);
      ZB_SET_TRAF_DUMP_OFF();
    
        /* Set device address to the value read from FICR registers. */
      zb_osif_get_ieee_eui64(ieee_addr);
      zb_set_long_address(ieee_addr);
    
        /* Set static long IEEE address. */
      zb_set_network_router_role(IEEE_CHANNEL_MASK);
      //zb_set_max_children(MAX_CHILDREN);
        zb_set_max_children(3);
      zigbee_erase_persistent_storage(ZB_FALSE);
      zb_set_keepalive_timeout(ZB_MILLISECONDS_TO_BEACON_INTERVAL(3000));
    
        /* Initialize application context structure. */
      UNUSED_RETURN_VALUE(ZB_MEMSET(&m_dev_ctx, 0, sizeof(m_dev_ctx)));
        /* Register callback for handling ZCL commands. */
        //ZB_ZCL_REGISTER_DEVICE_CB(zcl_device_cb);
    
        /* Register dimmer switch device context (endpoints). */
      ZB_AF_REGISTER_DEVICE_CTX(&dimmable_light_ctx);
        /** Start Zigbee Stack. */
      zb_err_code = zboss_start_no_autostart();
      ZB_ERROR_CHECK(zb_err_code);
      app_timer_create(&timer, APP_TIMER_MODE_SINGLE_SHOT, _my_own_handler);
      app_timer_start(timer, APP_TIMER_TICKS(5000), NULL);
    
    
      while(1)
      {
        zboss_main_loop_iteration();
        UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());
      }
    }
    
    
    /**
     * @}
     */

    8510.sdk_config.h

    Thank you for your support

    Best regards,

    Tu

  • 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,

    Tu

  • 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

  • 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,

    Tu

  • 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.

    Mesh_zigbee_route_discovery_not_working.pcapng

    Please tell me when there is something new,

    Best regards,

    Tu

  • 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,

    Tu

Reply
  • 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,

    Tu

Children
  • 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

  • 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,

    Tu

  • 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

  • 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. route_request_after_12_no_ack_packet. .pcapng

    Best regards,

    Tu

  • 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?

    Tu Hoang said:
    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.

    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

Related