Turn on light in the evening when door opens

I want to turn on my livingroom lights as soon as a registered user opens the door in the evening.
I have managed to get this working (almost 100% perfect) by using IFTTT in combination with Apilio. The only problem I am still facing is when a leave my home at night, I first (manually) turn off all my lights and then I open the door (manually / not using the app). But this ofcourse activates the IFTTT when Nuki door opens triggers and this eventually leads to all my light being turned on. I would like to make a distinction between opening the door via the App (I always open my door via the App when entering my home). I never use the app for opening the door when I am in my house.
Looking at the Nuki webpage I see that this page shows when the door is opened by a registerd user. So the information I need is being broadcasted. Unfortunately the Nuki triggers within IFTTT do not make a distinction between any users and registerd users.
If this is posible using the Nuki API, could somebody tell me what is needed to get that working?

Currently there are 2 ways to make that happen with IFTTT:

  1. Create a new applet for every registered user (i.e. “If Geert unlocks door then switch on the light”, “If Geerts Wife unlocks door then switch on the lights”)
  2. Use the “If anybody comes home” trigger to switch on the lights. This will only fire when someone comes home with Auto-Unlock and therefore obviously does not work if you do not use Auto-Unlock at all.

Thank you for your answer. But the problem is Auto-unlock does not work for me because of the back-door entry problem (entering the house via the back-door also opens the front-door). And using the unlock option does not work because I do not lock my door before 10 pm. So when I come home in the dark at 7 pm I use the app to open my door (but as it is not locked) the unlock triggers will not be activated. It would work perfectly if a trigger ‘user X opened the door’ or ‘a registered user opened the door’ would exist. Are there plans to make such a new trigger in the near future?

Could this be realized by een API?

  1. The unlock action also fires when you unlatch. Should be fine if you use this one.
  2. The Smart Lock does not know who opens the door, therefore a trigger on a person is not possible.

I thought I had checked that the unlock trigger would not work in my case but I apparently made an error while checking this. Unlock, indeed, also triggers the open door trigger. But what exactly is the difference between the two? Is the open door trigger caused by the door sensor detecting that the door has been opened, and the unlock is triggered by the mechanisme turning the key?

Jurgen, you say that the smart lock does not know who opens the door. I guess you mean the smart lock does not know who MANUALLY opens the door. If I open the door using the App the smart-lock does know that I did that (or is it the bridge?) Anyway it would be perfect if IFTTT would make a distinction between ‘door opened manually’ and ‘door opened via App’. In that case it would be easy to program my lights switching on only when the ‘door open via App’ triggers was activated. In those rare cases that I would use my key when opening the door, I would not mind to turn on the lights myself.
As I would also like this ‘turning lights on’ to work for my Airbnb guests, the option op needing to add an extra IFTTT applet for every individual guest is not going to work. For that reason a distinction between ‘door opend via App’ and manually opend door is also required. Could you please consider adding those triggers in IFTTT?

I think I finally manged to get things working with the current set of triggers. For now please disregrard my wish for exrta triggers in IFTTT. Allthough I still think it would be preferable to split the unlock and unlatch trigger two separate triggers.

The Smart Lock has 2 sensors:

  1. Bolt position detection - Knows when the lock is locked, unlocked, unlatched
  2. Magnetic door sensor - Knows when the door is opened and closed

Unfortunately we (= Nuki, but also in natural language) call the “unlatch” command “Open Door”, which can lead to a bit of confusion with opening and walking through a door. The Smart Lock can not detect who went through a door, therefor the door sensor entries don’t have a name associated to it. For the lock sensor this is different and the Smart Lock can associate a name to a lock action if it has been performed by a registered client (e.g. iPhone App, Keypad, …).

I have been testing extensively and I am regularly seeing that when I open and close the door within the same minute, the order of the triggers in IFTTT sometimes gets mixed up. The close door trigger, comes before the door open trigger. This makes things a lot more complex. I now need to program delayed trigger actions. This is really very unnecessary and a lot of work. Could Nuki fix this problem?


@Juergen, I thought I had tested all possible scenarios but this morning a 6 am (while the night mode had locked my door) I noticed that when manually opening my door and leaving my house, the lights turned on again… The reason, the unlock trigger takes a ‘Who’ person as a parameter. I had set that to Anybody. So if an ‘unknown’ person unlocks the door the trigger will also fire. Because the ‘who’ parameter does not have an option for ‘Registered user’ I now have to create a separate trigger for every registered user. This is an unnecessary hassle. Could it be possible to add the ‘Registered User’ in the list? A registerd user in this case is every named user in the ‘Manage users’ list. Including all the automatically created users for AirBnb. This extra option does not replace the Anybody option. Anybody should also include the 'unknown / unregisted user. The Registered user option excludes the unknown/ unregistered person.

I get similar out of sequence problems with IFTTT applets controlling other devices, so I don’t think this is down to the lock. More likely something to do with IFTTT delays, which can vary quite a lot. My feeling is that IFTTT is not really suitable for sequences of commands which have to be executed in a particular order - only for simple triggers.

Hi Maritin, I have not used IFTTT other than with Nuki, so I was not aware that it might be caused by IFTTT. I did solve the problem by delaying the (in my case Close door) trigger using Apilio. Every time the Nuki lock triggers the Close door action, I use IFTTT to evaluate a Apilio Logiblock that waits 5 seconds before executing the action. The action then calls IFTTT again to execute what I initially wanted IFTTT to do whenever the door is closed.

Hi Geert. When you create an IFTTT applet it normally says that it should run “within a few seconds” of being triggered, but the help pages only commit to “within 15 minutes”. Presumably this is because there are two different services involved in every action, making timing unpredictable. My own experience is that even running the same applet twice in succession can give different delay times, so sequences of commands easily get out of order. There is a thing aimed at business users called IFTTT Platform which apparently allows more complex actions, but I’ve never used it - and presumably there is a charge. The best bet is to add an external delay as you have done.

I have they impression that IFTTT Platform is only for creating new services for IFTTT. Nuki probably used this to create the IFTTT triggers I have been using. So I think that using IFTTT platfom is not going to solve the trigger order problem. Or am I mistaken?

I just read this: https://platform.ifttt.com/docs/faq question: Why does IFTTT use a polling architecture? and question How often will IFTTT poll my server?

So I think Nuki is not using the Realtime API.

@Nuki, is that correct? Are you not using the Realtime API? If correct, can you start using it?