• State Answer Suggested
  • Locked Locked
  • Replies 26 replies
  • Answers 2 answers
  • Subscribers 55 subscribers
  • Views 1927 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: What is the maximum number of devices can be added into Black/whitelist ?

Arun Krish
Expert 1810 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Hi,

      I have implemented the Whitelist in ZC with three number of devices. I want to add more number of devices. So I need to what is the maximum number of device address can be added into the NV-RAM. Because I am using IEEE addresses in whitelist, it should not create any problem in my application.

  • 0
    Guru 735475 points
    One NV ID can store 256 bytes so it can store 32 IEEE addresses. If you use 4 NV ID, it can easily store 128 IEEE addresses.
  • 0 in reply to YiKai Chen
    Expert 1810 points

    Ok Thank you..

    I will be using OTA client, so writing more data in NV RAM should not affect my application. Consider I am going to add 250 device  addresses into the NV RAM. It will create any problem in my application?

  • 0 in reply to Arun Krish
    Guru 735475 points
    I don't think it will have any impact to your application.
  • 0 in reply to YiKai Chen
    Expert 1810 points

    With One nv id I can store 32 IEEE address ( 256 bytes) . If I want to store 500 IEEE address into the NV RAM, I should have 16 nv id's. 

    Lets consider, I have added 500 addresses into nv_ram. Now I will be checking that. 

    What about the time to accept the association request of ZR?  And ZC will stable for all time?

  • 0 in reply to Arun Krish
    Guru 735475 points
    I couldn't understand your question. Can you elaborate?
  • 0 in reply to YiKai Chen
    Expert 1810 points

    If I am storing 500 addresses in whitelist, Howlong it will take to accept the Associate request of the Router. Is ZC will be stable ?

  • 0 in reply to Arun Krish
    Guru 735475 points
    I don't have information for this. You have to test this by yourself.
  • 0 in reply to YiKai Chen
    Expert 1810 points
    Can I get any information from TI employees regarding this?
  • 0 in reply to Arun Krish
    Expert 1620 points
    Hi Arun,

    Its unlikely that you will be able to hold 500 devices associated to the coordinator (as you mention that ZR are associating to ZC). At some point those joining devices will do so through other router devices.

    Maybe if you explain what are you trying to do and the use case, we can come up with something more reliable that do not depend on white-listing hundreds of devices. May be you can set a MAC address prefix and filter by that instead of having such list (combined with opening the network during very specific time windows)
    Another useful information would be what stack version are you using?
  • 0 in reply to Luis Luna
    Expert 1810 points

    Hi Luis,

        Consider the  following scenario, I have thousands of Routers and 20 coordinators (Home automation   ZR-Switches, ZC- controls the switches from cloud). In which, hundred Router should  connect with Coordinator-1, same thing for other coordinators. 

    If my switches are installed in near by homes, ZR may connect with the neighbour's home network. In that case any neighbour can access my switches. So I want to make an list of devices, which should be connected with particular ZC. 

    And my stack is zstackhome-1.2.2a...

    Any Idea for this use case....

  • 0 in reply to Arun Krish
    Guru 735475 points
    If this is your user case, why don't you disable permit join on other Zigbee network and only enable permit join on specific network that you are working. This is how we usually work with several Zigbee networks work in the neighborhood.
  • 0 in reply to YiKai Chen
    Expert 1810 points
    How it is possible when neighbour also using same switch like mine?
  • 0 in reply to Arun Krish
    Guru 735475 points
    Then, why do you say "If my switches are installed in near by homes, ZR may connect with the neighbour's home network. In that case any neighbour can access my switches. "
  • 0 in reply to YiKai Chen
    Expert 1810 points
    It means, I will manufacture more number of switches and it will be distributed to neighbouring homes. Consider my use case is for wider applications. So it may be installed any home, if neighbouring homes bought the same means what will happen in that time?
  • 0 in reply to Arun Krish
    Guru 735475 points
    If you always keep Zigbee network disable permit join, Insee no reason why the switch of one home would join another home.
  • 0 in reply to Arun Krish
    Expert 1620 points
    Hi Arun,

    This kind of issues has been addressed by Zigbee manufacturers by their selves in the way YiKai is describing, which is having the network open so, the devices can join only when the customer wants it, after that you close the network so other devices do not join your network. That forbids having unwanted devices in your network. But I think that your concern is what happens if someone else do not close their network and your devices do attempt to join their network instead of yours, right?
    Z3.0 (the latest stack), does have the install code feature which works as follows:
    ZR device is instructed to use the install code, this install code generates a key which is used to join the network.
    ZC is instructed to use the install code from ZR and it also gets the MAC address of ZR, so ZC uses the install code when ZR attempts to join.

    ZR cannot get into a network if the Coordinator of that network does not use the IC, so it will not join neighbors network but customer's network.

    If this address your issue, please download the Z3.0 stack and play with IC. Sample applications already provide a nice interface to play with and you can see if these address your issue.

    Hope this helps!
  • 0 in reply to Luis Luna
    Guru 735475 points
    In Z-Stack 3.0, the maximum permit join duration is 254 seconds which is to avoid user doesn't disable permit join by accident.
  • 0 in reply to YiKai Chen
    Expert 1810 points
    Thanks Luis and Yikai,
    For Time being I can't go for zstack3.0. Most of the development is done with zstack home automation 1.2.2a, so now it's not possible for me to work on new stack...

    Hi Luis,
    If power reset is happened in all nearby homes means all the routers will try to search for the network, that time it has possibility of joining into neighbour's network. How to handle this problem. If I am going for new stack also it neighbour's ZR may connect with other network within the permitjoin time if power reset is happened in all neihbouring homes....

    Hi Yikai and Luis,
    Instead of creating whitelist in ZC, I can create whitelist in ZR with Coordinator's IEEE address. In this case each ZR will have only one address and it should connect with the particular ZC only. Whata about your suggestion?
    If this is fine means can you please suggest me that, where to create whitelist in ZR code....
  • 0 in reply to Arun Krish
    Guru 735475 points
    Do you enable NV_RESTORE in your project? If you enable it, the device would keep the network information in NV and use it after power recycle. So, It shouldn't join other network even after power recycle.
  • 0 in reply to YiKai Chen
    Expert 1810 points
    Hi Yikai,
    NV-RESTORE is enabled. But my requirement includes black/ white list. So I am trying with whitelist in ZC side and I achieved that. Now I am trying the same thing in ZR side with only one coordinator's address, so that ZR will join with particular ZC only. I need the solution for that..
  • 0 in reply to Arun Krish
    Expert 1620 points

    Hi Arun,

    Seems like we are missing something critical in your use case as I agree with Yikai that enabling Nv-Restore would solve the issue of ZR do not joining other networks.

    When you enable Nv-Restore, ZR will retrieve the nwk information including ZC address and ExtPanID, which is the same thing as the ZR performs joining, but without having to actually join the network, in this sense, you save time and OTA traffic that joining all the devices into the network would cause and you can be sure that the devices will remain with the right coordinator.

    If your use case mandates for some reason for ZR to perform joining, please explain why and may be we can provide more help or suggest a better way to achieve your use case.

    Going ahead in your request:

    You can use OsalNv API to store the IEEE address of the ZC, refer to the documentation or OSAL_NV.h, it is quite simple. The IEEE address of the coordinator you can get it from the address manager 

    AddrMgrEntry_t  nwkEntry;
