We figured out, that using the Bridge API, the Smartlock moves though the Smartlock is already in the position the lockAction requests.
E.g.
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.
Iām not sure if this is a good idea. I can imagine the lock state locked/unlocked detection is not 100% reliable and it may cause you a serious trouble if Nuki thought it was unlocked even if it was locked refusing unlock your home.
Btw, it happened to me just seldomly I tried to unlock already unlocked Nuki. So I think the battery saving would be insignificant.
Thatās a thing of your trust to the device, and the trust of NUKI to itās own device
For several years I used a Homematic Keymatic that does not move to a position it already holds.
I think the hardware of NUKI Smartlock is accurate enough to know the current state. And I really hope so! Because, on the other hand, I also trust the device that if I send an āunlockā, it really unlocks, and not stays locked or even unlatches!
