[BETA] Nuki Smart Lock 2.0 & 3.0

Just sent them (forwarded them) again... I actually sent you two emails.
1 with the logs, the second with screenshots of the nuki bridge driver after installation in HE

Thanks,
Marcus

@Marcus,

Found your e-mail at my SPAM folder ... sorry

Version 0.1.1 released to address the detected bug.

Please try again and tell me how it goes.

Thanks,

Marco

Don't see it on Github yet..... Have you put it there?

Oh... Its the lock driver and the bridge driver you updated and not the app... I just found those....

Give me a sec to test.....

Your a genius!!!

Works like a charm......

@maffpt So how do you suggest I unlatch the lock out from the Hubitat Dashboard?

Right now the icon only offers me to UNLOCK (if LOCKED) or LOCK (if UNLOCKED) the door only. To physically open the door I need to "UNLATCH" the door, it would be nice to have that option in the ICON too. Not a big deal, or course I can just re-install the HTTP command like before and make a virtual button to execute the action.

@maffpt I created a virtual button for the button and wrote a rule in rule machine using the SEND GET HTTP command see screen shot....

Like I said Marco... This is really just a nice go have to be able to physically "unlatch" (open) the door and not just unlock it let somebody in via the Hubitat Dashboard.

If course you can always to this with the Nuki App anyway and in my case my lock will auto unlock (and unlatch) when I came home via the Nuki app anyway

It was not necessary to update the app, just the drivers.

To tell you the truth I did not see how it shows at the Dashboard. Still in TODO list.

Does not show as a Open button at the Dashboard? I've mapped the "unlatch" to the "open" operation, so it should be shown as a "open" button.

Of course it would be very nice! It did not show as a "Open" button at the Dashboard?

Let's see if we can avoid this. The "package" should cover all usual operations. Give me some more time to check it.

Now, about the Opener driver, it's still in the oven ...

Marco

The door lock shows in the dashboard as a standard lock. The status changes if you lock/unlock the door which is how it should be. But the door is definitely only locked and unlocked with the dashboard tile and not unlatched when UNLOCK is performed. This is fine for many people I am sure and probably for safety reasons better than always unlocking AND unlatching the door when UNLOCk is pressed on the dashboard as if the button is pressed when you are away by mistake your front Will be open all day. I would suggest a selection in the Door driver that allows you to select your preference of UNLOCKING or UNLATCHING the door when “UNLOCK” is selected on the dashboard.

Alternativly you would probably to have create a custom dashboard icon with the option of selecting LOCK, UNLOCK or UNLATCH withiin the dashboard icon.

Thanks for a job well done so far.... Looking forward to v. 1.2 etc.

Marcus

Interesting suggestion ... totally feasible. Included in the README.md at GitHub under the version 2.0 features.

This I confess that I don´t know how to do - yet ...

But I´m afraid that, based on my experience with HE environment and even Groovy (the programming language used do develop apps and drivers), it will take some time. This goes to version 3.0 ...

Marco

I like it when you like my suggestions :slight_smile:

I will just use my UNLATCH button on the Dashboard until v. 3.0 no worries

I think that's the whole idea of this community: colaboration.

A funny story: Once an user asked me if he could give me suggestions about a application we´ve developed. I told him, sure, of course. When he started to tell his suggestion, I interrupted him and complemented: but I can't assure you that we'll do what you want .... LOL

Jokes apart, receiving feedback is always positive. However, sometimes the suggestion is so particular that I can't see clearly much more people using it and I'm forced to say no.

That's not the case now. It's useful and, to be honest, not difficult to implement in code. Believe it or not, the hard part will be the documentation: the feature must be clearly documented to avoid misundestanding from the user since it envolves the security of a home/office.

Marco

I fully understand the concept of the community and users providing app or drivers or just plain advise to others. I have a technical background but am by no means a programmer so I feel that what I can contribute if limited to helping people test applications or pass on things that I have came up with that don’t need any programming like using the http get commands wth the NUKI api to get the lock working in Hubitat. I still just always feel that I am taking so much more than I am giving.