nwkEntry.user    = ADDRMGR_USER_DEFAULT;
nwkEntry.nwkAddr = 0x0000; //coordinator address

if(AddrMgrEntryLookupNwk( &nwkEntry ) == TRUE)
{
  (void)nwkEntry.extAddr;  //Coordinators IEEE Address
}

    You can filter the network you join by changing ZDApp_NwkDescListProcessing to match with the previously saved Coordinators IEEE

      // If the extended Pan ID is commissioned to a non zero value
  // Only join the Pan that has match EPID
  if ( osal_ExtAddrEqual( ZDO_UseExtendedPANID, pNwkDesc->extendedPANID) == false )
    continue;

    As a general rule ZC uses its own IEEE as ExtPANID, Z-Stack does by default, but if you find that the coordinators that your customers will use that may have a different ExtPANID, then you will have to rely on ExtPANID information as the IEEE address of the coordinator will not appears in the beacon frames during the network discovery.

    Hope this helps!

  • 0 in reply to Luis Luna
    Expert 1810 points
    Hi Luis,
    Based on the requirement for the switches(ZR) and coordinator(ZC), I should implement the black /white list to form a network at all times.

    It may be done in three ways...
    1. Creating whitelist in coordinator to allow the particular devices only.
    2. Creating whitelist in router to join with particular coordinator.
    3. Creating blacklist in router, that should not connect with the particular ZC.

    This is what I have done so far...
    1. For 1st way, I have implemented whitelist in zmac_AssociateRsp() function.
    In this function I have created a list, which should be allowed to join with ZC.
    But if I want to add the addreses through UART instead of hardcoding it, how to do it?. Because, with OSAL_NV_WRITE API I can write only two addreses, but I want to add more number of address.

    2. For this I have checked with your reply I can't achieve this . can you please check and leave the reply..

    3. Black list in router should not not be done with PAN ID, ift is also done by IEEE address.
    If router joined in some other network means it (ZC) will send leave request to the router. After receiving the request from the router it should add the particular address into blacklist. So ZR should check the list every time before connecting into the network.

    Thank you...
  • 0 in reply to Arun Krish
    Expert 1620 points
    Hi Arun,

    If you have to implement only one of those, the easiest one is '2' and would avoid such cases of devices joining unintended networks.

    2.- You can write ZC IEEE address in Nv with the existing Nv serial interface in one of the Application Nv Items (0x0401 or above), read it and use it in the code I did provide in ZDApp_NwkDescListProcessing() instead of ZDO_UseExtendedPANID.

    If for some reason you still need 1 and 3, here are the comments:

    For '1', you must be aware that any router may allow other devices to join, avoiding association is not practical, so you either kick the devices out of the network after association is completed or do not transmit the nwk key, which left the joining device either leaving the network or not being able to participate in the network.

    For '3' you will have to create your own black list manager that parses and writes application Nv Items and read those in the ZDApp_NwkDescListProcessing() to avoid networks that the device got kicked from.

    As Z-Stack 1.2.2a does not supports white/black listing you will have to create your own MT commands to introduce IEEE address along with the list manager for approaches '1' and '3'.

    Hope this helps!
  • 0 in reply to Luis Luna
    Expert 1810 points

    Ok Thank you...

    Now I am trying to write data to NV RAM using SYS_OSAL_NV_WRITE API in z-tool, But with that I am able to write only 128 bits of data. If I want to write more data into same nv_id, how to do it?

    Consider I am going to write 10 IEEE addresses in same NV_ID....

    Right now in nv_id 0x0401, I am able to write upto 128bits.(0xAA, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00, 0x97, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00) from z-tool using API.

    But I want to write more addresses in same NV_ID, as below..

    0xAA, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00, 0x97, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00,0x2A, 0x3F, 0xA4, 0x0A, 0x00, 0x4B, 0x12, 0x00,0xAA, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00, 0x97, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00,0x2A, 0x3F, 0xA4, 0x0A, 0x00, 0x4B, 0x12, 0x00

    or else like

    0xAA, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00

    0x97, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00

    0x2A, 0x3F, 0xA4, 0x0A, 0x00, 0x4B, 0x12, 0x00

    0xAA, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00

    0x97, 0xA4, 0xE9, 0x09, 0x00, 0x4B, 0x12, 0x00

    0x2A, 0x3F, 0xA4, 0x0A, 0x00, 0x4B, 0x12, 0x00

  • 0 in reply to Arun Krish
    Expert 1810 points

    Hi Yikai Chen,

               Please reply for my previous post.

  • 0 in reply to Arun Krish
    Guru 735475 points

    I have tried to help you in your another similar post.