[BETA] Nuki Smart Lock 2.0 & 3.0

[MarcusD]

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:

1. What does Activate CM stand for?
2. 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?
3. 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

[maffpt]

@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

[MarcusD]

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

[maffpt]

Hi @MarcusD !

@MarcusD

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.

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.

@MarcusD

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)

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.

@MarcusD

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.

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 ...

@MarcusD

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)

After one of our conversations I understood the way the Opener works independently from the Lock.

@MarcusD

1. What does Activate CM stand for?

It stands for "Continuous Mode":

Note: image copied from here.

Meaning ... it's a RTO at large!

@MarcusD

2. 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?

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 !

@MarcusD

3. Under Current status I only see Battery 100 at first

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.

@MarcusD

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.

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

[alexdelprete]

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

[maffpt]

@alexdelprete

I just locked the Nuki through Alexa's Hubitat skill and your Nuki app/driver.

This is great!

@alexdelprete

it takes a couple of seconds more respect to Nuki's skill,

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.

@alexdelprete

After the door locked, actually while it was already locking it, Alexa answered with: "no response received".

This behaviour I've never witnessed. Does it happens repeatedly?

@alexdelprete

dev:7702020-06-14 01:43:09.680 infoPorta Casa Fiano: Status changed on this device to LOCKED. Battery status is NORMAL.

This message is logged when the bridge/lock reports back the successful of the operation. It's normal.

@alexdelprete

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)

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

[BETA] Hubitat Package Manager

Ok I think this is stable enough now to release as a beta. This is a package manager for Hubitat that makes installing and managing your apps and drivers easier. It allows you to install an app (for example Ecobee suite that has 13 apps and 2 drivers) with "one click" instead of having to do each one manually. It also automatically checks to see if new versions of anything installed using this app are available. As time goes on I hope more developers will come on board (if apps you use aren't su…

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

[alexdelprete]

I already use HPM since a couple of weeks, great app, and I updated your app through it some days ago.

@maffpt

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.

mmm...I'm using latest version, but I can still see the Ping function, on the Bridge, not on the door child device.

@maffpt

Going back to the Alexa's response, please let me know if it happens every time.

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?

[alexdelprete]

Hi Marco,

good news by Nuki's API dev.

Create callback for door sensor status in Bridge API

Bridge Beta FW 2.6.0 / 1.16.0 with door sensor state

[maffpt]

@alexdelprete

I already use HPM since a couple of weeks, great app, and I updated your app through it some days ago.

Good to know. The HPM is great.

@alexdelprete

mmm...I'm using latest version, but I can still see the Ping function, on the Bridge, not on the door child device.

My bad: I've mixed up where the ping was used ... but now it's corrected at version 0.3.3.

@alexdelprete

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,

Great! I was worried on how to debug that ... no need anymore!

@alexdelprete

Alexa's timeout for response expired?

Maybe communication between Bridge and Lock - I really don't know. Let's see if someone else gets the same problem - hope not ...

@alexdelprete

good news by Nuki's API dev.

Sorry to correct you: this is GREAT news!

I've requested to be enrolled in the beta program so I can start to support it. Luckily I have the Nuki door sensor.

Thanks to keep me informed.

Best

Marco

[alexdelprete]

No need to thank me. You are the dev, you are the one to thank, I can only support you for small things in order to give back something.

Thanks for your work. Let me know if you want me to test, I'm on beta list both for the nuki lock and the bridge.

[alexdelprete]

@maffpt

Version 0.4.0 - 2020-06-17
New feature: support for Nuki Bridge BETA firmware 2.6.0, where the door status (open, closed) is reported back when the Nuki door sensor is installed - It allows HE users to execute actions based on when the door is opened/closed (using the "Contact" capability)

Note : the Lock's driver will act accordingly with the user's Bridge firmware version: if 2.6.0 or later is installed, it will report door open/close events and only if the door sensor is installed and properly configured

This is awesome Marco. You were really fast.

I'll test it asap and report the feedback. Thanks a lot.

[alexdelprete]

It works perfectly, and it's also pretty fast. I receive a notification from HE every time the door opens/closes.

Thanks again for your work.

[maffpt]

@alexdelprete

It works perfectly

This is great to know!

@alexdelprete

and it's also pretty fast.

I've noticed that the feeedback from the Bridge is faster on FW 2.6.0. I'll do some additional tests to check it.

@alexdelprete

I receive a notification from HE every time the door opens/closes.

Have you tried to catch the open/close events at RM rules? I did some tests an it's working too.

@alexdelprete

Thanks again for your work.

I'm glad you're liking it.

Thanks for the support and feedback.

Marco

[alexdelprete]

@maffpt

Have you tried to catch the open/close events at RM rules? I did some tests an it's working too.

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.

[maffpt]

@alexdelprete

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.

Grazzie mille!

Marco

[alexdelprete]

Looks perfect to me.

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.

Grazie mille amico mio,

Alessandro

[alexdelprete]

I just tried latest version with the new feature: I told Alexa to lock the door, it's using Hubitat skill.

It works, it doesn't lock because it's open. After 30 seconds Alexa says: "sorry, the device doesn't answer."

If I try after I close it, it work as it usually does, after it closes Alexa says "the device is locked."

It would be cool if the answer to the first try would be: "the door is open, I won't lock it." but I don't know if it's something related to the skill or not.

Good job Marco.

[maffpt]

I've posted a support topic on how to report back to Alexa a failed command - let's see how we can do it.

I'll get back to you as soon as I - hopefully - get an answer.

Thanks for your support in testing it and for providing very useful insights.

Ciao.

Marco

[alexdelprete]

That's great. I didn't even know it was possible to provide a "return code" to Alexa.

No need to thank me, I thank you for all the work. If there's anything else you want me to test please let me know.

I'll play with RM as soon as I have some time and report back.

Ciao,

Alessandro

[MarcusD]

Ciao Marco and everyone else... Hoping all is well!

Finally got back home (briefly) and got a chance go push the bridge button and update the app and drivers of the bridge lock and opener to 0,5.0 (see you have been busy)

1. Gould not update via the update manager (see screen shot but updated manually... Even after manually installing the 0.5.0 app it thinks I am still using 0.3.0

   
   
   
   

2. Lock and Opener work but Status of Lock is not updated unless I hit the status button in the lock device driver?

Happy Sunday and thanks again for the great effort! Can’t wait for a version where I won’t need to re-write my rules after an update....

Marcus