On a side note and slightly off topic, so maybe I should open a new thread, but what are your thoughts in regard to MQTT. I am thinking about setting up a Pi and playing with MQTT, as that would give me access to many Arduino and other devices that support MQTT. it seems that is all device level so fast, reliable and low power consumption.

Please don't underestimate your contribution ... all levels of tech expertise is important, even none! A non "contaminated" view is essential since the user probably won't assume nothing when using an app/product.

Please, again, don't underestimate your contribution. Everyone contributes, some more technically, others don't. But everybody helping things move forward is that matters.

I've read a little about MQTT and seems to be interesting. However, my current strategy is to focus on using HE as a main hub. Adding even a Raspberry (that, by the way, I own one) builds up complexity.

As an example of my approach, I'm focusing on Alexa as my voice control and my Philips HUE lights can be controlled directly by Alexa instead of HE. I've opted to control through HE, since this way I'll have a central log on where everything is recorded. This doesn't mean that this is the right choice, since if an option works, it works! But in my case, since I plan to provide home automation services, I need to define a path where I at least think that will cause me a little overhead as possible in the future. That's the same with MQTT - at least for now, I don't plan to use it.

I'm working on the Opener driver now - but since I'm in a period of my work schedule that is kind of heavy, I'll be back at it only on Tuesday.

Again, stay tuned!

Marco

Hi guys!

Just to keep you all up to date on what's going on over here.

Well, I began to develop the Opener driver and something hit me: if there are multiple locks and multiple Openers paired to the same bridge, how could I decide which Opener works with which lock? Nothing that some coding could not solve ... but at the cost of much more working hours and making the Integration not so straightforward as I want and as it is now.

However, I think that the usual use case is one bridge, at least one lock paired to it and, some times like in @MarcusD case, just one paired Opener. In this scenario, there'll be no doubt with Opener works with which lock, right? Right? :face_with_monocle:

So, this is I'm gonna do:

  • One lock + one optional Opener per bridge

    Only install the lock, or lock + Opener, if there is at most one of each. This way I can keep basically the same coding that I have now, by just implementing this limitation.

If in the future others users come with different scenarios, I'll handle it then.

Going back to the coding ...

Marco

Marco,

Thanks for the update.

I am not sure that I fully understand your concern or maybe I have generally misunderstood the use case of the opener.

I’m my case (and that is what I think is the general use case of the opener) the opener opens a separate door that is not in any way connected to the doors that are using the Nuki locks.

In my case (and by the way I have two Nuki locks but only have one installed) I have one Nuki Lock on the apartment door and use the opener (connected to the buzzer on the Seidel Intercom) system to buzz open the downstairs main entrance door to the apartment complex. The actions of opening the main entrance door OR my apartment door are not connected.

I don’t think you need to worry about how many locks or openers are being used in whatever combination on a single bridge at all.

As long as each Nuki Lock, Ooener, or key pad shows in Hubitat as a SINGLE device and allows the same functionality that is all anybody should need, right?

I mean the functionality like opening the lock when the opener is pressed would be programmed in the Nuki app anyway? As long as the correct status of the devices shows and is updated in HE like it does with the lock right now already, all is good.

Alternatively a HE user could program the actions on the Nuki App OR use rule machine to perform actions when a lock opens or the opener is pressed etc.

That would keep your coding task simple and give the user the choice of where to program the actions (Nuki App or Rule machine)

Marcus

Probably it's me who misunderstood the use case ...

That's the way it works? Through the Nuki app? I knew I've read it somewhere but when I've tried to check it reading the API documentation I could't find it.

So, API wise, since there is really no "relationship" between the lock and the Opener, I'll keep the logic as it is now.

Thanks for calling my attention on this!

That's was my original intention: just integrate the lock (and other devices) into the HE.

Thank you again !!

Marco

Hi Marco, happy Sundsy. How are things going in regard to the door opener integration, ready to test as soon as you are ready.

Regards,
Marcus

You too !

Slower than I wished for ... I'm already coding but I've entered a "sprint" at my job that isn't giving me time to dedicate time to coding. And to make things worse, this pandemic is making havoc to my nerves,

By the way, your input was very important. Thanks again.

Don't go away ... I'll be back soon with news.

Marco