Add user to bridge HTTP API notifications

(Phuturist) #1

Product name

Nuki bridge

Summary

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.
0 Likes

Callback including user Id
Keypad via Bridge HTTP-Api
Keypad via Bridge HTTP-Api
(Anthony Amar) #2

Hey Phuturist!

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!

Hope this help you and some others! :slight_smile:

2 Likes

Open the door with configurable log entry
(Phuturist) #3

Thanx for the heads up, I have not looked into the Web API yet but it’s good to hear there is a work around available. Is your code public somewhere?

0 Likes

(Anthony Amar) #4

Hi!

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

1 Like

(Phuturist) #5

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!

0 Likes

(Stephan Lendl) #6

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

0 Likes

(Phuturist) #7

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.

0 Likes

(Stephan Lendl) #8

Then we like to leave it open here to see what others might think.

0 Likes

(Gregor) #9

I think it would make sense to have the user on the Bridge API!

Always better to avoid unneeded complexity like having to use another API…

0 Likes

(Stephan Lendl) #10

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.

What do you think?

1 Like

(Phuturist) #11

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.

1 Like

(Gregor) #12

Using the ID would be an acceptable solution.

Sidequestion: Would a different entry code from the keypad also produce unique IDs?

0 Likes

(Stephan Lendl) #13

Keypad codes have their own unique auth ID we could use, yes.

2 Likes

(Gregor) #14

Sounds good! :+1:t2:

0 Likes

(Rafael Uguina) #15

+1 sounds great for me as well

0 Likes