Hi, I am experiencing quite a large delay between the point the opener is first triggered (when someone rings the buzzer) and the point that IFTTT registers this and runs an applet to make my lights flash. The delay is commonly 45 minutes or even longer from the point the buzzer is pressed (in fact, I have never yet seen the applet run at the time the buzzer is pressed) - confirmed by review of Nuki Activity logs and IFTTT activity logs at https://ifttt.com/activity.
I don’t experience delays on any other applets with IFTTT. Does anyone know of a solution to this? I have already tried completely removing Nuki from IFTTT and re-setting up the applets again.
Thanks Jürgen. The Nuki Web log updates instantly (I just tested it there again to check) but nothing appears in the IFTTT activity log until much later.
I assume signing up for the beta will not help in this instance? Happy to give it a shot if there’s a possibility, but I’m open to any other ideas for troubleshooting you might be able to offer here.
Thanks again. Brief update, I went into the applet settings and manually pressed on the “Check Now” button. This immediately caused my lights to flash (as a previous notification from Nuki still hadn’t triggered) - but what is weird is that I have now pressed the buzzer a couple of times since then, and the IFTTT applet has run / lights have flashed within ~10-20 seconds of pressing the buzzer, which is a massive improvement.
It might just be coincidence and go back to longer delays later, I’ll keep an eye on it - but I’m optimistic as before now I have never had a Nuki applet run any faster than ~45 minute delay.
Edit* - just to add, I also enabled the “Get notifications when this connection is active” toggle at the same time I clicked “Check now”, so it could be either thing that’s bumped this applet into running properly. I’ve now tested multiple times, and it’s working with normal ring, ring to open, etc, without a problem. I’m really pleased, albeit baffled as to why doing any of this has changed things!
Just for completeness - the only other things I’d done in making this work were:
enabling the Nuki Web API
assigning a static IP address in the DHCP table of my router, to the Nuki Bridge
Don’t think either of those things caused IFTTT to start working, but just in case anyone has the same issue I was experiencing, worth including everything I did.
I’m having a similar issue. Also with the 45ish min delay. The weird thing is that the the trigger gets created at the time of entry (when I ring the bell) but doesn’t run untill 45 min later
See attachment
O.k., so it seems the delay is on passing the trigger to IFTTT. After next occurence of the trigger event, could you check if it immediatly shows up in Nuki Web?
The geofence is only running locally on the smartphone while the trigger for IFTTT is done via Nuki Web. So if you just enter/exit the geofence nothing on the Smart Lock itself should have changed as only the App starts scanning for the device via bluetooth (which will stop after leaving the geofence again).
Forget about IFTTT for a second. I’m saying that nuki web freezes when this happens (exit-enter-exit-enter geofence) and you can’t use nuki web for several minutes (spinning loader screenshots). THATS the bug (I assume if that’s fixed, then IFTTT will work as supposed)
Great. Thanks for letting me know and please keep me posted if it helps. I don’t think the problem is with IFTTT response time. It’s more the web app that is slow to send an update to IFTTT. I don’t have any other issues with any of my other IFTTT applets
there is now i difference as pro user . is give polling applets they guaranteed under 5 min activity . ( nuki use them ) and it give Realtime applets they run in a few seconds like my wascher , …
Sounds promising. The issue I see is the delay coming from Nuki web. If I log on there and manually press update there IFTTT get triggered within seconds after that. But sometimes Nuki web doesn’t update for a while (minutes or hours cause its “Stuck” - I assume some bug). I saw someone else talking about delays in their notifications, I assume its related to the same issue as mine since when I update the web I also get the missing notifications instantly (hope I’m making sense)
IFTTT always polls as a default and “realtime” is added on top of that. We are running on the Realtime API and are currently checking why IFTTT is showing it otherwise for the Applets. Experienced delays are an additional topic we are checking.
I think this issue relates to the delay of notifications - I saw another thread about that (about the bridge going into deep sleep). I’ve now enabled all notifications in my Nuki app (I used to have them disabled). That seems make the bridge (or Nuki web) to not get stuck or go into deep sleep, so both notifications and IFTTT gets triggered. The times where I haven’t gotten a notification, IFTTT haven’t worked either. If I then go to Nuki web and manually press “update now” I will instantly get the missing notifications from the app and IFTTT gets triggered right after that as well.
This might also be related to the issue, but often when I go to “manage Notifications” in the app it says I’ve been logged out, so I have to re-log in with my Nuki web account.
