I’d like to see an addition in the bridge http api callback. It would be great if the user who initiated the change in lockstate would be mentioned in the posted JSON as well. This would allow for further integration with other home automation devices.
Features
add user that changed the lockstate to JSON callback of Bridge HTTP API
Reason
being able to do other home automation stuff based on who opened or locked the door
Examples
people that use a home automation controller (like Homey, Vera, Fibaro Home Center etc.) or home automation software (like Domoticz or Home Assistant). Currently apps for most of these already exist but can only do other stuff based on lock state or critical battery level. Also receiving the user that iniated a change would open up a lot more use cases.
I had the same needs and I found a way to have the informations in JSON about who initiated change.
In the API, when you’re initiating a change in lockstate, you receive in JSON a thing like Nuki Web().
You can pass a descriptions beetwen those parenthesis by sending a POST request to https://api.nuki.io/api/key/:id and updating the description params with a string.
You can see it here : https://api.nuki.io/#!/ApiKey/post
I’m making this everytime someone lock/unlock the door. I pass the user ID and other important information and then parse the string to retrieve the ID and identify the user who did the change with this.
It need a bit of development but this a great way to have what you’re describing here!
No it’s private, but I can link you the part you need if you want ? This is in Ruby/RoR if you want.
Btw, this is not something very difficult to do.
You can try on the Swagger API Nuki with the endpoint I’ve provided before.
Just update it each time a user make a particular action.
Don’t hesitate to DM me, I’ll be happy to help
Anthony
Yeah, had a look at the Web API and I’ll figure this out myself. Looks pretty straight forward and I need it to work in nodejs so your code probably wont help me much. Thanx anyway!
@Phuturist Do you still think this feature would be very important to have for the http API? (As this is not easily doable due to restrictions to what data the bridge can access.)
For me it’s still important but I cant speak for other users ofcourse. Having a workaround with the Web API decreases the need to have this implemented in the bridge API but I like to keep things simple and the workaround makes this functionality more complex. I still have to look into how workable this is for me and because the current bridge API implementation for my domotica controller (Homey) was not coded by myself as well that may take some time.
Completely switching all logic from the bridge API to the Web API does not seem possible as well. I now get instant notification on my LAN which are pushed from the bridge when the lock state changes. As far as I can tell there is now way of subscribing for lock state change events on the Web API so I’d still need to use the bridge API or I’d have to poll the Web API which causes delays and I’m not a big fan from polling in general.
But to answer your question.Yes, for me it’s still important to implement this in a simple way. But I can image you have other stuff higher on the backlog. So feel free to close it if the business value does not weigh up to the effort needed to implement this.
We acknowledge that this feature request still has many supporters. So a quick update on our thoughts toward it:
Status:
The Bridge API has no access to last user data at the moment as it has no admin rights (i.e. doesn’t know the admin PIN code - for several reasons).
Idea:
Giving admin rights to the bridge in general has too many downsides from our point of view. So there could be the idea to at least integrate the user ID for last action into lockstate and callbacks. This should enable advanced usage in integrations without knocking over our entire rights management on the bridge.
That’s all I’m asking for. As long as it’s identifiable which unique ID triggered the last action I’m happy. I can translate to actual user in my own domotica system.
We are currently deciding for the smart lock solution for the whole house (several flats). Showing UID in the callback is crucial to disarm alarms, so definitely +1 on this request. Disarming alarm should be done on local level and should work even without internet connection, so web-api workaround is not proper solution.
Imo revealing uid of the last user is not security issue and could be accessible to non-admin users.
I’ve upvoted this but I would like to see more granular information like the pin code used and invalid pin code notifications as this would allow for wider adoption and integration with existing platforms/apps. Linking posts:
