Nuki Card with Callback support (supports both Lock & Opener, it replaces the official integration)

The custom component has been updated:

Changes:

  • Define entity categories (Hass 2021.11 feature)
  • Expose FW versions as diagnostic entities
  • Delete Bridge callbacks via the custom service
  • Expose currently set callbacks as attributes of the ‘Bridge Callback Set’ entity

Next milestone for the project will be Web API only mode, to better support devices without the bridge

1 Like

@Dominik.W it looks like you’ve set the Web token but it doesn’t seem valid. Please make sure it is set correctly don’t set it at all

In Nuki Card I first checked how many callbacks were on the bridge and if the webhook was already present in one of them, only then I tried to add it to the bridge, if needed. I thought the component did something like that…and in case there were 3 callbacks already, it threw an error (or delete one of them…can’t remember :sweat_smile:)

The nuki_ng has a special binary sensor for that.

And no, it doesn’t remove other integrations callbacks

But in case there are 3 already present, it doesn’t know…and the bridge gives the error. I was suggesting to preventively check before configuring the callback…

You‘re right! It was the web token.
I left it blank and now the error is gone.
I used the Longlife HA Token and inserted it there.
Was this not right? What do I need that token for?

No it’s the Nuki Web API token. You can control Nuki via web. Konstantin wants to leverage Web API for users without the bridge.

You register the token in your http://web.nuki.io console:
image

you mean Smart Lock 3.0 users, right? Because with SL 2.0 the bridge is required for web API.

The one you can create on https://web.nuki.io/

It’s a Web API for Nuki devices. Right now, if a web API token is provided, you can control access to keypad entries and Nuki users (enable/disabled them from hass). More to come

Mainly yes, for Nuki 3.0. But Web API could be useful also for Nuki 2.0 users:

  1. When your Hass server doesn’t have network access to the Bridge
  2. Generally speaking, using Web API you can do more in comparison to the Bridge API

Correct, but you depend on the cloud. With the bridge you can decide if you want only-local, or both.

The bridge API is missing functionalities for other devices, but for the lock/opener/door sensor, it has what’s needed. They could enrich Bridge API with some more functionalities.

Hello again :slight_smile:
I have just a question regarding detecting when someone rings on mu intercome, can I catch that trigger, in order to show some notifications, and to turn on some flashing lights in my apartment?
So, I need to watch I assume, some binary sensor right?

Yes you can. It is discussed a lot, check the thread, I’d say a couple of months ago…september. Discussion on the opener, automations, etc.

But if you read the latest posts, you would know there’s a custom component now, you better switch to that.

Great!

Thank you both @kvj @alexdelprete

yes, watch for the following binary sensor
_ring_action_state (for Nuki card) or
_ring_action (for custom component)

on = door bell ring

Thanks I figured it out!
Just an another question: just now, my lock was locked my door by itself?
In my logbook, I can see this event as image

Maybe someone trying to call my nuki smart lock with my nuki token? :slight_smile:

That’s not the lock sensor. Switch to the component.

Is it possible to see unlatched state? I can’t seem to find it in any sensor. I’m using the component.

Does it report only unlocked? The component should support all states, and the Bridge API describes unlatched state (id: 5).

Let’s see what @kvj says…

yes correct. Only unlocked and open.