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
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.
@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.