Distinguish lock states in general and specifically for callback

Nuki APIs Bridge HTTP-API
1

Hi, when my Nuki is locked and then unlocked (door stays closed), my callback function is triggered with status Unlocked. Later, when someone opens and closes the door, I receive another callback trigger with the same status. I cannot distinguish this from the real “unlock” action. When the door is unlocked and I open it and then wait a little, I get again exactly the same trigger and status. If I then close the door again (after the wait), my callback function is called again. So I am not able to determine whether the door is really unlocked, opened + closed in a short time interval, or whether the door was opened and kept open, or it was closed after being open for a while.

What is the best way to find out? Or does this require a change to the API of Nuki lock or Bridge? PS. I have the version 2 lock a bridge and latest firmware. Thank you, Martijn

2

I’m seeing the exact same behavior here. It seems to me that the open/close sensor (the extra magnet you glue next to the lock) state change isn’t reflected in the state + stateName field of the callback. But I recieve a callback every time I open/close the door.

Probably a workaround but I haven’t tested it my self. When you get a callback, send a request to the /list endpoint or /lockState. Beware that the documentation states, that one should prefer /list over /lockState, because the latter drains the battery of the lock, where /list gets you the cached state from the bridge.

3

Which bridge FW version does your bridge currently have?

We just introduced this with the latest beta, see

So if you already get callbacks for door state changes you should also have the states in the payload for the callback.

4

Which bridge FW version does your bridge currently have?

I’m on 2.5.2. And I already get the callback calls. They payload for open/close is always:

{
  "deviceType": 0, 
   "nukiId": 3xxxxxxx5, 
  "mode": 2, 
  "state": 3, 
  "stateName": "unlocked", 
  "batteryCritical": false
}

@MatthiasK It would be great if the internal IP-adress and espacially the port (I’m only receiving my external IP-adress) of the bridge will also be part of the payload. So one could handle reply-requests back to the bridge without hardcoding these details on the receiving and of the callback.

5

This is still the current public Bridge FW and not the new beta, so the payload does not contain the door state (and the callbacks should only be triggered by lock state changes)

6

the callbacks should only be triggered by lock state changes

This is definitely not the case. I get these callbacks for my unlocked door everytime I open/close the door. But it also doesn’t bother me much :slight_smile: