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.
I’ve enabled debug mode in the opener a couple of days ago (It was a suggestion in the thread about the opener going to deep sleep). Since then I didn’t have any issues with delays in notifications or IFTTT
Has this been fixed yet, according to the IFTTT app when setting up the trigger for the opener it says that you have set your trigger up using the polling rather than the realtime api (or that your realtime api implementation with IFTTT is not functioning correctly between yourselves and IFTTT on your server which has caused them to have to revert to their fallback of polling) which is obviously the source of the significant delay and makes the use of the “Doorbell Ring” IFTTT trigger all but useless as it can be anything upto an hour between polls from their end if you do not use the realtime api correctly and notify IFTTT that there are waiting events immediately before a natural fallback poll is performed by IFTTT.
