I’m looking into creating an automation that can trigger specific scenes based on who has unlocked the door.
The use case is: triggering a specific scene when the housekeeper comes in or a different scene for when guests are walking in.
Each guest / housekeeper will have a specific pincode. I can save the IDs of the codes on my database. If I’ve read the docs correctly, I can setup a webhook to notify my system when the door is unlocked.
Question is: how can I determine (quickly) what code has been used? Would latency be a problem? (I don’t want to take several seconds for the scene to trigger; imagine walking in and lights turning on 30-60 seconds later…that’s not a good experience).
The MQTT topic lockActionEvent follows the format lockAction,trigger,authId,codeId
Get the ID of the event: if codeId is 0, use authId, otherwise you can read codeId (authId is used by all events but keypad events where codeId is used instead)
To get the auth details, you have to query https://api.nuki.io/smartlock/{smartLockId}/auth; the API response will contain the authId == id from MQTT event
First of all, please accept my gratitude for at least considering this feature. In fact knowing who opened the lock via keyfob/fingerprint is actually where entire smart home experience starts from, therefore this feature is really super important for profesional installations.
So I was able to get it working, however it needs more work from NUKI team. That is… if I grant access to somebody via NUKI app, then capture him using authID + codeID, it all works great, however… if I delete a few of those users via NUKI app and add some new ones… Guess what… these new users have the same codeID… which eventually/potentially can cause a real disaster in real live gate control situations, for example rental properties, etc… so codeID should never be reused internally by NUKI lock.
I did not test it long enough to spot that limitation. What I do is to periodically query the Web API to get an updated list of users with their IDs. I do match on user label rather than ID because I though it made more sense for me. And I’m glad I did because I might have accidentally avoided this “bug”.