New openHAB2 Binding for Nuki Smart Locks

Yes, you are right! Thanks for sharing this thread

@all I provided an alternative download URL - please see https://community.openhab.org/t/new-openhab2-binding-for-nuki-smart-locks/25940?u=mkatter

Progress! I can now lock and unlock via the Openhab Switch item, BUT a manual unlock or lock doesn’t update the item. As you are changing the way callback works is it better to wait for a later version and test some more?
This isn’t on a door yet so waiting isn’t a problem

Neither the Smart Lock nor the Binding will work correctly, if the Smart Lock is not mounted on a door!

I definitely recommend to mount and set up the Smart Lock and the the Nuki Bridge first. Then, if everything is working as expected, you should start with the next challenge: testing the Nuki Binding :slight_smile:

The binding .jar which I uploaded to Google Drive (link is in the first post) is the current development state and it works fine for me.

It was mounted on the door, so as far as Nuki is concerned all is normal :wink: It seems to store the lock and unlock position somewhere, so with care to not pull out the batteries it still thinks its on a door. I guess they didn’t want to stall the motor after every lock and unlock as it would kill the batteries.
I’ve got it working with the Google Drive version, but I think the callback server terminates once it has had a reply from the lock after a lock / unlock operation. This means it doesn’t catch an operation from the button. See the last but one line in the log I PM’d you. Is this the way it should work?

Correct, once the Smart Lock is calibrated you can “use” it also unmounted :slight_smile:

