• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 58 subscribers
  • Views 4383 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2530: [Z-Stack 3.0] End device auto search a new parent when its existing one getting lost

Barry Mok [HKU]
Intellectual 630 points

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Dear all TI developers,

I was using Z-Stack Mesh 1.0 to do the following task:

 

Suppose I have 2 router (router A & B) and 1 end device. Originally, the parent of the end device is router A. Then, I switch off router A, the end device will automatically look for a new parent and hence router B will then be the parent of the end device.

 

NOW, I am using ZigBee 3.0, SampleLight for the two router and SampleSwitch for the end device. Seems like the example cannot achieve the above-mentioned mechanism.

 

Does anyone know how can I let the end device automatically search for new parent when its existing parent is lost (in Z-Stack 3.0)?

 

Thank you very much.

 

BR,

Barry

  • 0
    Guru 735695 points
    It shall work like Z-Stack mesh 1.0.0. I suggest you to use Ubiqua Packet Analyzer to check it.
  • 0
    TI__Expert 8950 points
    Hi Barry,

    The behavior for this case is not currently defined by the ZigBee 3.0 specification, so it is up to the developer to handle this in the application. In Z-Stack 3.0, we have provided the BDB commissioning status BDB_COMMISSIONING_PARENT_LOST, which will be sent to the application in the case of an end device losing its parent. You can see an example of how to handle this in the sample applications like SampleLight, just search for BDB_COMMISSIONING_PARENT_LOST in zcl_samplelight.c
  • 0 in reply to JasonB
    Guru 735695 points
    ＠Jason doesn't Z-Stack 3.0 device turn to orphan and start sending beacon requests to rejoin another parent when it loses connection with original parent node?
  • 0 in reply to YiKai Chen
    TI__Expert 8950 points
    In Z-Stack Home Automation 1.2.2a, end devices that lost their parent would automatically start the rejoin/backoff cycle which I'm sure you're familiar with, which was handled inside ZDApp.c. This logic was defined by the ZigBee Home Automation profile, hence its inclusion in 1.2.2a.

    With the ZigBee 3.0 specification, that particular logic as well as any definition for what happens with a parent-loss case was removed, so until the ZigBee Alliance defines another method of handling this case we decided to move parent-loss handling to the application. As mentioned before, the provided sample applications demonstrate a simple method of handling parent loss, under the handling for BDB_COMMISSIONING_PARENT_LOST. This eventually ends up calling the API bdb_ZedAttemptRecoverNwk();

    I believe that what currently happens when an end device loses its parent is an orphan notification is sent out, the end device will send a single beacon request, and then the application should receive the BDB_COMMISSIONING_PARENT_LOST message. If the application does not handle this message, the device will stall.

    Another thing I should mention is that coordinator realignment has been deprecated/removed as well, so rejoining devices will always do a regular rejoin instead.
  • 0 in reply to JasonB
    Intellectual 630 points

    DearJason,

    Thank you so much on your explanation.

    BTW, would you please beliefly explain what is coordinator realignment? Any specific documents talk about this?

    Thanks ,

    Barry

  • 0 in reply to JasonB
    Guru 735695 points
    Thanks Jason for detail explanations.
  • 0 in reply to JasonB
    Intellectual 300 points
    I also like to know what does "coordinator realignment has been deprecated/removed" impact would be. For example if a power loss occur, what happen to the network? Will the network break?
  • 0 in reply to Mohd Khairun Nasir Saadi
    Guru 735695 points
    You can read home.iitj.ac.in/.../zigbee.pdf to know more about coordinator realignment.
  • 0 in reply to Mohd Khairun Nasir Saadi
    TI__Expert 8950 points
    One potential way an orphaned device could rejoin a network is if the network's coordinator responded to the orphaned device's Orphan Notification with a Coordinator Realignment, which allowed the end device to "rejoin" the network without going through the standard rejoin procedure.

    So over-the-air you would see Orphan Notification from ZED -> Coordinator Realignment from ZC -> (ZED "rejoined"). So the change I mentioned is Z-Stack 3.0 coordinators will no longer send out Coordinator Realignment to Orphan Notifications. Orphaned devices will need to complete their own rejoin procedure, using the method mentioned above.
  • 0 in reply to JasonB
    Intellectual 630 points
    Dear Jason,

    You are correct. if I search the keyword "SAMPLEAPP_END_DEVICE_REJOIN_EVT" inside the example of Z-Stack 3.0 (e.g. zcl_samplesw.c) there is some codes implement in application framework:

    #if ZG_BUILD_ENDDEVICE_TYPE
    if ( events & SAMPLEAPP_END_DEVICE_REJOIN_EVT )
    {
    bdb_ZedAttemptRecoverNwk();
    return ( events ^ SAMPLEAPP_END_DEVICE_REJOIN_EVT );
    }
    #endif

    The end device can search now parent. I have verify it. Thanks.

    BR,
    Barry
  • 0 in reply to JasonB
    Guru 735695 points
    @Jason, if I trigger bdb_ZedAttemptRecoverNwk(), does it follow scan/backoff mechanism in Z-Stack Home 1.2.2a? If not, how can I do similar thing for power saving when device attempts to recovery network?
  • 0 in reply to YiKai Chen
    Prodigy 25 points
    hi, can you contact me email pls,
  • 0 in reply to sdfsdf dfsd
    Guru 735695 points

    If you have any issue or question, you can post on E2E forum and I will try to help.