Here we are ! Go for it @MarcusD !
Currently I'm just testing the driver installation. Commands to follow soon.
Note: The app/drivers still do not check for devices already installed with the same "Network ID"
Great news Marco,
I wish I could be ready but I had to go take care of my Grandmother and will not be at home for a few weeks to press the button on the bridge to give it a try:)
I will get someone to go and press the button for me and get back to you asap. I updated both the bridge and lock drivers, added the opener driver and updated the Nuki Lock 2.0 app...
What I did see ist that you are still mentioning to click the 'next' button during the installation (which doesn't exist:)) when you mean to click in the grey box where it says "click here to install"
Have a great weekend!
Hi @maffpt,
I have a Nuki Lock fw 2.7.21 with Nuki Bridge fw 2.5.2.
I installed your app 0.2 through Package Manager, everything went ok.
I added the user app, it discovered the bridge, I tried to install it, but as soon as I press the button on the bridge I have this error (the token is modified):
Error: No signature of method: user_app_maffpt_Nuki_Smart_Lock_2_0_Integration_194.logebug() is applicable for argument types: (org.codehaus.groovy.runtime.GStringImpl) values: [getBridgeToken: got response ([success:true, token:tjkuxx])] Possible solutions: logDebug(java.lang.Object), logInfo(java.lang.Object), logWarn(java.lang.Object)
I tried rebooting, and reinstalling the app but nothing helped. Any advice?
Thanks for the great job, hope to make it work. 
Alessandro
1 Like
My fault ... sorry
I've discovered this error yesterday but somehow I forgot to update it at GitHub ...
I've corrected it and updated the app for version 0.3.1 - Hubitat Package Manager should update it. Let me know.
Marco
1 Like
It worked perfectly. Thank you. 
Marco, in the status of the lock, can you also capture the status of the magnetic door sensor, to detect if the door is open or closed? I don't know if it's in Nuki's API, I hope so.
Another question: fob/keypads are managed only as events through the bridge right? Or do I need to see them in the device list?
Amazing job! I'll try with Alexa later so I can get rid of Nuki skill and make it work only on LAN.
I am not a programmer but as I had been using the API via the bridge before Marco provided the integration, I am pretty sure the Nuki magnetic contact sensor Is not handled through the API and hence cannot shown in the Hubitat dashboard. I never installed the Nuki magnetic contact sensor as I was already using a separate contact sensor (Xiaomi) to Monitor the door but of course now that thanks to @maffpt we have our Nuki lock integrated to HE we can use rule machine to set up actions when an external contact sensor reports open or closed.
I'll ask devs on Nuki forum if the magnetic sensor status is in the API and, if not, when will it be available.
I simply love the idea of HE managing my Nuki/door status. Now I can do several things I had in mind.
Thanks to Marco.
You're welcome !
I read that the door status can be obtained with the Nuki Web API (internet), however, for the current integration package I've been using a local API (HTTP API - local) to keep it aligned with Hubitat Elevation's philosophy as much as possible.
I have plans for the future (a distant future, to be honest) to prepare a totally different integration package exploring all the possibilities of the Web API.
Until then, you can use a different magnetic door sensor, like the one suggested by @MarcusD.
In my case I'll use a Fibaro one.
Thanks for the compliment !
It's working fine with Alexa. However you must find the correct action word for Alexa understand what you want.
In Brazilian Portuguese, e.g., we tend do use the "open/close" verbs (abrir/fechar in Portuguese) instead of "lock/unlock" (travar/destravar in Portuguese) to - wrongly - refer to lock/unlock doors.
If I've not guessed wrong, you are from Italy, and being it true, you'll need to use the corresponding Italian verbs. If you're really from Italy, please let me know witch Italian verbs Alexa understands to lock/unlock the door - I'm learning Italian myself and it would be interesting to know it. Neve miss a chance to learn !!
Right - the drivers let you know that the lock has been used, but with no knowing what triggered the action.
No, those devices are not directly controlled by the API.
There are feature requests/discussions going on ...
But so far no commitment from Nuki for this development, I suggest you post a comment there manifesting your interest in it - maybe someday they we can get their attention.
Thanks !
Marco
I'll have to wait then.
I like the fact that Nuki provides an internal sensor. On the door you only apply a small magnet, all the rest is in the Lock. I don't want to add a device that does the same thing the product does. But I understand the fact that you want to adhere to HE philosophy, that is the main reason I chose HE too.
I don't understand why you can check locked/unlocked status locally and the open/closed only via web. It's not consistent.
I know that since I first installed my Nuki Lock/Bridge: the Nuki skill didn't recognise my commands, the instructions on the skill were not correct. I wrote a post on Nuki forums when I found out you had to say lock instead of close (in italian).
I will. I'm in touch with one of the devs there via private messages for a problem I had. I'll see what he tells me.
Marco, thank you so much for your work, I really appreciate it. If you need an italian friend with wich you want to practice your italian, don't hesitate to contact me.
Ciao,
Alessandro
Me too - I also have the Nuki's magnet to use with their lock.
I don't understand it too. This is the reason of a lot of complains from people that would prefer a local solution instead of a web one only.
You don't need a Nuki Alexa Skill - just activate the Alexa Hubitat Skill, and in Italian !
Check it here: Alexa Hubitat Skill in Italian
Good luck for us ! The availability of this would open a lot of possibilities, like greeting the person who opened the door with light settings, music, even personally saluting him/her.
The pleasure is mine.
Thanks for the offer. Rest assured I will !
If this nasty coronavirus does not completely blow out my plans, I'll be heading in mid October to Agropoli (south of Salerno) to stay there from 3 to 6 months to get my Italian citizenship, enjoy the cuisine, the culture and, last but not least, consolidate my Italian - my grandfather was from that region and I'm very excited to be there and kind of "returning to the roots".
Ciao anche a te.
Marco
Here is the guy I'm in contact with, that wrote why it takes so long:
I know, was just telling you how I started, well before I had my HE.
I'm from Napoli. But I live in Rome since 20y.
Let's keep in touch.
Ciao,
Alessandro
I'm an IT professional myself and I can tell you that those security allegations doesn't apply in this case. We don't want to interfere with app/lock/bridge encrypted communications. We just want to receive an event at the bridge, generated at the lock, with information regarding who locked/unlocked the door.
I've been thinking about this problem and after releasing at least the version 1.0 I will check if mixing local & web resources I can make it work as we expect. I could, even, give the user the option to run local only or mixed, with added benefits of it. I'll keep everyone posted.
So, you are from Napoli hum? I can't wait to visit the world famous pizzerie di Napoli !
Marco
1 Like
I talked with the guy for some issues in the past, he's very skilled and has always been honest to me with his feedback, I tend to give him credit. If he says there are issues I believe him, nevertheless that leads me to think they chose a bad design/architecture to start with, and now they have to decide if they need to work around the problem or revisit the design. It happens. I'm in IT since many years, have seen lot of these cases.
Letting the users decide to enable the option to retrieve the open/closed status, warning that it requires access to the an internet web service I think it's a good compromise. We know that our philosophy here is to make everything work locally, but in this case, while waiting for the bridge api to offer that information, I think it's a good choice.
Go for it Marco.
P.S.: Napoli offers a lot more than the famous pizza, believe me.
OK.... I found someone to hit the button on the bridge and re-ran the app......
Of course all my rules are with the lock are gone as you warn about in the app and I saw that the click next has been updated to click to install
So let's get to the interesting part....
First things first... The Opener and lock were "re-found" and the Lock and Opener shown as devices in HE under Nuki Bridge.
From there on I am at a total loss as to what you are intending me to be able to do with this new Hubitat device inside Hubitat.
I was thinking that I would be able to make a virtual switch and then run a rule that "like in the Nuki App" activates the door opener (buzzer on the door) for the time set in the nuki app? (see video per email)
Like I said, correct me if I am wrong but the Nuki Opener is a totally separate device than the Nuki Lock and they are in no way connected (not even in in the Nuki App or API, I think at least) The Nuki Opener is physically connected to the house/apartment intercom system and all it does is activate the buzzer (push button) to let someone in at the downstairs front door. The idea if the RTO (Ring To Open) function if that when somebody rings the doorbell of the intercom system the buzzer (Nuki Opener) is activated and that person can enter the downstairs apartment door automatically. I think automatically opening the downstair apartment door as soon as somebody (any random person) rings my bell is a stupid idea and don't use that function. Again this is all about the downstairs door that is activated (opened) by the buzzer and has nothing to do with any doors that are using a Nuki 2.0 Locks!!!!
I looked at the options available in the device driver in HE and played around a little:
- What does Activate CM stand for?
- I see an Open and a Close. What is supposed to happen if you click on on or the other? Nothing happened when I click on "Open" or "Close" Are these buttons connected to the opener or to the Lock?
- Under Current status I only see Battery 100 at first, after a clicking on status if shows a bunch of stuff which I thing is related to the Nuki Lock and after I use the Nuki app to activate the opener and then click on status again I see some information that I guess is related to the Opener. (see Video I sent via mail)
Kind regards,
Marcus
@MarcusD, first I beg your pardon for the delay in my response.
I need to prepare a careful response to align what I did with what users like you expect from it. I'm back in a sprint at my job and I need a few days to do it. I ask for your patience with it. Probably by next monday I'll have it.
Meanwhile, I'd like to inform you that I've included the functionality of install and updating the app and drivers using the Hubitat Package Manager. It makes easyer to keep the app and drivers up to date.
Marco
Hey Marco...no need to beg for my pardon, this is just your hobby and you are doing it for us. You have a real job, take all the time you need, no hurry from my side.... I just wanted to get my feedback to you as soon as I could.
I will download the Hubitat Package Manager and be ready whenever you are...
Cheers,
Marcus
Hi @MarcusD !
Since I don't have (probably yet ... 
) an Opener, I just took a look at the Nuki Bridge HTTP API and implemented all states, commands and modes described there.
The "Open" tile shown in your video will ask for the Opener to strike the actuator at the door, meaning, opening the door.
The "Close" tile will deactivate the Ring to Open (RTO) and Continuous Mode (CM) at the Opener - see the explanation of what CM is later in this answer.
I couldn't agree with you more ... It scares me!
One situation where I think it could be useful is when you know someone you are waiting is about to arrive and you don't want the person to wait even a moment for you to command the unlatching of the door - like when it's raining. It would be a nice touch when the person you're waiting is your girlfriend, but I'd rather stay away from using it - if she doesn't know that it is available she won't miss it !
DISCLAIMER: sure I like to take good care of my girlfriend, but the risks involved could be great. And probably she has an umbrella with her anyway ...
After one of our conversations I understood the way the Opener works independently from the Lock.
It stands for "Continuous Mode":
Note: image copied from here.
Meaning ... it's a RTO at large!
Well, I'm ashamed to report that I forgot to implement the "open" and "close" methods ... shame, shame, shame
The "Open" and "Close" tiles are created by the HE environment when we declare that the device has the "doorControl" capability, which is the matching capability for the Opener. When clicked, they will call the corresponding method (open or close) that I completely forgot to implement ... shame again !
This is something that I don't like: Lock and Opener doesn't report the battery level in % as expected by HE - it's reported only as "battery critical" true or false. Not much to work with ... so, I did a judgement call and interpreted the "battery critical = false" as 100% level and "battery critical = true" as 5%. Best I can do for now.
The state shown initially will always be the current status of the device (Opener in this case). Since it has a battery, it's shown the battery status.
The state "doorControl" is the status reported by the Opener itself, the exact text reported from it is shown. If you fell curious about the possible values reported by the Opener, take a look at here.
The state "progress" is just a reporting status used by the driver to keep the user informed of what's going on.
The following sequence shows what happens at the "current states" area of the Lock driver interface when you ask the driver to unlock the door and no problem is detected:
- The state "progress" changes to " locking (waiting for Nuki bridge to finish operation)
It means that the lock command was sent to the Bridge/Lock and the driver is waiting for the operation to complete - at this moment you can see/hear the lock working - The state "lock" changes to "locking" to report what's going on
- The state "progress" changes to lock command successfully sent (waiting for Nuki Bridge confirmation)
It is shown to inform you that the command was sent to the Lock and the driver is waiting for the Lock/Bridge "formally" report the result - A few seconds later ...
- The state "lock" changes to "locked" when the Lock/Bridge finally reports the final status of the Lock
- The state "progress" changes to "locking successful" to report that everything worked as expected
So, I've implemented the missing methods, the "lock & unlatch" option as we discussed before and uploaded the driver to GitHub.
Thanks for your feedback !
Marco
Hi Marco (@maffpt),
I just locked the Nuki through Alexa's Hubitat skill and your Nuki app/driver.
The door locked correctly, it takes a couple of seconds more respect to Nuki's skill, but that's not a big deal. After the door locked, actually while it was already locking it, Alexa answered with: "no response received".
I checked Hubitat's logs and found this error:
dev:7702020-06-14 01:43:09.680 infoPorta Casa Fiano: Status changed on this device to LOCKED. Battery status is NORMAL.
dev:7692020-06-14 01:39:20.712 errorgroovy.lang.MissingMethodException: No signature of method: user_driver_maffpt_nuki_Nuki_Bridge_609.ping() is applicable for argument types: (java.util.HashMap, java.lang.Boolean) values: [[BridgeId:13XXXXX564, IP:10.1.10.23, Port:8080, Label:Nuki Bridge (13XXXXX564), ...], ...] Possible solutions: ping(), find(), run(), run(), any(), print(java.lang.Object) (ping)
Let me know if you need further info to track this one.
Thanks,
Alessandro
This is great!
Yes, there's a noticeable delay to the lock/bridge to report back to Hubitat about the lock status change.
The way the driver was developed, when it sends the lock/unlock command to the lock, it waits for the operation to complete. Then, it takes some seconds for the bridge/lock to report back to Hubitat the status change. You can follow this behaviour through the driver's interface. The driver reports that the command was successfully sent when the lock finishes the operation and it informs that it is waiting for confirmation. This confirmation comes few moments later. Probably this is the delay experienced at Alexa's interface.
This behaviour I've never witnessed. Does it happens repeatedly?
This message is logged when the bridge/lock reports back the successful of the operation. It's normal.
I can see that this log record happened a few minutes before, when probably you requested the execution of the Ping command at the driver's interface. The version you have installed has been replaced with a new one, where this command was removed. The Status command checks if the lock is connected, if it seems to be working alright and so on.
The latest version of the app/driver now has the option of using the
It's a brand new development created by one of the members of this community. With it the task of keeping your apps & drivers up to date gets simpler and much more efficient. I strongly suggest you to install the HPM. Once you've installed the HPM, just follow the instructions and get the newest app & drivers. And it comes with the benefit of, optionally, you can ask the HPM to notify you when new versions come up.
Going back to the Alexa's response, please let me know if it happens every time.
Marco
I already use HPM since a couple of weeks, great app, and I updated your app through it some days ago.
mmm...I'm using latest version, but I can still see the Ping function, on the Bridge, not on the door child device.
I've done 3 more tests: now it worked correctly, but I also noticed it was MUCH faster to respond this time. Could it be that the first time I tried, and I noticed the slowness, Alexa's timeout for response expired?
