Timeout issue about zigbee4java HOT 5 CLOSED

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?

from zigbee4java.

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...

from zigbee4java.

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..

from zigbee4java.

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.

from zigbee4java.

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.

from zigbee4java.