-
Notifications
You must be signed in to change notification settings - Fork 68
Handle of ZDO_SIMPLE_DESC_REQ #64
Comments
Hi Brhett. You have two nodes in you network, the coordinator dongle with address 0 and another node with address 40442, correct? Your log starts at 940 stating that there are 2 endopints on the dongle. Is this finding related to the following line at 941? At 943 the discovery of the dongle's endopint 2 is started requesting it's simple descriptor but there are other things moving. For example, you receive ZDO_MGMT_LQI_RSP at 945. This probably matches a previous request not shown in the log. This response shows the existence of your other node with address 40442. However, Also note that while the discovery of the dongle's endpoint 2, the discovery process requests the IEEE address of the other node with address 40442. This requests goes over the air and the response is not showed in the log. Then we get to the problem. The simple descriptor for the dongle's ep 2 is received at 968 and the discovery process continues with ep 1. Also note that the simple descriptor of ep 1 is reported twice at 994 and 995 (but nobody is waiting for it at that point). Is the above picture correct? It looks like all asynchronous responses are duplicated but is this a firmware or an application problem? Can you reproduce this sistematically or did it happen just once? About your proposal to try to match the ep number, I'd go further also matching the destination address and the network address of interest. These parameters are common to every ZDO request. Ciao, |
Hi Cristiano,
Actually, there is only one node, the coordinator dongle. It would be discovered as address 0 and address 40442 since I've set a custom endpoint to the dongle to make it work as a IAS CIE. _So the problem is that why there are two response of simple descriptor request for each endpoint?_ "destination address" and "network address" can not be used for resolving above issue as these two endpoints have the same values. So I have to use the "endpoint" provided by the znp interface to handle this case. Regards, |
Hi Brhett, About the suggestion to match ep, destination network address e address of interest, it does not help in this specific case but in those cases where you could receive a delayed response from a node while you are inspecting another one. It's just defensive code. Can you reproduce the problem systematically? Ciao, |
Hi Cristiano, You are right. The node 40442 is another node, which was associated in the past. It disappear after resetting the dongle (4th parameter is set to "true" for clearing the network state).
Yes. It could be reproduced easily. Add codes below in start() of ZigBeeConsole besides Brhett@bb3428b ZigBeeNetworkManager manager = zigbeeApi.getZigBeeNetworkManager();
manager.addCustomEndpoint("1", "260", "1024", "0", "[0,1,3,1281]", "[3,1280,1282]"); Regards, |
Hi Brhett, This leads us to your other issue #63. Ciao, |
Hi Cristiano,
I don't know. I found the API has been marked as deprecated since the 1st revision of ZigBeeNetworkManager.java (copying from z4o?)
If we don't resolve the duplicated response of ZDO_SIMPLE_DESC_RSP, the "list" command would not list the added custom virtual device (IAS CIE in this case). Regards, |
Hi Brhett,
The relevant part of the log is:
|
Hi Cristiano, Have you add codes in start method of class ZigBeeConsole ? //discoveryModes.remove(DiscoveryMode.LinkQuality);
final ZigBeeApi zigbeeApi = new ZigBeeApi(port, pan, channel, resetNetwork, discoveryModes);
+ // create virtual device "IAS CIE"
+ ZigBeeNetworkManager manager = zigbeeApi.getZigBeeNetworkManager();
+ manager.addCustomEndpoint("1", "260", "1024", "0", "[0,1,3,1281]", "[3,1280,1282]"); And "list" console command expects the device "IAS Control and Indicating Equipment" is displayed if everything is fine. Regards, |
Hi Brhett, From my log you can see that endpoint 1 is already registered (at 09:32:56 670). I will check the createDefaultSendingEndPoint() tomorrow but there is something wrong with createDefaultSendingEndPoint(): three default endpoints are created! Ciao, |
Hi Cristiano, My custom endpoint would be registered as _endpoint 1. Then _ApplicationFrameworkLayer.createDefaultSendingEndPoint() would create endpoints at free endpoints(i.e. starts from 2). So there would be no duplicate endpoint.
It looks like _AF_REGISTER_ only accepts 16 input/output clusters so that the _createDefaultSendingEndPoint()_ has to split the output clusters into 3 different endpoints. Regards, |
Hi Brhett, I've added your code for the IAS CIE but is still works for me (see log below). Maybe some differences in the dongle firmware version? I've added a method to get the dongle firmware version in cdealti@f631128. I got this for mine: 15:19:26 610 INFO Dongle product ID: 0
This is not correct and needs to be fixed.
|
Hi Cristiano, I cannot reproduce it any more if I re-flash the dongle with the pre-built firmware CC2531ZNP-Pro-Secure_LinkKeyJoin.hex. So the duplicate response of _ZDO_SIMPLE_DESC_RSP_ should be caused by my previous self built one. Regarding to the maximum numbers of clusters in per _AF_REGISTER, the "AppInClusterList" and "AppOutClusterList" might take up to 32 bytes according to the ZNP interfaces specification. So I think 16 clusters is the maximum number for each _AF_REGISTER call. Regards, |
Hi Brhett, |
@cdealti Thanks for your help. The root cause is that I've built the firmware with "zgZdoDirectCB" set to TRUE in ZGlobals.c. |
1 ZDO_SIMPLE_DESC_REQ would get 2 ZDO_SIMPLE_DESC_RSP. (I don't see why/where the 2nd ZDO_SIMPLE_DESC_RSP is sent. Any ideas?)
If a node has 2 endpoints, the result would be unexpected.
See example below. The coordinator has 2 endpoints. Inspecting endpoint 1 would take the 2nd result of inspection of endpoint 2 as its result, which is incorrect.
It could be resolved by updating the WaitForCommand by adding an extra parameter "endpoint". If the asynchronous response is ZDO_SIMPLE_DESC_RSP, checking the value of "Endpoint" field of the response to determine whether the response is dedicated to current waiter.
Any suggestion?
The text was updated successfully, but these errors were encountered: