I’m using the NUKI Pro 3.0 + Bridge to full satisfaction for over 6 months now. The smart lock is linked to Homey through the official app to trigger flows based on lock / unlock events. Think: lights on/off, arm/disarm security system, thermostat control, etc.
Lately I’ve noticed an significant delay in the relay of the event messages between the platform. For example: I’ve unlocked the NUKI through my phone and the lock responds within a second as designed. However, the “unlocked” trigger is send to NUKI Web (and thus Homey) with a delay anywhere between 30 seconds and 10 minutes. In my situation this triggers the burglar alarm which is pretty anoying. Based on my experience for the last month there no issue on “non peak moments” between 10:00 and 16:00 (response times <30 sec). Delays almost always occur between 17:00 - 19:00 on “peak times” when most people come home.
In my effort to troubleshoot the root cause I’ve found that the “unlock” event trigger is delayed between the NUKI lock / bridge and NUKI Web. When I log in to NUKI web after opening the door, the event is not listed and therefore no trigger is given to Homey. Checking back in after 10 minutes shows the event with a backdated timestamp. The Homey app shows the event listed with the actual timestamp, which is several minutes later. See screenshots below.
More people experiencing this problem? Any clues on how to fix it? Feels like it’s outside of my control due to a problem between the NUKI lock and NUKI Web. My best guess would be a throughput capacity problem somewhere in the platform, but I have no knowledge of the backend integration. All help is much appreciated.
Example: I’ve unlocked the lock on 17:25 and the event trigger was given to Homey on 17:29 (4 minute delay)
NUKI app listed as 17:25 seen directly after unlock (in-sync)
NUKI Web listed as 17:25, backdated timestamp - only visible after 10 min (out-of-sync, 4 min delay)
Homey app listed as 17:29 when event trigger was given to Homey (out-of-sync, 4 min)
Slack app showing triggering of unlock-flow on 17:29 (out-of-sync, 4 min)
Instal nuki direct… its local works perfect for me… latest version available on github : GitHub - pfreguia/nuki.homey: Your home has never been so smartly secured
Thanks, installed the local integration today and will check results this week. Both web and local integrations timestamps are written to a gsheet so will be able to generate some data on the delayed event messaging for the NUKI team.
Coming back to my previous post to share some of the collected data. I’ve logged all lock and unlock events over the period 28th of Feb to 13th of March (N=68). For each lock/unlock action both the local HTTP API eventdata and the NUKI WEB eventdata were written to a gsheet to analyse the differences.
- Average delay between HTTP API and NUKI WEB is 6.7 seconds
- There are major differences across the day. The average delay on non-peak hours (10:00 - 16:00) is just 2.3 seconds, while the average delay on peak-hours (16:00 - 20:00) is a whopping 17.7 seconds.
- The averages are skewed by major outliers of up to 60 seconds of delay. 80% of the datapoints shows a delay of <10 seconds (what I would consider acceptable), it’s the 20% of outliers that are the problem.
||Average delay (s)
|06:00 - 10:00
|10:00 - 16:00
|16:00 - 20:00
|20:00 - 06:00
I can confirm that I also suffer from a delay in receiving push notifications. And indeed it differs per part of the day
Firstly, apologies in the delay in getting back to you as I was on PTO. Thank you very much for the data, where the delay seems to be high during the peak hours. We need to dig deeper into this to find the issue. I will revert when I have more details on this. However, it is great that you could install an alternative app intermediately. Thanks.
I also have a problem with messages from Nuki Web to the Homey App since about 3 months. In my case, messages from the lock/bridge are visible in the Nuki Web App with a acceptable low delay.
The problem is mostly with events from the Nuki Door Sensor relayed from the Web App to Homey. Sometimes they get relayed with a large delay, sometimes they are missing completely on Homey side. I’ve also seen differences across the day. Lock/Unlock events are relayed without problems.
I‘ve also raised a ticket with Athom in January.
do you have an update regarding the delays?
I have sent you a private message requesting for more details.
I also see this delays very often.
Most of the time the delay is just a few seconds, which I think is normal behavior for a web service.
But sometimes it takes really long or log entries simply don’t show up on Nuki web until another log entry triggers the upload again (and both the new one and the old one show up together in Nuki Web, even that the old entry might happened already hours before).
My Lock is a 3.0 Pro, but I remember the same discussions from people with a 2.0 Lock and a Bridge from the time where I also used that hardware combination (maybe 2 or 3 years ago).
So my question is: Is this pretty normal, as this isn’t a paid subscription service and therefore compromises in reliability have to be accepted?
Or doesn’t it happen to a Nuki 2.0 + Bridge combination normally anymore, and it’s related to the low power Wifi implementation of the Nuki 3.0 Pro?
Real-time logs might also not be the main idea behind the web api, and might have been built more with the administration of smart lock credentials in mind.
But if the uploading of the logs doesn’t work reliable, it renders the IFTTT hooks pretty pointless, as they rely on them.
Any feedback welcome …