Enhance the local Http bridge API (callbacks), so we get detailed information about device events instead of just the final state of an lock action

Feature requests
,
1

Product name

For which NUKI product do you want to submint a feature request?

NUKI Bridge API

Summary

Some examples for events that we currently can’t get from the local HTTP API but should be possible for a complete integration in Smart Home systems:

(Many of them are already possible with IFTTT, but not if you want to process these events in a local smart home system in your internal network)

  • Someone opened the door (Unlatch event)
    Including who opened the door: Unknown, specific Fob, specific user
  • Door gets opened / closed ( based on door sensor of the V2)
  • Someone ringed the doorbell (Opener)
  • Front door was opened (Opener)
    Inluding who opened: Unknown, specific user
  • Front door was opened by Ring-to-Open (Opener)
    Inluding who opened: Unknown, specific user
  • . . .

Don’t know if the bridge has the user names available. But any kind of unique ID to identify a user would help.

See this discussion:

Features

Would be really nice if NUKI could add these new callback calls.
Problem might be to stay compatible with the current JSON data structure.

An idea would be to add new keys to the JSON for these events / states and keep the old ones as they are.

  • action: which holds one of these values:
    https://developer.nuki.io/page/nuki-bridge-http-api-190/4#heading--lock-actions
    or undefined if the callback wasn’t triggered through a lockAction.
    The Opener might need an additional entry to the lockActions for the ringing doorbell

  • userid: holds an identifier for the user causing this callback call

  • sensor: which holds the value open or closed for the Nuki 2.0 locks with door sensor, or is undefined when no door sensor is installed.

So the callback calls could work like that for an unlock -> unlatch -> unlock transition:

  1. Unlocking in the app -> the lock action triggers the callback with the old value for state (“unlocked”) and action = “unlatching” and doorState = “closed”
  2. Door opens, the door sensor triggers the callback with the current state (could be still “unlocked” to stay compatible with the current behaviour, but could also be “unlatched” at this moment), action would be undefined and sensor = “open”
  3. The lock releases the latch and the finished lock action triggers the callback call that we already have at the moment: in this case with the values state = “unlocked”, action is undefined and sensor = “open”
  4. The door gets closed, the door sensor trigger the callback again, this time with sensor = “closed”, state = “unlocked” and action is undefined.

That wouldn’t break current implementations, but adds more information to the API.

Reason

Because NUKI is a smartlock. :slight_smile:
So I want to be able to detect it’s actions in my SmartHome, not just a small subset of it. :wink:

Examples

This should enhance every service that tries to build on the information of the bridge API callbacks.
So examples would be the NUKI modules for almost every SmartHome system around.

2

I edited the feature request to be more specific, that it’s about adding event driven callback calls additionally to the state driven ones we have currently.

Hope this makes things clearer.

3

There is already one for the bell ring callback, but yours includes much more features!

4

push