Hi,
Can anybody tell me if this can be integrated with Hubitat or somebody is using it already?
It supports IFTTT so it should be possible?
Thanks!
Kind Regards,
Kevin
If it integrates with IFTTT, then technically you should be able to at least partially integrate it with Hubitat. However, getting the device directly integrated will be impossible as it's WiFi/BT only.
1 Like
Not quite true... they (NUKI) provide an API the lets enables you to perform pretty much every action over http commands, so you could technically use rule machine to control the doors. I am using mine with the native NUKI APP (auto open and lock when I leave and providing codes and entry for guests etc.) and just using IFTTT to set the HA Mode to AWAY and HOME when I leave or arrive home. Works so well that I actually never even took a serious look at the API as I am not a programmer.
Cheers,
Marcus
Soon there will be a HE Nuki app & drivers. I’m developing it right now.
Stay tuned! 
1 Like
Sounds good that will make it very simple... I assume your app will be using the NUKI BRIDGE HTTP API?
That would make it easy for anybody with a NUKI Bridge to get the lock integrated. If your app finds or asks for the bridge IP and finds or ask for the token key that would be pretty much all the user would need to enter into the app.
I will be willing to test anything you have, but I assume you have a NUKI yourself if you are working on an app and drivers.
Cheers from Germany,
Marcus
It's possible to integrate the bridge and devices like locks and openers directly in HE. I'm already doing it.
That's how I'm doing.
Yes, local communications. I only need to contact Nuki servers to obtain the IP of the bridge. From there it's only local, talking directly with the bridge. To discover the bridge, I'm afraid, contacting Nuki servers is inevitable, unless I found a way of detecting the bridge scanning the local network and, so far, I don't know if the HE environment even allows me to do that. I'm gonna look into it in version 3.0 ( 
).
Yes again. That's exactly what I'm doing. So far I can install multiple bridges and Nuki devices like locks in a single app's run, even reinstalling bridges and locks previously installed.
This delete/add might be a problem if the user has RM rules linked to the to be deleted devices. But the user has the possibility of not selecting a bridge - and its paired devices by consequence - to be reinstalled. To overcome this possible "damage" do RM rules in the case the user just want to add a new lock to an existing bridge, version 2.0 ( ) will be able of giving the user the possibility to opt to install only new devices.
That will be very welcome!
Recently I've participated in a discussion about documentation where it was argued that developers should not do the documentation on things they develop. I disagree with it - with discipline it can be made. However, testing is a thing that I believe - no, do not believe, I'm absolutely sure - that must be made by someone else besides the developer. I'm looking forward for your help to do tests yourself. Many thanks for the offer!
By the way, do you also happens to have a Nuki opener? Currently I don't have one - just the bridge, a single lock and a keypad. I plan do install an opener when I move from Brazil to Portugal, but if you have one I won't need to wait. If this nasty virus does not interfere with my plans, I should land in Portugal by January or April/2021, so, with someone doing the testing of the opener driver it would be possible to do it earlier than at those dates.
Stay tuned! 
Stay at home. Stay safe. Stay healthy. 
Greetings from Germany to Portugal!
Sound like what I have done without that a device and app by using the get http command in RM4 and sending Nuki the \lock and \unlock command plus device id and token via http. Works fine, I just can’t get the current status of the lock back into Hubitat because The info it’s returned as json and not plain test which can’t be handles by Hubitat. See this thread.
Anyway I have two locks (one installed) the bridge and the opener! (Denice id: 2) So I am reedy test any time you are:) If it works I can live with the install breaking the Rules as I would not need them anymore? Why would the rules stop working anyway if you are just installing an app and driver? My rules just contain the get http command and the url that would always remain unchained?
Marcus
Here's another one who is very excited about this project!
I do not have an Opener, but I do have the lock, the Bridge and a Fob.
Currently using IFTTT to:
- Lock the door when mode changes to Away or Sleeping.
- Unlock the door when mode changes from Away or Sleeping.
- When lock is unlocked by Fob, set virtual presence to on.
- When lock is locked by Fob, set virtual presence to off.
I'm not the sharpest knife in the drawer, but willing to help if I can...
I will be following this thread with great interest. Thank you for your work!
Yes, it's exactly the way I'm doing and, yes, it works fine.
I've never used (yet ...) RM to send HTTP requests. Please send me screen shots of how you build the request in RM. Let me see if I can get a glimpse of what's going on.
Just what I'll need: at least two locks! The code is supposed to handle 'n' locks and respective paired devices, but, to tell you the truth, code sometimes is wickedly mean and don't behave exactly the way it is supposed to do ... damn code! 
For sure I'd like you testing it.
Sure it will - I'm putting my reputation of 40+ years of experience in IT on it! Man usually beats the machine. And I'm sure this will not be one of the occasions when it happens otherwise.
When a device is created, no matter the way, manually or programmatically, the device gets a HE internal numerical id (you can see it on the left corner of the HE log screen). If you remove+add the same device, even with the same name, label, driver, etc, when you add the device again it gets a brand new HE numerical device id. However, RM and other apps internally refers to an installed devices through their internal numerical id, not their name - so that's why any reference - anywhere - for a device removed and then reinstalled - like my app does - will just remove all references of the replaced device all over HE.
This approach - using internally the numerical device id, instead of their "name" is the right way of doing it - well, at least the most efficient and safe one. This way the user can change the device name (i.e. the label) of the devices whenever he/she wants, without breaking anything.
As an example of this approach is the correct one, if a database uses your name as your id, not your employee registration number as they internally do, every time that's necessary, per example, correct your name that has been wrongly registered in the system, the poor system will have to change every reference wherever your id - your name - has been used. Databases can assure that the consistency of reference to you - your id - is obtained, but, imagine, if you have thousands and thousands of references to your name all over the company's databases, the simple act of changing your name - in this case, your employee id - will simply stop the database and all applications using it until the update is securely ended.
This is called 'referencial integrity' and it's exactly what HE does by eliminating all references to the device when it is removed - keeping 'referential integrity'.
So, to finish, internal id is the way of doing it, being employee id or device id.
In your case, you don't have devices configured in HE - just RM rules that talk directly with the devices via their APIs. In this case, there is no HE internal device id you are implicitly referencing to and your present rules will not be affected. Truth is, using my app/drivers and your RM rules as they are now, you'll be contacting the physical device (the bridge) in parallel. The only way they can clash with each other is sending conflicting commands to the bridge in parallel, at the same time, possibly making the bridge behaviour differently as expected. But that's how would be like two different persons commanding a dog to 'seat' & 'roll' at the same time - the poor dog may think by himself: what the heck this guys want me to do first?
A fob - great! Another device to work with ...
You all see, as of now, I can't assure that every Nuki device can be directly supported. I've read that when someone unlocks the door using the keypad for an example, there's no report via API of who's code (or fob) has been used, so not being possible to pinpoint exactly the person who supposedly unlocked the door. For me it's an important feature, since I think it's interesting - or even important - to know who unlocked the door.
Imagine a situation where your partner is with you and someone unlocks your door using your partner's keypad pin or key fob? Ok, it could be one of the members of your family using your partner's keypad pin instead of theirs, but this would be something undesirable and, in my opinion, even dangerous.
When the opportunity comes, I'll inspect the bridge's internal log if I can identify indirectly who's keypad pin or fob has been used. Hope this can be done 
If it is possible this way, I'll need to programmatically inspect the log ... at version 3.0 for sure
Every knife can cut my friend ...
Rest assured that I'll need help to do the tests!
I'm the one who thanks your 
and @MarcusD willingness to help!
Stay home. Stay safe, Stay healthy.
Let me take a few days to look into it.
1 Like
Yes @pietsnot and I finally found the third command (action 10 to unlock the door only (without opening, pushing down the door latch.
So practically 3 command needed...
action=1 UNLOCK (only)
action=2 LOCK
action=3 UNLOCK and UNLATCH (open)
This is becoming a joint Pan-European project, we should apply for funding by the EU in Brussel:)
So v.4.0 will have allow creating access codes and duration from within HE? My buddy programmed something back in the day that allowed you to send a text message (TWILO) to a number and then get an acces code valid from XX to XX to his garage. That was pretty handy.
Hi Guys!
Happy to see NUKI integration keeps rolling.
Can somebody please tell me where i can get the token from.
I will be also be happy to help testing and give feedback on bugs.
Thanks.
Kevin
https://api.nuki.io/discover/bridges will discover your bridge IP address.
{"bridges":[{"bridgeId":XXXXXXXXXXX,"ip":"192.168.XXX.XXX","port":8080,"dateUpdated":"2020-04-28T10:30:45Z"}],"errorCode":0}
http://192.168.XXX.XXX:8080/auth (after enter, press button on bridge within 30 seconds) will give you the token.
{"token": “XXXXXX”,"success": true}
If you get response {"success": false} try again (make sure to press button on Nuki Bridge within 30 seconds!)
The token is also available from within the Nuki app under device configuration and bridge
Hummm ... sounds interesting. Anyone with a contact in Brussels? 
I need to start keeping track of these version X features list ... I don´t want that someone accuse me of false advertising
Please tell me what you mean with that ... 
Hi everyone!
I thrilled to announce that the BETA version (v0.1) of the Nuki Integration app & drivers is available.
The app & drivers are available here: Nuki Smart Lock 2.0 for Hubitat Elevation
The app & drivers in this BETA release support a debug logging option that comes unselected by default. I recommend only activating the "debug logging" option when a problem is detected - it generates a lot, but really lot of debugging information that will fill the HE log with a lot of information that it is not necessary unless a problem is detected.
Hope to hear from you all soon.
Thanks for the suggestion of @ogiewon, I've opened a new thread regarding the support of the Nuki Smart Lock 2.0 in the HE environment,
Check the BETA version of the Integration app & drivers for the Nuki bridge and Nuki Smart Lock 2.0 HERE: Nuki Smart Lock 2.0 for Hubitat Elevation BETA.
Marco
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
