TI中文支持网近期将协调器协议栈从2.5.1升级到ZHA1.2.
现在有个突出的问题：协调器发送设备的控制命令时，使用AF_DataRequest（）函数发送时，trans ID是一个值，返回函数AF_DATA_CONFIRM（）中的trans ID是另一个值。这两个ID号不一致，在网关程序中问题很严重~~
在2.5.1协议栈时没有这个问题，两个trans ID都是一个值。
另外，后续调试发现AF_DATA_CONFIRM的trans ID，不是随机值，每次都是跟aps_counter的值相同，感觉就是在trans ID的传递中，不知哪个环节被替换成aps_counter的值了。
希望TI的技术人员能帮忙解决下哈，都调了一个多礼拜了…………
miffy：
建议不要用这种方式跟踪指令失败与否，应该利用指令的default response，ti官方的网关参考也是这样实现的
user5020974：
回复 miffy:
谢谢hold li答复~
这里需要trans ID的目的主要是网关部分的需求，网关部分有可能连续的发送多个指令，它需要使用预定的trans ID来确定哪条指令成功哪条指令失败，default response是受控设备收到指令后的设备发送的数据了，这时候网关下发的trans ID已经丢了
Aries Lord：
回复 user5020974:
请查看文件Z-Stack Core Release Notes.txt，里面Version是多少？另外你发送的数据是否超过了81字节？在2.6.1版本以前（典型就是2.5.1），发送超过81字节的数据帧，fragment的confirm transID会与发送时的不一致。最新的z-stack home 1.2.2a不存在此现象。
user5020974：
回复 Aries Lord:
您好，Version 2.6.3。另外数据都是没超过20字节的，而且这个问题是将协调器升级到ZHA1.2后才出现的，以前使用的2.5.1的时候反而没问题
Aries Lord：
回复 miffy:
综合混用，在confirm的时候去开始default response的等待。但是确实有一种情况，就是发送端没有收到MAC ACK但是收到default response。confirm可以用于连续发送时防止buffer溢出，用于诊断底层出现异常。
Aries Lord：
回复 user5020974:
还是换成 home 1.2.2a吧，1.2.2还有很多其它bug
user5020974：
回复 Aries Lord:
多谢了，现在就开始往1.1.2a升级了-_-
