使用ZIGBEE PINID的困惑

公司的无线控制项目，ZIGBEE组网速度快，低功耗，所以选择了ZIGBEE，接触ZIGBEE4天时间，把协议栈，各种发送机制都研究了一遍。感到一个非常大的困惑，在网上查阅了大量资料，也不少朋友提出过这些问题，但是这些问题始终没有得到最完美的解释，难道朋友们都没有碰到过相同的问题？或者ZIGBEE协议的联盟没有发现这样的问题？放上来请各路大神提提更好的解决方案。

公司的方案设想如下：（星型网）

1. 所有的协调器烧录一个程序（适合大规模生产），设置一个相同信道，PINID的默认值比如0Xfff0。

2. 所有的节点只烧录一个程序（适合大规模生产）

3. 上位机控制协调器，或者通过WIFI，或者通过有线以太网发命令给协调器.

4．组网成功后，协调器发送广播指令，每个节点回传自己的MAC到协调器，上位机保存这些MAC到并对应设备，比如44 22 33 00 0A 0D 03 08 代表A开关…

4. 协调器对所有节点发送带节点MAC的广播，节点程序收到广播后，根据自己的MAC比对，相同的才做出相应的动作， 并返回结果。

5. 节点对协调器发送点对点通讯，并附有自己的MAC地址。协调器根据节点发送上来的MAC判断是哪个节点发送上来的，做出相应的处理。

6. 一套产品由一个协调器+n个节点组成 ，比如节点是5个，一套设备中共有6个配件。

  （而ZIGBEE网络要保证只有每套产品组网）

7. 协调器可以用上位机控制，而节点无需上位机控制，也不带按钮。

PINID 是协调器发布的入网标志，这个标志编译时候默认的，也可以是随机的（设置成0xFFFF），如果默认的PINID被占用（另外一个协调器）。协调器PINID会自动+1，直到相同的信道内没有相同的PINID既然PIND那么重要，为什么ZIGBEE不利用 本身的全球唯一地址IEEE作为PINID，这样的话，协调器也就有了全球唯一的PINID。所有的节点都会自动加入此协议。而节点是根据默认PINID或者是自动找到通讯质量最好，最近的一个协调器找到并加入。由于PINID是16位的，而IEEE地址为64位的，这是ZIGBEE协议本身制定的。（这个由ZIGBEE联盟去解决了）

模拟场景 邻居A，邻居B同时购买了本公司的产品。

问题一：如果出厂时候协调器设置成0XFFFF，节点也设置成0XFFFF，这样的网络会十分的混乱，可能A节点找到B的协调器，B找到了A的节点。

问题二：如果出厂时候固化PINID，节点+协调器每套产品都设置成不同的PINID。这样的工作量是巨大的，可以保证本公司的产品不会混乱，也不能够保证附近没有第三方相同的PINID产生。而协调器地址自动+1后，所有的节点将找不到原来的协调器而连不上网了！

问题三：有朋友说用NV_RESTORE编译选项，那就必须每套产品都需要先进行一次组网，

而且PINID要不相同，相同的PINID又可能造成混乱，这样跟问题一差不多。

问题四：MAC白名单

看到一位朋友提出的MAC过滤机制，构想不错，在所有的协调器与路由中输入配置节点的MAC，而节点无需配置，自由组网。这样是可以防止恶意的节点接上本网络中，但是如果是恶意的协调器呢?

像本项目中，中心是协调器发送数据，节点才返回数据，如果A邻居家的协调器坏了，或者关掉了，B邻居家用自己的协调器白名单通过了A邻居家的节点，使A邻居家的节点全部加入了B邻居家的协调器，这样就可以任意控制B邻居家的。是否又需要每个节点都加入协调器的白名单。不符合的协调器不加入！

【MAC白名单方案也许是最可行的，但需要完善】

全球唯一标识IEEE这个不错，下面构想的方案核心也许围绕着此。

构想如下：

硬件：网关协调器带SPI的FLASH，保证足够的空间存储节点的MAC白名单

      节点不带FLASH，因为只需要保持一个协调器的地址。

1. 出厂时候协调器（网关）PINID设置成0XFFFF自由组网
2. 节点的PINID设置成0XFFFF自由组网
3. 每个设备的MAC地址都打印成条码或者二维码贴在产品后面
4. 用户买回家后，先打开所有设备
5. 用上位机检测是否所有节点MAC已经加入本网，是否有未知的节点加入本网
6. 协议器保存所有节点的MAC白名单在自身的FLASH中（这里本论坛已有朋友给出了源代码）
7. 协调器去掉未知节点的MAC，统一发送广播自己的MAC给白名单中的所有节点
8. 节点收到协调器的MAC后，保存协调器的MAC。
9. 邻居A的节点加入网络后，发起查询协调器MAC地址的指令，协调器返回自身的MAC地址节点比对保存的MAC，如果查询没有返回（其他第三方的协调器），或者查询有返回（本公司产品）但是MAC地址不符合（邻居B的协调器），节点自动退出该网络，自动寻找下一个网络，，，，

这个构想，操作简单，只需要上位机软件对协调器进行设置，节点的设置由协调发送指令完成

当节点设备发生故障的时候，可以更换，或者添加新的设备MAC，并绑定节点设备。

这里会有几个需要实现的问题

1. 节点怎么保存MAC（数据）地址到自身的NV里面？具体代码如何实现？
2. 节点判断不符合的协调器MAC时候如何退出网络，具体代码如何实现？
3. 节点是否可以根据保存的协调器的MAC地址自动查询，具体如何实现？

这些问题非常困扰，各位大虾高手们，你们在玩ZIGBEE吗？或者有什么公司把这些做的十分的完美成熟？还望指点，谢谢！为什么ZIGBEE联盟把这些本来应该处理好的问题留给所有的有志加入ZIGBEE协议使用的朋友们。

一方面，节点入网后发送验证请求给父设备（验证请求信息自行定义），节点若超过一段时间没收到正确的验证应答则将当前加入的网络保存到NV中（可在NV中建立一个网络黑名单），然后复位成新节点，再次进行网络搜索时跳过该网络，重复上述过程直到加入到正确的网络为止；另一方面，父设备在收到子节点的入网申请后，查找该子节点的MAC地址是否存在于白名单中，若存在则允许入网，若不存在则拒绝子节点入网。

@QING XU1,

如果你们公司的该项目确定使用星型网络的话，那么建议你研究TI MAC协议栈，只有802.15.4的物理层和MAC层，然后就是Application的数据了，没有网络层。这样开发会更简单。

关于你提到的提问，

1） PANID是一个随机产生或者固定的16位变量，确实会存在冲突。但是ZigBee网络里面还有一个是ExtendPANID，这是一个64bit的变量，默认情况下选择Coordinator的MAC地址作为网络的ExtendPANID，所以说网络的唯一标识符是有的。 PANID可以理解是网络号，ExtendPANID是具体到哪个Coordinator建立的网络，所以是唯一的。

2）问题一： 确实这种情况会存在，但是一般情况下网络的Permit Join是关闭的，也就是只有需要添加设备的时候才打开一段时间的Permit Join。另外节点在选择加网的时候，是根据网络的信号强度来选择加网的，一般自己的家里的设备选择自己家的网络。即便设备加错了网络，也可以让设备重新加网。

3）问题二：这种方法确实不可取，一般也不推荐客户使用，一般都是让Coordinator随机产生PANID

4）问题三：不需要这么做.

5) 恶意协调器，如果节点加错了，可以重新加