Your obersvations are all connected to each other:
-
When you send a lock command to the Smart Lock, the Smart Lock first “Accepts” it (= it says that it will perform it). At this point the client (e.g. App, Bridge, Keypad) could disconnect and the Smart Lock will still perform the action. If the client stays connected it receives state updates until the lock action results in a final “Complete” messages (or error). At this point every client should disconnect.
-
Together with the complete state a log entry is written in the Smart Locks activity log and the bridge is notified that there is a change in the lock state. Which triggers the bridge to fetch the current state and forward it via callback.
Point (2) is why you typically don’t get transition states as call back, because the transition already happened before the log entry is written and the bridge is notified. If you want to free up the http connection you can use the “nowait” command. This will reduce the likeliness of a concurrency problem, because the duration of the lock action is much shorter (only 1-2sec instead of e.g. >20s if you trigger lock’n’go) but this has no impact on the callback. This will still only be triggered after the “complete” is written and after the bridge did fetch the state from the lock.