Bridge-API-Callback fires, even if it was added AFTER finishing the lockAction request (nowait=0)
I tried to add a delay of 2 seconds between lockAction response and creation of callback, but I still get the callback, which I don´t wan to get
(Using SmartLock 3.0 Pro)
Steps:
remove callback
perform lockAction (nowait = 0)
wait 2 seconds (for testing purposes)
add callback
Expected behaviour: NO callback is fired, because it was added AFTER finishing lockAction
There might be a dependency to my other issue regarding callbacks…
HINT: When I increase the delay from 2 to 15 seconds, I don´t get the callback fired!
So, it defentitely seems to be dependent from my other issue, that all callbacks are fired with a delay of ~7s
The bridge callbacks fire based on state changes, not based on command execution.
So if you send a command (with no wait) and add a callback afterwards before the state change(s) resulting from the command have been synchronized, the call back will fire.
Bear in mind that the bridge is not a high performance device. Furthermore the bridge API is not built to handle requests in a short sequence. Although your implementation might work, there is a risk that it fails under some conditions (e.g. when the BLE connection to the Smart Lock takes longer than expected). It would be safer if you the callback stays and the receiver of the callback ignores unwanted calls.
Thanks for your reply.
I am sending commands with nowait=0 => wait = 1
As mentioned there might be the rootcause in an internal communication error;
Bridge looses the BLE-connection (BLE-connectionTimeout) after executing the lockaction.
Afterwards it takes several seconds to reestablish the connecton.
That is not a lost connection but a closed connection. After a few seconds of inactivity a connection is closed on purpose. Therefore BLE-connectionTimout is not an error message, it just says that the timeout occurred.
Afterwards the Bridge scans again an sees that the Smart Lock has changed it’s state, connects, reads it and fires the callback. All pretty normal.
But something might still be wrong. I’ll double check and report back when i have news.
Looks like SL2 & SL3 do not fully behave as they should (for ideal performance of the callbacks). We’re further investigating. Have an eye on future SL beta firmware updates which might lead to an increased call back speed.
