Rate-Limit

Nuki APIs Web API
1

Hello,

For a connection to a security system, I need timely information whether a user has gained access via keypad. I don’t get any reliable information about this via the local callbacks, because it is not possible to distinguish whether the user has gained access normally or via the keypad (I have already read the reasons for this in other threads, I hope that this will change soon).

Now I query in parallel every 5 seconds the logs of the Web-API to look there for entries, because the Web-API does not offer a callback. (Except the extended API, for which I have already applied).

There would be theoretically also the access by keypad recognizable. But in some cases it takes up to 10 minutes until the log is up to date. Therefore, this is not yet the all-encompassing solution.

Therefore, I now also trigger a sync of the smartlock every 5 seconds. This gives me a delay after the input that is at least only in the minute range. Unfortunately, it is not quite recognizable from when a sync makes sense. To reduce spam on the API I tried before to trigger a sync when receiving a local callback as well, but that didn’t solve the problem, even with 5 seconds pause before the sync. In the web log some entries were still not visible. So something seems to happen in the background before a sync makes sense.

So now to my real question: How many API requests am I allowed to make per minute? Currently there are 2 requests every 5 seconds by querying the logs + sync, so 24 requests per minute.

2

Another problem has now been noticed. If you use Sync too often: If the Nuki is performing an action and a sync occurs in exactly this second, you can’t perform any syncs for about 2 minutes because they hang up.

Overall, there seems to me to be no reliable method to send a notification to a dedicated system that informs about door openings.

Even if the bridge would send all the required information, which unfortunately it doesn’t, because it doesn’t have permissions to display who or what opened the door. This morning the Smartlock was opened manually at 07:12:04, the callback from the local bridge was at 07:17:25, in which case the information from the WebAPI was available much faster.

If there was a way locally, as the app can do, to retrieve the log, that would probably be the only way to get reliable information with a delay in the sub 1 minute range.

Are there any beta firmwares from Bridge or Smartlock that could help in this area?

3

Besides the suggested solution with the access options like the app, another possible solution would be to fix the “sync hanger”.

Currently, the procedure is as follows:

The local bridge reports a callback, which is then stored in a database. A continuous worker runs in parallel and waits for such entries. This worker also remembers the last ID in the web API logs of Nuki for one hour. If the worker now detects a new entry, it looks at which log ID was current before the new entry and performs a sync until this last ID has changed to a new one. However, if you have just performed 2 actions in a row on the lock, the sync hangs and the update takes up to 2 minutes. For automatic shutdown of an alarm system after successful PIN entry, for example, absolutely unusable if you do not want to constantly shock the neighbors & operations center with false alarms.

In addition, unfortunately, you need a worker that permanently searches the weblogs in general for new entries that have not yet been made. Because like e.g. this morning the local callback was executed only after many minutes. Therefore each WebAPI log entry is stored again in a separate table with the LogID and an execution date of the worker (information to Telegram bsp). The two workers share a 2nd common table so that no info is sent / evaluated twice.

This 2nd worker will probably be omitted when my application for extended API access is granted, because then a callback would be performed. (Of course I don’t know yet how reliable they are).

4

:see_no_evil:

:see_no_evil:

There is a hard limit, but that does not really matter. What you are doing is abusing the APIs for something that needs a push (webhook or similar mechanism) with a much too short polling interval. Polling with intervals below 30s will only lead to problems.

IFTTT has a trigger for this which you can simply use to achieve what you want. Then there is the advanced API which can also issue webhooks. Apart from that a bridge can trigger a webhook when there is a state change. Polling the WebAPI afterwards can also solve the problem, but you need to give the system some time to update.

Triggering the sync of a Smart Lock through the API will drain the batteries of your Smart Lock in no time. This should never be used in a polling scheme.

5

Hi Jürgen,

thanks for your reply.

Unfortunately, neither IFTT nor fetching the WebAPI would solve my problem, as the timescales required by these systems are too unreliable and too long. Both are also dependent on the smartlock syncing correctly.

I need timely information when the lock has been opened, by whom it was opened. The whole thing has to happen in under 30 seconds.

If I rely on the information of the web API, 1-2 minutes can pass at least, sometimes you will find no update in the WebAPI and therefore in IFTTT until you manually trigger a sync.

The batteries are not relevant for me, then I just charge them more often, if necessary even 1x per day. A solution will be found for this.

The cleanest and most effective solution would be if I would receive such information locally, without first having to address an external cloud service or to receive a response from that same. This is not very efficient for smart homes. For this, however, the bridge would at least have to reveal more about the type of opening, e.g. was the door opened manually or by a user?

The connection to the cloud for information content can also have very confusing pitfalls, e.g. if I suddenly have more information on the web than locally. For example, I just triggered a door opening via the web API, which was also entered correctly there, but 20 minutes later I still have not received a callback from the local bridge.

It seems to me that Nuki is not designed to be used in a professional environment when combined with other systems. Which is a pity, because especially the use with Keypad just cries out to be implemented in combination with an alarm system.

Furthermore, I have noticed: When I open the door it should report unlatched and when I unlock it it should report unlocked - but both times it reports unlocked. I only get unlatched when I manually open it to the end with my hand on the lock. Is that the way it is supposed to be?

Even if I directly
{
“action”: 3,
“option”: 0
}

“unlatched” is executed but unlocked is reported in the local callback.