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".
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 !
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)
@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.
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...
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.
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.
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.
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.
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?
Yes I tried sending a notification on my phone each time the door opens.
I was thinking to use RM logic in order to condition the locking command to the status of the door: right now if you lock the door there's no checking of the status of the door, so if it is open, it locks it anyway. Many people requested this to Nuki, but we could actually improve this using your driver/app and RM. Or you could also embed this into the driver with a configurable option.
Mio amico italiano, you have great ideas! And this one is not difficult to implement.
That's I'm thinking to do:
Create, as per your suggestion, an option at the driver's interface to ignore or not the door locking command if the door is open
This way, the user may opt to do not have the door locked if it is open/ajar
Create a custom attribute at the lock's driver (commandIgnored) that will "tell" why the command (lock in this case) has been ignored (if it's the case)
This way, the user will be able to "detect" at the RM when the lock command is ignored and why; as an additional benefit, I may use the same custom attribute at other use-cases that may arise.
I'll start to look at it ASAP but first I'd like to know what you think about it.
It would be cool, following a lock command, to have Alexa say (via Echo Speaks voice message): "sorry, I could not lock the door because it is open."
With RM, if we can check that custom attribute, it's perfectly doable. And Nuki skill doesn't provide this level of functionality. That's what you can achieve when you have full control of devices and a great hub like HE. And obviously a good developer like you.