[原创]奥特曼Zigbee读书日记（四）-- 设备“对话”专题(2)

回复 10# outman


    实时关注,一定配合

这两天有些事情在忙，一直没时间去看这个例程的问题。刚刚看了下，里面确实有个小bug，其实并不是串口的收发出了问题，而是在发送RF数据的时候指针的问题导致送出去的数据就是错的，所以显示自然就乱码了。现在已经改好了，附件已经更新过了。
如下是运行结果：（“老张”和“老王”现在只会反复说同一句话，有兴趣的同学可以让他们俩更聪明些 ）

在“project ==> edit configurations”中，分别建立“Coordinator”“Router”及“EndDevice”三种设备的项目设置，注意在"based on configuration"下拉框中要选择之前做过配置的“debug”，然后删除“debug”与“release”。
"based on configuration"在哪里找呀，没找到

我写得不够清楚，是在“project ==> edit configurations”中点“New...”，新建配置

找到了，以后还会有这种白痴问题问您哈

请教奥版，能否这样理解：假设老王是协调器，老张是终端。那么老王的嘴就是协调器上的一个EndPoint(20), 老张的人耳朵是终端上的一个EndPoint(20），下面有几个问题：

1. 嘴和耳朵的EndPoint号一定要相同吗？我理解是不必一定相同，这里之所以相同，是因为可以共用同一个宏定义代码，对吗？
2. ProfID的定义我还是很晕，针对的是嘴？ 是老王？还是老王给老张打招呼这件事？
3. 假设老王这个协调器身上除了嘴这个EndPoint外还有个EndPoint(手，招手），老张除了耳朵外还有眼睛这个EndPoint, 那么现在的需求就是老王的嘴绑定老张的耳朵，老王的手绑定老张的眼睛，那么程序中的ProfID该怎么定义, EndPoint的初始化，还有绑定这些代码该怎样写？因为现在的例程全是一个物理设备上面仅有一个EndPoint, 没有一个物理设备上多个EndPoint的例程。

　　其实我原来用嘴来比喻的意思是，嘴和耳朵构成了一个沟通的渠道，在这个渠道上发送控制信号。还记得小时候玩过的“指鼻眼”的游戏吗？对方叫你指哪，你就得指哪~这就是通过嘴－－空气－－耳，构成的渠道进行控制的例子。

　　不过楼上的比喻也算贴切，那我就按楼上的思路说下我的理解：
　　EndPoint号与ProfID号必须都相同时才能进行通讯。这两个名称都是抽象的概念，既不是指老王，也不是指嘴。拿楼上的比喻来说，抛开“打招呼”这个目的不说，“嘴对耳朵说”和“招手给眼睛看”可以理解成两件事情，分别为两种ProfID，当然嘴如果对眼睛说，那肯定是没用的（武侠片里的“看嘴辨声”我们就不说了~），即ProfID不同的无法通讯。

　　那EndPoint可以这样来理解，嘴可以对左耳朵和右耳朵说，招手可以给左眼睛或者右眼睛看（只是个比方，大家别较真），那么嘴和左右耳朵要用相同的EndPoint号，才能通上话，或者也可以只和其中一个耳朵有相同的EndPoint号，那样的话，另外一个耳朵就听不到他们讲什么了，不过它的任务说不定是听另外一张嘴的话呢~~

　　楼上可以用教程里提供的例程修改一下这两个ID号，做个实验，看看不同的ID能不能进行通讯。

实验中...
schedule无法预测...

仔细的研读了一下绑定请求代码

        destination.addrMode = Addr16Bit;
        destination.addr.shortAddr = NWK_BROADCAST_SHORTADDR;
        if ( ZDO_AnyClusterMatches( 1, &commandId, sapi_epDesc.simpleDesc->AppNumOutClusters,
                                                sapi_epDesc.simpleDesc->pAppOutClusterList ) )
        {
          // Try to match with a device in the allow bind mode
          ret = ZDP_MatchDescReq( &destination, NWK_BROADCAST_SHORTADDR,
              sapi_epDesc.simpleDesc->AppProfId, 1, &commandId, 0, (cId_t *)NULL, 0 );
        }
        else if ( ZDO_AnyClusterMatches( 1, &commandId, sapi_epDesc.simpleDesc->AppNumInClusters,
                                                sapi_epDesc.simpleDesc->pAppInClusterList ) )
        {
          ret = ZDP_MatchDescReq( &destination, NWK_BROADCAST_SHORTADDR,
              sapi_epDesc.simpleDesc->AppProfId, 0, (cId_t *)NULL, 1, &commandId, 0 );
        }

用自然语言来表达就是：首先判断我想绑定的簇ID---也就是commandID对我来说是输出还是输入，如果是输出，则能绑定到的Device的条件是：1. 该Device中的某个EndPoint的ProfId和我的ProfId一致。2. 匹配到的这个EndPoint的输入ID中必须包含有commandID(输出，输入刚好称为一对)
如果是输入，上面第1个条件相同，第2个条件中的输出改为输入即可。

这样看来绑定的关键在于：ProfID相同，并且有相匹配的簇ID。这里并没有去匹配EndPoint号，也就是说即使EndPoint号不同也能绑定。

当然这仅仅是代码分析的结论，实验结果如何后续通知。

实验结果：
               Device A            Device B          BindResult
EndPoint            2                     3                    Ok
ProfID             0x0f10              0x0f11             NG
CmdID            cmdid                Null                  NG

也就是说楼上的分析正确：绑定与EndPoint号无关，只与ProfID和CmdID有关


一个Device注册2个EndPoint的实验进行中...