[BETA] Nuki Smart Lock 2.0 & 3.0

Hi Marco,

good news by Nuki's API dev. :slight_smile:



Good to know. The HPM is great.

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

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

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

Sorry to correct you: this is GREAT news! :smile:

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

1 Like

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

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

This is awesome Marco. You were really fast.

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

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

Thanks again for your work.

This is great to know!

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.

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

I'm glad you're liking it.

Thanks for the support and feedback.

Marco

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

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

1 Like

Looks perfect to me. :slight_smile:

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." :wink:

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

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

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

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

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

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

    image

  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

Hi @MarcusD, welcome back!

I could not reproduce the Hubitat Package Manager (HPM) error. I have a second HE hub which was with version 0.3.0 and updated it to 0.5.0 without any problem. Have you updated the HPM before updating my app/drivers?

This is the expected behaviour. The status (using the "progress" custom attribute) is only shown when requested and also it is not written at HE events database - it is just a transitory attribute.

I've created a fictitious version (0.5.1) to check your report of "damaged" RM rules after an update. Unfortunately I wasn't able to reproduce the error too. How have you manually updated the app/drivers? Did you overwrite the existing app/drivers or deleted and reinstalled them?

For you too (but I thing it's already Monday where you are ...).

Not at all - I'm who thank you and @alexdelprete for your willingness to test the app/drivers, and, last but not least, to give me back precious inputs!

Marco

Marcus, I cannot reproduce your issues here.

if I were you, I'd delete/uninstall NSL and reinstall it via HPM directly.

Let us know how it goes...

Hi @alexdelprete , Hi @maffpt

I had copied and pasted the new 0.5.0 app version and not deleted and re-installed (my bad!!!!). I will delete and re-install via HPM. Unfortunately I will not be home again and will not be for a while. and as I have to push the button on the bridge to re-install I can't do it remotely (VPN) either.

Also, if is really as Marco stated the stated "normal" for the status of the lock not to be updated to "locked" or unlocked" in the dashboard (or device driver) when the HE dashboard lock icon is used to lock or unlock the lock, then it makes no sense for me to use this integration as I cannot use the status of the door to force other actions within HE. I am surprised about this because it was working before and even now if I use the Nuki App or the physical button to lock/unlock the lock the status in changed ih the lock device created in Marco's NIKI Smart Lock 2.0 and the HE dashboard? Actually even if I use the GET HTTP commands to LOCK/UNLOCK/UNLATCH the lock via RM within Hubitat the status is updated so I will just use those. That way I also don't have got keep fixing my rules every time I update the the lock and opener driver:)

Cheers,
Marcus

Hi @MarcusD !

Sorry for taking so long for an answer.

Let's see:

I probably didn't understand your previous question. What I did answer was that at the device's page the "progress" attribute only shows the status when requested - the dashboard worked fine. Well, not so fine as I'd like, since no transitioning state (closing, opening) icon is shown at the tile, just the "unknown". I'm in debt on fine tuning the dashboard behaviour - however it's in the "to do list".

As I said before, updating the app/drivers does not invalidate the rules, since no app/device are reinstalled - just the code is updated.

I haven't be able to reproduce none of the behaviour you've reported. Neither our colleague @alexdelprete.

What I'd like to ask you - once more - is to start from the beginning. And the penalty if loosing - again, sorry - your RM rules.

I'm sorry for the inconvenience - please, do not abandon us! Your inputs are valuable.

Best

Marco

Hi, I am new to all this. Is it possible to use the Nuki keypad with the Hubitat Security Manager in any way or should I use a separate keypad for that? Any recommendations in that case on what works with your Nuki driver. Many thanks

@erik1,

When you say Hubitat Security Manager you mean Hubitat Safety Monitor or Hubitat Lock Manager?

Anyway, what I can tell you about Nuki environment is that the keypad it is not a device per se - it is used only to unlock the door, that's all.

With the app/drivers I've developed, the keypad is not configured as a device - Nuki's documentation does not provide any specific information about it. When a door is unlocked, the driver reports back to HE the event and no specific information on how it was triggered - nor keypad, nor manually, nor Nuki app - nothing - just that it happened.

If I'm not wrong, Nuki does not provide ways of recovering the key codes used with Hubitat Lock Manager - so, it seems that it is not compatible with it.

What specific use case you intend to use the Nuki Lock? Maybe I can help you with that.

Thanks @maffpt,
I like to be able to give out codes that I can later remove. Not everyone would like to download the Nuki app. It would have been easier to use Hubitat for everything but it might ending up being more complex to use the security manger and/or lock manager than using the Nuki app. Thanks

2 Likes