Much easier said than done! 
You would need an app with an endpoint, then a virtual device to send everything to.
Not the solution you're looking for, but I've done it using IFTTT.
A virtual lock on Hubitat (showing on dashboard) is being (un)locked when anyone (un)locks the Nuki.
I'm also locking my door via IFTTT because I couldn't get the API to work, but I will try this again, now that I've read this tread.
You lost me at endpoint 
Seriously all I need is to be able to read out the JSON response when I call the NUKI BRIDGE HTTP API ({"mode": 2, "state": 1, "stateName": "locked", "batteryCritical": false, "success": true} into a variable and them look for "unlocked" or "locked" in that variable within Hubitat.... Looks like I was close but Hubitat can only receive plain text and not JSON...
I have been using IFTTT to communicate with NUKI too. Works OK but not too reliable. I prefer to avoid IFTTT whenever possible.
I can help you with the implementation locking and unlocking of the NUKI Door Lock out of Hubitat if needed that part is pretty easy if you look look at the documentation the NUKI Bridge HTTP API (link posted above) You will need the NUKI bridge of course to implement this
Marcus
I'm reading MAKER API can do that, but that sounds like another beast to get to grips with
I forgot about Maker api
Yep, you might be able to do it with that. (it's basically an endpoint anyway)
Easiest way to try Maker api is create a virtual switch and have a play sending commands to that
Once you have done it a couple of times it's quite easy to work with
Installed a virtual switch and Maker API but I have no understanding of what I can or have to do in there to send a http command or force and answer from NUKI...
Okay, so I've tried locking and unlocking the door from Hubitat. It works, but it's working too wel! 
When I unlock the door it opens the door completely...
My intention is only to lock the door when Mode changes to Away or Sleeping and to unlock the door when Mode changes from Away or Sleeping. Not to open the door 
IFTTT unlocks the door without opening it... I guess I have some Googeling to do...
Greetings to NL
LOL .. Good job....
I ran into the same issue.
Via the NUKI App there are three options (LOCK, UNLOCK and OPEN which just "pushes" down the lever allowing you to enter the door from the outside (assuming you have no physical lever on the outside of the door. The OPEN function is only available when the door is UNLOCKED. When the door is Locked and you choose the UNLOCK in the app the door is unlocked AND the lever is pressed down so you can enter from the outside. I do not have a lever on the outside so that is ok for me, but the downside is that if you hit the button in the Unlock button in NUKI App by mistake your front door would be open I have the same issue you are describing and was not aware that via IFTTT you can unlock the door from the LOCKED state without the lever been pushed and the door opening?
I thought that would only happen if you have the settings in the NUKI APP set to an installation WITH a physical door handle on the outside of the door. Then the unlock always just unlocks the lock and locking just locks the lock.
Keep me posted if you find a solution
Marcus
If IFTTT can do an UNLOCK without opening the door when the door was locked there must me a call for that function... We just have to find it!!!
Great news.... app and drivers are coming soon....
1 Like
Got it! This will unlock the door, but not open it.
http://192.168.x.x:8080/lockAction?nukiId=xxxxxxxxx&deviceType=0&action=1&token=xxxxxx
action=1 unlock
action=2 lock
action=3 unlatch (open)
LOL I just found that in the API documentation too.....
Yeap works well......
Now we can wait and see if @maffpt will make the integration even nicer with his app and driver
1 Like
That's what I intend to do: nice ... 
Once I have a director that complained all the time because I simply did not, not even with HIS explicit instructions to do so, released something that I develop without doing it in a cool way, as nicest as possible, on inside and outside.
My justification? If I ever release something that it was not "nice" or "cool", nobody, nor even him, would believe that it was me who did it ...
He always was mad at me because of that ! But at the same time pleased ... He was more crazy than I am ...
For example, when I release the app/drivers for you guys test it, you'll see a lot - I mean a really really lot of debugging code inside the app/drivers code. That's because I've been so beaten by HE and Groovy that I had to do it. I'm used to develop things with an IDE (Integrated Development Environment) tool, and since HE does not provide it, but only a nice editor, I've been forced to go back at least 30 years in the past in terms of debugging code.
However, when I get to do the public release, there will be two different versions of the app/drivers: one clean and nice, without the debugging code, nice inside ... and another ugly 
one, full of debugging code.
Now you can understand why the director use to be regularly mad at me ... 
LOL.... Crazyness get's you a long way!
Without the support of people like you HE would be dead as a doorknob in the US and useless for most people semi seriously using HE in the EU due to lack of supported devices like locks, switches, thermostats, etc., etc.
Without people providing app/drivers for 3td party devices like SONOF (tasmota) and even the most common devices, TADO thermostats, NUKI Door locks, half of the stuff people are using would have to me controlled outside of HE with the original app.
Marcus
1 Like
Yeah, sometimes to a mental hospital far away from the civilization ... 
Thank you for your kind words. The existence of this community was a nice suprise - and a very welcome one - when I opted to use HE as one of the keystones of my technical strategy for my home automation busines. You know, when I finally move to Portugal IĀ“ll be retired and my pension will be in Brazilian Real and my expenses, guess what .. in Euros! I need to at least plan something to do that I like - I love IT - and make some money in the process. So far I have both the architect and the contractor that I hired to do the renovations at my apartment in Portugal that are very curious for what IĀ“m planning to do in my apartment.
Since IĀ“ll use the Nuki at the door of the apartment and there is no full suport for it yet at HE, IĀ“ve decided to start my journey into the "entrails" of HE with it.
Do you have any suggestion of device reasonably widely used in the UE that I should look into? Suggestions are welcome ...
My dream is get to a point where I get free devices from the manufacturers to integrate or simply use ... would be nice, donĀ“t you think? Hey, any manufacturer out there interested in a patronage? No strings attached, please!
Again talking about my apartment. With the total renovation that IĀ“m doing, I had the opportunity to rethink it to be fully automated. For example, there will be only 4 physical electrical switches - one for cut the power to all light bulbs and led strips (all Hue Philips), one to command the exaustor close to the shower, another for the exaustor close to the toilet - both with HE command in parallel - and another to command the lights above the sink. Everything else commanded either by voice (Alexa - Google sucks!), sensors or, on some cases, HUE dimmers and, on some cases, with all mixed up.
I have a lot of Sonoff/Tasmota devices. Great job from @markus with that.
Hey, a lot of Marco (myself) & Markus & Marcus here. Nice coincidence !
Marco (maffpt)
1 Like
What type of use cases are you thinking about specifically?
I have and using a HUE bridge and bulbs lights etc. That all works well in HE. I am using original Hue bulbs and some cheaper IKEA bulbs and IKEA Tradfri light controllers for lighting in the kitchen (within HUE) I'm renting but if I was im my own house I would want to be more flexible with LED light stripes and have access to cheaper (3rd party) LED strips (HUE is so overpriced) and would look into some other kind of RGB controller. I am using SONOS for my speakers in HE and TADO for my heating the I have running in HE with a custom driver from the community. NUKI of course you know about and a bunch of Sonoff/Tasmota switches for turning off stuff. Three Amazon devices for voice control which is another issue because a lot of device type do not show up in Hubitat using the HU Amazon Echo App. Like virtual Switch for example. This must me something related to Amazon.de as when I was in he US until last May they showed up fine. Unfortunately HE support can't help me there and Amazon says it should work....
@MarcusD, sorry for taking so long to answer your comment.
Yes, it is. IĀ“m well aware of it. However, otherwise requested by a potential customer, I intend to keep my lights within HUE realm - so far I have so many things to work with that IĀ“ve opted to keep the lights exclusivelly HUE. LetĀ“s see what the future reserves ...
Are your HUE lights handled directly by Alexa? IĀ“ve opted to control everything, including HUE lights through HE. This way I have a central log (HE log) of what is happening with the HUE lights. I know that I could control HUE lights both ways, but I prefer to keep the minimum intersystems connections as possible.
IĀ“ve just checked: there is no German Hubitat Alexa Skill. With the recently released version in Portuguese (Brazilian variant) everything works fine here.
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 with news.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