The Nuki Bridge is not posting its Lock State change to openHAB2.

  1. Did the Smart Lock unlock / lock when you toggled the Switch Item in the Sitemap?
  2. Did you also change the callback URI on the Nuki Bridge (to http://openHAB2ServerIP:8080/nuki/bcb)? It’s documented in the README.md in the shared Google Drive folder.

It turns out that the bridge hadn’t retained the callback, I have entered it again and it works.
I’ll keep an eye out for any updates and test again if it helps, otherwise I’ll wait for the released version. :joy:

OK, thanks for helping and the feedback!

Have fun with the Smart Lock, the Binding and openHAB2 :slight_smile:

1 Like

Great work - works perfectly for me as well. This was the right .things configuration-format for me:

Bridge nuki:bridge:NukiBridge1 [ IP="192.168.x.x", PORT=8080, APITOKEN="xxxxxx", CALLBACK_PORT=8081 ] { 
  Thing smartLock FrontDoorLock [ NUKIID="123456789" ]
}

Now here is my wishlist (it’s Easter period soon :slight_smile:):

  • Could you add support for pulling the latch?
  • Could you add a string item that reflects all states?
  • Could you add the “critical battery” information?

Thanks for your great work and keep it up! :slight_smile:

3 Likes

I’ve noticed that when I use the binding I get an error in the log, there is a slight delay between operating the test item and the lock operating, this doesn’t really upset the functionality. I only usually get the “takes more than 5000ms” errors around 4 times on booting from the RFXCOM binding

2017-04-06 08:44:18.388 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@f49244' takes more than 5000ms.
2017-04-06 08:44:18.393 [WARN ] [ome.core.thing.internal.ThingManager] - Handler for thing 'nuki:smartLock:NukiBridge1:FrontDoorLock' takes more than 5000ms for processing event
2017-04-06 08:45:04.661 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@f49244' takes more than 5000ms.
2017-04-06 08:45:04.667 [WARN ] [ome.core.thing.internal.ThingManager] - Handler for thing 'nuki:smartLock:NukiBridge1:FrontDoorLock' takes more than 5000ms for processing event
1 Like

@kevin @mkatter forgot to mention this. I see this errors as well.

@kevin @philKrylc
Thanks for the feedback. This issue is already written down on my internal issue tracker :slight_smile:

@philKrylc
Please use the latest Nuki Binding .jar (see first post). As I can see from the config you posted you are still using the outdated configuration!

Use the channel “smartLockUnlatchClose” to pull the latch.

I’ll think about this as the Nuki Bridge does not really send all of the available states.

I added this to my internal Feature Request list

Thx

1 Like

For issues and feature requests, please use the github issue tracker here:

So… there is no longer an internal issues tracker / internal feature request list :slight_smile:

Thx

@kevin @philKrylc
FYI - I just fixed the issue

takes more than 5000ms for processing event
2 Likes

Great to see your progress - I already love the binding. However, I don’t prefer the implementation of the mentioned channel. Why? Because, often I open (and unlatch) my locked door, but than I leave it unlocked (but closed). This channel would be in the state “ON” then. Now I cannot unlatch the door without locking it before unlatching it. This is just my personal opinion and behavior. Maybe it is a good solution to implement a string that can be used to send any command: Lock, Unlock, Unlatch?

Thanks a lot for your great work! Wishing you a pleasant weekend! :slight_smile:

You already got everything you need!

Just define an Switch Item depending on your door and a String Item for Command:

// Use Channel smartLockOpenClose if you have a handle
Switch Frontdoor_OpenClose 		"Frontdoor (Open / Close)"		<switch> { channel="nuki:smartLock:NB1:SL1:smartLockOpenClose" }
// Use Channel smartLockUnlatchClose if you have a knob
Switch Frontdoor_UnlatchClose	"Frontdoor (Unlatch / Close)"	<switch> { channel="nuki:smartLock:NB1:SL1:smartLockUnlatchClose" }
// Independently of the above, configure your String Item to send commands
String Nuki_Action 				"Nuki Action"					<lock>

Next, define your Sitemap as desired, e.g.

sitemap nuki label="Nuki Smart Lock" {
	Frame label="Switches" icon="lock" {
		Switch item=Frontdoor_OpenClose    label="Frontdoor (Open / Close)"
		Switch item=Frontdoor_UnlatchClose label="Frontdoor (Unlatch / Close)"
	}
	Frame label="Nuki Action" {
		Switch item=Nuki_Action mappings=[cmdOpen="Open", cmdUnlatch="Unlatch", cmdClose="Close"]
	}
}

Lastly, handle your desired command, e.g.

rule "Nuki Action"
when
	Item Nuki_Action received command
then 
	switch (receivedCommand) {
		case "cmdOpen":
			Frontdoor_OpenClose.sendCommand(OFF)
		case "cmdUnlatch":
			Frontdoor_UnlatchClose.sendCommand(OFF)
		case "cmdClose":
			Frontdoor_OpenClose.sendCommand(ON)
	}
	Nuki_Action.postUpdate(NULL)
end
2 Likes

Hi Markus,

I have now successfully added the binding. I configured the Things via PaperUI (you could add this option to your Readme).
As I am using Alexa to control several Switches within the house in my former manual setup for Nuki I set the OFF command to “lock” and ON command to “unlock” which allowed me to “Switch the house completely off” with only one spoken command leading to locking the door.
Now with the binding the Switch ON is hardwired to “lock” and OFF hardwired to “unlock”. Is there an easy way you could implement with the binding to define which way you want it to be handled?
Unfortunately ON or OFF does not properly match the status of a door lock neither does Alexa offer door lock commands currently.

But I think you understand the point from a voice command perspective when switching a house “off” where an unlock command sent to the lock does not match.
Maybe there is an easy work-around I currently don’t think off but maybe it is easy to be implemented with the Things definition to decide what switch state leads to what command.

Thanks for the good work and I also like the features on the feature list.

EDIT 1: Maybe I can make use of the described Nuki String Action by defining a “virtual” Switch Item (just have to figure out how) for Alexa to toggle this Switch.

EDIT 2: I got it to work. If anyone is interested:

// virtual Switch item to trigger a rule to reverse the commands for open/close to match Alexa ON/OFF actions
// goal is to have the door closed when command is sent to "switch off" Nuki or "the house"
Switch Nuki      				"Nuki "     			<door>	[ "Switchable" ] // tagging as Switchable is mandatory for Alexa to find the Item via Hue Emulation and have it toggled with ON/OFF commands
Switch Frontdoor_OpenClose      "Frontdoor Open/Close"  <door>	{ channel="nuki:smartLock:NB1:SL1:smartLockOpenClose" }
rule "Nuki reverse open/close"

when 
	Item Nuki received update
then
	if (Nuki.state == ON) {
		sendCommand(Frontdoor_OpenClose, OFF)
	}
	if (Nuki.state == OFF) {
		sendCommand(Frontdoor_OpenClose, ON)
	}
end

BR

Uwe

2 Likes

Hi Uwe,
that’s exactly how I would have done that - nice! :slight_smile:

Thanks for sharing!

CU

I think i will buy a nuki too.

Does anyone use the NUKI android bridge software instead of the nuki bridge?

Is this working the same way?

Can i use nuki and nuki bridge offline only in my house or will it always be connected to the cloud? I only want to use it inside my house connected only to openhab2 and not to the cloud. Is this possible or will nuki stop working?

I’ve been running the binding live for a few days now and its working well.
Thanks @mkatter for developing this

1 Like