Closed cdjackson closed 8 years ago
You get this timeouts constantly? are you running on the main thread? if not, can you run the commands on the main thread just for testing?
I get the timeouts regularly - not every time, but quite often. Not just timeouts, but other errors as well that I’ve not had the time to look into yet.
What do you mean exactly by running it on the main thread? This error was when running in the console - I’ve not looked too closely at what threads get spawned in the stack...
The console is running on the main thread, commands invoked from the console should be run on the main thread, so it may be a different issue from #32 All those issues are really strange..
This code is originating from zigbee4osgi so take my analysis with a grain of salt.
I think the AF message listener part is working correctly and even if you had two AF message listeners for the ZigBeeEndpointImpl it should not cause this kind of problems as they would still process the response message the same way for the ZigBeeEndpointImpl and pass the message to consumers (WaitForClusterResponse) or listeners (ClusterListener).
One culprit could be that the consume method in WaitForClusterResponse does not seem to match request and response pairs properly. I am not sure if there is mechanism for 100% matching in the AF_DATA_REQUEST and AF_INCOMING_MESSAGE as transaction sequence numbers seem to be used to number the messages in downstream and upstream separately for AF_DATA_REQUEST and AF_DATA_CONFIRM where as AF_INCOMING_MESSAGE always has 0.
Could it be that when switching between applications you are receiving incoming AF messages intended to your application to the console application? Does the problem occur if you run console after plugging in and out the dongle?
Do you see any errors in the serial interface layer? If not then it is questionable whether port speed is causing or affecting this problem.
The AF_DATA_REQUEST and AF_INCOMING_MESSAGE pairing is now fixed by using transaction IDs in ZCL message headers. If time outs still occur please reopen this ticket.
This is an example of the timeouts I'm currently seeing. This isn't the only error, but it's one I captured in the console and will try and investigate -:
I think this is the end of the transaction - the interesting thing (I think) is that it skipped the unregistration of the message listener - why?
Next it does what I assume is a routine network inspection - I don't think this is relevant, but I've left it in to complete the log...
And then I turn the light off...
Here I get a timeout, even though the response is received ok (apparently). I suspect that this is because there are now two message listeners since the first one wasn't unregistered. One of the two listeners is receiving the response (presumably the first one that wasn't unregistered), and the other (presumably the second) times out!