The problem is, that the current Callbacks are only sent after a lock action is finished and reflect the final state.
This is the answer that the NUKI team replied to many questions about this in the forum.
I opened a feature request because of this, but I’m not sure anymore if the request in it’s current state is a good idea:
I’m not sure if the callback system needs a bigger rework to get this done the right way.
The current system (only one callback type which was thought as representing the current state of the lock instead of sending “events”) might be the reason for many shortcomings of the HTTP API.
If we would have an event driven system for the callback this would make things a lot easier for the NUKI devs.
There could be different event types, and based on the event type it would be possible to use different JSON structures.
This would allow them to add new event types without breaking existing implementations on the customer side.
At the moment we have one structure for all callbacks, regardless what happened. It’s more or less the same you get if you manually poll the status, just sent automatically to you.
I think this is the problem why we still don’t have callback calls for the Opener when someone rings at the door.
And it’s also the reason why we don’t get real events for the lock like “Door was opened” or even better “Door was opened by Person X” Where Person X, can be a Fob ID, “Unknown” or the user in case of a smartphone, like we already see it in the log of the app or as the website lists.
This isn’t easy to implement now, if you have to stay compatible with your current implementation.
By the way, most of this stuff is already implemented through IFTTT, which also leads me to the assumption,
that these features would already be in the HTTP API if it would be easy to add…