Add user to bridge HTTP API notifications

Feature requests
21

It’s been a couple of months now. Is there anything to say about the status of this feature request?

This is pretty crucial stuff for integration in smart homes.

4 Likes
22

We are aware of this request, but we do not communicate our timelines, priorities and roadmaps in the public, so there have been no updates.

3 Likes
23

Would like to see the support for the user who changed the lockstate in the Bridge HTTP API too. This way @Phuturist can make his Homey app even better.

24

Hi everyone!

This feature would be very welcome!

I’m developing an integration/driver to use Nuki directly on my hub of choice: Hubitat Elevation (HE).

Since HE approach is local processing (whenever possible, of course), getting a POST directly from the Bridge itself (no web interface involved) about who locked/unlocked the lock would open a bunch of automation possibilities, e.g., start playing a playlist based on who opened the lock, send a notification about who get in/get out of the house, to command a camera to start recording when a delivery person uses the keypad code that I’ve provided specifically to unlock the door for the delivery and so on. As I said before, a bunch of possibilities!

I hope @MatthiasK that this feature gets into Nuki’s feature development queue soon - for a developer point of view it would be awesome!

Best for everyone!

1 Like
25

Here I’m again … hope Nuki releases this feature soon !

26

This feature would indeed be super useful, in particular when also knowing which Keypad user opened the door / or which pin.

Any news on timeline?

1 Like
27

No upates yet on this as we do not communicate our timelines, priorities and roadmaps in the public.

28

@MatthiasK could you at least let us know if this is actually still on the roadmap?

1 Like
29

Is there any chance getting the code used in the JSON or possibly programming the keypad through the bridge API’s? This opens up many possibilities for integrating the Nuki Keypad with various different home automation systems. There is a lack of good keypads in the EU region and this would be great!

1 Like
30

@MatthiasK could you elaborate on what “planned” really means? Are there actually actions being taking to get this feature request done or is it just sitting somewhere at the bottom of a long backlog?

1 Like
31

@Phuturist That was a somewhat awkward formulation on my part as we do not communicate our timelines, priorities and roadmaps in the public. So yes, we (still) see it as a valid feature request. But no, I can’t give you any more details about it.

32

I’m loosing faith in this feature request every getting resolved (and in Nuki in general but that’s a different topic). For now I want to see if I can use this work around. Is there anyone that has some working code available for what’s described above. My own programming skills are limited but with some working code I’m sure I can adopt it for my own situation.

33

The reason why I switched from z-wave DANALOCK locks was hardware quality and reliability, unfortunately there I could easily recognise in Homeassistant if the lock was opened by PIN from keypad or the lock was opened by zwave or manually. This was sufficient for my home automations which I miss so much right now. Please, if you could possibly speed this up, I would be grateful.

34

As I need this notification for my home automation I have switched to Homematic. I will change back in case this notification is working. If you can tell me that this will not included I will sell my device. Sorry, but my priorities seems to look different from the developer…

35

For what it’s worth. I was able to work around this with the suggestion of using the WebAPI. I added this REST sensor to Home Assistant.

  - resource: https://api.nuki.io/smartlock/4xxxx9/log?limit=1
    scan_interval: 3600
    headers:
      Authorization: !secret nuki_web_api_token
      Accept: 'application/json'
    sensor:
      - name: "Nuki Last Log Entry"
        value_template: "{{ states('sensor.date') + ' ' +states('sensor.time') }}"
        json_attributes_path: "$.[0]"
        json_attributes:
          - "name"
          - "action"
          - "trigger"
          - "state"
          - "autoUnlock"
          - "date"

This gets the data about who/waht triggered the lateste action. The scan interval is to make sure it does not trigger often, I update the sensor directly after the Bridge API detects a change in lockstate with this.

- service: homeassistant.update_entity
      target:
        entity_id: sensor.nuki_last_log_entry

That gives you the raw data about who/what triggered the lockstate change and allows for further automation.

3 Likes
36

Thanks. This works for me too. I use FHEM:

defmod NUKI_WEB JsonMod https://api.nuki.io/smartlock/logattr NUKI_WEB DbLogExclude .*attr NUKI_WEB httpHeader Authorization: Bearer [KEY]attr NUKI_WEB readingList complete();;
37

I always get an empty name, is there something special need to have it filled ?

38

Not that I know of. You have named the users and keypad codes in the app I assume?

39

If you have a door sensor as well like me, the name is always empty for the related open/close events. In my case the solution of @Phuturist is therefore not optimal: by retrieving always the last event, some events may be overlooked when several ones are triggered and logged one right after the other, which happens with a door sensor.
Ideally, I think log entries should be retreived using the filter fromDate, then loop in the results and update e.g. a text helper entity, and store the latest date from the results to be used as parameter for the next update.

40

I found that filtering by action=3 & limit = 1 i get the last operation with name filled, except when the door was opened using the nuki button