We figured out, that using the Bridge API, the Smartlock moves though the Smartlock is already in the position the lockAction requests.
Smartlock is locked -> lockAction LOCK generates a motor movement.
Smartlock is unlocked -> lockAction UNLOCK generates a motor movement.
A user of our Nuki Bridge implementation asked if he should check the current status (from the callback) before , to decide to sending a request or not. As the Bridge callback can be very late (users talk about delays of up to 20 seconds), I cannot recommend this way, as the delay may lead to unpredictible problems in the home automation logic (e.g. an UNLOCK action hasn’t sent it’s callback yet, and home automation logic filters a LOCK action as it does not know about the ‘unlocked’ state),…
Therefore it would be favorable, when the Smartlock filters actions that are already fulfilled.