Extend Nuki Bridge API

Nuki APIs Bridge HTTP-API
#1

Hello NUKI team,

I followed the progress made with the Nuki Web API, especially with the Webhooks extension.

Lately, we get more and more requests of users to get more information from there Nuki devices (Smartlocks, Openers, recently for the keypad).

Unfortunately, for a Smart Home the Webhooks API is too insecure and complicated to implement, especially for Open Source developers like we are (LoxBerry NUKI Plugin to provide Loxone Integration).
As open source developers, we cannot provide and continuously operate and secure a cloud server to manage hundreds of users.
On the other way, for decentrally used Webhooks, we do not want users to open their networks that Nuki servers can operate. This would be irresponsible to desire this (most users are not it engineers or network experts).

To come to the point:
Please implement more information to the Bridge API Callback.
Or, if the MQTT protocol is still considered, implement more information to the publishes.
The Bridge currently holds more information as the Callback returns.
For example, the Trigger (system, manual, button,…) and IDs of the trigger (App-ID/Bridge-ID/FobID).
Furthermore, the Webhooks provide callbacks for log entries (e.g. wrong code on the keypad), that is not pushed by the Nuki Bridge.
Also user information when the Smartlock is operated, got requested several times.

It would be very helpful, when the Bridge in the local network also could push that information that the Nuki Cloud Webhooks do.

Smarthomes should not depend on Cloud infrastructure.

Best regards,
Christian

15 Likes
#2

I would just like to add my vote for MQTT support. It seems to be on track to becoming the de-facto standard for F/OSS home automation, and it’s really easy to integrate with other devices and services.

1 Like
#3

Let’s see what Apple presents during their Developer Conference in June, but currently Matter (former known as CHIP) is on a good track to become the most relevant standard in that space within the next few years: Google's commitment to Matter could unite the fragmented smart home industry | Engadget

2 Likes
#4

CHIP/Matter is ok, but it’s another corporate standard dominated by “cloud” players. I hope it will be able to fill a similar niche as CoAP/MQTT/etc.

2 Likes
#5

I just registered an account here to voice my interest in an extension of the API the bridge has to offer. I’m currently using my new nuki hardware in conjunction with home assistant and node-red and I would really love to see more features. I think @christianTF already mentioned the keypoints.

Is there any news regarding either mqtt (which I would prefer) or Matter?

2 Likes
#6

As Matter is still in progress and even not in public draft, you may use the waiting time to add some fields to the callback :wink:.
As data already get prepared for Webhook, this doesn’t sound to be much effort.

1 Like
#7

Some additional fields in the local API (callback) like the trigger (Manual, User) would be very helpful. Especially in the area of alarm secured smart environment. If an “unlock” is done manually, it should not disarm the alarm system, but if an “unlock” is done via a keypad or a user, it would make sense.

1 Like
#8

Hi!
I’m pretty new to this field, and I am a bit stuck. I am not sure my question fits with this topic, so do not hesitate to redirect me if it does not.
I managed to get callback once the door is opened, unlocked, locked.
However, I can’t manage to find how to get a callback when the button (on the smartlock) is pressed. Currently, via Nuki, button pressed fires ‘unlock’ event. But I am using Nuki with home assistant, and I would like to add another event (lights on) when the button is pressed (and not after the door has been unlocked due to the button pressed). How could I do this? Thanks!

1 Like
#9

Just for Reference:

#10

@marius1 I agree with you. I suggested something similar here: Who/What locked/unlocked the smart lock and here: Option to allow/disallow users to unlock the smart lock

Unfortunately, at the moment the reply from the support team is usually to forward us to the MQTT API, which is only supported by 3.0 Pro locks.