Battery saving: Don't start motor on actions that are already fulfilled

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.

Best regards,
Christian

1 Like

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 :wink:

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!