• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 615 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.

Z-Stack Lighting - End Device sometimes not joining parent

Sjef de Krijger
Expert 1405 points
Other Parts Discussed in Thread: Z-STACK

Hi,

My setup is one ZLL Light (RTR) and a Remote (ED).

Touchlinking and then joining that touchlinked parent is problematic. After a number of tries, the end-device  will touch-link but mostly not join and subsequent commands (e.g. add to group) sent by the remote to the light are not executed.

I currently lack a good packet sniffer so I'm debugging with the remote's UART. Here's what I see most often when it goes wrong, looking at the STATE_CHANGE:

DEV_NWK_ORPHAN -> DEV_NWK_DISC -> DEV_NWK_DISC -> DEV_NWK_DISC -> DEV_NWK_DISC -> DEV_NWK_DISC -> DEV_NWK_DISC

This sequence is seen most often: one time DEV_NWK_ORPHAN, followed by 6 times DEV_NWK_DISC.

Sometimes this is followed by  DEV_NWK_ORPHAN -> DEV_NWK_NWK_DISC -> DEV_END_DEVICE. This is a good outcome, but it takes a long time to get here.

The way to get out of this state is to reset the remote by cycling power. Reset to factory new does not solve it, only sometimes.

When everything is ok, the sequence is just DEV_NWK_DISC -> DEV_END_DEVICE.

It seems the joining of end devices is problematic with Z-Stack. I read more (mostly unanswered) forum posts about this. Is this a known defect? Will it be fixed?

Regards,

Sjef.

  • 0
    TI__Genius 9180 points
    Sjef,
    I apologies if you have found unanswered posts on this subject, I'll search E2E to see if I can help resolve them. We do not have any issues with end devices joining a network reliably, but there are many conditions where this should fail.

    I have some questions to help diagnose this issue:
    Was the End Device previously joined to another network and reset to fn before seeing this issue or was it newly flashed?
    Which version of stack are you running?
    Is this reliably reproducible with certain conditions?

    Also a packet trace with the TI packet sniffer can be imported in to Ubiqua, so a psd file from TI packet sniffer would help us to diagnose the issue.

    Regards,
    TC.
  • 0 in reply to TopCat
    Expert 1405 points

    TC,

    The end-device was reset to FN. Stack version is 2.6.1 (the released Z-Stack Lighting 1.0.2).

    I'm still trying to find a way to reliably reproduce this issue. Yesterday and today it didn't show up. What I have until now is (copy of the comments I added in our remote controller firmware):

     

                     Situation 1: Touch link a lamp

                     1a) The remote is FN and a lamp is touchlinked or,
                         The remote is NFN and the previous parent is turned off and a new lamp is
                         touch-linked.

                     The remote must join the lamp as its parent, before it can send a command
                     (i.e. read basic or add group) to the lamp.
                     This was first solved by calling zllInitiator_OrpanedRejoin in the ProcessTL
                     function - OrphanedRejoin will only attempt to rejoin if the device state
                     was DEV_NWK_DISC and then return ZSuccess or ZFailure otherwise.
                     
                     But this seemed to sporadically cause an infinite loop of state change events
                     to the DEV_NWK_DISC state (every second) which could be broken by either power-
                     cycling the lamp or the remote - so it seems that the lamp also actively causes
                     this loop.

                     In this revision the OrphanedRejoin is still called when the device state is
                     not DEV_END_DEVICE (basically the same as before, as OrphanedRejoin already
                     conditionally calls initiatorReJoinNwk) so the risk for this loop is still there,
                     but the remote has a much better chance of joining the lamp and adding it to
                     its group which is a very important user requirement. Still, the chance is not
                     100% because even when the remote has joined the lamp, it sometimes still can't
                     communicate with it.


                     Situation 2: Touch link another controller (for cloning)

                     2a) The original is NFN and the copy is FN

                     The copy must join a parent before it can communicate with the original for
                     cloning. If this does not work, the following happens:

                     - Nothing - the copy does not touch-link with the original.
                     - The copy changes state to DEV_END_DEVICE but the original does not receive
                       a command that causes ProcessTL to be called.
                     - The copy changes state to DEV_END_DEVICE, original executes ProcessTL and
                       starts a sequence of 'READ BASIC' commands to confirm communication with
                       the copy, but this times out after 10 retries.

     

    I'm particularly worried about the DEV_NWK_DISC infinite loop, but as I said I didn't find a way to reproduce it yet, and it happens only sporadically. The other problems come down to unable to communicate and happen more often. I would like to reliably auto-add a touchlinked lamp to the remote's group each time.

     

    Let you know when I find a way to reproduce this.

    Thanks,

    Sjef.

     

     

     

     

  • 0 in reply to Sjef de Krijger
    TI__Genius 9180 points
    Sjef,
    in case 1, does the remote send out a dataReq before starting touchlink? Is there anyway in you application where this can happen? If the device is in an Ophan Scan the touchline can fail. I have seen application implementations which start the remote polling for some time when it is woken from deep sleep, but for best results you should not start a poll req from the application when the remote touchily button is pressed.

    Regards, TC.
  • 0 in reply to TopCat
    Expert 1405 points

    TC,

    It looks like I need a place to start the polling after waking up from deep sleep at some point other than directly after pressing any key. This should work both for touchlinking a lamp (maybe start polling in the ProcessTL function of the remote) and also for touchlinking another remote - problem here is that for that other remote, I'm not sure where to start the polling.

    Regards,

    Sjef.