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: IAS zone device kicked out by the coordinator after rejoin

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

Hello,

I'm having one weird problem maybe someone faced it in the past and can give me some help.

I have a motion sensor "Nyce NCZ-3043" that I'm trying to use with a custom coordinator (based on the zigbee stack 3.0). But when the motion sensor (end device) asks to rejoin, the coordinator sends a leave message and I can't quite figure out why.

I paired the device doing the following steps:

-> Open the zigbee network and put the motion sensor in paring mode

-> Write the "CIE Address" attribute with my coordinator MAC

-> Wait for an enroll request and send a enroll response

Everything works as expected, but as soon as I remove the batteries and put them on the device tries to rejoin and fails....

So far what I've tried the changes bellow but nothing seems to work

-> zgApsAllowR19Sec = TRUE

-> BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE       FALSE

One thing I notice compared to a a device that works is the motion sensor doesn't send the "Nwk Aux Header" in the rejoin request when other devices do. Can this be the reason for the join to fail?

Since this is a 3rd party device changing the end device firmware isn't an option I was hoping maybe I could make my coordinator accept this device changing some flags in my code.

I attached an ubiqua with the rejoin problem I described here maybe it's easier to see if something is wrong that way.

I'm a bit stuck at this moment and don't know what else to try, if anyone has any suggestions feel free to share :).

IASzoneSniff.zip

  • I see the 3rd party device doing polling and suddenly send orphan notification to do rejoin. I think this is nothing to do with Z-Stack coordinator. You have to check with 3rd party device manufacturer.
  • Hi,

    It looks like the device is sending the rejoin request unsecured, (that is why the Nwk Aux Header is missing, it is not using the NWK Key to encrypt the packet), you should send the rejoin secured. Also setting zgAllowRejoins  to TRUE it will allow rejoins using well known or default keys but it looks like the device does have the correct NWK key since it is encrypting the leave command correctly.

    Regards,
    Dalila

  • Hi Dalila,

    I think you are right about the unsecure rejoin. I tried to set the variable zgAllowRejoins to TRUE and the behavior did change but sadly it still doesn't work. I have this following results:
    -> zgAllowRejoins = FALSE: Sends Leave message without rejoin
    -> zgAllowRejoins = TRUE: Sends leave message with rejoin

    The problem with the last scenario with that the device enters a loop of rejoining and getting told to leave by the coordinator. Is there another way to accept a unsecure rejoin?

    Changing the end device firmware to do a secure rejoin isn't an option since it's from a third party, but I guess that would be the ideal solution for this problem...

    @YK Chen that sudden rejoin was made by me when I took the batteries off and putted them on again. It wasn't a spontaneous behavior on the network itself
  • What do you mean “sudden rejoin was made by me”? It sounds you modify something in Z-Stack to do something unexpected and cause this issue.
  • What I meant to say was that I did a power cycle on the end device. After it turned on again the rejoin sequence was triggered.
    If I haven't removed the batteries the rejoin sequence wouldn't have happened. It was nothing code related and the coordinator works fine with other devices, I'm only having issue with this particular one because the manufacturer implemented an unsecure rejoin.

    Hope I managed to explain myself a bit better now :)