Many thanks for all the hard work Maarten.
Some more observations on the version 2 protocols:
Firstly, there's an error response similar in format to the ACK:
Code: Select all
0000rrrr00E1cccc
rrrr = response handle as returned by ACK
cccc = CRC16 checksum
This indicates that the circle in question is not contactable (out of range, unplugged, etc)
Secondly, there seems to be a limit in the number of commands the MC can keep track of at a time when it's congested.
I'm working on a multi-threaded app which as it stands makes a number of simultaneous requests for power data (not by design as such). Sending the command and waiting for the ACK are synchronous, and the actual response is dealt with asyncrhonously when it arrives (based on response handle) leaving the app free to send other commands in the meantime, i.e. as soon as the ACK for the first command is received, the second command can then be sent.
This works well up to about 3 or 4 commands being queued simultaneously, but at that point responses seem to sometimes get dropped randomly. My current development setup is Circle+ and 5 Circles so 6 commands get queued simultaneously. All get sent and ACKed but I almost invariably have to retry 1 or often 2 of these as no response arrives. They almost always work on the first retry. From looking at the Domotiga source, I'm guessing the commands are completely synchronous, so issues shouldn't arise
I'm not sure what the cause is, perhaps it's due to the MC being swamped, or maybe wireless interference. I'm going to continue working on it as I need to make it a bit more robust, but if anybody has any insights, I'd be happy to hear them!
Regards,
John