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

Nuki APIs Bridge HTTP-API
, ,
#1

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
#2

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.

#3

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!