Configurable transactionTimeout in XBee public API

[darrencocco]

Having a request timeout issue with GetChannel on the Xbee module. Using it in OpenHab. Would like a method to configure it.

It would be appreciated if there was a publicly exposed API for setting the com.zsmartsystems.zigbee.dongle.xbee.internal.XbeeFrameHandler#transactionTimeout in ZigBeeDongleXbee so that we can then make that an advanced configurable item in OpenHab.

I have considered just manually setting the com.zsmartsystems.zigbee.dongle.xbee.internal.XbeeFrameHandler#DEFAULT_TRANSACTION_TIMEOUT to something less aggressive (currently 500).

I've confirmed that this is the problem by manually setting the transactionTimeout to 2000 (probably much larger than needed) with the Java remote debugger.

Happy to write the code myself and send it as a pull request. If you're happy with that then some rough guidelines on how it should be look would be appreciated (otherwise I will just poke around the other implementations for inspiration).

[cdjackson]

Do you have any "justification" for why it needs to be this long? If so, maybe the easiest thing is simply to change the default.

I mean is this specified in any XBee docs anywhere, or what reason is there to increase it by a factor of 4? Is it just an issue with slow host performance. Also, what is the downside (if any) of increasing it?

[darrencocco]

2000 was just a random number I picked during the investigation process, I thought it would be high enough that the dongle would definitely have enough time to respond(to eliminate false negatives).

It's unlikely to be a host issue as I've tried it on two hosts (olimex a64 and my development workstation) and have been able to replicate the issue.

I haven't found any XBee docs that speak of the timing for a request/response pair.

This value is used in the sendRequest which itself is just a wrapper around sendRequestAsync method synchronous with it timing out on the transaction timeout period.

I guess the downside is that any requests to sendRequest might take a little longer instead of failing.

[darrencocco]

I did some further testing and managed to shave it down to 1200 without seeing timeouts

[cdjackson]

Ok, thanks for the info and testing. I'm pretty sure this was working in the past as it was delivered to a commercial user a few years ago, so it's a bit strange that it didn't work on either of your systems...

Anyway, I don't currently see any downside in increasing it, so please feel free to provide a PR to increase this to 1200.

[darrencocco]

Cool, I will give it a bit more burn in on my system to make sure everything is stable and then fire off a PR when it's all good.